What are availability zones?
Many Azure regions provide availability zones, which are separated groups of datacenters within a region. Availability zones are close enough to have low-latency connections to other availability zones. They're connected by a high-performance network with a round-trip latency of less than 2ms. However, availability zones are far enough apart to reduce the likelihood that more than one will be affected by local outages or weather. Availability zones have independent power, cooling, and networking infrastructure. They're designed so that if one zone experiences an outage, then regional services, capacity, and high availability are supported by the remaining zones. They help your data stay synchronized and accessible when things go wrong.
Datacenter locations are selected by using rigorous vulnerability risk assessment criteria. This process identifies all significant datacenter-specific risks and considers shared risks between availability zones.
The following diagram shows several example Azure regions. Regions 1 and 2 support availability zones.
To see which regions support availability zones, see Azure regions with availability zone support.
Note
You need to deploy two or more Virtual Machines to different availability zones in the same region to get the highest possible SLA connectivity percentage.
Zonal and zone-redundant services
When you deploy into an Azure region that contains availability zones, you can use multiple availability zones together. By using multiple availability zones, you can keep separate copies of your application and data within separate physical datacenters in a large metropolitan area.
There are two ways that Azure services use availability zones:
Zonal resources are pinned to a specific availability zone. You can combine multiple zonal deployments across different zones to meet high reliability requirements. You're responsible for managing data replication and distributing requests across zones. If an outage occurs in a single availability zone, you're responsible for failover to another availability zone.
Zone-redundant resources are spread across multiple availability zones. Microsoft manages spreading requests across zones and the replication of data across zones. If an outage occurs in a single availability zone, Microsoft manages failover automatically.
Azure services support one or both of these approaches. Platform as a service (PaaS) services typically support zone-redundant deployments. Infrastructure as a service (IaaS) services typically support zonal deployments. For more information about how Azure services work with availability zones, see Azure regions with availability zone support.
Some services don't use availability zones until you configure them to do so. If you don't explicitly configure a service for availability zone support, it's called a non-zonal or regional deployment. Resources configured in this way might be placed in any availability zone in the region, and might be moved. If any availability zone in the region experiences an outage, non-zonal resources might be in the affected zone and could experience downtime.
For information on service-specific reliability support using availability zones as well as recommended disaster recovery guidance see Reliability guidance overview.
Physical and logical availability zones
Each datacenter is assigned to a physical zone. Physical zones are mapped to logical zones in your Azure subscription, and different subscriptions might have a different mapping order. Azure subscriptions are automatically assigned their mapping at the time the subscription is created. Because of this, the zone mapping for one subscription could be different for other subscriptions. For example: Subscription A may have physical zone X mapped to logical zone 1, while subscription B has physical zone X mapped to logical zone 3, instead.
To understand the mapping between logical and physical zones for your subscription, use the List Locations Azure Resource Manager API. You can use the Azure CLI or Azure PowerShell to retrieve the information from the API.
az rest --method get --uri '/subscriptions/{subscriptionId}/locations?api-version=2022-12-01' --query 'value'
Availability zones and Azure updates
Microsoft aims to deploy updates to Azure services to a single availability zone at a time. This approach reduces the impact that updates might have on an active workload, because the workload can continue to run in other zones while the update is in process. You need to run your workload across multiple zones to take advantage of this benefit. For more information about how Azure deploys updates, see Advancing safe deployment practices.
Paired and unpaired regions
Many regions also have a paired region. Paired regions support certain types of multi-region deployment approaches. Some newer regions have multiple availability zones and don't have a paired region. You can still deploy multi-region solutions into these regions, but the approaches you use might be different.
Shared responsibility model
The shared responsibility model describes how responsibilities are divided between the cloud provider (Microsoft) and you. Depending on the type of services you use, you might take on more or less responsibility for operating the service.
Microsoft provides availability zones and regions to give you flexibility in how you design your solution to meet your requirements. When you use managed services, Microsoft takes on more of the management responsibilities for your resources, which might even include data replication, failover, failback, and other tasks related to operating a distributed system.
Availability zone architectural guidance
To achieve more reliable workloads:
- Production workloads should be configured to use availability zones if the region they are in supports availability zones.
- For mission-critical workloads, you should consider a solution that is both multi-region and multi-zone.
For more detailed information on how to use regions and availability zones in a solution architecture, see Recommendations for using availability zones and regions.