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 has a large global footprint, but counts and competitor comparisons change; use Microsoft’s current regions catalog when choosing a location. 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 groups regions around a market and may support data-residency needs, but actual storage, processing, support access, and replication depend on the particular service and configuration. Selecting a European region alone does not establish GDPR compliance; assess the service’s data-location terms and the organization’s full legal obligations.

Three facts to know about regions

Availability Zones

Availability Zones (AZs) are physically separate locations within a single region, each containing one or more datacenters. 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 commonly offers three or more zones; check the current regional configuration for the chosen service.

Three deployment patterns to know:

• 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). Can tolerate a zone outage when the service and application are correctly configured; recovery behavior depends on the service.
• 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. If the application and load balancer are configured for healthy cross-zone routing and have enough remaining capacity, traffic can continue through Zones 1 and 3. Do not infer a universal 99.99% SLA or zero visible interruption from placement alone; verify the relevant service SLA and architecture conditions.

Trap: Availability Zones are intended to reduce the impact of a zone-level failure inside a region when the workload uses them correctly. They do NOT protect against an entire region going offline — that is the job of multi-region designs and region pairs.

Region Pairs

Some Azure regions have a Microsoft-designated region pair, usually in the same geography; exceptions include Brazil South paired with South Central US. Other regions are unpaired. Microsoft has described a 300-mile separation target where possible, not a universal guarantee. Pairing can inform platform-update and recovery planning, but schedules and priorities are service-dependent and do not make a customer workload highly available by themselves. Design, deploy, replicate, and test a recovery path explicitly.

The published outline includes region pairs as a concept. A customer may choose a suitable secondary region instead of assuming the designated pair is the best or only disaster-recovery target.

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; serves eligible U.S. government organizations and partners under service-specific compliance offerings; verify current eligibility and certifications.
• Azure China — operated by 21Vianet, a local partner, NOT Microsoft directly, with separate accounts and identity under China-specific service terms.

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. Legal and contractual requirements may constrain region choice. Verify the relevant service data flows; a region choice alone never guarantees regulatory compliance.
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 zone-level resilience where supported, and arrange replication and tested failover to a second eligible region 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 — honor applicable residency constraints, and Microsoft's HQ location is never a deployment factor.