2.1 Azure Regions and Availability Zones

Azure Regions and Geographies

An Azure region is a set of one or more datacenters deployed inside a latency-defined perimeter and connected by a dedicated regional low-latency network. Azure advertises 60+ regions across 140+ countries, the largest footprint of any public cloud (AWS and Google Cloud have fewer). On the AZ-900 you do not memorize region names; you must know what a region is and the rules that govern it.

A geography is a discrete market (for example United States, Europe, Asia Pacific) that typically contains two or more regions and enforces data-residency and compliance boundaries. Data you store in a region stays inside that geography unless you explicitly configure replication elsewhere. This is the mechanism that lets you satisfy laws such as the EU's GDPR: deploy in West Europe or North Europe and your data stays in the EU geography.

Three facts the exam tests about regions

Availability Zones

Availability Zones (AZs) are physically separate datacenters within a single region. Each zone has its own independent power, cooling, and network and is far enough from the others to avoid a shared local disaster, yet close enough for low-latency replication over Microsoft's private fiber. A region that supports zones has a minimum of three zones.

Three deployment patterns appear on the exam:

• Zonal services — you pin a resource to one specific zone (for example, place VM-A in Zone 1). Fast intra-zone communication, but the zone is a single point of failure.
• Zone-redundant services — Azure spreads the resource across zones automatically (zone-redundant Azure SQL Database, ZRS storage). Survives a full zone outage with no action from you.
• Non-regional (global) services — never tied to a region at all: Microsoft Entra ID, Azure DNS, Azure Front Door, Traffic Manager.

Worked example

You run a web tier across Zones 1, 2, and 3 behind a zone-redundant load balancer. Zone 2 loses power. Traffic shifts to Zones 1 and 3 with no customer-visible outage. Spreading two or more VMs across zones is what unlocks the 99.99% VM uptime SLA — a single VM with premium SSD only reaches 99.9%.

Trap: Availability Zones protect against a datacenter-level failure inside a region. They do NOT protect against an entire region going offline — that is the job of multi-region designs and region pairs.

Region Pairs

A region pair is two regions inside the same geography that Microsoft links for resiliency, ideally 300+ miles (≈480 km) apart to reduce the chance one disaster takes out both. (Microsoft notes the 300-mile target is not achievable in every geography.) The two benefits:

1. Sequential maintenance — planned platform updates roll to only one region of a pair at a time, never both simultaneously.
2. Prioritized recovery — in a broad outage, one region per pair is recovered first.

Note: Microsoft is steering customers toward self-selected disaster recovery and zone-redundant designs rather than fixed pairs, but region pairs remain valid AZ-900 content.

Sovereign Clouds

Sovereign clouds are physically and logically isolated instances of Azure, with their own portal, identity, and billing — they are not just regions.

• Azure Government — for US federal, state, local agencies and contractors; meets FedRAMP High, DoD SRG, ITAR, CJIS; access requires verification of US-government affiliation.
• Azure China — operated by 21Vianet, a local partner, NOT Microsoft directly, to satisfy Chinese data-sovereignty law; separate accounts and identity.

Exam reflex: "Operated by 21Vianet" = Azure China. "FedRAMP High / DoD" = Azure Government. A separate, isolated portal = a sovereign cloud, not a region.

Choosing the Right Region

When a scenario asks where to deploy, evaluate four factors in this order:

1. Compliance and data residency (first) — a legal or regulatory rule that says data must stay in a country or geography overrides everything else. GDPR (EU), HIPAA-adjacent state laws, and government mandates are the usual triggers. If a question mentions a law about where data lives, the residency answer wins.
2. Proximity to users — once compliance is satisfied, pick the region closest to the bulk of your users to minimize latency. A user in Sydney served from East US suffers far higher round-trip time than one served from Australia East.
3. Service and feature availability — confirm the specific service, VM size, or GPU you need actually exists in that region; newer offerings roll out region-by-region.
4. Cost — identical resources can be priced differently across regions, so among otherwise-equal options, choose the cheaper one.

Putting the pieces together

A single resilient deployment can stack all four concepts at once: choose a region in a compliant geography, spread instances across that region's Availability Zones for datacenter-level resilience and the 99.99% SLA, and replicate to a second region (a paired region or a self-selected DR target) for region-level disaster recovery. AZ-900 expects you to match each concept to the failure it addresses: a zone outage versus a whole-region outage versus a legal residency requirement.

Trap: Do not pick "lowest price" or "closest to Microsoft headquarters" when any compliance requirement is stated — residency always comes first, and Microsoft's HQ location is never a deployment factor.