The question this answers
What is a region, what is an availability zone, and which failures does each one actually contain?
The service must keep serving when a data centre loses power, must answer European users within a stated latency budget, and must keep customer records inside the EU because the contract says so.
Two independent controls: placement in a geography with a legal jurisdiction and a distance to your users, and placement across isolated failure domains within that geography so that one facility's failure is survivable.
Two different words for two different problems
A region is a geographic area — a metro, roughly — with its own jurisdiction, its own price list, its own set of available services, and a physical distance to your users that sets a hard latency floor no engineering can remove. Regions are the unit of *data residency* and of *disaster*: a region-wide failure is rare and, when it happens, is the kind of event that makes the news.
An availability zone is one or more physically separate facilities inside a region, engineered to fail independently: separate power, separate cooling, separate network paths, far enough apart that one flood or fire does not take both, close enough that the round trip between them is small enough for synchronous replication. Zones are the unit of *ordinary failure*: a power event, a cooling failure, a network partition inside one building.
The design consequence is precise. Spreading across zones costs a little latency and no meaningful complexity, and it protects against the failures that actually happen. Spreading across regions costs a great deal — a distributed data problem, doubled operational surface, expensive continuous replication — and protects against a failure class that is genuinely rare. That asymmetry is why the honest default is *multi-zone always, multi-region only when a stated requirement forces it.* See Multi-Zone Deployment and Multi-Region Deployment.
Distance is a physical constraint, and it shows up in the design
Latency between zones is small — a fraction of a millisecond to a couple of milliseconds — which is why synchronous replication between zones is a normal design and synchronous replication between continents is not. Latency between regions is bounded below by the speed of light in fibre, and no amount of provider engineering changes it: roughly 5 microseconds per kilometre of fibre, doubled for a round trip, plus routing that is never a straight line.
Concretely: a user in Frankfurt talking to a service in Frankfurt sees single-digit milliseconds. The same user talking to a service in Virginia sees something on the order of 90–100 ms of pure network round trip before the application does any work at all. If the page makes six sequential dependent requests, that is over half a second of nothing but distance. This is why "put a region near the users" is a real latency intervention and "add a bigger instance" is not.
It is also why chatty cross-region designs fail in a way that looks like an application bug. A service in region A calling a database in region B pays that round trip *per query*, and an ORM issuing fifty queries per request turns a 100 ms distance into a five-second page. The fix is architectural — fewer, larger round trips, or the data closer — never a faster instance. See CDN as Infrastructure for the read-path answer.
PATH RTT (order of magnitude) synchronous replication? --------------------------------------- ------------------------ ----------------------- within one rack ~0.1 ms yes, trivially zone A -> zone B, same region ~0.5 - 2 ms yes, this is the normal design region -> region, same continent ~10 - 30 ms painful; usually asynchronous Frankfurt -> Virginia ~90 - 100 ms no. async, and accept an RPO Frankfurt -> Sydney ~250 - 300 ms no. treat as a separate system WHAT THIS MEANS IN PRACTICE 6 sequential dependent requests at 100 ms = 600 ms of pure distance an ORM issuing 50 queries across a region boundary = 5 s per page the fix is fewer round trips or closer data. never a bigger instance. ILLUSTRATIVE: figures are rounded orders of magnitude for teaching. Measure your own paths.
Which failure does each level actually contain?
The value of the region/zone vocabulary is that it lets you state, for each component, which failures it survives. Doing that honestly usually reveals that a design labelled "highly available" survives an instance failure and nothing else, because every redundant copy sits in the same zone or depends on something that does.
The recurring instance of this is egress. A team spreads instances across three zones, feels redundant, and routes all outbound traffic through one NAT device in one zone. When that zone fails, the instances in the surviving zones are running, the load balancer reports them healthy, the internal health check passes — and every outbound call to a payment provider or an identity provider times out. The failure domain of the system was never the instance tier; it was the egress path, and nobody had drawn it.
The other recurring instance is the control plane. Provisioning new capacity, changing DNS, rotating a secret and reading logs all depend on provider APIs, and those APIs are themselves regional. A region incident frequently degrades the ability to *respond* to the region incident, which is why a failover plan that requires making changes in the failing region is not a plan. See Disaster Recovery.
| Failure | Single instance | Multi-instance, one zone | Multi-zone | Multi-region |
|---|---|---|---|---|
| Process crash / OOM | outage | survives | survives | survives |
| Instance or host failure | outage | survives | survives | survives |
| Rack, power or cooling event | outage | outage | survives | survives |
| Zone network partition | outage | outage | survives if egress and data are also multi-zone | survives |
| Region-wide service degradation | outage | outage | outage | survives with a tested failover and an accepted RPO |
| Bad deploy or bad config | outage | outage | outage — it replicates everywhere | outage — it replicates everywhere |
| Data deleted by mistake | data loss | data loss | data loss — replication copies the delete | data loss. only backups help — see Backup Strategy |
Key points
- A region is a jurisdiction and a distance; a zone is a failure domain. They solve different problems and cost radically different amounts.
- Multi-zone is the honest default: it survives the failures that actually occur, costs a cross-zone hop, and adds almost no design complexity.
- Multi-region is a decision forced by a stated latency, residency or recovery requirement — never a default, and never automatically high availability.
- Redundant compute with single-zone egress, DNS or data is not redundant; draw the failure domain of every dependency, not just the ones you scaled.
- Replication propagates deletes and bad configuration. No amount of geographic spread substitutes for backups.
The loop, answered
Every field is required, which is why no lesson here can recommend something without saying what it costs and what simpler thing to consider first.
- • The provider maps a zone identifier onto one or more physically separate facilities with independent power, cooling and network paths inside a metro area.
- • Zones inside a region are joined by high-bandwidth, low-latency private links, which is what makes synchronous cross-zone replication and a single regional load balancer possible.
- • Regional services (object storage, managed queues, most load balancers) are already spread across zones by the provider; zonal resources (an instance, a disk, a NAT device) are not, and you place them yourself.
- • Cross-region connectivity runs over the provider backbone or the public internet, is metered per gigabyte, and is bounded below by the speed of light.
- • Placing every zonal resource deliberately, including the ones that are easy to forget: NAT devices, disks, cache nodes and the standby database.
- • Verifying that a zone failure is actually survivable, by removing a zone on purpose rather than by reasoning about the diagram.
- • Tracking which services in your design are regional and which are zonal; the list differs by provider and changes over time.
- • Owning the residency claim: knowing where every copy of the data is, including backups, logs and the analytics pipeline nobody put on the diagram.
- • A zone fails and the surviving instances lose outbound connectivity because the single NAT device lived in the failed zone — internal health checks stay green throughout.
- • A zone fails and capacity does not recover, because the remaining zones had no headroom and the scale-out competes with every other tenant doing the same thing at the same moment.
- • A "multi-zone" database turns out to have its standby in the same zone as the primary, because the placement was left to a default.
- • A region incident degrades the provider control plane, so the runbook step "provision replacement capacity" cannot be executed.
- • Data residency is violated by a component nobody classified as data: logs, traces or a backup replicated to a cheaper region.
- • Capacity is per zone, and a zone can run out of a particular instance type independently — designs pinned to one instance family in one zone are the ones that fail to scale during an incident.
- • Cross-zone traffic is usually metered, so a chatty service that lands randomly across three zones pays for a third to two-thirds of its internal traffic crossing a boundary.
- • Adding a region multiplies the operational surface and does not add capacity for a single user, since a user is served by one region at a time.
- • Region choice is a compliance control: it decides jurisdiction, which decides who can compel access to the data.
- • Zones are a reliability boundary, not a security boundary. Nothing about a zone limits what an identity can reach — that is Least Privilege in Infrastructure's job.
- • Residency obligations extend to every derived copy: backups, snapshots, logs, traces, analytics exports and the disaster-recovery region.
- • A second region doubles the surface where a secret, key or policy must be correct, and a rotation that misses one region fails silently until failover.
- • Cross-zone traffic is usually metered per gigabyte in at least one direction — a real, recurring cost of doing multi-zone correctly.
- • Zone redundancy multiplies the fixed cost of zonal components: three zones means three NAT devices, not one.
- • Cross-region replication is continuous, bidirectional in active-active designs, and typically the most expensive transfer rate on the price list.
- • Regions have different price lists for identical resources; a workload placed for latency may cost meaningfully more than the same workload elsewhere.
- • Per-zone health and per-zone request distribution — an even split is the evidence that zone redundancy is real rather than declared.
- • Cross-zone and cross-region transfer volumes, which are simultaneously the cost signal and the "this service is chattier than we designed" signal.
- • Replication lag on any standby, because lag is exactly the data you lose on failover — see RPO & RTO.
- • The signal that lies: a regional aggregate health check. It stays green while one zone is completely dead, because two thirds of the fleet is answering.
- • A single zone with good backups, for internal tools and anything where a few hours of downtime is genuinely acceptable. Stating that acceptance is more honest than a half-built redundancy that has never been tested.
- • Multi-zone within one region for essentially every production system — this is the alternative to multi-region, and it is the right one far more often than the industry discourse suggests.
- • A CDN plus read replicas instead of a second region, when the requirement is read latency for distant users rather than survival of a region.
- • Backup and restore into a second region (a cold recovery plan) instead of running one, when the RTO is measured in hours rather than minutes. Vastly cheaper and far easier to keep correct.
- • Multi-zone buys survival of the common failures and charges cross-zone traffic plus duplicated zonal components. Almost always worth it.
- • Multi-region buys survival of a rare failure class and charges a permanent distributed-data problem, doubled operations and the highest transfer rates on the price list.
- • Choosing a region for latency may conflict with choosing it for cost, service availability or residency; these constraints frequently do not have a common solution and someone has to decide which loses.
Regions, zones and failure domains
failure domain = the set of things that fail together same process → a crash takes all of it same host → a kernel panic takes all of it same zone → one power or network event takes all of it same region → a control-plane or provider event can take all of it copies only count once they stop sharing the domain that failed
What people believe, and what is true
Availability zones are just data centres in different cities.
They are close enough for low-millisecond round trips — same metro, usually — which is precisely what makes synchronous replication between them practical. Different cities would be different regions.
Multi-region means highly available.
It means you have a second copy of the infrastructure. Availability comes from a failover that has been tested, an agreed RPO, and a plan that does not require acting inside the failing region.
Replication across zones protects the data.
It protects against hardware loss. It faithfully replicates an accidental DELETE and a bad migration to every copy. Only backups with retention protect against that — see Backup Strategy.