Azure's physical footprint: regions, region pairs, sovereign regions, availability zones and datacenters

Why this matters

Every Azure resource runs in a real building somewhere, and where that building is decides three things a business cares about: how fast the application feels to its users, whether its data stays inside the borders a regulator has drawn, and what survives when something breaks. Choosing a location is usually the first decision in any deployment, and it is one of the hardest to change later, because moving a running workload to another region means rebuilding it there.

A manager needs this vocabulary to answer an auditor who asks where customer records are kept. A salesperson needs it when a customer in the public sector asks whether Azure can meet government isolation rules. A junior administrator needs it to know that putting two virtual machines "in the same region" protects against far less than putting them in two availability zones. Teams that skip this end up with an application in the wrong country, or with a "highly available" design that one power failure can take down.

The lesson

Regions, region pairs and sovereign regions

A region is a geographical area that contains one or more datacenters, close enough together to be linked by a fast, low-latency network. Azure has regions on every inhabited continent, with names such as East US, West Europe, UK South, Japan East and Australia East. When you create most Azure resources, you choose the region they run in.

Regions are grouped into geographies. A geography is a discrete market, such as the United States, Europe, Canada or Japan, that usually holds two or more regions. Geographies matter because they mark data residency and compliance boundaries: data kept in a region inside a geography is held to that geography's rules.

Four things usually decide which region a workload goes in:

• Latency. The further the users are from the region, the longer every request takes. A shop whose customers are mostly in Japan, but whose app runs in the eastern United States, will feel slow to them however large its servers are. Redeploying to a region near Japan is what shortens the path. Bigger virtual machines, or spreading them across zones in the same US region, do nothing for distance.
• Data residency and compliance. If a regulator says a Canadian bank's customer records must stay in Canada, the bank picks a region physically located in Canada. Lower prices or more features elsewhere do not matter if using them would break the rule.
• Service availability. Microsoft does not offer every service in every region. New services often reach some regions before others, so an architect checks that every service a workload needs exists in the chosen region before committing to it.
• Price. The same service can cost different amounts in different regions. When two regions are both close enough to the users and both offer every service needed, price is a reasonable way to decide between them. Management groups and billing accounts are not tied to a region, so they are never a factor in where resources go.

Some services are not deployed to a region at all. Non-regional (or global) services, such as Microsoft Entra ID and Azure DNS, are not placed in a region by the customer, and Microsoft keeps them running even through the loss of a zone or a whole region.

Region pairs. Many Azure regions are paired with another region in the same geography, usually hundreds of kilometres away. Microsoft sets the pairs; customers cannot choose a partner region. East US is paired with West US, for example, and UK South with UK West. Newer regions are not always paired, so "many regions" is accurate and "every region" is not. The pairs exist to support disaster recovery, and they do that in three ways:

• Updates go to one region of a pair at a time. If a planned platform update turns out to be faulty, the other region is still on the previous version and can keep serving workloads. This limits how far a bad update can spread. It does not give customers any choice over when maintenance happens.
• Recovery is prioritised. In a broad outage that hits many regions, Microsoft prioritises restoring one region of each pair.
• Some services replicate to the pair. Geo-redundant storage, for instance, keeps three copies of data in the primary region and copies it asynchronously to the paired region (lesson 9 covers storage redundancy in full).

The pairs are kept far apart on purpose, so they do not share power or suffer the same natural disaster, but they normally stay in the same geography and often the same country, which keeps replicated data inside the same residency boundary. A small number of pairs cross a border, so check the pair if residency is strict.

Sovereign regions are instances of Azure that are physically and logically isolated from the public Azure cloud. They exist to meet strict legal, compliance and government requirements, not to get new services first, not to be cheaper and not to back up public regions. Two are worth knowing:

• Azure Government is for US government agencies and their partners. It is physically isolated from public Azure, and it is operated by screened US personnel. A region pair inside the United States is still public Azure, so it does not give that isolation.
• Azure in China, also called Azure operated by 21Vianet, serves customers inside mainland China. It is operated by 21Vianet, a Chinese company, under an arrangement with Microsoft, not by Microsoft itself. It needs its own separate account and has its own portal; an ordinary public Azure account cannot reach it.

Sovereign clouds often receive new services later than the public regions do.

Availability zones

An availability zone is one or more physically separate datacenters within a single region. Each zone has its own independent power, cooling and networking. If one zone loses power, the others in the region keep running. Zones in a region are joined by Microsoft's high-speed, low-latency private fibre network, which is fast enough for services to copy data between zones synchronously. They are not linked over the public internet, and they are not linked by an ExpressRoute circuit (ExpressRoute connects a customer's own network to Azure, as lesson 8 explains).

Two facts about zones are tested often:

• Not every region has availability zones. In a region without them, the portal shows no zone choices. If an administrator wants a zone-redundant database and sees no zone options, the region is the likely reason.
• A region that supports zones has a minimum of three. Three means a zone-redundant service can lose one zone and still keep running with copies in the other two.

Services use zones in one of three ways, and the names are worth learning exactly:

A zonal VM pinned to zone 2 runs only in zone 2. To survive a zone failure with zonal resources, you deploy more than one and place them in different zones. Two web server VMs, one in each of two zones, keep an app online if an entire datacenter in the region loses power.

Spreading an application across zones gives two outcomes at once: protection from the failure of a single datacenter, and low-latency links between the copies, because the zones are close together. It does not give lower latency for users on other continents, because every zone is in the same region. It does not create copies in the paired region, because that comes from geo-replication. And it does not isolate anything from public Azure.

Zones work for data as well as for virtual machines. A company that wants its storage to survive the loss of one datacenter, while keeping every copy inside one region, uses zone-redundant storage (ZRS), which writes copies synchronously across three zones. Locally redundant storage (LRS) keeps its three copies within a single datacenter, so losing that datacenter could make the data unavailable. Geo-redundant options send a copy to another region, which a "single region" requirement rules out.

Do not confuse zones with availability sets. An availability set spreads VMs across racks with separate power and network hardware (fault domains) inside a single datacenter. It protects against a rack or host failing, not against the whole datacenter going down. Lesson 7 covers availability sets in detail.

Azure datacenters

An Azure datacenter is a physical facility: a building full of racks of servers, with its own power, cooling and network infrastructure. Datacenters are the bottom layer of Azure's physical structure:

• datacenters are grouped into availability zones;
• zones (or, in regions without zones, the datacenters themselves) make up a region;
• regions are grouped into geographies, and many regions are paired.

Customers do not deal with datacenters directly. They deploy to a region, and optionally to a zone, and Azure decides which datacenter and which hardware the resource runs on. A customer cannot pick a datacenter by its street address, cannot lease cage space to install its own servers (that is colocation, a different model), and cannot visit a datacenter on request. Microsoft owns and runs the buildings and the hardware.

That is why, under the shared responsibility model from lesson 1, physical security of the datacenters is always Microsoft's responsibility, for IaaS, PaaS and SaaS alike. Even when a customer runs its own virtual machines, it manages the operating system and the data on them, never the building, the power or the physical access controls.

Keep the physical and the logical apart. A datacenter is a building. A resource group is a logical container that organises resources for management and has no physical existence (lesson 6). A subscription is a billing and access boundary, not a place.

What the exam is really asking

Most questions in this area describe a failure or a requirement and ask which layer handles it. Match the scope:

• One rack or host fails: an availability set (fault domains in one datacenter).
• One datacenter fails: availability zones, which are separate datacenters in one region, or zone-redundant storage.
• A whole region fails: the paired region, through geo-replication and Microsoft's recovery priority.
• Legal isolation from public Azure: a sovereign region, such as Azure Government or Azure operated by 21Vianet, not a region pair.
• Users far away: a region closer to them. Zones and bigger VMs do not reduce distance.
• Data must stay in one country: a region physically in that country.

The common traps are mixing up a zone (inside one region) with a region pair (two regions), treating every region as having zones or a pair, believing customers choose their pair or their datacenter, and saying 21Vianet's service is run by Microsoft. Learn the three words zonal, zone-redundant and non-regional, and the minimum of three zones in a region that has them.