Azure Naming Conventions for Multi-Region Deployments

For multi-region deployments, put the region abbreviation in every resource name so each region’s resources are distinct, for example rg-payments-prod-eus-001 in East US and rg-payments-prod-wus2-001 in West US 2. Keep every other component identical so the primary and failover sets line up.

Single-region naming conventions are straightforward. Multi-region gets complicated fast, you’re creating near-identical sets of resources in two or more regions, and the names need to distinguish them clearly while remaining consistent and automation-friendly. This guide covers how to extend your CAF naming scheme for multi-region deployments.

Why the region component matters more in multi-region

In a single-region setup, the region abbreviation in resource names is informational, you have kv-payments-prod-eus-001 and the eus is just there for completeness. In a multi-region setup it becomes load-bearing: without it, your primary and failover resources have identical names and can’t coexist in the same resource group.

The region abbreviation must be:

• Consistent, use the same abbreviation everywhere (eus, not eastus or e or east-us)
• Short, especially for constrained resources like storage accounts (24 chars)
• Unambiguous, eus and eus2 are distinct; eu is too vague

Commonly used abbreviations:

Region	Abbreviation
East US	eus
East US 2	eus2
West US 2	wus2
West US 3	wus3
Central US	cus
West Europe	weu
North Europe	neu
UK South	uks
UK West	ukw
Southeast Asia	sea
East Asia	ea
Australia East	aue
Japan East	jpe
Canada Central	cac
Brazil South	brs

The complete region abbreviations list covers all 40 regions.

Active-passive (primary / failover)

The most common multi-region pattern: resources run in one region, with a standby replica in another that’s promoted on failover.

Name the primary and failover resources identically except for the region component:

Primary:
  rg-payments-prod-eus-001
  vnet-payments-prod-eus-001
  kv-payments-prod-eus-001
  sql-payments-prod-eus-001
  stpaymentsprodeus001

Failover:
  rg-payments-prod-wus2-001
  vnet-payments-prod-wus2-001
  kv-payments-prod-wus2-001
  sql-payments-prod-wus2-001
  stpaymentsprodwus2001

The parallel structure makes it immediately obvious which resources belong together and which region is which.

Active-active

In active-active, both regions serve traffic simultaneously. The naming pattern is the same as active-passive, region abbreviation differentiates the pairs:

app-payments-prod-eus-001      ← East US instance
app-payments-prod-weu-001      ← West Europe instance

sql-payments-prod-eus-001      ← East US primary replica
sql-payments-prod-weu-001      ← West Europe primary replica

Global resources that sit in front of both regions (Traffic Manager, Front Door, Cosmos DB accounts) don’t belong to a region, omit the region component or use a generic label:

traf-payments-prod-001         ← Traffic Manager profile (global)
fd-payments-prod-001           ← Front Door (global)
cosmos-payments-prod-001       ← Cosmos DB (multi-region replication built in)

Global and regional resource groups

Separate your global resources from your regional ones with a matching resource group pattern:

rg-payments-prod-global-001    ← Traffic Manager, Front Door, DNS zones
rg-payments-prod-eus-001       ← East US resources
rg-payments-prod-weu-001       ← West Europe resources

This makes the architecture visible from the resource group list alone, and keeps blast radius bounded, deleting the West Europe resource group doesn’t touch the global routing layer or the East US resources.

Shared networking in multi-region hub-spoke

In a hub-spoke topology, hubs are regional but peers are not. Name them accordingly:

Hub VNets (one per region):
  vnet-hub-prod-eus-001
  vnet-hub-prod-weu-001

Spoke VNets (workload + region):
  vnet-payments-prod-eus-001
  vnet-payments-prod-weu-001
  vnet-hrportal-prod-eus-001

VNet peerings (relationship-based name):
  peer-hub-eus-to-payments-eus-001
  peer-hub-weu-to-payments-weu-001

Terraform: multi-region with for_each

variable "regions" {
  default = {
    eus  = "eastus"
    wus2 = "westus2"
  }
}

variable "workload"    { default = "payments" }
variable "environment" { default = "prod" }

resource "azurerm_resource_group" "regional" {
  for_each = var.regions
  name     = "rg-${var.workload}-${var.environment}-${each.key}-001"
  location = each.value
}

resource "azurerm_key_vault" "regional" {
  for_each            = var.regions
  name                = "kv-${var.workload}-${var.environment}-${each.key}-001"
  resource_group_name = azurerm_resource_group.regional[each.key].name
  location            = each.value
  tenant_id           = data.azurerm_client_config.current.tenant_id
  sku_name            = "standard"
}

The for_each loop creates identically structured resources in each region, with the region abbreviation (each.key) slotting into the name automatically.

Bicep: multi-region with module loop

param regions array = ['eastus', 'westus2']
param regionCodes object = {
  eastus: 'eus'
  westus2: 'wus2'
}

param workload string = 'payments'
param environment string = 'prod'

module regionalDeploy 'modules/regional.bicep' = [for region in regions: {
  name: 'deploy-${regionCodes[region]}'
  params: {
    workload: workload
    environment: environment
    region: regionCodes[region]
    location: region
  }
}]

Inside modules/regional.bicep:

param workload string
param environment string
param region string
param location string

resource kv 'Microsoft.KeyVault/vaults@2023-07-01' = {
  name: 'kv-${workload}-${environment}-${region}-001'
  location: location
  properties: {
    sku: { family: 'A', name: 'standard' }
    tenantId: subscription().tenantId
  }
}

Checklist for multi-region naming

• Region abbreviation is included in every regional resource name
• Global resources omit region or use global as the component
• Primary and failover resource names are identical except for the region component
• Resource groups are separated by region (and optionally a global group for shared resources)
• Region abbreviations are consistent across all templates and teams
• Storage accounts and container registries (no hyphens) still fit within 24/50 character limits with the region added

Use AzureNamer to generate CAF compliant names for your multi-region architecture, it handles character limits and separator rules automatically for all 200+ Azure resource types.