Profile picture of Liam Moat

Liam Moat

Principal Engineer at Microsoft

Naming convention for Azure Resources

By Liam Moat. . 4 minutes read.

For a long time, I have wanted to document my naming conventions for Azure Resources - this post does just that. A consistent naming convention makes resources easier to find and easier to understand. It can provide structure amongst the chaos of potentially hundreds (if not, thousands) of resources deployed across different regions and environments. A consistent naming standard is the first pillar of the Azure enterprise scaffold and a best practice for cloud applications.

Remember that it’s difficult to rename resources in Azure, so a few minutes now will save you trouble later.

Important Note: The naming convention that I use, is unique to me. It provides me with the information that I need and organises resources in such a way that makes sense to me. This means it might not work for you. It may, however, be a great starting point.

Consider naming rules and restrictions:

Each resource or service type in Azure enforces a set of naming restrictions. Before defining your own standards for naming resources, I strongly recommend you take a look at the Naming rules and restrictions for Azure cloud services.

Common guidelines

This convention provides a naming standard for subscriptions, resource groups and resources. The following rules are shared across all three:




Organisation Portfolio Product Line Environment Name
Contoso Human Resources N/A Development con-hr-sub-dev
Contoso Human Resources N/A Production con-hr-sub-prd
Contoso Information Technology Internal Apps Development con-it-internal-sub-dev
Fabrikam Core Services N/A N/A fab-core-sub

Resource Group



Organisation Product Environment Region Name
Contoso Payroll System Development North Europe con-payr-rg-dev-n-eu
Contoso Payroll System Production North Europe con-payr-rg-prd-n-eu
Contoso Payroll System Production West Europe con-payr-rg-prd-w-eu
Fabrikam Expenses Service Production UK South fab-exp-rg-prd
Fabrikam Infrastructure N/A UK South fab-infra-rg




Organisation Product Resource Identifier Environment Name
Contoso Payroll System App Service Plan N/A Development con-payr-asp-dev
Contoso Payroll System App Service Plan Internal Development con-payr-asp-int-dev
Contoso Payroll System Web App Service N/A Development con-payr-web-dev
Fabrikam Expenses Service Azure SQL Server N/A Production fab-exp-sqlsrv-prd
Fabrikam Expenses Service Azure SQL DB N/A Production fab-exp-sqldb-prd
Fabrikam Infrastructure Virtual Network N/A N/A fab-infra-vnet
Fabrikam Infrastructure Storage Account N/A N/A fabinfrastor

Full example

Let’s take a look at a full example, including a subscription, resource group and a selection of resources - deployed into both development and production.

In this example, we will omit the environment identifier for production across all names:

Multiple instances

The naming convention so far assumes a single instance of each resource group or resource will be deployed into each environment. For a number of reasons, this isn’t always the case. For example, you may have multiple production instances deployed across multiple regions. In this scenario, we can use the <env> variable for the resource name and replace it with <instance>.

<instance> could be an incrementing number (e.g. 01, 02, 03) or we could use the uniqueString function to generate a unique name for each resource.


As you start to define your own naming convention, I encourage you to review and adopt where possible Microsoft’s Patterns and Practices guidance. In addition to a well defined naming convention, consider how to organize resources with tags. Resource tags give resources metadata to logically organize them into a taxonomy - and can be used to capture all the information that doesn’t make sense to store in the name.