🌍 Azure Regions and Availability Zones: Where Your Things Actually Live

What a region and a zone are, how to choose one, the three kinds of zone support, why your zone 1 is not my zone 1, and how this compares with AWS, Google Cloud and Oracle Cloud

The short version

• A region is a place: a set of datacenters in one area, connected by a fast private network. You pick a region for nearly everything you create. Microsoft says Azure has over 70 of them.
• An availability zone is a separate group of datacenters inside a region, with its own power, cooling and network. Regions that have zones have at least three.
• A geography is a group of regions that form a data residency boundary: for example the United States, or Europe.

Everything below is detail on those three sentences, and on the choices you make because of them.

Regions

Microsoft's definition: a region consists of one or more datacenters, connected by a high-capacity, fault-tolerant, low-latency network, usually within a large metropolitan area. The names you see are things like East US, West Europe, UK South, Japan East, Australia East. Two details that surprise people:

• The name is not always where you think. "East US" is a region in the eastern United States, not a datacenter in a city of that name. The "List of Azure regions" page shows the actual location.
• Some regions are not open to everyone. Sovereign clouds (for example Azure Government, or Azure operated by 21Vianet in China) are separate, for customers with strict legal requirements, and they often have fewer services.

How to choose one

Microsoft lists three things to weigh, and I would add a fourth, which is the one beginners meet first:

1. Latency. Pick a region near your users (or near you, for learning). Distance means delay.
2. Availability zones. If you will run anything that matters, pick a region that has them (table below).
3. Data residency. If the law or a contract says the data must stay in a country or in the EU, choose a region inside that geography. The geography is the boundary that matters, not just the country name in the region.
4. Price and service availability. The same service can cost different amounts in different regions, and not every service exists in every region. Newer services often appear in a few regions first. The "Products available by region" page shows it. And free-tier offers can run out of capacity in one region: this is why the free Azure VM guide tells you to try another region if your size is unavailable.

For learning: choose one region near you and stay in it. Put everything for one project in that region. Mixed regions are how a small test turns into a confusing bill (data moving between regions is billed: check the bandwidth pricing page) and a confusing portal.

See the list yourself

The Azure CLI can list the regions your subscription can use:

az account list-locations --output table

It prints a name such as eastus (the short name you use in commands) next to its display name (East US). To find the ones that have zones, Microsoft's page gives this query:

az account list-locations --query "[?availabilityZoneMappings].{availabilityZoneMappings: availabilityZoneMappings, displayName: displayName, name: name}"

Both need a signed-in account (from the documentation, not run here). Without an account, the "List of Azure regions" page has the same information.

Availability zones

A zone is a logical grouping of one or more physically separate datacenters in a region. Each has independent power, cooling and networking. They are usually several kilometers apart, within about 100 kilometers of each other: far enough that one storm or one power failure does not take out two, close enough that the network between them is fast. Microsoft's target for the round trip between zones is under about 2 milliseconds. And Azure does not charge for data transfer between zones in the same region.

Which regions have them

Microsoft's list (read on 6 October 2026) shows most regions with 3 zones: for example East US, West US 2, West US 3, Central US, Canada Central, Brazil South, North Europe, West Europe, UK South, France Central, Germany West Central, Sweden Central, Japan East, Southeast Asia, Australia East, Central India and South Africa North. Some are marked as preview or "coming soon" for a zone (East US 2 is listed with 4, and North Central US with 3, both with a note). Even in a region with zones, a service may not support them there: the service's own reliability guide says.

Three kinds of resource

For a resource such as a virtual machine, a disk or a database, there are three possibilities, and the words matter:

• Zonal: you choose one zone, and the resource lives there. It is protected from faults in the other zones, but if your zone fails, it fails. To be safe you run separate copies in different zones and design the failover yourself. Use it when you need to keep two machines close together (low latency) or to control placement.
• Zone-redundant: the service spreads or copies the resource across several zones for you, and handles the failover. Some services do this automatically, others when you switch it on (often a setting or a higher tier).
• Nonzonal (also called regional): you did not choose, so Azure puts it in some zone of the region, you are not told which. If any zone has an outage, your resource might be in it. This is the default, and it is what you get if you click through the portal quickly.

A resource that survives a single zone failure is zone-resilient: either zone-redundant, or several zonal copies in different zones.

The trap: your zone 1 is not my zone 1

The zone numbers (1, 2, 3) you see are logical. Each datacenter group has a physical zone, and Azure maps it to a logical zone per subscription, when the subscription is created. So subscription A's "zone 1" may be subscription B's "zone 2". It almost never matters when you run everything in one subscription. It matters when two subscriptions must be in the same physical zone (for example for speed between teams): you can look at the mapping with the CLI command above (it prints availabilityZoneMappings), or with the "Check Zone Peers" API.

Using a zone

Creating a virtual machine in a specific zone from the CLI is one option:

az vm create --resource-group demo-rg --name vm1 --image Ubuntu2204 --zone 1 --admin-username azureuser --generate-ssh-keys

(The same options as in the free VM guide, plus --zone. From the documentation, not run here.) For anything that matters, the usual shape is two or three machines in different zones behind a load balancer, or a zone-redundant managed service. A single machine in a single zone is a pet, and zones will not save it.

Region pairs, and what they are not

Microsoft pairs some regions with another region in the same geography. You cannot choose the pairs. Some services use the pair for geo-replication and disaster recovery. Many newer regions are not paired: they rely on zones instead. And a pair is not a backup: you still choose what to replicate and test the restore (the backups page of the FreeBSD Corner has the idea, with a real disaster test: ZFS backups).

Zones do not protect against a whole-region outage. For something that must survive that, Microsoft's advice is a solution that is both multi-zone and multi-region. For data that has to stay in one country, use several zones in that region, plus real backups.

Not everything has a region

Most services you create belong to a region. A few are nonregional: Microsoft runs them in two or more regions for you. Microsoft Entra ID (your tenant, see the account tutorial) is one: you only choose the geographic area where its data is stored, for example Europe or North America.

And the resource group has a location too. It stores the metadata about the resources in it, and the control-plane requests (create, change, delete) are routed through it. The resources inside can be in other regions, but Microsoft recommends the same location. Choose the one close to you, and keep it the same as your resources: then a regional outage affects one place.

The same ideas on the other clouds

The words differ, the shape is the same. From each provider's documentation, in broad terms (check their current pages for details):

• AWS: Region, with Availability Zones inside it. The zone names (us-east-1a) are also mapped per account, like Azure's: the zone ID (use1-az1) is the stable one.
• Google Cloud: Region, with zones inside it (us-central1-a). Zonal and regional resources are the same idea as above.
• Oracle Cloud: Region, with Availability Domains (some regions have just one), and Fault Domains inside them.
• Azure: Region (and geography), availability zones, and the extra concept of the region pair.

Common mistakes

• Deploying in a region far away because it was the default in a tutorial, and then wondering why SSH and web pages feel slow.
• Mixing regions in one project.
• Assuming a "highly available" service is zone-redundant by default: read the service's reliability guide, and check the tier.
• Putting everything in one zone and believing zones made it safe.
• Choosing a region by price alone and discovering later that the data may not leave a certain country.
• Forgetting that every command needs a location (--location eastus, or --zone): a typo creates things in a region you did not mean to use.

The cheat sheet

• Region = a place (one or more datacenters). Geography = a data residency boundary. Zone = a separate datacenter group inside a region, at least three in a region that has them. Microsoft says "over 70" regions.
• Choosing: latency, zones, data residency, price and service availability. For learning: one region near you, and stay in it.
• Zonal = you pick one zone, you build the failover. Zone-redundant = the service spreads it. Nonzonal = Azure picks, you are not told.
• Logical zone numbers are per subscription. Mapping: az account list-locations --query "[?availabilityZoneMappings]...".
• Cost: no charge for data between zones in a region. Data between regions is billed. Prices differ by region.
• Region pair: chosen by Microsoft, not by you, not a backup. Many new regions are unpaired.
• CLI: az account list-locations --output table, --location eastus on az group create, --zone 1 on az vm create.

← Creating an Azure Account: What You Get and What to Set Up First · ↑ All tutorials · Azure Services: A Map for People Who Know Linux →