One thing I continuously see is a discrepancy on how to name Azure resources. I’ve seen such usage as just ‘Program1’ and have that name for every service type associated with ‘Program1’. I’ve seen rg-program1-app, where app is substituted for the different service types. Such as rg-program1-ai for Application Insights.

Professionally and personally I don’t agree with either one of these. A good naming standard should give you all the basic information such as what type of resource it is, where it is located geographically and what environment. In addition a good naming standard should not have any conflicts with other resources in different regions and/or environments.

Now Microsoft has there own recommendations. Essentially the recommendation is :

seriviceAbbreviation-Application-Environment

This looks great at first pass but is flawed in terms of talking about having resources being geo redundant. If we follow these standards and have an App Service in East Us\S and another one in West US we’d run into a DNS conflict and am unable to publish. Now if you dig into the documentation a little further it denotes it as adding -001 and -002 to the app service name. In addition there are caveats for globally available resources.

My suggestion is the following format for a naming convention:

serviceAbberviation-Application-Environment-RegionAbbreviation

So we’d end up with something like wapp-Application1-dev-eus. For global resources we’d substitute ‘gbl’. The reason being is all of our locations would be three characters and align to a standard. We’d also make the environment three characters. By doing so we can make our lives easier in terms of automating deployment and future functionality by assuming certain placement of characters.

Also this trickles up to how we’d place our resources in a resource group. All resources that are globally available would be set in a resource group named:

rg-Application1-dev-gbl

Now, globally isn’t ‘technically’ an available region but by labeling it as such we are letting our admins and everyone know that global resources will go in here. Regional objects like App Services would go in something like:

rg-Application1-dev-eus

This will help in our deployments as our deployments are now being boxed in by region. This leads to a higher transportability of our deployments.

For ways to automate a resource naming standard at deployment check out my post Using Arm to Automate Azure Naming Standards

At the end of the day organizations may determine their own naming standards; however, the important piece and/or takeaway is you MUST have a naming standard and MUST have it as close as day 1 as possible.