AZ-900Chapter 12 of 127Objective 2.1

Availability Zones and Region Pairs

This chapter covers two critical Azure architectural concepts: Availability Zones and Region Pairs. These are the foundation of high availability and disaster recovery in Azure. For the AZ-900 exam, this falls under objective 2.1 (Describe core Azure architectural components), which typically accounts for about 15-20% of the exam. Understanding these concepts is essential because they directly impact SLAs, resilience, and cost decisions. By the end of this chapter, you will be able to explain how Azure achieves fault tolerance across datacenters and regions, and you will know exactly what the exam expects you to remember.

25 min read
Beginner
Updated May 31, 2026

Data Centers as Hotel Rooms

Imagine you are planning a large conference in a city and need to book multiple hotel rooms for your attendees. You want to ensure that if one hotel has a fire alarm or power outage, your event can continue without disruption. You have two strategies: First, you can book rooms in different wings of the same hotel. These wings are physically separate—they have their own elevators, stairwells, and power supplies—so a problem in one wing doesn't affect the other. This is like placing your VMs in different Availability Zones within one Azure region. Second, you can also book rooms in a hotel in a nearby city, say 300 miles away. If the entire first city faces a natural disaster, the second city's hotel can host your event. This is like using a Region Pair. The key mechanism: Availability Zones protect against localized failures (e.g., a transformer explosion) within a single region, while Region Pairs protect against region-wide disasters (e.g., a hurricane). Both use independent power, cooling, and network infrastructure to ensure isolation. In Azure, when you deploy across zones, your VMs are placed in physically separate datacenters with low-latency connections. For Region Pairs, data is replicated asynchronously across hundreds of miles, ensuring data durability even if an entire region goes down.

How It Actually Works

What Are Availability Zones and Why Do They Matter?

Availability Zones (AZs) are physically separate locations within an Azure region. Each zone has its own independent power, cooling, and networking. If one zone fails, the others remain operational. This is a fundamental shift from traditional on-premises setups where all servers are in one building or even one room. In on-premises, a single power outage or cooling failure can take down the entire infrastructure. Azure solves this by providing three or more zones per supported region (e.g., East US 2 has three zones). You can deploy your resources across zones to achieve an SLA of 99.99% for VMs (when using two or more instances across zones).

How Availability Zones Work – The Mechanism

When you create a virtual machine in a region that supports Availability Zones, you can choose a specific zone (e.g., Zone 1, Zone 2, or Zone 3). Azure ensures that the VM's physical host is in the corresponding datacenter. Behind the scenes, Azure assigns a zone to each resource based on your selection. For example:

Zonal deployment: You explicitly pick a zone for each VM. This gives you control over placement, but you must manage load balancing yourself.

Zone-redundant deployment: Azure automatically distributes your resources across zones (used for services like Azure SQL Database or Azure Load Balancer).

Key components: - Availability Set: An older concept that spreads VMs across fault domains and update domains within a single datacenter. Availability Zones are the modern replacement, offering better isolation. - Standard SKU Load Balancer: Can be zone-redundant, meaning it distributes traffic across VMs in multiple zones. - Managed Disks: When you create a VM in a specific zone, the managed disks are also placed in that zone to maintain data locality.

Region Pairs – Disaster Recovery Across Geography

A Region Pair consists of two Azure regions within the same geography (e.g., East US and West US, or North Europe and West Europe). These pairs are at least 300 miles apart to ensure physical separation from natural disasters. Microsoft guarantees that platform updates are rolled out sequentially across a pair, so only one region is updated at a time. This minimizes the risk of simultaneous failure.

Key characteristics: - Asynchronous replication: Data is replicated from the primary region to the secondary region with a lag (typically minutes). This means if a disaster occurs, you might lose some recent data (RPO of minutes). - Automatic failover: For some services (like Azure Storage GRS), failover is manual or automatic depending on the service. For others (like SQL Database geo-replication), you control the failover. - Data residency: Region pairs are in the same geography to comply with data sovereignty laws (e.g., data in Europe stays in Europe).

How It Compares to On-Premises

In a traditional on-premises data center, high availability means having redundant power supplies, multiple network paths, and backup generators. But everything is still in one building. A fire or flood can destroy everything. Disaster recovery requires a second site (cold, warm, or hot), which is expensive and complex to maintain. Azure's Availability Zones offer the equivalent of multiple on-premises sites within a single city, but without the cost of building and managing them. Region Pairs provide the equivalent of a geographically separate disaster recovery site, but with Microsoft handling the replication and failover.

Azure Portal and CLI Touchpoints

In the Azure portal, when creating a VM in a supported region, you'll see an option for "Availability options" with choices like "Availability zone" or "Availability set." For CLI, you can specify the zone with the --zone parameter:

az vm create --resource-group myRG --name myVM --image UbuntuLTS --zone 1

For a zone-redundant load balancer:

az network lb create --resource-group myRG --name myLB --sku Standard --frontend-ip-name myFrontend --public-ip-address myPublicIP --zone 1 2 3

For region pairs, you can view the paired region of a region using:

az account list-locations --query "[?name=='eastus'].{Pair:pairedRegion[0].name}" -o tsv

This returns "westus" for East US.

Business Scenarios

E-commerce platform: Deploy web servers across two Availability Zones to handle a zone failure. Use Azure Load Balancer to distribute traffic. If one zone goes down, the other zone continues serving customers. The SLA for two VMs across zones is 99.99%.

Financial services: Use a Region Pair for disaster recovery. Primary region is East US, secondary is West US. SQL Database geo-replication ensures data is replicated asynchronously. If East US fails, manually fail over to West US. This meets regulatory requirements for geographic separation.

Media streaming: Use zone-redundant storage for video files. If one zone fails, the files are still accessible from other zones. This avoids downtime during peak viewing hours.

Walk-Through

1

Identify Region and Zone Support

First, determine which Azure regions support Availability Zones. As of 2024, not all regions have zones—some older regions (like West Europe) have three zones, while others (like West US) have zones. You can check the Azure documentation or use the CLI: `az account list-locations --query "[?availabilityZoneMappings!=null].name"`. For region pairs, every region has a paired region (except Brazil South, which is paired with South Central US). This step is crucial because if you choose a non-zone-enabled region, you cannot use Availability Zones, and your SLA will be lower.

2

Design Your Application for Zones

Decide whether to use a zonal or zone-redundant deployment. For VMs, you typically create at least two VMs in different zones and place them behind a load balancer. For stateless applications, this is straightforward. For stateful applications (e.g., databases), you need to consider data replication. For example, Azure SQL Database offers zone-redundant configuration (preview). You must also ensure that your application can handle the latency between zones (typically <2ms). Azure guarantees low latency because zones are within the same region.

3

Deploy Resources Across Zones

In the Azure portal, when creating a VM, select the region and then choose 'Availability zone' and pick a zone (e.g., Zone 1). Repeat for a second VM in Zone 2. Alternatively, use ARM templates or CLI. For example, to create two VMs in different zones: `az vm create --resource-group myRG --name vm1 --zone 1 --image UbuntuLTS` and `az vm create --resource-group myRG --name vm2 --zone 2 --image UbuntuLTS`. Then create a Standard Load Balancer and add both VMs to its backend pool. The load balancer will distribute traffic across zones.

4

Set Up Disaster Recovery with Region Pairs

For critical applications, configure disaster recovery across a region pair. For Azure VMs, use Azure Site Recovery to replicate VMs from the primary region to the secondary region. For Azure SQL Database, enable active geo-replication. For storage, use geo-redundant storage (GRS) which replicates data asynchronously to the paired region. This ensures that if the primary region experiences a disaster, you can fail over to the secondary region. Note that failover is not automatic—you must initiate it (except for some services like Azure DNS).

5

Test Failover and Validate SLAs

Regularly test your disaster recovery plan by performing a failover drill. Azure Site Recovery allows you to do a test failover without impacting production. After failover, ensure your application works correctly. Also, understand the SLAs: For VMs deployed across two Availability Zones, the SLA is 99.99%. For VMs in the same Availability Set (without zones), it's 99.95%. For a single VM, it's 99.9%. These SLAs are important for exam questions—know the numbers.

What This Looks Like on the Job

Scenario 1: E-commerce Website with High Availability

A retail company runs its e-commerce website on Azure VMs. They want to ensure the site remains available even if a datacenter fails. They deploy two VMs in East US 2—one in Zone 1 and one in Zone 2. Behind them, they place a Standard Load Balancer that distributes traffic. They also use Azure SQL Database with zone-redundant configuration. During a power outage in Zone 1, the load balancer automatically routes traffic to the VM in Zone 2. The database continues to serve reads and writes because it replicates across zones. The site experiences no downtime. Cost: They pay for two VMs (instead of one) and the load balancer. They also pay for the zone-redundant database (higher cost than single zone). This setup achieves 99.99% uptime.

Scenario 2: Financial Services with Disaster Recovery

A bank must comply with regulations requiring geographic separation of data centers. They deploy their primary application in East US and use Azure Site Recovery to replicate VMs to West US (paired region). They also use Azure SQL Database geo-replication to the paired region. During a hurricane that affects East US, they manually initiate a failover to West US. The RPO is 5 minutes (data loss limited to 5 minutes). The RTO is 1 hour (time to bring the application online). They test this quarterly. Cost: They pay for the secondary region resources (VMs, storage, etc.) which are in a stopped/deallocated state most of the time (lower cost). The geo-replication incurs additional storage costs.

What Goes Wrong When Set Up Incorrectly

Single zone deployment: If all VMs are in one zone and that zone fails, the entire application goes down. The SLA drops to 99.9% for a single VM.

No load balancer: If you have VMs in two zones but no load balancer, you must manually redirect traffic. This leads to downtime during failover.

Ignoring region pairs: If you only use Availability Zones but not Region Pairs, a regional disaster (e.g., earthquake affecting the entire region) can still cause total loss. You need both for full resilience.

Misunderstanding replication: Using locally redundant storage (LRS) instead of geo-redundant storage (GRS) means data is not replicated across regions. During a regional failure, data is lost.

How AZ-900 Actually Tests This

Objective Code: AZ-900: Describe core Azure architectural components (15-20% of exam)

The exam tests your ability to distinguish between Availability Zones, Availability Sets, and Region Pairs. Expect 2-3 questions on this topic.

Common Wrong Answers and Why Candidates Choose Them

1.

"Availability Zones and Availability Sets are the same thing." – Wrong. Availability Sets protect against failures within a single datacenter (fault domains and update domains). Availability Zones protect against entire datacenter failures. Candidates confuse them because both are used for high availability.

2.

"Region Pairs are for low-latency replication." – Wrong. Region Pairs are for disaster recovery, not low latency. They are at least 300 miles apart, which adds latency. For low latency, you deploy within the same region or use multiple zones.

3.

"All Azure regions have Availability Zones." – Wrong. Only certain regions (e.g., East US, West Europe) have zones. Older regions (e.g., West US) do not. Candidates assume all regions are equal.

4.

"You must use both Availability Zones and Region Pairs together." – Not necessarily. For many applications, Availability Zones alone provide sufficient resilience. Region Pairs are only needed for disaster recovery across regions.

Specific Terms and Values That Appear on the Exam

SLA values: 99.9% (single VM), 99.95% (two VMs in Availability Set), 99.99% (two VMs across Availability Zones).

Number of zones per region: 3 (minimum) in supported regions.

Distance for region pairs: At least 300 miles.

Replication type: Asynchronous for region pairs.

Services that support zones: VMs, managed disks, load balancers, SQL Database (preview), etc.

Edge Cases and Tricky Distinctions

Brazil South: This region is unique because it is paired with South Central US, which is not in the same geography. This is an exception.

Zone-redundant vs. zonal: Zone-redundant means the resource is automatically distributed across zones (e.g., Azure SQL Database). Zonal means you choose a specific zone (e.g., a VM).

Update domains vs. fault domains: Availability Sets use fault domains (physical separation) and update domains (planned maintenance). Availability Zones are more granular.

Memory Trick

"Zones are for zone-out (local failures), Pairs are for pair-ic (regional disasters)." Remember: Zones = within one region, Pairs = across regions.

Key Takeaways

Availability Zones are physically separate datacenters within an Azure region, each with independent power, cooling, and networking.

Not all Azure regions support Availability Zones; check Azure documentation for supported regions.

Deploying at least two VMs across two different Availability Zones achieves a 99.99% SLA.

Region Pairs are two Azure regions in the same geography, at least 300 miles apart, used for disaster recovery.

Data replication across Region Pairs is asynchronous, meaning there is a potential for data loss (RPO of minutes).

Availability Sets are an older concept that protect against failures within a single datacenter using fault domains and update domains.

The Brazil South region is an exception—it is paired with South Central US, which is not in the same geography.

For disaster recovery, use Azure Site Recovery for VMs and geo-replication for databases across Region Pairs.

Zone-redundant services (e.g., Azure SQL Database) automatically distribute data across zones; zonal services require manual placement.

Always test your failover plan regularly to ensure it works as expected.

Easy to Mix Up

These come up on the exam all the time. Here's how to tell them apart.

Availability Zones

Protects against datacenter failures

Uses physically separate datacenters within a region

Offers 99.99% SLA with two VMs

Requires region support (not all regions)

Resources can be zone-redundant or zonal

Availability Sets

Protects against rack-level failures

Uses fault domains and update domains within one datacenter

Offers 99.95% SLA with two VMs

Available in all regions

All resources are within the same datacenter

Watch Out for These

Mistake

Availability Zones are available in every Azure region.

Correct

Not all regions support Availability Zones. Only regions that have been updated with the necessary infrastructure (e.g., East US 2, West Europe) offer zones. Older regions like West US do not. Always check the Azure documentation.

Mistake

Availability Zones and Availability Sets provide the same level of protection.

Correct

Availability Sets protect against failures within a single datacenter (e.g., a rack failure) by spreading VMs across fault domains. Availability Zones protect against entire datacenter failures by placing VMs in physically separate datacenters. Zones offer higher resilience.

Mistake

Region Pairs are used for low-latency data replication.

Correct

Region Pairs are designed for disaster recovery, not low latency. The paired regions are at least 300 miles apart, which introduces significant latency. For low latency, use Availability Zones or deploy within the same region.

Mistake

You must deploy resources across all three Availability Zones to get the 99.99% SLA.

Correct

The 99.99% SLA requires at least two VMs deployed across two different Availability Zones. You do not need three zones. However, deploying across three zones provides even higher resilience.

Mistake

When using Availability Zones, data is automatically replicated across zones.

Correct

Data replication is not automatic. You must configure it. For example, managed disks are zone-specific unless you use zone-redundant storage (ZRS). For databases, you need to enable zone redundancy explicitly.

Frequently Asked Questions

What is the difference between an Availability Zone and an Availability Set?

An Availability Zone is a physically separate datacenter within an Azure region, with its own power, cooling, and networking. An Availability Set is a logical grouping of VMs within a single datacenter that spreads them across fault domains (different racks) and update domains (planned maintenance windows). Availability Zones provide higher resilience because they protect against entire datacenter failures, while Availability Sets protect against rack-level failures. For the exam, remember that Zones are for cross-datacenter resilience, Sets are for intra-datacenter resilience.

How many Availability Zones does an Azure region typically have?

Most regions that support Availability Zones have at least three zones. However, some regions may have more. For example, East US 2 has three zones. The exam may test that the minimum is three, but you should know that the exact number can vary. Always check the region's capabilities in the Azure portal or documentation.

Can I use Availability Zones for all Azure services?

No, not all Azure services support Availability Zones. Services that commonly support zones include Virtual Machines, Managed Disks, Load Balancer (Standard SKU), VPN Gateway, and Azure SQL Database (preview). Services like Azure Functions (Consumption plan) or Azure App Service (some tiers) may not support zones. Always verify in the service documentation. For the exam, know that VMs and load balancers are zone-enabled.

What is the SLA for a single VM in an Availability Zone?

The SLA for a single VM is 99.9%, regardless of whether it is in an Availability Zone or not. The 99.99% SLA applies only when you have two or more VMs deployed across two or more Availability Zones. The 99.95% SLA applies to two or more VMs in an Availability Set. These SLA numbers are frequently tested on the exam.

How do I choose between Availability Zones and Region Pairs?

Use Availability Zones for high availability within a region—they protect against datacenter failures and provide low-latency connectivity. Use Region Pairs for disaster recovery across regions—they protect against region-wide disasters but have higher latency and potential data loss. For maximum resilience, combine both: deploy across zones for local HA and replicate to a paired region for DR. The exam expects you to understand the trade-offs.

What is the difference between zonal and zone-redundant deployment?

Zonal deployment means you explicitly choose a specific zone for each resource (e.g., create a VM in Zone 1). Zone-redundant means Azure automatically distributes the resource across multiple zones (e.g., a zone-redundant load balancer or SQL Database). Zonal gives you control but requires manual load balancing; zone-redundant is simpler but may not be available for all services.

Is data automatically replicated across Availability Zones?

No, data is not automatically replicated across zones. You must configure replication. For managed disks, you can use zone-redundant storage (ZRS) to replicate across zones. For databases, you need to enable zone redundancy. By default, resources are zonal—they stay in the zone you choose. The exam may test that zone-redundant storage is an option for data replication.

Terms Worth Knowing

Ready to put this to the test?

You've just covered Availability Zones and Region Pairs — now see how well it sticks with free AZ-900 practice questions. Full explanations included, no account needed.

Done with this chapter?