This chapter covers Availability Zones and Region Pairs — two related but distinct ways Azure protects workloads from failure at different scales. AZ-900 tests these under objective 2.1, part of the "Describe Azure Architecture and Services" domain, one of the largest sections of the exam.
Jump to a section
A simple way to picture Availability Zones and Region Pairs
Picture a hospital that keeps a backup generator in the basement of its main building. That protects against a power-grid outage — but if a fire or flood takes out that specific building, the generator goes down with it. A more resilient hospital keeps a second, fully independent generator in a separate building on the same campus, with its own power feed, its own cooling, and its own staff. If one building has a local failure, the other keeps running, because the two are physically isolated from each other even though they're minutes apart. That's the idea behind an Availability Zone: not a second copy on the same rack, but a separate physical location — its own power, cooling, and networking — close enough for fast connections, far enough that one localized failure doesn't take both down. A Region Pair takes the same idea and applies it at a much larger scale: instead of two buildings on one campus, it's two entire regions, chosen specifically so a disaster affecting one is unlikely to affect the other at the same time.
What an Availability Zone is
An Availability Zone is a physically separate location within an Azure region — its own datacenter (or set of datacenters), with independent power, cooling, and networking. A region that supports Availability Zones typically has at least three of them, connected by high-speed, low-latency networking so they can work together as if they were one location, while still failing independently.
What a Region Pair is
A Region Pair is a different concept operating at a larger scale: two full Azure regions within the same broader geography, designated by Microsoft to work together for disaster recovery. Services that offer geo-redundant replication (such as geo-redundant storage) copy data to the paired region, so a failure affecting an entire region doesn't mean total data loss.
How they differ
Availability Zone: protects against a localized failure (power, cooling, a single datacenter issue) *within* a region. Choosing a zone-redundant deployment option keeps a workload running even if one zone has a problem.
Region Pair: protects against a much larger-scale event affecting an entire region, by keeping a copy of certain data or services in a separate, paired region.
Not every Azure region has Availability Zones — it depends on the specific region's build-out, so this is worth checking per region rather than assuming it's universal.
Portal and CLI touchpoints
When creating zone-redundant resources (for example, a zone-redundant virtual machine scale set or a zone-redundant storage account), the Azure portal presents a "zone redundancy" or "availability zone" option at deployment time. Azure CLI and ARM/Bicep templates expose the same setting as a zones parameter on supported resource types:
az vm create --resource-group myRG --name myVM --zone 1Region pairing itself isn't something you configure directly — it's a fixed relationship Microsoft defines per region, and services that support geo-redundancy use that existing pairing automatically.
Check whether a region supports zones
Before assuming zone redundancy is available, check the specific target region's documentation — Availability Zones aren't offered in every Azure region. This matters for exam questions that describe a specific region and ask what resiliency options are available there.
Choose a zone-redundant SKU or option
For resources that support it, zone redundancy is usually a deployment-time choice rather than something added afterward. Virtual machine scale sets, some storage tiers, and several PaaS services offer a zone-redundant option at creation.
Understand what geo-redundant storage adds
Geo-redundant storage (GRS) replicates data to the paired region automatically. It protects against a regional-scale event, but it's a separate feature from zone redundancy — a resource can be zone-redundant, geo-redundant, both, or neither, depending on what's configured.
Know that failover isn't always automatic
Even with geo-redundant storage, failing traffic over to the paired region is not always automatic for every service — some require the customer to initiate failover. This is a common point of confusion worth remembering for the exam.
A retail company running its checkout service during a high-traffic sales event deploys its virtual machine scale set across multiple Availability Zones in the same region. When one zone experiences a power issue, the scale set instances in the other zones continue serving traffic, and customers checking out never notice — because the failure was contained to a single zone rather than the whole region.
Separately, a financial services company storing transaction records uses geo-redundant storage so a copy of that data exists in the paired region. If the primary region became unavailable for an extended period, the company would still have the data safely available in the paired region — though depending on the specific service, they might need to actively initiate failover rather than have it happen automatically. Teams sometimes assume failover is instant and automatic for every service, which is one of the most common misconfigurations to watch for when designing for resiliency.
Objective 2.1 asks candidates to describe Azure's approach to high availability and disaster recovery, and Availability Zones vs. Region Pairs is one of the most frequently tested distinctions in that objective.
The most common wrong answer is treating "Availability Zone" and "Region" as the same thing — candidates confuse a zone (a physical location *within* a region) with the region itself. Another common mistake is assuming every region has Availability Zones; the exam sometimes names a specific region and expects you to know that zone support varies. A third common trap is assuming geo-redundant storage failover to the paired region happens automatically for every service — for many services it requires action, not just configuration.
Stable terminology worth knowing: Availability Zone, Region Pair, Geo-redundant storage (GRS), Zone-redundant. These names and their definitions are stable; specific counts or distances associated with them are not something to memorize as fixed numbers.
Memory trick: if the question is about surviving a problem *within* one region, think zones. If it's about surviving the loss of an *entire* region, think region pairs.
An Availability Zone is a physically separate location within a region — its own power, cooling, and networking — used to survive a localized failure.
A Region Pair is two full regions within the same geography, used to survive the loss of an entire region.
Not every Azure region offers Availability Zones — check the specific region rather than assuming.
Geo-redundant storage replicates to the paired region, but failover to that copy is not automatic for every service.
Zone redundancy and geo-redundancy solve different problems at different scales and are configured separately.
These come up on the exam all the time. Here's how to tell them apart.
Availability Zones
Protects against a failure within a single region
Physical locations with independent power/cooling/networking
Low-latency connection between zones in the same region
Not available in every region
Configured per-resource at deployment (e.g. zone-redundant SKU)
Region Pairs
Protects against loss of an entire region
Two full regions in the same broader geography
Higher latency between regions than between zones
Every standard region has a defined pair
Enabled via geo-redundant service options, not a per-resource zone setting
Mistake
Every Azure region has Availability Zones.
Correct
Zone support varies by region — some regions don't offer them. Always check the specific region rather than assuming.
Mistake
Region pairs mean failover is fully automatic.
Correct
Pairing makes geo-redundant replication possible, but for many services, failing over to the paired region requires an explicit action, not just having the data replicated there.
Mistake
Region pairs are separated by a specific, memorizable distance.
Correct
Microsoft designs region pairs with substantial physical separation to reduce the odds a single event affects both, but the exact distance isn't a fixed number worth memorizing — the concept (deliberate geographic separation for resiliency) is what matters for the exam.
Mistake
Zone redundancy and geo-redundancy are the same feature.
Correct
They protect against different scales of failure and are configured independently — a resource can have one, both, or neither.
A Region is Azure's largest geographic building block — a broad area with its own set of datacenters. An Availability Zone is a physically separate location *within* a region. A region that supports zones typically has at least three of them. For the exam, remember: zones live inside a region; they aren't a separate region themselves.
No. Zone support depends on both the specific region and the specific service — some services offer a zone-redundant option, others don't, and availability varies by region. Rather than memorizing a list, understand the concept: zone redundancy is an option to check for on a per-service, per-region basis.
Not always. For many services, geo-redundant replication keeps a copy of your data in the paired region, but the actual failover — redirecting traffic or promoting that copy to primary — often requires action from the customer rather than happening automatically. This distinction between 'data is replicated' and 'traffic has failed over' is a common exam trap.
Region pairs are chosen to be geographically separated within the same broader area, reducing the chance that a single large-scale event (like a natural disaster) affects both regions in the pair simultaneously. The exact criteria and distances aren't published as a fixed number to memorize — the takeaway for AZ-900 is the purpose, not a specific figure.
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?