Azure Regions, Region Pairs, and Sovereign Clouds

An Azure region is a set of datacenters within a defined geographic perimeter, connected by a dedicated low-latency network, and it’s the primary unit you choose when deciding where a resource physically lives. A region pair links two regions in the same geography (typically 300 miles or more apart) so Microsoft can stagger platform updates and offer built-in disaster recovery between them. Sovereign clouds, such as Azure Government and Azure operated by 21Vianet, are separate, isolated instances of Azure built to satisfy specific national legal or security requirements that standard public regions can’t meet.

Datacenter, region, and geography: three different scopes

These three terms describe increasingly larger scopes, and AZ-900 tests the boundaries between them directly:

• Datacenter: a single physical building with its own power, cooling, and networking, housing the actual servers. You never choose an individual datacenter when deploying a resource; you choose a region or Availability Zone instead, and Microsoft manages the physical facility behind that choice.
• Region: a set of one or more datacenters deployed within a latency-defined perimeter and connected through a dedicated network. This is the scope you actually pick in the portal (East US, West Europe, and so on), and it determines where your data physically resides.
• Geography: a broader area of the world, often aligned with a country or set of countries, that contains at least one region and is used to reason about data residency and compliance boundaries. A geography can contain multiple regions, giving you a choice of where within a compliant boundary to deploy.

A helpful way to keep these straight: datacenters are physical buildings, regions are groups of those buildings that communicate fast enough to act as one deployment target, and geographies are the legal/compliance wrapper that regions sit inside.

Region pairs: built-in disaster recovery and staggered updates

Microsoft designates most Azure regions as part of a pair with another region in the same geography. That pairing does two concrete things:

1. Disaster recovery. Services like geo-redundant storage (GRS) replicate data asynchronously to the storage account’s designated paired region by default, giving durability against a full regional outage without any manual configuration of a destination. During an actual regional incident, Azure Service Health is what surfaces personalized alerts about which specific resources are affected.
2. Staggered platform updates. Microsoft rolls out planned platform updates to only one region in a pair at a time. This reduces the risk that a single bad update takes down both halves of the pair simultaneously, and it preserves a healthy region to recover to if something does go wrong.

Region pairing is a deliberate, documented relationship, not something you configure yourself, and it’s not the same thing as choosing a region “near” another one. A small number of pairs are documented exceptions that cross geography boundaries: Brazil South, for example, is paired with South Central US rather than another region inside Brazil. If a scenario depends on a region pair staying within a specific country, that’s a detail worth verifying rather than assuming.

Region pairs are also not interchangeable with Availability Zones. Availability Zones protect against a single datacenter failure inside one region; a region pair protects against the loss of an entire region. A resilient architecture typically uses both: zones for datacenter-level fault tolerance within the primary region, and the paired region for full regional failover, keeping replication latency low because paired regions share a geography.

Choosing a region: latency and data residency

Two practical factors drive region selection outside of disaster recovery. The first is latency: choosing a region physically close to your concentration of users directly reduces the network distance data has to travel, which is the most effective lever for cutting perceived application latency for a geographically concentrated audience. The second is data residency: an organization that must keep customer data within a specific country’s borders (a common requirement for government or financial services workloads, and part of the broader compliance and governance benefits of the cloud) satisfies that by selecting a region located inside that country, since region choice is what determines the physical jurisdiction data resides in. Availability Zones, management groups, and resource group naming conventions don’t affect either of these; only the region selection does. Region choice also feeds directly into cost, since list pricing varies by region — see what affects your Azure bill for the other factors involved.

Sovereign clouds: isolated instances for specific jurisdictions

Standard Azure regions are part of the global commercial cloud. A sovereign region is different: it’s a physically and operationally isolated instance of Azure, run specifically to satisfy a jurisdiction’s legal, compliance, or national security requirements that the global cloud can’t meet.

Concept	Scope	Example
Datacenter	Single physical building	One facility within a region
Region	Group of datacenters, low-latency network	East US, West Europe
Region pair	Two regions, same geography, DR + staggered updates	East US paired with West US
Geography	Country or set of countries, compliance boundary	United States, Europe
Sovereign region	Isolated Azure instance for specific legal requirements	Azure Government, Azure operated by 21Vianet

Two examples cover almost everything AZ-900 asks about sovereign clouds:

• Azure Government is operated separately from commercial Azure for United States federal, state, and local agencies and their vetted partners, with physically isolated infrastructure and screened personnel. Availability Zones or a resource lock in a standard region don’t substitute for this; only the sovereign offering satisfies government-only access-control and personnel-screening requirements.
• Azure operated by 21Vianet serves mainland China and is run by a licensed local partner, physically and operationally separate from global Azure, with no direct connectivity to it. Subscriptions and tools used in global Azure don’t carry over; that separation is exactly why organizations expanding into China sometimes find they can’t manage China-based resources through their existing global endpoints.

Sovereign regions are not paired with standard public regions for disaster recovery. Region pairing is a relationship among regions within the public cloud’s own geographies; a sovereign instance sits outside that structure entirely, which is a distinction the exam calls out directly.

How the AZ-900 exam tests this

• The definitional stack. A question asks you to distinguish a datacenter from a region, or a region from a geography; the physical-building-versus-group-versus-country-scale distinction is the whole test.
• The disaster recovery scenario. An organization wants a cost-effective DR strategy without researching an arbitrary secondary location; the answer leans on Microsoft’s predefined region pair rather than picking a random region on another continent.
• The “why stagger updates” scenario. A question asks why Microsoft updates only one region in a pair at a time; the answer is reducing simultaneous outage risk, not a regulatory requirement or shared hardware.
• The sovereign-versus-standard scenario. A U.S. federal contractor or a company entering the Chinese market needs an Azure option standard regions can’t provide; the answer is Azure Government or Azure operated by 21Vianet, not Availability Zones or a stricter Azure Policy assignment.
• The latency-versus-residency scenario. A question gives either a performance goal (reduce buffering for a concentrated user base) or a legal goal (keep data in-country) and asks what to change; both point back to region selection, just for different reasons.

You can work through AZ-900 practice questions built around exactly these distinctions to get comfortable sorting a scenario into “physical scope,” “disaster recovery,” or “sovereign compliance” on sight.

Quick reference

• A datacenter is a physical building; a region is a group of datacenters on a shared low-latency network; a geography is a country-scale compliance boundary containing one or more regions.
• Region pairs link two regions in the same geography for disaster recovery and staggered platform updates; a few documented pairs cross geography lines (Brazil South and South Central US).
• Geo-redundant storage (GRS) replicates asynchronously to a storage account’s designated paired region by default.
• Region selection is the primary lever for both network latency (choose a region near your users) and data residency (choose a region inside the required jurisdiction).
• Availability Zones protect against a single datacenter failure within one region; region pairs protect against the loss of an entire region.
• Sovereign regions (Azure Government, Azure operated by 21Vianet) are isolated instances built for specific legal or national security requirements, not just stricter versions of a standard region.
• Sovereign regions are not paired with standard public regions; region pairing only occurs within the commercial cloud’s own geographies.