The perfect Azure naming convention

This post is the 2nd in the naming convention series . With this post I want to share my 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.

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

Technically this naming convention arranges components sizewise but to simply visualize it the components are arranged in the form of a stacking doll, a.k.a a Matroska . Therefore I like to call this the Matroska approach.


Starting with the biggest component, and moving to an ever smaller one. Up to the point of the sub-resource (examples of sub-resources are noted below) as 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
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 organizing of resources in a Matroska manner also ties into the order of Azure logical containers (management groups, subscriptions and resource groups) the actual order slightly changes depending on what is considered an environment. Is an environment defined as a subscription or as a resource group? Or in some cases even as a management group?

This is how the Matroska naming convention would look like when a subscription defines an environment.

Matroska with a subscription as an environment

The following image show an implemented example of this approach. It consists from a workload called Digital Solutions, with a production environment which contains a payment processing application that runs a virtual machine that has a network interface.

Example of a Matroska with a subscription as an environment

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

Workload naming convention in practice

In addition to the Matroska 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 Matroska naming convention should be as follows:



Resource groups as environments

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



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.

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

Single letter:

Three letter:

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.