Azure Availability Zones: How HA Works Within a Region
Availability zones are how Azure delivers high availability within a single region. By spreading your resources across physically separate data centers, you can build applications that keep running even when one data center goes offline — without the complexity or cost of a full cross-region failover.
What availability zones are
An availability zone (AZ) is a physically separate data center within an Azure region. Each AZ has its own:
- Independent power supply (separate electrical feeds and backup generators)
- Independent cooling infrastructure
- Independent network connectivity to the broader Azure backbone
The zones within a region are close enough to each other (typically under 2 milliseconds of network latency) to allow synchronous replication of data — you write to zone 1, and by the time the write is acknowledged, the data is also in zone 2. This is the latency budget that makes synchronous database replication within a region practical.
Azure labels its zones as Zone 1, Zone 2, and Zone 3. Importantly, the labels are per subscription — “Zone 1” in your subscription might map to a different physical building than “Zone 1” in another subscription. Microsoft does this to spread load across buildings. When the documentation says to deploy across zones 1, 2, and 3, it means three different physical buildings regardless of the label mapping.
Most mature Azure regions support three availability zones. Not all regions have AZs — check before committing to a region if zone redundancy is a requirement. See Azure global infrastructure for region selection guidance.
Zonal vs. zone-redundant services
Azure services handle availability zones in one of two ways:
Zonal services
You explicitly place the resource in a specific zone. A zonal virtual machine in Zone 1 stays in Zone 1. If Zone 1 fails, that VM is unavailable until the zone recovers. To get redundancy, you create multiple instances: one VM in Zone 1, another in Zone 2, a third in Zone 3, and put a load balancer in front of them. You control the placement.
Services that support zonal deployment: Virtual Machines, managed disks, Azure Kubernetes Service node pools, Azure SQL Database with zone-pinned replicas.
Zone-redundant services
Azure automatically spreads the resource across multiple zones. You don’t choose a zone — Azure handles placement and replication. If one zone fails, the service continues running on the remaining zones. This is the simpler model because Azure manages the distribution.
Services that support zone-redundant deployment: Azure Storage (ZRS), Azure SQL Database (zone-redundant configuration), Azure Cache for Redis (Premium tier), Application Gateway v2, Azure Load Balancer (Standard tier), Azure Service Bus (Premium tier).
Zone redundancy is usually a configuration option, not a default. For Azure SQL Database, you must enable the zone-redundant configuration explicitly. For storage, you must choose ZRS (zone-redundant storage) instead of the default LRS (locally redundant storage) when creating the account. Check the configuration options for each service you use.
A 3-zone web application architecture
Here is what a zone-redundant three-tier web application looks like in Azure — and critically, what happens when Zone 2 fails:
Azure Region: West Europe
─────────────────────────────────────────────────────────────────
[ Azure Load Balancer — Zone-Redundant (Standard tier) ]
│ │ │
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Zone 1 │ │ Zone 2 │ │ Zone 3 │
│ │ │ │ │ │
│ VM: web-1 │ │ VM: web-2 │ │ VM: web-3 │
│ (App Tier) │ │ (App Tier) │ │ (App Tier) │
│ │ │ │ │ │
│ VM: api-1 │ │ VM: api-2 │ │ VM: api-3 │
│ (API Tier) │ │ (API Tier) │ │ (API Tier) │
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
▼ ▼ ▼
[ Azure SQL Database — Zone-Redundant Configuration ]
Primary replica in Zone 1
Synchronous replica in Zone 2
Synchronous replica in Zone 3What happens when Zone 2 fails:
- The Standard Load Balancer detects that its Zone 2 health probes are failing. Within seconds, it stops sending traffic to Zone 2 VMs.
- Traffic is redistributed between the healthy Zone 1 and Zone 3 web and API VMs. Capacity drops by one-third but the application stays up.
- Azure SQL Database’s zone-redundant configuration automatically promotes a replica. If the primary was in Zone 2, one of the synchronous replicas in Zone 1 or Zone 3 is promoted to primary. Because replication was synchronous, no data is lost. The failover typically takes 20–30 seconds during which database connections are interrupted.
- Applications that handle transient database connection failures (with retry logic) continue to work through the SQL failover. Applications without retry logic see brief errors during the 20–30 second promotion window.
The entire event — load balancer rerouting, SQL primary promotion — happens automatically with no manual intervention. The monitoring team sees alerts, investigates, and Azure recovers the Zone 2 resources when the data center issue is resolved.
The most overlooked part of zone-redundant design is the application layer. Azure can reroute traffic and promote database replicas automatically, but if your application doesn’t implement retry logic for transient connection failures, users will still see errors during the 20–30 second database failover window. Retry logic with exponential backoff is a requirement, not an optimization, for zone-redundant architectures.
Enabling zone redundancy for common services
Virtual Machines
# Create a VM in a specific availability zone
az vm create \
--resource-group rg-webapp-prod \
--name web-vm-zone1 \
--image Ubuntu2204 \
--size Standard_D2s_v5 \
--zone 1 \
--admin-username azureuser \
--generate-ssh-keys
# Create VMs in zones 2 and 3 the same way, incrementing --zoneAzure Storage (ZRS)
# Create a storage account with ZRS (zone-redundant storage)
az storage account create \
--name acmestorageprod \
--resource-group rg-webapp-prod \
--location westeurope \
--sku Standard_ZRS \
--kind StorageV2Azure SQL Database (zone-redundant)
# Create an Azure SQL Database with zone redundancy enabled
az sql db create \
--resource-group rg-webapp-prod \
--server acme-sql-server \
--name acme-db-prod \
--service-objective "GP_Gen5_4" \
--zone-redundant trueStandard Load Balancer (zone-redundant frontend)
# Create a Standard load balancer with a zone-redundant frontend IP
az network lb create \
--resource-group rg-webapp-prod \
--name acme-lb \
--sku Standard \
--location westeurope \
--frontend-ip-name lb-frontend \
--public-ip-address acme-lb-pip
# Standard SKU load balancers are zone-redundant by default
# (Basic SKU does not support availability zones)Latency between zones
Azure guarantees that availability zones within a region are connected with a network round-trip latency of under 2 milliseconds. In practice, inter-zone latency in West Europe and East US is typically 0.5–1.5ms.
This low latency enables synchronous replication — a write to a database primary in Zone 1 can be confirmed at the Zone 2 replica before acknowledging the write to the client. This is how Azure SQL Database zone-redundant configurations achieve zero data loss on zone failure.
Contrast this with cross-region latency: East US to West US is typically 60–80ms, which is why synchronous replication across regions is generally impractical for databases with write-heavy workloads. Cross-region replication is typically asynchronous, meaning a small amount of recently committed data could be lost in a regional failover.
Availability zones vs. region pairs: which layer do you need?
These are two different layers of resilience that address different failure scenarios:
| Failure scenario | Availability zones protect against this? | Region pairs protect against this? |
|---|---|---|
| Single data center power failure | Yes — traffic moves to other zones automatically | Not needed — AZs handle it |
| Cooling failure in one building | Yes | Not needed |
| Network partition affecting one zone | Yes | Not needed |
| Natural disaster affecting entire region (e.g. hurricane, earthquake) | No — all zones in the region may be affected | Yes — paired region is geographically distant |
| Major Azure service outage in one region | Sometimes — depends on whether the outage is zone-isolated | Yes — paired region has independent systems |
| Accidental resource deletion in one region | No | Yes, if geo-replication is configured |
Most production workloads should use availability zones as a baseline. High-criticality workloads (financial systems, healthcare platforms, government services) layer region pairs on top for geographic disaster recovery. The cost of running in two regions is roughly double, so the decision to add cross-region DR depends on the business cost of downtime.
Common availability zone mistakes
- Using a Basic Load Balancer instead of Standard. The Basic SKU load balancer does not support availability zones. If you create a Basic load balancer and later want zone redundancy, you must replace it. Always use the Standard SKU for any workload that requires HA.
- Deploying VMs across zones but forgetting the data tier. Three VMs across three zones sounds zone-redundant, but if the database is a single VM in Zone 1 with LRS storage, a Zone 1 failure still brings down the application. Zone redundancy must cover every tier, not just the compute layer.
- Assuming zone-redundant means no data loss on failover. For synchronously replicated services (Azure SQL Database zone-redundant), this is true. For asynchronously replicated services, a small amount of recent data may be lost in a failover. Always check the RPO (recovery point objective) of each service’s zone-redundant configuration.
- Not implementing application-level retry logic. Even automatic failovers cause brief interruptions. Database connections drop during the 20–30 second primary promotion window. Applications without retry logic expose those interruptions as errors to users. Build in exponential-backoff retries for all external service calls.
Summary
- Availability zones are physically separate data centers within a region, each with independent power, cooling, and networking.
- Services are either zonal (you pin to a specific zone) or zone-redundant (Azure spreads and replicates automatically).
- Zone-to-zone latency is under 2ms, enabling synchronous replication and zero data loss on zone failure for supported services.
- AZs protect against single data center failures. Region pairs protect against full regional disasters — you need both layers for maximum resilience.
- Zone redundancy must cover every tier (compute, storage, database) and applications must implement retry logic to handle the brief failover window.
Frequently asked questions
What are Azure availability zones?
Availability zones are physically separate data centers within a single Azure region. Each zone has its own power, cooling, and networking infrastructure. They are typically within 2ms of each other for synchronous replication. Deploying across multiple zones means your application can survive the failure of one entire data center without downtime.
What is the difference between availability zones and region pairs?
Availability zones protect against a single data center failure within a region — the kind of outage caused by a power issue, cooling failure, or localized hardware problem. Region pairs protect against a full regional disaster — something that takes down an entire city or area. You use both layers for the highest availability: AZs for local resilience, region pairs for catastrophic regional failure.
Do all Azure services support availability zones?
No. Azure services fall into three categories for AZ support: zonal (you pin the resource to a specific zone), zone-redundant (Azure automatically spreads the resource across zones), or no zone support (the service does not differentiate between zones). Check the Azure documentation for the specific service you intend to use before assuming AZ support is available.