What is the difference between the internal name and display name?

The internal name (like eastus or westeurope) is the lowercase code used in CLI, ARM templates and APIs. The display name (East US, West Europe) is the human-readable label shown in the Azure portal. They map one to one.

What is an Azure paired region?

Most Azure regions are paired with another region in the same geography for platform-managed replication and sequential update rollout. For example East US pairs with West US, so geo-redundant storage replicates between them automatically.

Do all Azure regions support availability zones?

No. Availability zones are physically separate data centres within a region, and only a subset of regions support them. Zone support is required for zone-redundant services and the highest single-region SLAs.

Why do some regions have no pair?

Newer regions and some single-region geographies (such as certain Asian or government regions) are not paired. For those you must design cross-region redundancy yourself rather than relying on the platform pairing.

How are Azure regions grouped into geographies?

A geography is a data-residency and compliance boundary that contains one or more regions, like United States or Europe. Geographies ensure data-residency and compliance requirements are honoured within market or sovereign boundaries.

What is the Azure Region Codes Reference?

Searchable Azure region reference with internal region name, geography, display name, availability-zone support and the paired region used for platform-managed replication. It runs free in your browser on Gera Tools, with nothing uploaded.

Azure Region Codes Reference

Name: Azure Region Codes Reference
Creator: Gera Tools
License: https://creativecommons.org/licenses/by/4.0/

Azure region codes reference

An Azure region is a set of data centres in a defined geography, deployed within a latency-defined perimeter. Choosing one affects latency, cost, data residency and which services are available. This reference maps each Azure region’s internal name (used in CLI and ARM) to its display name, geography, availability-zone support and paired region for replication.

How it works

Azure uses two identifiers per region: a lowercase internal name (eastus, westeurope) for automation, and a display name (East US, West Europe) for the portal. Regions belong to a geography — a compliance and data-residency boundary.

Most regions have a paired region in the same geography. Azure uses pairs to:

replicate geo-redundant storage automatically,
roll out planned platform updates one region of a pair at a time,
prioritise recovery of one region in a pair during a broad outage.

Availability zones are isolated data centres inside a region; only zone-enabled regions support zone-redundant deployments.

Commonly referenced Azure regions

Internal name	Display name	Geography	Paired with
`eastus`	East US	United States	`westus`
`eastus2`	East US 2	United States	`centralus`
`westus`	West US	United States	`eastus`
`westus2`	West US 2	United States	`westcentralus`
`westus3`	West US 3	United States	`eastus`
`centralus`	Central US	United States	`eastus2`
`northeurope`	North Europe	Europe	`westeurope`
`westeurope`	West Europe	Europe	`northeurope`
`uksouth`	UK South	United Kingdom	`ukwest`
`ukwest`	UK West	United Kingdom	`uksouth`
`eastasia`	East Asia	Asia Pacific	`southeastasia`
`southeastasia`	Southeast Asia	Asia Pacific	`eastasia`
`australiaeast`	Australia East	Australia	`australiasoutheast`
`australiasoutheast`	Australia Southeast	Australia	`australiaeast`
`japaneast`	Japan East	Japan	`japanwest`
`canadacentral`	Canada Central	Canada	`canadaeast`

This list covers the major regions; the full set is returned by az account list-locations --output table and changes as new regions open.

How to look up a region in the CLI

List all available regions for your subscription:

az account list-locations --output table

Check which services are available in a specific region:

az provider show --namespace Microsoft.Compute --query "resourceTypes[*].{resource:resourceType, locations:locations}" --output table

Choosing a region

Several factors determine which region makes sense for a given workload:

Latency to users: Regions closest to your users give the lowest network round-trip times. For EU-resident users, westeurope (Netherlands) and northeurope (Ireland) are often the lowest-latency choices; UK-based users frequently benefit from uksouth (London).

Data residency requirements: GDPR, UK GDPR, and other data-protection laws may require personal data to remain within a defined geographic boundary. Azure geographies map to these boundaries — European data stays in European regions. Choosing a region outside your required geography for a regulated workload is a compliance risk.

Availability zone support: Zone-redundant services (zone-redundant storage, zone-redundant Azure SQL, zone-redundant App Service plans) require a region that has at least three availability zones. Not all regions do — check the AZ support flag in this reference before designing a high-availability architecture.

Service availability: Not every Azure service is available in every region. Newer AI, specialized compute (confidential VMs, GPU), and edge services are sometimes available in a subset of regions before becoming global. Verify availability for your specific resource types using the CLI command above.

Tips and notes

Use the internal name in az CLI, ARM/Bicep templates and Terraform.
Prefer zone-enabled regions for production workloads needing high single-region SLAs.
Check the paired region when designing geo-redundant storage and DR.
Some newer regions have no pair — plan cross-region redundancy manually there.