
“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:
devfor Developstgfor Stagingprdfor 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-rgResource Groupcontoso-dev-logLog AnalyticscontosodevkvKey VaultcontosodevstStoragecontoso-dev-cosmosCosmos
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-01App Plancontoso-dev-app-01-01App Service for Web Appcontoso-dev-app-01-01-appiApp Insightscontosodevapp01kvKey Vaultcontosodevapp01stStoragecontoso-dev-app-02-01App Service for Web Apicontoso-dev-app-02-01-appiApp Insightscontosodevapp02stStoragecontosodevapp02kvKey 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-02App Plancontoso-dev-app-01-02App Service for Web Appcontoso-dev-app-01-02-appiApp Insightscontoso-dev-app-02-02App Service for Web Apicontoso-dev-app-02-02-appiApp 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!?!? 😃
Discover more from Matt Ruma
Subscribe to get the latest posts sent to your email.

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.