One of the most difficult things in IT is naming things. The same goes for choosing the correct naming convention to use when naming cloud resources in Microsoft Azure. Sure, you can name things pretty much anything you want, but if you’re not careful you’ll end up with a jumbled mess of mismatched resource names that don’t make sense. Before you begin creating resources in Azure, it’s important that you decide on a naming convention for those resources. This is especially true since you can’t rename Azure resources after they are created; without deleting and recreating them.

Why is an Azure naming convention important?

Standardizing on a naming convention for your Azure resources is extremely important. You don’t want your Azure Subscription to be a jumbled mess of resources with no indication of what each is for, what department is responsible.

There are several reasons it’s important to standardize on a good naming convention:

• Azure Resource names need to be unique within Azure and within your specific Azure Subscription.
• Admins and others need to be able to easily sort and filter Azure Resources when working without the risk of ambiguity confusing them.
• Resource organization is more than just putting resources in Resource Groups. Naming goes a really long way towards increasing the level of organization in Azure.
• Resource use and purpose must be clearly indicated to avoid interference and unintentional downtime.

There are multiple scope levels of uniqueness required for naming Azure Resources. For example, you might need to make sure the Azure Resource names are unique across all of Azure or just your Azure Subscription.

Here are the different scope levels for naming Azure Resources:

• Global – This scope requires Azure resource names to be unique across all of Azure. This means that the resource name can only be used by a single Azure customer, regardless of their Azure Subscription or Azure Region. Some examples of this are PaaS (Platform as a Service) resource types like Azure App Service since the resource name results in the same name being used for a DNS endpoint for the service.
• Azure Subscription – Within a single Azure Subscription each Azure Resource Group name must be unique. Since Azure Resource Groups are used for organizing resources within a single Subscription, the naming uniqueness requirement is only scoped to that particular Azure Subscription.
• Resource Group – Certain Resource Types must have unique names within a particular Azure Resource Group. An example of this scope is the Virtual Network (VNet) resource type that must have unique names in a Resource Group since the name is used for routing within the Resource Group.
• Resource Attribute – Within a specific Azure Resource, depending on the Resource Type, there are certain attributes or sub-resources within the parent-resource that must have unique names within the scope of just that particular Azure Resource. An example of this is with Subnets within a Virtual Network, these must each have a unique name within the VNet, but you can use the same Subnet naming pattern across multiple different VNets.

Overall, with all the different scope levels for Azure Resources, it’s still best to have a naming convention that provides both uniqueness and consistency across the different naming scopes. At least, across Global, Azure Subscription, and Resource Group scope levels. These names will display in Resource lists within the Azure Portal, or generated through the command-line tools (Azure CLI or PowerShell) and will reduce ambiguity of duplicate names being used.

Should Resource Type be in the Name?

There is some debate as to whether an abbreviation of the Azure Resource Type in the name of the resource. After all, the Resource Type is metadata that tells what the resource is, so why is the resource type abbreviation needed? Well, there are times when you have just resource names, or IT professionals not the most familiar with Azure, so you may want to include the resource type abbreviation in the name.

Most organizations adopt a naming convention that includes the Resource Type abbreviation in the resource names. This allows you to see what the resource type is in the name, and to easily search for resources by name and explicitly find the resource type you’re looking for. It also helps alleviate ambiguity when you may have multiple resources with the same name that are of different resource types. Say, what do you do when someone says to delete a resource, but you find multiple with the same name?

With Azure Resource name restrictions that limit the length of resource names, an additional 3 or 4 characters for the resource type in the name can be wasteful. This is especially true with Azure Storage Accounts which have one of the most limiting naming restrictions. If you waste precious characters on the Resource Type abbreviation in the name, then you may need to shorten the workload or use purpose part of the name. This can also limit your ability to ensure the uniqueness of the resource names within your organization.

Overall, after the debating, it’s more common for organizations to adopt a naming convention that includes a Resource Type abbreviation in the resource names. This is even something that is recommended in Azure Resource naming best practices suggested by Microsoft.

Naming Components and Separator Character

When deciding on a naming convention to standardize on, there are several different naming components to keep in mind. Some will likely always be necessary in almost all naming conventions, while others may not apply to your specific case or organization. Deciding on the final naming convention will depend on which of these naming components you require.

Here are the most common naming components to keep in mind when coming up with a naming convention:

Naming Component	Description
Azure Region	The Azure Region where the resource is deployed.Such as East US 2 or Central US. An example shorter abbreviation for these might be E2 or C1.
Environment	The application lifecycle for the workload the resource belongs to; such as Development, UAT, Test, or Production. An example shorter abbreviation of these might be DEV or PRD.
Organization	An abbreviation or moniker representing your organization.
Workload or Application Name	The name of the application or workload the resource belongs to. Such as Jumpbox, Data Lake, AKS.
Business Unit	The top-level department or business unit of your company that owns or is responsible for the resource. Such as HR, Marketing, IT.
Instance	A number or letter indicating uniqueness when you have multiple instances of this resources for the same workload. Such as 01.
Resource Type	An abbreviation for the Azure Resource Type of this resource. Such as rg, vm, sql, aks.

Which ever naming components you decide are absolutely necessary, be careful that you choose the correct limited number of components along with the appropriate separator character in the chosen naming convention. The most common separator character between each naming component of a naming convention is the hyphen or dash (-) character. However, there are Resources like the Azure Storage Account that does not allow this character in the Resource Names, so you will need to vary your convention with this Resource Type as a special case.

One of the naming components that’s optional based on your preferences, but still recommended is the Organization. This component is recommended as there are certain Azure resources that need to be named uniquely at the Global scope within Microsoft Azure. The reason is these resources names are used to define a DNS name for them and must be unique across all Microsoft customers using Azure. Including the Organization naming component will help create a naming convention that will be more compatible with creating Globally unique names in Azure while still keeping resource naming consistent across all your resources.

NOTE: When creating Azure Resources using the Azure Portal UI, it will append the Resource Type abbreviation to many of the Azure Resources that are created by through the Azure Marketplace. This makes using a specific naming convention to often require you to use automation tools (such as Azure CLI, ARM Templates, Terraform, etc.) to fully utilize names that adhere to this naming convention.

Shortness is important when deciding on the value or abbreviation to use for the various naming components. Generally, it’s best to keep each one to 2 or 3 characters maximum if possible so the final resource names are short as possible, since Azure has naming requirements that will limit the length of Azure resource names to various lengths and limited characters allowed.

When abbreviation the Environment naming component, it’s common to use 3 characters, or sometimes 4 characters for certain environments. The following are some common abbreviations for different Environments:

• Development – dev
• Test – tst
• User Acceptance Testing – uat
• Production – prd

The Workload or Application Name component is likely the one component that will end up being named a little longer so the resource name remains meaningful to it’s use. This makes keeping other components shorter more important, so there’s a few more characters in the character length limit on resource names available for this component to still make sense.

Azure Region + Environment Prefix Naming Convention

The “Azure Region + Environment Prefix” naming convention (as I’ll refer to it in this article) is an easy to follow naming convention, that

{region}-{org}-{env}-{workload}-{instance}-{type}

Here’s a simple example of using this naming convention for all the resources related to a single Azure Virtual Machine organized within an Azure Resource Group:

E2-B59-DEV-VS22VM-01-rg  <- Resource Group
E2-B59-DEV-VS22VM-01-vm <- Virtual Machine
E2-B59-DEV-VS22VM-01-ip <- Public IP Address
E2-B59-DEV-VS22VM-01-nsg <- Network Security Group
E2-B59-DEV-VS22VM-01-vnet <- Virtual Network
E2-B59-DEV-VS22VM-01-nic <- Network Interface
E2-B59-DEV-VS22VM-01-osdisk <- Operating System Disk

As you can see within naming convention starting with the most global aspect of the resource, then moving through the naming pattern towards the more single resource specific information, you’ll be able to sort resources by name and it will nicely group related resources together. All resources will be sorted in alphabetical order by Region, then Environment, then Workload, then Instance, then Resource Type. Sorting by name is very organized, and searching for resources by partial name is very organized as well.

“As a consultant, I’ve helps many organizations migrate to and adopt Microsoft Azure, and we’ve had lots of success using what I refer to as the “Azure Region + Environment Prefix” naming convention. I can’t take credit for this naming convention, my colleagues over at Solliance came up with this one.

Chris Pietschmann, Founder Build5Nines.com, Microsoft MVP

Resource Type Prefix Naming Convention

Microsoft doesn’t have a name for this naming convention, as this is the only naming convention that’s promoted by the Microsoft documentation.

This naming convention puts the naming components you’re most likely looking for when searching for specific Azure Resources towards the front of the resource name. Such as Resource Type abbreviation and Workload, then the other components follow.

{type}-{org}-{workload}-{env}-{region}-{instance}

Microsoft doesn’t include the Organization ({org}) naming component in their version of this naming convention. However, by including it you will be able to keep resource names at the Global scope more closely named to the rest of your resources in Azure. Some resources, like Azure Storage Accounts or Web Apps, require a globally unique resource name across all Microsoft Azure customers since the resource name is used as part of the DNS name generated for the resource.

Here’s a simple example of using this naming convention for all the resources related to a single Azure Virtual Machine organized within an Azure Resource Group:

rg-B59-VS22VM-dev-eastus-01  <- Resource Group
vm-B59-VS22VM-dev-eastus-01 <- Virtual Machine
ip-B59-VS22VM-dev-eastus-01 <- Public IP Address
nsg-B59-VS22VM-dev-eastus-01 <- Network Security Group
vnet-B59-VS22VM-dev-eastus-01 <- Virtual Network
nic-B59-VS22VM-dev-eastus-01 <- Network Interface
osdisk-B59-VS22VM-dev-eastus-01 <- Operating System Disk

Scope Level Inheritance Naming Convention

Another naming convention that I’ve personally come up with that still maintains uniqueness, but also helps shorten names by reducing the use of metadata (like Resource Type) in the naming convention is something I like to call the “Scope Level Inheritance” naming convention.

This naming pattern focuses on child resources inheriting the prefix of their name from the parent resource. For example, the prefix of each Resource name is the same as the name of the Resource Group that contains it. Also, for resources that only need to be unique at the Resource Group scope that are part of the same workload / application will end up with the same Resource name; largely by omitting the Resource Type abbreviation from the name.

Here’s a basic format to adhere to for the Scope Level Inheritance Naming Convention:

{region}-{org}-{env}-{workload}-{instance}

With this naming convention, you only use a later naming component if it’s necessary for the Resource being named. For example, an Azure Resource Group might be named like E2-PRD-DataLake with the following Azure Resources:

e2-b59-prod-datalake <- Azure Synapse Analytics
E2-B59-PROD-DataLake-managed <- Azure Synapse Analytics managed resource group

e2b59proddatalake <- Azure Storage Account

E2-B59-PROD-DataLake-IR-01 <- Integrated Runtime VM 1 - Virtual Machine
E2-B59-PROD-DataLake-IR-01 <- Integrated Runtime VM 1 - Network Interface
E2-B59-PROD-DataLake-IR-01 <- Integrated Runtime VM 1 - Virtual Network
E2-B59-PROD-DataLake-IR-01 <- Integrated Runtime VM 1 - Public IP Address
E2-B59-PROD-DataLake-IR-01 <- Integrated Runtime VM 1 - Network Security Group

E2-B59-PROD-DataLake-IR-02 <- Integrated Runtime VM 2 - Virtual Machine
E2-B59-PROD-DataLake-IR-02 <- Integrated Runtime VM 2 - Network Interface
E2-B59-PROD-DataLake-IR-02 <- Integrated Runtime VM 2 - Virtual Network
E2-B59-PROD-DataLake-IR-02 <- Integrated Runtime VM 2 - Public IP Address
E2-B59-PROD-DataLake-IR-02 <- Integrated Runtime VM 2 - Network Security Group

Something you can see with this naming convention is that any Azure Resources that are all part of the same workload that don’t require unique names within the scope of the Resource Group they are provisioned within will be sharing the exact same name. This can help you know that all resources with the same name go together in the event that they share a Resource Group with other resources.

A potential downside of this naming convention is that by multiple Azure Resources sharing the same name, it’s possible some Admins or IT Professionals may get confused by this ambiguity. It doesn’t make this a bad naming convention, but rather something you will need to deal with through educating your team to handle it. As this could provide a frustration point with this naming convention, it could prove more advantageous to choose one of the other naming conventions to standardize on.

NOTE: Keep in mind the above resource name examples are simplistic, and something simple like e2b59proddatalake for the name of an Azure Storage Account may not be unique enough to ensure no other Azure customers are already using that name. As a result, you may end up needing to stray from the strictness of the naming convention at times to adhere to naming requirements of certain Resource Types.

Azure Resource Type Abbreviations

When naming Azure Resources there are character count limits. This will impose a strict limit on how long the resource names can be, so you’ll want to abbreviate the naming components, especially the Resource Type component used. A shorter abbreviation will allow you to use more characters in the maximum allowed for other naming components. It’s generally best to keep the Resource Type abbreviations to 2 or 3 characters maximum if possible. However, there are times when 4 characters fit best depending on the Azure Resource Type.

Here are some of the most common Azure Resource Types and their abbreviations commonly used:

Azure Resource Type	Abbreviation
API Management	apim
App Service Plan	asp
Azure Function App	func
Disks	disk or osdisk
Network Interface	nic
Network Security Group	nsg
Public IP Address	ip
Resource Group	rg
Virtual Machine	vm
Virtual Network	vnet

There are way too many Azure Resource Types to list common abbreviations for in this article. When you’re naming Azure Resources, you can see it’s fairly simple to come up with an abbreviation to use. If you need more suggestions, the Microsoft docs contain a page that lists out all the Resource Types and abbreviations.

Resource Tagging to Add Metadata

Keep in mind that you can use Resource Tags to capture additional metadata for Azure Resources, such as Department / Business Unit, that you don’t include within your naming convention. While it can be very advantageous to the Environment (like DEV or PROD) in your resource naming to ensure uniqueness, there are other things that could better serve as metadata on the Azure Resources through the use of Tags. This would help you reduce the number of required naming components and reduce the resulting name length for your Azure Resources.

Basically, an information about the Azure Resources that don’t fit in the naming convention you choose to use, you can always include it as Tags on the Azure Resources and Resource Groups. This can help keep information about the Azure Resources on the resources themselves; regardless if it’s directly in the name or included in the list of Tags assigned to the resource.

Good luck choosing a naming convention for your organization! I really hope this article helps you figure out what the best naming convention for your organization to better organize all the Azure Resources you are about to create and manage.

About the Author