Azure Architecture Series #12 — Resource Naming Standards That Survive Three Years

Business Challenge

A platform team ratifies a naming convention in week one, before anything is deployed. It is a good one, close to what Microsoft itself recommends: type, workload, environment, region, instance, separated by hyphens. rg-retail-prod-weu-001. It goes into the Bicep modules, the pull request template and the wiki, and for the first month everything named through it comes out identical and readable.

Three things then happen, in this order, and each one is a different kind of failure.

Week five. The first storage account. st-retail-prod-weu-001 is rejected before it reaches a resource group: storage account names allow lowercase letters and numbers, and nothing else. The hyphen is not a style preference the platform is willing to accommodate. Somebody strips the delimiters for that one resource type, the deployment succeeds, and the convention now has an exception in it — documented nowhere except in the module that needed it.

Month nine. The business unit called Retail is folded into a division with a different name. Four hundred resources still say retail, and there is no rename operation on any of them.

Year three. A new workload is called Excel Export, and the deployment stops on something nobody has seen before:

Code=ReservedResourceName;
Message=The resource name <resource-name> or a part of the name is a
trademarked or reserved word.

Architecture

A naming convention is usually written as a style guide — a sentence with angle brackets in it, agreed in a meeting. It is more useful to read it as a schema, because that is what Resource Manager treats it as. The platform validates every name against a per-type schema at create time, the schema differs by resource type, and the field it validates is one you can almost never change afterwards.

Scope decides what a collision costs

Microsoft documents three scope levels for naming purposes, and the resource rules table adds two more that matter to a platform team.

• Global — unique across all of Azure. This applies to PaaS resources with public IP endpoints, because the name becomes the initial default public DNS name. Storage accounts, key vaults, container registries, web apps and SQL servers are all here.
• Tenant — management group IDs.
• Subscription — resource groups.
• Resource group — virtual machines, virtual networks, network security groups, NICs, public IPs, disks. Two resource groups can hold identically named resources without conflict.
• Parent resource — subnets inside a virtual network, databases inside a SQL server, containers inside a storage account, rules inside an NSG.

The practical consequence is that a globally scoped name is being competed for by every other Azure customer, and a convention that reads beautifully in a document can simply be unavailable. stretailprod001 is a name several thousand organisations might plausibly want. The lower the scope, the more the convention is a matter of taste; at global scope it is a matter of what is left.

Scope also decides the blast radius of getting it wrong. A duplicated subnet name is caught by the deployment that creates it. A storage account name that turns out to be taken is caught in the same place, but the fix is different: you cannot resolve it by putting the resource somewhere else, only by changing the name.

The character rules are a schema, not a house style

The per-type rules are where a single convention quietly becomes several. A few of the ranges, from the same table:

Two rows of that table are enough to fork a convention. Storage accounts and container registries reject the hyphen, so either every name in the estate drops the delimiter, or the estate carries two families of name and every script that parses one has to know which it is holding. Microsoft states the trade-off plainly: use a hyphen for readability, but not every resource allows a delimiter, and if you need absolute consistency across all your Azure resource names, do not use one.

The virtual machine row hides a second name entirely. A VM has a resource name and a host name, the portal uses the same value for both when you create one, and the 1-15 Windows limit is the host name restriction — the resource name itself can run to 64 characters. A convention that assumes 15 characters everywhere for VMs is constraining the wrong field; one that assumes 64 will produce Windows machines that cannot be created.

The 24-character budget

Storage accounts and key vaults both cap at 24 characters, and because a convention is only worth having if it is the same everywhere, that cap is effectively the estate's budget. It is smaller than it looks once the components are laid out.

Take the recommended components — type, workload, environment, region, instance. A two-character type abbreviation, prod, a three-letter region code and a three-digit instance number spend twelve characters between them: 24 − 2 − 4 − 3 − 3 = 12. Twelve characters are left for the only component a human actually reads to identify the thing. Spell the region out as westeurope instead and the arithmetic becomes 24 − 2 − 10 − 4 − 3, leaving five.

This is why Microsoft maintains a published abbreviation list — rg, vnet, snet, nsg, vm, st, kv, cr, mg — and it is why the same list is worth adopting verbatim rather than inventing a local one. The abbreviations are not there to look tidy. They are there because the budget does not stretch.

It is also the first place to ask whether a component belongs in the name at all. Environment and region are both stable facts, so they qualify on the permanence test below — but they cost seven of twenty-four characters to encode, and both are available from the resource's own properties and from a tag. A component earns its place in the name when something reads the name to find it: a person scanning a portal list, a script matching a prefix, a policy denying a pattern. If nothing does, it is paying rent.

Reserved words, and the check that happens whether you need it or not

Resources with an accessible endpoint cannot use reserved words or trademarks in the name, and the name is checked when the resource is created even if the endpoint is not currently enabled. That last clause is what makes this an architecture problem rather than a curiosity: a private, internal, no-public-access deployment is still validated against the list.

The list runs to around forty entries and reads like a product catalogue — ACCESS, AZURE, BING, EXCEL, EXCHANGE, OFFICE, OFFICE365, ONEDRIVE, OUTLOOK, SHAREPOINT, SKYPE, VISIO, XBOX. Two entries are stricter than the rest: MICROSOFT and WINDOWS are blocked as a whole word or as a substring anywhere in the name. One is weaker: LOGIN is blocked only at the start.

An estate that names resources after the applications they serve will meet this eventually, because the applications organisations run are frequently named after the products they integrate with. It is worth putting the list into whatever validates names before a deployment reaches Azure, so the failure happens in a pull request rather than half way through an apply.

Why This Architecture Holds Up

Applying that test to the usual components is uncomfortable, because the ones that fail it hardest are the ones people most want to encode.

What "cannot be renamed" costs in practice

There is no rename operation on most resource types, so the real question is what the workaround costs. Moving a resource is the closest thing available, and moving is not renaming — it changes the resource's ID, not its name.

That is its own bill. Microsoft's instruction after a move is to find every place the resource ID appears — custom dashboards, scripts, templates — and change it. During the move, both the source and destination resource groups are locked, and that lock can last up to four hours, during which nothing in either group can be created, deleted or updated. Any active role assignment on the moved resource does not travel with it: it becomes orphaned and has to be created again on the other side. And a single move operation returns an error immediately above 800 resources.

Resource groups are worse, because they have no escape at all. You cannot move a resource group to a new subscription — you can only move all of its resources into a resource group that already exists in the target subscription, and tags, role assignments and policies do not transfer with them. A resource group name is therefore the most permanent string in the estate: it cannot be renamed, and the group itself cannot be relocated.

Key Architecture Decisions

Enforcing it, before the estate is large enough to need enforcing

A convention that is only in a wiki is a convention that holds for as long as the people who wrote it are reviewing pull requests. Azure Policy evaluates the resource name field directly, and a deny effect on a name pattern is one of the few controls that works before the resource exists, which is the only moment at which the name is still changeable.

{
  "if": {
    "allOf": [
      { "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
      { "not": { "field": "name", "match": "st??????????????###" } }
    ]
  },
  "then": { "effect": "deny" }
}

The pattern language is small and worth knowing exactly. like takes a wildcard * and the value must not carry more than one of them. match is a positional template: # matches a digit, ? matches a letter, . matches any character, and every other character matches itself. match and notMatch are case-sensitive — alone among the string conditions, which are all case-insensitive — so a rule that means to require lowercase should use match, and a rule that does not care should use matchInsensitively. There is also a fullName field, which returns the name prepended by its parents (myServer/myDatabase), for rules about child resources.

Closing Thought

The interesting question about a naming convention is not what it looks like. It is which of its components are claims about the world that could stop being true, and what happens to the estate when one of them does. Every component is a bet that a fact will outlive the resource, settled in a field with no update operation.

That is why the convention that survives three years is usually the plainer one. It carries the type, because the type never changes; something durable about what the thing is; and a number, because numbers do not go out of date. Everything else — owner, cost centre, project, criticality, the name of the team that built it — sits in tags, where changing it is a write rather than a migration. A shorter name looks like it is saying less. It is saying only the part that will still be true.

Official Azure Reference

• Naming rules and restrictions for Azure resources
• Define your naming convention
• Abbreviation recommendations for Azure resources
• Resolve reserved resource name errors
• Move Azure resources to a new resource group or subscription
• Details of the policy definition structure: policy rules
• Azure subscription and service limits, quotas, and constraints