Azure Regions and Zones

The azure regions and zones conversation confusingly mixes floorplans with geography. You pick a region like eastus and think you've secured high availability. Then a regional crisis takes your app offline because you used one availability zone. This lesson demystifies the physical layout of Azure — regions, availability zones, and paired regions — and shows you how to make deliberate, resilient choices instead of guessing.

The problem this lesson solves

Every Azure resource lives in a region — a geographic area like East US or North Europe. If you deploy everything into one region and that region becomes unavailable, your entire application goes down. A misconfigured az vm create or an accidental resource-group placement in a single zone can silently create a single point of failure.

You have three main levers for resilience in Azure: regions, availability zones (often just called zones), and paired regions. New developers often assume a regional selection is enough, or they pick a zone at random. This lesson removes that guesswork. You'll learn what an Azure region actually is, how zones provide physical separation, and how paired regions handle disaster recovery.

Core concept / mental model

Think of Azure's physical hierarchy like a city, a building, and a parking lot:

• Region = a city (e.g., eastus, westeurope). It's a geographic boundary containing multiple data centers.
• Availability zone = a specific data center building (or building block) inside that city. Each zone has independent power, cooling, and networking.
• Paired region = a second city affiliated with the first (e.g., eastus pairs with westus). Azure orchestrates replication between pairs for disaster recovery.

Not every service supports availability zones. For example, a basic Azure Blob Storage account might not be zone-redundant by default, while a Virtual Machine scale set can span zones. Zonal services (like a VM in a specific zone) give you physical isolation but require you to deploy across multiple zones for resilience. Zonal redundancy (like zone-redundant storage) uses Azure to automatically replicate across zones in the same region.

Pro tip — A region has a minimum of three availability zones, but not all resources can use them. Always check the service's documentation for zone support before you design your architecture.

How it works step by step

1. Identify the service capabilities — Some Azure services (e.g., Virtual Machines, Storage, App Service) explicitly mention zone support in their SKU or tier. For example, Standard tier in some services may offer zonal deployment while Basic does not.

2. Choose a region — Use Azure CLI or the portal to list regions that support availability zones. The az account list-locations command shows regions, but you must cross-check zone availability via the service's SKU.

3. Decide on your zone strategy — For mission-critical apps, deploy resources across at least two zones. If the region itself fails, you need a paired-region failover plan.

4. Configure zone redundancy — For storage, set --sku Standard_ZRS (zone-redundant) instead of Standard_LRS (locally redundant) when you create the account. For VMs, create multiple instances in different zones using an Availability Set or Virtual Machine Scale Set with zone settings.

5. Plan for paired-region failover — Even with zone redundancy, a regional disaster (like a hurricane) could affect all zones in a region. Use paired regions to mirror data or run an active-passive setup.

Hands-on walkthrough

1. List regions and their zone support

First, verify which regions are available to you and whether they support zones. The CLI doesn't directly output zone support, but you can see the region names.

az account list-locations --output table

Expected output (abbreviated):

Name          DisplayName               RegionalDisplayName
------------  ------------------------  ---------------------------------
useast        East US                   (US) East US
westus        West US                   (US) West US
...

Then, for a specific service like Virtual Machines, check its zone support using the Azure CLI or the SKU list. For simplicity, we'll use the portal or the az vm list-skus command:

az vm list-skus --location eastus --size Standard_D2s_v3 --output table

Look for zones in the output — if it lists multiple zones, the size supports zonal deployment.

2. Create a zone-redundant storage account

Use the --sku Standard_ZRS to explicitly ask for zone redundancy.

az storage account create \
  --name mystorageaccount$RANDOM \
  --resource-group myResourceGroup \
  --location eastus \
  --sku Standard_ZRS

Expected output (simplified):

{
  "kind": "StorageV2",
  "location": "eastus",
  "sku": {
    "name": "Standard_ZRS",
    "tier": "Standard"
  }
}

The Standard_ZRS SKU tells you Azure will replicate your data across multiple availability zones within eastus.

3. Deploy a virtual machine in a specific availability zone

Use the --zone parameter to place a VM in a particular zone.

az vm create \
  --resource-group myResourceGroup \
  --name myVM-zone1 \
  --location eastus \
  --image Ubuntu2204 \
  --zone 1

Then create a second VM in zone 2 to get true zone redundancy:

az vm create \
  --resource-group myResourceGroup \
  --name myVM-zone2 \
  --location eastus \
  --image Ubuntu2204 \
  --zone 2

Now your application can survive a zone outage if you load balance between these VMs.

Compare options / when to choose what

Choose zones when you need physical separation within a region. Choose paired regions when even a region-wide disaster is unacceptable.

Pro tip — Don't assume all resources in the same account automatically use zones. You must configure zone redundancy per resource or service. For example, a VM created without a --zone parameter is zonal-pinned to a single data center.

Troubleshooting & edge cases

"Zones not available" error

When creating a resource, you might see an error like 'Availability Zones are not supported for this SKU'. This means the service or tier you selected doesn't offer zone redundancy. Fix: switch to a SKU that supports zones (e.g., Standard_D2s_v3 vs Basic_A2).

Storage account created with LRS instead of ZRS

If you forget --sku Standard_ZRS, you get Standard_LRS (locally redundant). This replicates within a single data center, not across zones. To fix, you must recreate the storage account — you cannot change the SKU in place for some types. Always verify the sku.name in the output.

Picking a region blindly

Selecting a region far from your users adds latency. But choosing a region with no zone support for a critical service is worse. For latency, pick the closest region. For resilience, choose a region that supports zones for the services you need. Check the Azure region services page before you commit.

Zone ID confusion

Availability zones are labeled 1, 2, 3 within a region, but those numbers are not consistent across regions. Zone 1 in East US is not the same physical infrastructure as zone 1 in West Europe. Never assume you can mix zones across regions.

What you learned & what's next

You now understand Azure regions and zones: regions are geographic boundaries, availability zones are isolated data center blocks, and paired regions offer disaster recovery. You can explain the core concept, use the CLI to check zone support, deploy zonal resources, and configure zone-redundant storage. You also know the common pitfalls, like accidentally creating a locally redundant storage account or deploying a VM in a single zone.

In the next lesson, you'll apply this understanding to Azure Subscriptions — how to organize resources across regions and zones within a subscription, and how to use management groups to enforce your resilience policies at scale.