This chapter covers how to design Azure solutions for high availability using Availability Zones and paired regions, a core component of the Business Continuity domain (Objective 3.2) in the AZ-305 exam. Approximately 15-20% of exam questions touch on region and zone design, often in the context of selecting appropriate redundancy models, understanding SLAs, and meeting recovery objectives. You will learn the internal architecture of zones, how to choose between zonal and zone-redundant deployments, and how region pairing affects data residency and failover.
Jump to a section
Imagine a skyscraper with two identical elevator banks: Bank A and Bank B. Each bank has its own power supply, shafts, and control systems. The building's main lobby (the Azure region) has a single address, but tenants can access either elevator bank to reach their floor. If Bank A experiences a power outage or mechanical failure (an Availability Zone failure), Bank B continues operating independently. Tenants must ensure their applications are designed to use both banks equally—this is zone-redundant deployment. The building manager (Azure) ensures that the two banks are physically separate, with independent power, cooling, and network feeds. However, if the entire building catches fire (a region-wide failure), both banks fail. To survive that, you need a second skyscraper in a different city (a paired region). The key mechanism: each elevator bank (Zone) is isolated from the other—no shared transformers, no shared cooling towers, no shared network spine. When you deploy a virtual machine, you choose which bank (Zone) it lives in. Traffic from the street (internet) can be load-balanced across both banks using a load balancer that is zone-aware. This mirrors Azure's Availability Zones: physically separate datacenters within a region, each with independent power, cooling, and networking, connected through a high-speed private fiber network. The failure of one zone does not affect others, but you must architect your solution to use multiple zones to get the SLA benefits.
What Are Availability Zones and Why Do They Exist?
Availability Zones (AZs) are physically separate datacenters within an Azure region. Each zone has its own independent power source, cooling system, and network infrastructure. The purpose is to protect applications from datacenter-level failures, such as power outages, cooling failures, or natural disasters that affect a single building. By deploying resources across multiple zones, you can achieve a higher Service Level Agreement (SLA) — up to 99.99% for virtual machines running in two or more zones.
Azure regions are composed of one or more datacenters. Availability Zones are only available in regions that have at least three separate zones. As of 2025, most major regions (e.g., East US, West Europe, Southeast Asia) support Availability Zones, but some older or smaller regions do not. The exam expects you to know which regions support zones and that you can check this using the Azure CLI or portal.
How Availability Zones Work Internally
Each zone is essentially a separate physical facility with its own: - Power: Independent utility feeds, backup generators, and UPS systems. - Cooling: Separate chiller plants and cooling towers. - Networking: Independent network spine and internet connectivity. - Physical security: Separate perimeter and access controls.
Within a region, zones are connected by a high-speed, low-latency private fiber network. This network has redundant paths and is designed to keep inter-zone latency under 2 milliseconds (typically < 1 ms). This allows synchronous replication between zones for services like Azure SQL Database and Azure Managed Disks.
When you deploy a resource, you can choose to pin it to a specific zone (zonal deployment) or have Azure automatically distribute it across zones (zone-redundant deployment). For example: - Zonal: A virtual machine in Zone 1. If Zone 1 fails, that VM is unavailable. - Zone-redundant: A load balancer or a storage account that automatically replicates data across all three zones. If one zone fails, the service continues from the other zones.
Key Components, Values, Defaults, and Timers
Number of zones per region: Typically 3, but some regions have 2 or more than 3. Always check the official documentation.
Inter-zone latency: < 2 ms, typically < 1 ms.
SLA for VMs in multiple zones: 99.99% (compared to 99.95% for single instance with premium storage).
SLA for zone-redundant services: Typically 99.99% or higher.
Data transfer between zones: Charged at standard outbound data transfer rates (currently $0.01/GB in most regions).
Zone pinning: Once a zonal resource is created, it cannot be moved to another zone; you must recreate it.
Zone-aware services: Virtual Machines, Managed Disks, Load Balancers, Public IP addresses, Azure SQL Database, Azure Cosmos DB, Azure Kubernetes Service (AKS), etc.
Configuration and Verification Commands
To list available regions and their zone support using Azure CLI:
az account list-locations --query "[].{Name:name, DisplayName:displayName, AvailabilityZones:availabilityZones}" -o tableTo create a virtual machine in a specific zone:
az vm create --resource-group MyRG --name MyVM --image UbuntuLTS --zone 1 --size Standard_DS1_v2To create a zone-redundant load balancer:
az network lb create --resource-group MyRG --name MyLB --sku Standard --location eastus --frontend-ip-name MyFrontEnd --public-ip-address MyPublicIP --public-ip-address-allocation static --sku Standard --zone 1 2 3Note: The --zone parameter accepts a space-separated list for zone-redundant resources.
How Availability Zones Interact with Related Technologies
Azure Site Recovery: Can replicate VMs between zones within a region, but typically used for region-to-region disaster recovery.
Azure Traffic Manager: Provides global load balancing across regions, not zones.
Azure Load Balancer: Supports zone-redundant and zonal frontends. For zone-redundant, you assign all zones; for zonal, you assign a single zone.
Azure Application Gateway v2: Supports zone-redundant deployment (automatically distributes across zones).
Azure Storage: Zone-redundant storage (ZRS) replicates data synchronously across three zones. Geo-zone-redundant storage (GZRS) adds asynchronous replication to a paired region.
Azure SQL Database: Supports zone-redundant configuration for the Premium tier, replicating across zones synchronously.
Azure Kubernetes Service (AKS): Supports node pools in specific zones and can automatically spread pods across zones.
Region Pairs
Each Azure region is paired with another region within the same geography (e.g., East US with West US, North Europe with West Europe). The pair is at least 300 miles apart. Region pairs provide: - Sequential update: Azure updates are rolled out to only one region in a pair at a time, reducing downtime. - Data residency: Data stays within the same geography for compliance. - Disaster recovery: In case of a region-wide disaster, Azure may restore services in the paired region preferentially.
For disaster recovery, you can use: - Active-passive: Primary region active, secondary region on standby. - Active-active: Both regions active, traffic distributed using Traffic Manager. - Pilot light: Minimal resources in secondary region, scaled up on failover. - Warm standby: Scaled-down but fully functional secondary region.
Choosing Between Zones and Regions
Use zones for high availability within a region (RPO near zero, RTO minutes).
Use region pairs for disaster recovery across regions (RPO minutes to hours, RTO hours).
Combine both for maximum resilience (e.g., zone-redundant deployment in each region with region-to-region failover).
The exam often tests scenarios where you must select the appropriate redundancy based on RPO/RTO requirements. For example, if RPO must be < 5 seconds and RTO < 1 minute, use zone-redundant storage and VMs in multiple zones. If RPO can be 15 minutes and RTO 1 hour, use geo-redundant storage with Azure Site Recovery.
Limitations and Edge Cases
Not all services support zones. For example, Azure App Service (multi-tenant) does not support zonal deployment (but App Service Environment v3 does).
Some services like Azure Functions on Consumption plan do not support zones.
Zone-redundant deployment may require a Standard SKU (e.g., Standard Load Balancer, Standard Public IP).
Data transfer between zones incurs egress charges.
In a disaster, Azure may not automatically fail over to a secondary zone; you must have an active-active or automated failover configuration.
Exam Traps
Confusing zone-redundant with geo-redundant: Zone-redundant is within one region; geo-redundant is across regions.
Assuming all services support zones: Not all do; check the service documentation.
Forgetting that zonal VMs require managed disks: Unmanaged disks are not zone-aware.
Thinking that Availability Zones protect against region failure: They do not; only region pairs do.
Misunderstanding SLA: 99.99% applies to VMs in two or more zones, not to a single zonal VM.
Identify Application Availability Requirements
Determine the target SLA, RPO, and RTO for the application. For example, a critical database may require RPO of 0 seconds and RTO of 5 minutes. This dictates whether you need zone-redundant or geo-redundant design. Document the compliance and data residency requirements (e.g., data must stay in Canada). Also identify which Azure services the application uses and whether they support Availability Zones. This step is crucial because it drives all subsequent architectural decisions.
Select a Region with Availability Zones
Choose an Azure region that supports Availability Zones and meets data residency requirements. Use the Azure CLI command `az account list-locations` to check zone support. For example, Canada Central supports zones, but Canada East does not. If the required region does not support zones, consider using a different region or accept a lower SLA. Also note that some regions have only 2 zones, which may affect design.
Design for Zone-Redundant or Zonal Deployment
For each service, decide whether to deploy zonal (pinned to one zone) or zone-redundant (distributed across zones). Zone-redundant is preferred for critical workloads. For VMs, deploy at least two VMs in different zones behind a load balancer. For storage, use ZRS or GZRS. For databases, enable zone redundancy if supported. Ensure that all dependencies (e.g., load balancers, public IPs) are also zone-redundant. Document the zone assignment to avoid accidental single-zone failure.
Configure Networking Across Zones
Create a virtual network (VNet) that spans all zones. Subnets are not zone-specific; they are regional. Deploy a Standard Load Balancer with a zone-redundant frontend (assign all three zones). For inbound traffic, use a zone-redundant public IP. For outbound, use NAT Gateway or a zone-redundant firewall. Ensure that network security groups (NSGs) and routing are consistent across zones. Test inter-zone latency (< 2 ms) to confirm it meets application requirements.
Implement Disaster Recovery Across Regions
Even with zone-redundant design, plan for region failure. Use Azure Site Recovery to replicate VMs to a paired region. For databases, configure geo-replication (e.g., Azure SQL Geo-Replication, Cosmos DB multi-region). Set up Traffic Manager to route traffic to the secondary region during failover. Define runbooks for manual or automated failover. Test failover regularly to ensure RTO is met. Remember that zone-redundant does not replace region-level DR.
Enterprise Scenario 1: E-Commerce Platform
A large e-commerce company deploys its web application across Availability Zones in East US. They use: - 6 VMs (2 per zone) in a VMSS with autoscaling. - Standard Load Balancer with zone-redundant frontend. - Azure SQL Database Premium with zone redundancy enabled. - Azure Redis Cache Premium in zone-redundant mode. - Azure Storage for static content using ZRS.
The problem solved: During a power outage in one datacenter, the application continued serving traffic without interruption because the load balancer routed requests to the healthy zones. The database remained online because SQL Database automatically failed over to another zone within seconds. Performance: Inter-zone latency is < 1 ms, so there is no noticeable impact on user experience. Common misconfiguration: The team initially deployed the load balancer with a zonal frontend only in Zone 1, causing complete failure when Zone 1 went down. They fixed it by using a zone-redundant frontend.
Enterprise Scenario 2: Financial Services Disaster Recovery
A bank must meet regulatory requirements for disaster recovery across regions with RPO of 5 minutes and RTO of 1 hour. They deploy:
Primary region: East US with zone-redundant VMs and SQL Database.
Secondary region: West US (paired region) with warm standby VMs.
Azure Site Recovery replicates VMs from East US to West US with continuous replication.
Azure SQL Database active geo-replication to West US with automatic failover groups.
Traffic Manager with priority routing (primary active, secondary passive).
The problem solved: In the event of a region-wide disaster, the bank can failover to West US within the RTO. The warm standby reduces scale-up time. Common issue: The bank initially used Azure Backup instead of Azure Site Recovery, leading to RPO of 24 hours. They switched to ASR for near-continuous replication.
Enterprise Scenario 3: Media Streaming Service
A media company requires high availability for its streaming platform across multiple regions. They use:
Azure Cosmos DB with multi-region writes (active-active) across two regions.
Azure Front Door for global load balancing and failover.
AKS clusters in each region with zone-redundant node pools.
Azure CDN for static content delivery.
The problem solved: Users are always directed to the nearest healthy region. If an entire region fails, traffic shifts to the other region with no downtime. Performance: Cosmos DB multi-region writes ensure low latency for write operations globally. Misconfiguration risk: The team initially used a single region for Cosmos DB, causing a single point of failure. They fixed it by enabling multi-region writes.
AZ-305 Objective 3.2: Design for Business Continuity
The exam focuses on your ability to select the appropriate redundancy model based on business requirements. Key objective codes: - 3.2.1: Recommend a solution for availability and recovery. - 3.2.2: Recommend a solution for high availability. - 3.2.3: Recommend a solution for disaster recovery.
Most Common Wrong Answers and Why Candidates Choose Them
Choosing geo-redundant when zone-redundant is required: Candidates see 'redundancy' and immediately think of geo-replication. They overlook that zone-redundant provides lower RPO/RTO within the same region. The exam will give a scenario with RPO of 5 seconds and RTO of 1 minute — zone-redundant fits, geo-redundant does not.
Thinking all services support Availability Zones: Candidates assume that because VMs support zones, so do App Services or Functions. The exam tests this with a scenario requiring App Service high availability — the correct answer may be to use App Service Environment v3 (which supports zones) or to deploy multiple instances across zones via a different service.
Confusing Availability Sets with Availability Zones: Availability Sets distribute VMs across fault domains within a single datacenter, while Zones distribute across separate datacenters. The exam may ask which provides better SLA — Zones (99.99%) vs. Availability Sets (99.95%).
Assuming zone-redundant storage automatically provides geo-redundancy: ZRS replicates within a region only. For cross-region protection, you need GZRS or geo-redundant storage (GRS).
Specific Numbers and Terms That Appear on the Exam
99.99% SLA for VMs in two or more Availability Zones.
99.95% SLA for VMs in an Availability Set.
99.9% SLA for single VM with premium SSD.
ZRS (Zone-Redundant Storage), GZRS (Geo-Zone-Redundant Storage).
RPO: Recovery Point Objective, RTO: Recovery Time Objective.
Active geo-replication vs Auto-failover groups for SQL Database.
Azure Site Recovery for VM replication to secondary region.
Edge Cases and Exceptions
Some regions (e.g., France Central) have only 2 zones. In such cases, you cannot achieve the same SLA as a 3-zone region.
Some services (e.g., Azure Backup) do not support zone-redundant vaults; you must use geo-redundant storage for backup vaults.
Azure Load Balancer Standard supports zone-redundant frontends, but Basic SKU does not.
How to Eliminate Wrong Answers
If the question mentions 'within a single Azure region', focus on zone-redundant options.
If the question mentions 'across geographic regions', focus on geo-redundant or Traffic Manager.
If the question mentions 'data residency', ensure the solution uses a single region or paired regions within the same geography.
If the question asks for 'lowest RPO', look for synchronous replication (zone-redundant or local redundant).
Always check the SLA: if 99.99% is required, you must use multiple zones.
Availability Zones are physically separate datacenters within a region, each with independent power, cooling, and networking.
To achieve 99.99% SLA for VMs, deploy at least two VMs across two or more Availability Zones.
Zone-redundant services automatically distribute across zones; zonal services are pinned to one zone.
Not all services support Availability Zones; always verify before designing.
Region pairs provide disaster recovery across regions, with sequential updates and data residency guarantees.
Inter-zone latency is typically < 2 ms, enabling synchronous replication for databases.
Data transfer between zones incurs standard egress charges.
Use Azure Site Recovery for VM replication to a paired region for disaster recovery.
Zone-redundant storage (ZRS) replicates within a region; geo-zone-redundant storage (GZRS) adds cross-region replication.
The exam tests your ability to choose between zone and region redundancy based on RPO/RTO requirements.
These come up on the exam all the time. Here's how to tell them apart.
Availability Zones
Protects against datacenter failure within a region.
Provides RPO near zero (synchronous replication).
RTO in minutes (automatic failover for some services).
Data stays within the same region (compliance).
Requires at least 2 VMs across zones for 99.99% SLA.
Region Pairs
Protects against region-wide failure.
Provides RPO of minutes to hours (asynchronous replication).
RTO in hours (manual or automated failover).
Data moves to a paired region (may affect data residency).
Requires secondary region deployment for failover.
Mistake
Availability Zones protect against region-wide failures.
Correct
Availability Zones protect against datacenter-level failures only. A region-wide disaster (e.g., earthquake affecting the entire region) will impact all zones. Use region pairs for disaster recovery.
Mistake
All Azure services support Availability Zones.
Correct
Many core services (VMs, Storage, SQL Database) support zones, but others (e.g., Azure App Service multi-tenant, Azure Functions Consumption plan) do not. Always verify service documentation.
Mistake
Deploying a VM in a specific zone guarantees 99.99% SLA.
Correct
The 99.99% SLA applies only when you deploy two or more VMs across at least two Availability Zones. A single VM in one zone has a lower SLA (99.9% with premium storage).
Mistake
Zone-redundant storage (ZRS) replicates data across regions.
Correct
ZRS replicates synchronously across zones within a single region. For cross-region replication, use GZRS (Geo-Zone-Redundant Storage) or GRS.
Mistake
You can move a zonal VM to another zone without downtime.
Correct
You cannot change the zone of an existing VM. You must create a new VM in the target zone and migrate workloads. This is a common exam trap.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
Availability Sets distribute VMs across fault domains (racks) within a single datacenter. Availability Zones distribute VMs across separate physical datacenters within a region. Zones provide higher SLA (99.99% vs 99.95%) and protect against datacenter failures, while sets protect against rack-level failures. Use zones for critical workloads; use sets for legacy applications that cannot span datacenters.
The multi-tenant App Service plan does not support Availability Zones. However, App Service Environment v3 (ASE v3) does support zone-redundant deployment. If you need high availability for App Service, consider using ASE v3 or deploying across multiple regions with Traffic Manager.
Use Azure CLI: `az account list-locations --query "[].{Name:name, AvailabilityZones:availabilityZones}" -o table`. Regions with zones will show `true`. Alternatively, check the Azure portal or official documentation. Note that some regions may have only 2 zones.
A single VM in an Availability Zone with premium SSD storage has a 99.9% SLA. To get 99.99%, you must deploy at least two VMs in two different zones. The exam often tests this distinction.
No. ZRS replicates data synchronously across zones within one region. If the entire region fails, data is lost. For cross-region protection, use GZRS (Geo-Zone-Redundant Storage) or GRS (Geo-Redundant Storage).
No. The zone is set at creation time and cannot be changed. To move a VM to another zone, you must create a new VM in the target zone and migrate the workload. This is a common exam trap.
Data transfer between zones is charged at the standard outbound data transfer rate, which is approximately $0.01/GB in most regions. This can add significant cost for high-throughput workloads.
You've just covered Designing for Availability Zones and Regions — now see how well it sticks with free AZ-305 practice questions. Full explanations included, no account needed.
Done with this chapter?