Naming resource groups and resources in Azure in a consistent manner is challenging.

The naming guidance by Microsoft is quite good and is a good starting point.

Naming Resource Groups

In most modern systems you will have resource groups for each of your environments. A typical environment naming convention is Dev, UAT, and Prod. Typically you will have a resource group per deployable unit of software. In most cases the "unit" of deployment is an application. I recommend naming resource groups <product name>-rg-<environment>.

Example for Application XYZ

xyz-rg-dev
xyz-rg-uat
xyz-rg-prod

Naming Resources in Azure

The allowed names for resources can vary widely between resources. For example, a storage account only allows 3-24 lowercase letters while a Azure Sql database allows 1-28 alphanumeric, underscore and hyphen characters.

One good strategy is to always use lowercase alphanumeric characters because that's the lowest common denominator on all Azure resources. I prefer to do a variation of the lowest common denominator route and use hyphens in the resource name if the resource name allows hyphens.

Naming Rules

  • General convention is <service name>-<type of service abbreviated>-<environment>
  • lowercase letters and numbers
  • use hyphens if the resource name allows hyphens
  • some resources need the same name in every resource group and those would not have -<environment> appended at the end of the name

Naming Conventions

Compute

Entity Scope Length Casing Valid Characters Suggested Pattern Example
Virtual Machine Resource Group 1-15 (Windows), 1-64 (Linux) Case insensitive Alphanumeric, underscore, and hyphen <name>-<role>-vm<number>-<env> profx-sql-vm1-dev
Function App Global 1-60 Case insensitive Alphanumeric and hyphen <name>-func-<env> calcprofit-func-dev

Naming Collisions

Some resources in Azure must be named uniquely across all of Azure. It is common to run into naming collisions for these resources. For example, when I try to create a storage account called test I get the error message shown below.

test-error

One solution to get around naming collisions is to use a unique string when creating the resource. A unique string is typically a short hash of one or more concatenated input strings so the output is sufficiently random to avoid naming collisions. One way to create this unique string is when creating a resource via an ARM template. Appending a unique string to a resource will help ensure the name satisfies any uniqueness constraints required by a resource.

Unique string scoped to subscription

"[uniqueString(subscription().subscriptionId)]"

Unique string scoped to resource group

"[uniqueString(resourceGroup().id)]"

Unique string that is globally unique and different between resource groups:

"[uniqueString(subscription().subscriptionId,resourceGroup().id)]"