Skip to content

Azure Resource Naming Conventions – What’s in a Name?

Naming conventions are one of the most dull and unflattering things about IT Operations, but a well-designed convention can make your life much easier and is a critical part of being able to set up a repeatable and extendable continuous delivery pipeline. At Sigao Studios, much of our work is in Azure, and when we set up a project, this is the naming convention we have found helpful for our Azure resources: 

[App Name]-{Optional Resource purpose}-[Resource Type]-[Environment] 

And for resource groups: 

[App Name]-[Environment]

There are countless opinions about naming conventions, but Azure imposes some real restrictions on resource names, and the convention we’ve chosen helps us in a few ways. One of the most typical constraints with Azure resources is that many need to be globally unique. Often, these resources have this constraint because they are assigned a public DNS name. Storage account, SQL Server, Cosmos DB, and Service Bus are a few resource types subject to this constraint, so it’s important to be able to come up with a naming convention that will make it easy to generate unique names. Using Pascal/Camel casing vs special characters as separators is one of the first choices you need to make with any naming convention, and the somewhat inconsistent rules about case sensitivity within Azure and various other tools and platforms make it simpler to just rely on hyphens as separators. You can potentially use underscores as a separator for some resource names, but underscores are not allowed in DNS, and therefore not allowed in many resource names as well. Hyphens, however, are allowed in most all resource names, with a few exceptions like storage accounts. 

[App Name]

We work on a variety of different apps for various clients and having a way to uniquely identify the resources involved with each is important. The primary way we do this by adding an app name prefix to all resources. Because of the length constraints imposed by some Azure resources, it’s good to make this as short as possible, usually an acronym or abbreviation for the project. Putting this as the prefix makes it easy to group together all the related resources for a project when viewing large lists of sorted resources.

{Optional Resource purpose}

For simpler applications, we don’t always use the resource purpose descriptor, but when utilizing something like a service fabric cluster that is composed of multiple Azure resources, adding this descriptor can help identify which resources are tightly coupled together, and help remove some of noise in a resource group by clustering these resources together when sorting. In the case of a service fabric cluster, this would just be a small abbreviation like ‘sf’. This can also be useful if you have multiple resources of the same type and need an extra descriptor to differentiate them like ‘management’.

[Resource Type]

While including the resource type is not strictly necessary to satisfy uniqueness constraints (you can have a storage account and web app with the same name, for example), including it makes quick visual identification easier in large lists of resources, and places where you might not have easy access to the resource type metadata.

[Environment]

This is one of the most important components as far as automation is concerned. We use Azure Resource Manager templates to create all our resources, and we always have a template parameter for environment name. We use this to dynamically calculate resource names, allowing us to easily re-use the same template for multiple environments. We then configure the environment name as a variable in our Azure DevOps release pipelines, so that we can pass it in to the resource template and use it to configure other variables that vary in each environment by the environment name. This means deploying out a new environment can be as simple as creating a new environment in the Azure DevOps pipeline, and then pressing go.

Resource Groups

Some users prefer to put an ‘RG’ or similar phrase into the resource group name, like the resource type convention, but resource groups are rarely listed alongside anything other than resource groups, so we leave that bit out. 

Naming conventions are somewhat personal and situational, so this convention may not work exactly for you, but it has proven useful for us with a variety of applications.