Adventures in Azure: Naming Conventions

“There are only two hard things in Computer Science: cache invalidation and naming things.”

Phil Karlton

When it comes to naming resources I always somewhat follow the guidance recommended at Recommended naming and tagging conventions – Cloud Adoption Framework | Microsoft Docs.

Personally, I put more emphasis on tagging than naming, the tags can support more meaningful information.

When naming my Azure resources I am looking for two things: consistency and organization.

By consistency, I want an easy to follow naming conventions.

I want a name for a resource to take seconds to identity as opposed to minutes and sometimes hours.

By organization, I want related Azure resources to appear in proximity to each other when viewing a list of Azure resources in the Azure portal, e.g. for an app service, I want the monitoring resource to be below it in the list.

How do I name my Azure resources?

My naming convention consists of the following segments, some required, others optional:

Company/Product Identifier – Few characters, maybe 8 at most, an abbreviation for the company and/or product.

This ensures that resources that generate endpoints have unique endpoints, e.g. mjr-100 or contoso.

Environment Identifier – The environments I use are:

  • dev for Develop
  • stg for Staging
  • prd for Production

Resource Identifier – The name of the resource, in this case, I use the recommendations at Recommended naming and tagging conventions – Cloud Adoption Framework | Microsoft Docs.

Application Identifier – Numerical representation of the application, I use a two digit number, e.g. 01 or 02.

Instance Identifier – Numerical representation of the instance, sometimes I have one instance in eastus region and another in westus region, again, I use a two digit number, e.g. 01 or 02.

Sub Resource Identifier – The name of the resource that is associated to the parent resource, e.g. app insights or storage account instance, again, I use the recommendations at Recommended naming and tagging conventions – Cloud Adoption Framework | Microsoft Docs.

What does this look like in practice?

Let’s take a sample company, Contoso, my Azure resources would look like:

Shared

  • contoso-dev-rg Resource Group
  • contoso-dev-log Log Analytics
  • contosodevkv Key Vault
  • contosodevst Storage
  • contoso-dev-cosmos Cosmos

Couple of things to note.

These are shared resource group resources.

Storage accounts can only consist of letters and numbers, see Resource naming restrictions – Azure Resource Manager | Microsoft Docs, so no dashes allowed.

While Key Vault does allow dashes, it is limited in length to 3-24 characters, see Resource naming restrictions – Azure Resource Manager | Microsoft Docs, so I just remove all the dashes, to save a few characters.

All the naming rules can be found at Resource naming restrictions – Azure Resource Manager | Microsoft Docs.

East US

  • contoso-dev-plan-01 App Plan
  • contoso-dev-app-01-01 App Service for Web App
  • contoso-dev-app-01-01-appi App Insights
  • contosodevapp01kv Key Vault
  • contosodevapp01st Storage
  • contoso-dev-app-02-01 App Service for Web Api
  • contoso-dev-app-02-01-appi App Insights
  • contosodevapp02st Storage
  • contosodevapp02kv Key Vault

My standard practice is every App Service gets it’s own App Insights, Key Vault and Storage Account.

Both the Web App and Web Api reside on the same App Plan deployed in the eastus region.

West US

  • contoso-dev-plan-02 App Plan
  • contoso-dev-app-01-02 App Service for Web App
  • contoso-dev-app-01-02-appi App Insights
  • contoso-dev-app-02-02 App Service for Web Api
  • contoso-dev-app-02-02-appi App Insights

The Web App and Web Api use the same Key Vault and Storage Account in the eastus region because they have high availability already built-in, no real need to have them in two different regions.

Whatever your naming or tagging standards, I would encourage you to document them and share them with your team, could save them countless hours coming up with names and prevent bad naming conventions from being introduced.

If you have your own naming conventions, please share! I am always looking for better ideas and insights.

God bless!

Update

To ditch the dashes or not? I keep going back and forth on this one? Why am I so attached to those dashes? If I didn’t have them, then Storage and Key Vault would not be an exception.

Somebody help me get over this hump!?!? 😃

1 Reply to “Adventures in Azure: Naming Conventions”

  1. Matt, I fully agree with the need for consistency and organization. In fact, the way you identify your resources has to be standardized. Tags can be used as well and together with standardized naming. I think my article about enforcing naming standard using Azure Policy and deploy it with Azure DevOps Pipelines is a good addition to your article:
    http://bit.ly/az-simple-naming

    BTW: After reading the MS docs I use dashes as well if applicable. You can use dashes in Key Vault’s name.

Leave a Reply

Your email address will not be published. Required fields are marked *