“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 Developstg
for Stagingprd
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 Groupcontoso-dev-log
Log Analyticscontosodevkv
Key Vaultcontosodevst
Storagecontoso-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 Plancontoso-dev-app-01-01
App Service for Web Appcontoso-dev-app-01-01-appi
App Insightscontosodevapp01kv
Key Vaultcontosodevapp01st
Storagecontoso-dev-app-02-01
App Service for Web Apicontoso-dev-app-02-01-appi
App Insightscontosodevapp02st
Storagecontosodevapp02kv
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 Plancontoso-dev-app-01-02
App Service for Web Appcontoso-dev-app-01-02-appi
App Insightscontoso-dev-app-02-02
App Service for Web Apicontoso-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!?!? 😃
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.