Liam Moat

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:

• Names must be in lower case.
• Spaces and special characters are not allowed - with the exception of hyphens.
• Where possible, kebab-case should be used. Hyphens can be removed for services where only alphanumeric characters are allowed - such as Storage Accounts.
• Each segment should be a recognisable name or abbreviation in your organisation.
• Where parameters are marked as optional, it must be consistently used across an entire subscription. For example, if you choose to omit the <env> for a subscription, you should do the same for the resource groups and resources assigned to the given subscription.

Subscription

<org>-<portfolio>[-<productLine>]-sub[-<env>]

• org: Organisation or sub-division.
• portfolio: Department, team or product portfolio.
• productLine: Product grouping or function that is performed from within the portfolio. E.g. internal applications.
• env: (optional) Environment name. E.g. development or production.

Examples

Resource Group

<org>-<product>-rg[-<env>][-<region>]

• org: Organisation or sub-division.
• product: Product, solution, service or platform.
• env: (optional) Environment name. E.g. development or production.
• region: (optional) Azure Region. E.g. North Europe or UK South.

Examples

Resource

[<org>-]<product>-<resource>[-<identifier>][-<env>]

• org: (optional) Organisation or sub-division.
• product: Product, solution, service or platform.
• resource: Azure Resource. E.g. App Service Plan or Virtual Network.
• identifier: Used to differentiate between multiple instances of the same resource. E.g. the pricing tier or function.
• env: (optional) Environment name. E.g. development or production.

Examples

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.

• Subscription: con-hr-sub-dev
  • Resource Group: con-payr-rg-dev-n-eu
    • App Service Plan: con-payr-asp-dev
      • Web App: con-payr-web-dev
      • API App: con-payr-api-dev
    • App Service Plan (Consumption): con-payr-asp-cons-dev
      • Functions App: con-payr-func-dev
    • Application Insights: con-payr-appi-dev
    • Azure SQL Server: con-payr-sqlsrv-dev
    • Azure SQL DB: con-payr-sqldb-dev
    • Storage Account: conpayrstordev

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

• Subscription: con-hr-sub
  • Resource Group: con-payr-rg-n-eu
    • App Service Plan: con-payr-asp
      • Web App: con-payr-web
      • API App: con-payr-api
    • App Service Plan (Consumption): con-payr-asp-cons
      • Functions App: con-payr-func
    • Application Insights: con-payr-appi
    • Azure SQL Server: con-payr-sqlsrv
    • Azure SQL DB: con-payr-sqldb
    • Storage Account: conpayrstor

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.

Summary

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.