What's actually inside an Azure region? From the planet to one server, then we break it

Every deployment starts with the same small decision. You open a form, find the Region dropdown and pick something like UK South. It feels like a setting. It's actually a choice about which buildings, power supplies and fibre your app depends on, and which failures it can ride out.

This post walks down through every layer, from the global network to a single server, then breaks things on purpose. Everything here comes from Microsoft's own documentation, linked at the end.

The layers, top to bottom

Global networkMore than 80 regions joined by a private network spanning more than 500,000 miles

GeographyA distinct market. The United Kingdom has UK South (London) and UK West (Cardiff)

RegionA set of datacentres inside a latency-defined perimeter

Availability zoneOne or more datacentres with independent power, cooling and networking

DatacentreFences, officers, biometrics, metal detectors, UPS, batteries and generators

HostA physical server. Your VM usually shares it with other customers' VMs

The network that ties it together

Microsoft describes its global network as one of the largest in the world, spanning more than 500,000 miles and connecting more than 80 Azure regions. It connects with more than 4,000 internet partners at more than 190 locations. Traffic between Azure datacentres or regions stays on Microsoft's network rather than crossing the public internet.

Geography and region

A geography is a distinct market. A region is a set of datacentres deployed within a latency-defined perimeter: close enough together to behave like one place, but not one single building. When you deploy to UK South you never pick a datacentre. You pick the region, and optionally a zone.

Availability zones

Most regions that support zones have three of them. Microsoft's definitions are precise, so here they are with as little paraphrasing as possible:

• A zone is a logical grouping of one or more physically separate datacentres, with independent power, cooling and networking.
• Zones are typically several kilometres apart, and usually within 100 kilometres of each other.
• They're linked by a high-performance network with a round-trip latency of less than about 2 milliseconds.
• Traffic between zones is always encrypted, and Microsoft places them using more than 30 viability and risk-based criteria.

One detail catches people out: zone numbers are logical. Your "zone 1" in one subscription isn't necessarily the same physical zone as "zone 1" in another subscription. If two subscriptions need to line up, check the mapping rather than assuming.

Zonal

• Pinned to one zone that you choose
• Not resilient to that zone failing
• You're responsible for failover
• Good for latency-sensitive tiers you replicate yourself

Zone-redundant

• Spread across zones by the platform or by you
• Survives the loss of one zone
• For zone-redundant services, Microsoft manages failover
• For VMs, you add a load balancer and handle replication

Inside the building

Microsoft publishes a surprising amount about its datacentres. Access is layered, and each layer is checked separately:

1. Access request. You need a valid business reason, access is need-to-access only, and it expires. Visitors are badged as escort only.
2. Facility perimeter. Typically tall steel and concrete fences around every inch of the perimeter, cameras monitored at all times, guard patrols and bollards.
3. Building entrance. Trained, background-checked security officers who also patrol and watch the cameras.
4. Inside the building. Two-factor authentication with biometrics, and only into the parts you're approved for, for the time you're approved for.
5. Datacentre floor. Full body metal detection on the way in and out, only approved devices allowed, and cameras on the front and back of every server rack.

Power is layered too. Uninterruptible power supplies and banks of batteries cover short disruptions, emergency generators take over for longer outages and planned maintenance, and there are fuel reserves on site.

When a disk reaches end of life it's wiped using a process that complies with NIST 800-88. If it can't be wiped, it's destroyed: disintegrated, shredded, pulverised or incinerated, and the destruction is recorded.

The host

At the bottom of all this is a physical server, which Azure calls a host. A single VM runs on one host, and most VMs share their host with other customers' VMs. For durability, Azure keeps three healthy replicas of your data in the primary location.

Two terms matter once you run more than one VM:

• Fault domains are groups of VMs that share a common power source and network switch. An availability set can use up to 3.
• Update domains are groups that can be restarted at the same time during maintenance. An availability set can use up to 20.

Microsoft's VM documentation is clear that availability sets don't offer the same resiliency as availability zones, and recommends zones when reliability is the priority.

Region pairs

Many regions are paired with another region in the same geography. UK South is paired with UK West. Pairs get staggered platform updates, so both aren't updated at once, and priority in recovery if there's a wide outage. Some services also use the pair as their default replication target.

Two things are easy to miss. Many newer regions don't have a pair at all, and Microsoft says pairing doesn't automatically make your app more resilient. You still have to replicate your data and fail over. Azure Site Recovery can replicate VMs to almost any region, including regions that aren't the pair.

Now break it

Pick how your app is deployed, then pick what fails. The diagram and verdict use the behaviour Microsoft documents for virtual machines.

Assumes two or more VMs where the option says so, with a zone-resilient load balancer doing health checks. Other services, such as zone-redundant storage or databases, handle zone failover for you, so check each service's reliability guide.

A sensible default

• Production that people rely on: run across zones. It costs at least three VMs instead of one, but it covers servers, racks and whole zones.
• Anything that must survive a region: replicate to a second region and rehearse the failover. A plan you've never run is a guess.
• Monitor for zone problems yourself. Microsoft doesn't automatically notify you when a zone is down, and work in flight on a failed VM is likely lost.
• Check zone mappings if you place zonal resources in several subscriptions and expect them to line up.
• Single VMs are fine for dev, test and anything that can wait. Just make that a choice rather than a default.

FAQ

How many datacentres are in a region?

Microsoft doesn't publish a count per region. A region is a set of datacentres, and each availability zone is one or more of them.

Does every region have availability zones?

No. Most regions that support zones have three, and the list of zone-enabled regions is on Microsoft Learn. UK South supports zones.

If I use zone-redundant services, do I still need a second region?

Only if your app must survive the loss of a whole region. Zones protect you from a datacentre or zone failure inside one region. A second region is the only protection against losing the region itself.

Do I have to use the paired region for disaster recovery?

No. Some services replicate to the pair by default, but for VMs you can choose almost any region as the secondary. Data residency rules may limit which regions you can use.