Azure Naming Conventions – Think First, or You’ll Be Stuck

In the Azure cloud environment, many computing resources and asset types can be created to build-up an operational environment to support business needs. These include computers, networks, databases, queues, IP addresses, etc. All Azure resources have one thing in common – they must be given a name when being created. It’s a very good idea to develop a naming convention for resources prior to creating them.

Why Naming Conventions?

For anyone who’s worked with computers, and especially for those who write software, naming conventions are a well-known topic and best practice. A good naming convention – using abbreviations or upper/lower case for example – can improve maintainability, reduce human errors, and lower training complexity. The reason is rather simple, actually – the name assists in identifying the intended use of something, and possibly a categorization. For example, a SQL Server storage procedure might be called sp_Calculate_Salestax, where “sp” indicates that the object is a stored procedure (useful when seeing a long list of items; it’ll also cause like items to sort together in a display), and it performs a sales tax calculation. Without ever seeing the source code or having to reverse-analyze it, one can discern what the object is, and what it does. The underscores and initial capitalization make the name easier to read quickly.

A significant factor in Azure resource naming is that once a name is chosen at creation-time, it cannot be changed. The closest approximation of changing a name is to create an identical new resource with the preferred name, then delete the old one. That’s fine if you’ve just created the resource, but if you’ve got 100 of them and they’re interlinked, it’s essentially impossible. You’re stuck with the “wrong” name indefinitely. That’s why adopting a convention before creating resources is a really, really good idea.

Azure Silly Naming

Azure’s a bit funny when it comes to names, however. Some resource names can include punctuation, some can include mixed-case, and others cannot. There doesn’t seem to be any rhyme or reason – it’s really up to the specific resource being created. Therefore, it’s impossible to create one naming convention and use it consistently throughout Azure. Name length limits are also variable, dependent upon resource type, from 24 to 1024 characters. Microsoft’s documentation shows 23 different naming rules for the various Azure resources (see link, below), and you can expect this list to grow as new services are added.

One factor that influences allowable name syntax is whether the resource is internet-facing with a DNS name, or not. The internet’s naming rules have been around a long time and are very set, so it’s reasonable that internet-facing resources must comply with DNS naming requirements. Azure takes this a little further, disallowing some valid DNS syntaxes in certain contexts.

The following image shows a valid internet DNS name (jimmy-azure.core.windows.net) being rejected by Azure for a storage account.

DNS name rejection by Azure

But here’s a similar name, accepted for a Function App (jimmy-azure.azurewebsites.net).

DNS name acceptance by Azure

Automatic Names

There’s also a resource naming oddity I’ll mention in particular. When creating a Function App and specifying the Consumption Plan, Azure will make a special version of an App Plan on your behalf (with a unique icon) and set the name based upon deployment region. In the East US datacenter, Consumption App Plans will all be named EastUSPlan, a duplicate name which you cannot change. You won’t be able to distinguish which plan goes with which Function App. Internally, the identifier for each App Plan is unique, so Azure won’t confuse them, but your administrator won’t easily be able to understand which is which, and specific associations to Function Apps.

Here are 2 Consumption App Plans with duplicate names, created and named automatically during provisioning of a Function App.

Duplicate App Service Plan names

In another example, provisioning an Azure AD Domain Service also caused the creation of a virtual network with associated NICs, address, and load balancer. Note the last 4 items' names - something Azure itself assigned, and which cannot be changed.

Azure-assigned resource names

Tags

Resources also can have multiple tags associated with them. A tag is just a free-form short textual name/value pair. This allows you to locate resources according to your tagging strategy, regardless of the resource type or name. While not exactly a “name”, tags are an alternative way to label and manage Azure resources, using whatever tag-naming convention you wish and applicable across all Azure resources.

Here, a tag “applicationType : web” is used to locate resources, which are show in the right blade.

Application tags

Naming Best-Practice Suggestions

OK, taking into account the above peculiarities, what’s an Azure architect or admin supposed to do when choosing a resource naming convention? Are there any suggestions?

Sort-of. Microsoft has published an article with good details on exactly this topic. They document the naming restrictions mentioned above, per resource type. Azure resource names should be composites, formed segment-by-segment from meaningful short strings.

Consider these name components to form a name. Use the minimum number of components to clearly identify a resource within a larger Azure environment; avoid using redundant components that don’t add identification value. Abbreviate name segments to 2 or 3 characters at most, to insure the final name won’t be too long. When allowed, hyphenate the segments for easier reading. Consider excluding your company’s organization names, since re-orgs can occur, and companies merge or acquire other companies; thus this class of names is not necessarily durable.

• Company name (internet-facing only)
• Division name
• Resource location (East, West, etc.)
• Azure resource type (Storage, SQL, Virtual Machine, etc.)
• Technical function (Web server, DB server, domain controller, etc.)
• Serial / sequence 

Naming Samples

Resource Name	Description
RG-Math	Resource group for math functions. Visible internally only, can contain resources in multiple regions.
JA-AS-Math-Sqrt	App Service (web app) that provides a math function for square roots for Jimmy Azure company. Region doesn’t matter. Name is visible on the internet as http://as-math-sqrt.azurewebsites.net. Using a company prefix is a good idea here, since this name must be globally unique within azurewebsites.net.
ASP-Math	App Service Plan (PaaS VM scale unit) underlying the math app service. Must be in same region as app service, but doesn’t matter which region that is. Visible internally only.
VN-East-Sql	Virtual network in East region, intended to hold SQL Server. Network isn’t directly visible on the internet; that’s the job of a public IP address.
GW-East-Sql	Gateway attached to the virtual network for SQL in the East region.
JA-FN-Math-Sine	Function App for company Jimmy Azure, for a math function that calculates Sines. Visible on the internet as https://ja-fn-math-sine.azurewebsites.net.
jasaeastsql01	Company Jimmy Azure, Storage Account intended for SQL Server in the East region, number 01. Visible on the internet. Has more restrictive character requirements. Accessible at jasaeastsql01.core.windows.net and must be unique in core.windows.net.
JA-Srch-Docs01	Company Jimmy Azure, Search engine for documents, visible on the internet at https://ja-srch-docs01.search.windows.net. Region doesn’t matter.

  

References

• Microsoft general naming suggestions and restrictions.
• Microsoft Storage naming
• Microsoft Queue naming
• Microsoft Table naming
• Microsoft video starting with naming suggestions