“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.
Environment Identifier – The environments I use are:
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.
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.
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:
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.
contoso-dev-app-01-01App Service for Web App
contoso-dev-app-02-01App Service for Web Api
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
contoso-dev-app-01-02App Service for Web App
contoso-dev-app-02-02App Service for Web Api
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.
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!?!? 😃