Posted inAzure / Governance

The power and importance of a good Azure naming convention


When companies start experimenting with the Azure cloud, the often start by going to the portal and just configure the resources they need from the portal. This is done most often without any governance on the Azure landscape. The power and danger of having this kind of power within the click of a button will create a lot of value quickly, and will hit organizations back in a later stage when the Azure landscape is starting to grow.

A lot of the things that are being messed up in the beginning can be correctly easily afterwards. By going to the portal, updating the Infra as Code templates or by Azure Policies most settings can be corrected at scale. However, some things can’t be changed without doing a migration of the data. One of these things that can’t be changed without a redeployment is the naming of a resources.

What is a naming convention?

According to Wikipedia, a naming convention is defined as follow: A naming convention is a convention (generally agreed scheme) for naming things. And in that definition the challenge is directly described: Generally agreed scheme. Because who is going to define the scheme in the organization, and once agreed who is going to enforce and monitor the naming convention.

Some notes from the field

In order to apply a successful naming convention in Azure, I’ll share some experience from the field.

Step 1: Understand the goal of the naming convention

Naming convention is there for a reason. In order to come to the best naming convention you need to understand the value that it’s adding. For me there are multiple reason, but the most important one is that I like automation. I’ve worked for large organization where we needed to maintain and deploy Azure resources for hundreds of developers. And to do this efficiently you want to automate everything to the max. Needing to ask: How would you like to name it? is then becoming a time consuming exercise. Mostly because people will come with different suggestions like: Myteamsstorage account, or johndoest.

Next to that it looks more professional, and it can help in structing the environment regarding to ownership and cost. There are more (and maybe even better) ways to do so, like tagging, but it sure can help.

Important to mention is that the goal can vary per organization. In a big dynamic organization, you want to automate everything and therefor need naming convention. But for small organizations it might be that you use the naming convention for identification of the resources, and automation is not that important (yet).

Step 2: Assign a owner

Naming convention is part of Governance, and governance for me starts always with one thing: Who is the owner? The reason behind this is that there will be a moment, a point in time that the naming convention does not work. This is not a question if it will happen, but when. And when it happens, someone need to decide. This decision you want to have centralized because it might have impact on the whole organization.

Step 3: Identify the key pieces of information

This part is crucial to define the naming convention. What information do I need in my resources? And maybe equally important, which information do I not want in my resources. This is different of every organization and there is in my opinion not a golden truth. But there are some things to consider when doing this.

First thing to consider is: Can the information be changed? For example, if you assign a team name to the resource, is there a change that the ownership of the resource will be transferred to another team? If the answer on the question Can the information be changed is yes, it should not be in the naming convention but in tags.

Second thing is, which kind of information do I want to share in the naming convention. For example, do you want to include the organization name (or an abbreviation) in the resource? This is sometimes useful when multiple organizations use the same tenant and it also helps in making the naming unique. The naming of Azure resources must be unique per region or sometimes even globally. And therefore adding a company abbreviation can be useful.

The Microsoft official documentation1 has some suggestions on which components to add. My advise is to not follow this blindly. It depends per use case, per organization and there is no golden truth.

Some things should in my opinion always be there. These are:

  • Resource type
  • Environment (dev, test, acceptance, production etc. )
  • Index number

Third thing, the order of the convention. In other words, what do you put first, second, third etc. This can be helpful to group resources based on the naming convention. The Microsoft example puts resource type in front. However, that means that resources are being grouped on type, not on use case/solution. So think what the naming convention will do the sorting, and if that is the way you want it.

Fourth thing is if you want a readable naming convention, or consistency. Some resources like a storage account can only have numbers and letters. Naming conventions with a dash will then not work for all resources. I personally like consistency, and therefor use always use naming conventions which are applicable for all Azure resources. This decreases the readability, but my personal advise is to use tags for identification of the resources, not the naming convention. The various rules for naming per resources can be found here: Resource naming restrictions – Azure Resource Manager | Microsoft Learn

Step 4: Documentation

Once you defined the naming convention, it’s important to document this properly. Especially in the beginning when enforcing is not in place. With documentation you can communicate and educate the organization. Make sure you document the rationale, so that in later stage it is still clear why things are the way they are.

Step 5: Enforcement

Last but not least, the enforcement of the policy. It does not matter how good your define your strategy, how good you document and how good you communicate. People will use different names, period. Therefore it’s important that enforcement is in place. When automation is in place, you can do this in code like terraform & bicep. However this might not cover all use cases. Therefor it’s advices to write azure policies to enforce this.


A naming convention is in my opinion mandatory to set-up a good, professional Azure environment (and other environments off course). It is important to understand how naming works in Azure and define the goal and what you want to have in your naming convention. Without enforcement naming convention is basically useless. But when used properly it can be a very useful way to have your automation to the max.


To come to this blog, I’ve used the following sources, used some of the code as inspiration and altered it when I felt that it was required:

  1. Define your naming convention – Cloud Adoption Framework | Microsoft Learn ↩︎

My name is Remco Hooijer, and I’m an Azure Cloud Solution Architect with over 15 years of experience in the IT industry. I’ve worked with a wide range of clients and projects, from small startups to large enterprises, helping them to design, implement, and optimize their cloud solutions.

As a Microsoft Certified Trainer, I’m passionate about sharing my knowledge and expertise with others. I believe that education and training are essential to staying up-to-date with the latest technologies and best practices, and I love helping others to develop their skills and achieve their goals.

Whether you’re looking to migrate to the cloud, optimize your existing infrastructure, or develop new applications and services, I’m here to help. With my extensive experience in Azure and other cloud technologies, I can provide expert guidance and support to help you achieve your business objectives.

Leave a Reply

Your email address will not be published. Required fields are marked *