The perfect Azure naming convention

Featured image

This post is the 2nd in the naming convention series. With this post I want to share approach to naming Azure resources. Why a naming convention is important is already covered by my previous post. However I do believe that some background is required to understand this approach. So, lets dig in.

Posts part of the naming convention series:

Naming convention background

A proper naming convention is one of the main methods for building and maintaining Cloud infrastructure as cattle and not as pets. Supporting the transition from the traditional approach of treating infrastructure as pets “unique snowflakes” with names and emotional attachments, to a Cloud native model whereby if a problem with infrastructure is found the infrastructure in question (or its configuration) is “simply” destroyed and replaced (infrastructure as code). This approach is a must to provision and manage the complex and rather large amount of components & configurations the current day Cloud resources are consisting of.
In addition Azure resource names are immutable (meaning that they cannot be changed after creation) and in some cases not reusable for a set period of time (purge protection). So it is crucial to name resources with longevity in mind and to avoid extensive rework and downtime in later stages.

Therefore the purpose of this this naming convention is to ensure resource names reflect a logical structure allowing for all kind of automation, scripting and Infrastructure as Code to find, read and process this complex and large amount of resources & configurations with as little and simple logic as possible. Ensuring proper performance, low effort maintainability and drift control.

Resource tagging, a naming conventions best friend

By prioritizing automation operators might get into trouble processing resources by their names. Therefore any naming convention should always be implemented in conjunction with a proper tagging strategy. Since most resources can be tagged with up to 50 resource tags which are mutable and are unlike the resource names not subjected to limiting naming rules and restrictions an operator is be able to filter, search, find and process resources based on their tags effortlessly (check out the following screenshot examples). Resulting in a best of both worlds scenario. And of course tagging is the first step to implementing cost management but thats a different story :).

Example: Filtering resources

Example: Search resources

Example: Visual summary view

Naming convention explained

This naming convention arranges components sizewise, starting with the largest possible relative component, and moving to an ever smaller component up to the point of the sub-resource (examples of sub-resources are noted below). The sub-resource is the smallest component for this naming convention. Practically this naming convention is very similar to the metric system.

Some sub-resource examples:

  • A network card part of a virtual machine
  • A disk part of a virtual machine
  • A managed identity of a resource

Note: As mentioned in the previous chapter the naming convention has longevity of resources in mind. Some resource types can be configured for fail over and be recovered in a different region then the original one. Therefore the region (location) of a resource is not included in the naming convention. In addition, the region of a resources has been quite present in almost all views and is one of the default properties of a resource object.

Because sizewise organizing of resources also ties into the order of Azure logical containers (management groups, subscriptions and resource groups) the sizewise order slightly changes depending on what is considered an environment. Is an environment defined by a subscription or a resource group? Or even a management group?

In the following image the sizewise approach is visualized with a subscription as an environment.


And in the next image an example is depicted of this approach. This example consists from a workload called Digital Solutions, with a production environment which contains a payment processing application that runs a virtual machine with a network card attached to it.


Lets go ahead and try to implement the sizewise approach, putting this example to practice.

Workload naming convention in practice

In addition to the sizewise approach I keep the following common guidelines in mind:

  • All words must be in lower case
  • With the exception of hyphens (-), spaces and special characters are not allowed
  • Where possible, kebab-case should be used. Hyphens can be removed for services where only alphanumeric characters are allowed e.g. Storage Accounts
  • Recommended abbreviations for Azure resource types should be used for the <service-name-suffix> and <sub-resource-name-suffix>

Subscriptions as environments

If a subscription is considered as an environment the sizewise naming convention should be as follows:



Workload name affix: ds - Digital Solutions
Environment: prd - Production environment
Application: ppa - Payment Processing Application
Resource type: vm - Virtual Machine
Instance number: 001 - First vm part of this environment

Using this information the result should look as follows:

ds-prd-ppa-vm001 (Virtual Machine #1)
ds-prd-ppa-vm001-nic001 (The 1st NIC belonging to VM#1)
ds-prd-ppa-vm001-nic002 (The 2nd NIC belonging to VM#2)
ds-prd-ppa-vm001-mi001 (User assigned Managed Identity belonging to VM#1)
ds-prd-ppa-vm001-dsk001 (The OS Disk belonging to VM#1)
ds-prd-ppa-vm001-dsk002 (The Data Disk belonging to VM#1)

Resource groups as environments

If a resource group is considered as and environment the sizewise naming convention should be as follows:



Workload name: ds - Digital Solutions
Application: ppa - Payment Processing Application
Environment: prd - Production environment
Resource type: vm - Virtual Machine
Instance number: 001 - First vm in this environment

Using this information the result should look as follows:

ds-ppa-prd-vm001 (Virtual Machine #1)
ds-ppa-prd-vm001-nic001 (The 1st NIC belonging to VM#1)
ds-ppa-prd-vm001-nic002 (The 2nd NIC belonging to VM#2)
ds-ppa-prd-vm001-mi001 (User assigned Managed Identity belonging to VM#1)
ds-ppa-prd-vm001-dsk001 (The OS Disk belonging to VM#1)
ds-ppa-prd-vm001-dsk002 (The Data Disk belonging to VM#1)

Environment Acronyms

To support the above elaborated naming convention the I have defined the following environment acronym’s. Currently I have limited these to the following two versions. A single letter and a 3 letter one.

Note: if other acronyms within the naming convention consist from more then 3 character the single letter acronym for the environment is advised.

Single letter:

E -> Experiment environment
D -> Development environment
T -> Test environment
A -> Acceptance environment
P -> Production environment

Three letter:

exp -> Experimental environment
dev -> Development environment
qua -> Quality Assurance environment
uat -> User Acceptance Testing environment
prd -> Production environment

You have probably noticed there isn’t a sandbox environment present here but its named Experimental. The reason for this difference is that I consider a sandbox environment as something that has been set-up temporary and/or for individual use and with only the required components while an experimental environment is a complete environment targeted to be used by multiple teams.

Closing statement and further reading

Thanks for reading this post, if you haven’t please check out previous post on this subject and I cant wait to share my next post of this series. If you are interested please check out following documentation from Microsoft on this topic.