multi-regiondisaster recoveryazurecafnaming conventions

Azure Naming Conventions for Multi-Region Deployments

How to extend your Azure CAF naming scheme to handle multi-region, active-active, and primary/failover architectures without name collisions or ambiguity.

AzureNamer Team ·

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)
  • Unambiguouseus and eus2 are distinct; eu is too vague

Commonly used abbreviations:

RegionAbbreviation
East USeus
East US 2eus2
West US 2wus2
West US 3wus3
Central UScus
West Europeweu
North Europeneu
UK Southuks
UK Westukw
Southeast Asiasea
East Asiaea
Australia Eastaue
Japan Eastjpe
Canada Centralcac
Brazil Southbrs

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 203 Azure resource types.

Try AzureNamer

Generate CAF-compliant names for all 203 Azure resource types — free, no login required.

Open the Generator →