Failure domains: what a region, a zone and a cell actually buy you

TL;DR: A failure domain is a boundary within which failures correlate. Zones contain physical infrastructure failures, regions add geography and most control planes, and cells contain the failures you cause yourself. A deployment crosses all three, which is why multi-zone alone does not protect you from the most common cause of outage.

The symptom this explains

A service runs in three availability zones. The runbook says it survives the loss of one. Then a single configuration change goes out and the whole service is down in every zone within about a minute.

Nothing about the zone design failed. The change was simply not the kind of failure a zone boundary contains, and the useful skill is being able to say in advance which failures each boundary does contain.

The boundaries, and what each one holds

An availability zone is one or more datacentres with independent power, cooling and network, connected to its siblings by low-latency links. Low latency is not the same as negligible, so do not assume every cross-zone round trip is under a millisecond; measure the path you depend on. A zone boundary contains a power failure, a cooling failure, a fire, a top-of-rack or aggregation switch failure. It does not contain a configuration change pushed to every zone at once, which is a far more frequent cause of outage than a datacentre losing power.

A region is a geographic area containing several zones. It contains a natural disaster or a regional power event. Many provisioning APIs are regional, which produces a failure mode worth knowing: a region can lose the ability to create capacity while existing instances keep serving traffic normally. Region boundaries also do not cleanly contain identity and DNS, because some of those services are deliberately global. AWS IAM has a global control plane, Route 53's authoritative DNS runs on a globally distributed data plane, and STS offers regional endpoints you have to opt into using. AWS documents which of its services are global and which are regional; check each dependency rather than assuming the region contains it.

A cell is not a cloud primitive. It is a design decision: partition your own users onto independent stacks so that a fault affects one partition instead of everyone. This is the boundary that contains the failures you cause, because a change can be applied to one cell and observed before it reaches the next. Shared dependencies defeat it, so a cell that still talks to one global database is only partially isolated, and a rollout that hits every cell at once is not isolated at all.

Your own changes are the common case

Zone and region failures are rare and well publicised. Your own changes are neither. A configuration error, a bad release, a schema migration or an expired certificate reaches every zone in seconds, because propagating everywhere quickly is exactly what a deployment system is built to do.

So the more useful availability question is usually not "what happens if a zone fails" but "what is the largest number of users one mistake can reach". Put numbers on it and the difference is stark. Suppose a service has eight cells of equal size. A change released to one cell first exposes 1 / 8 = 12.5 percent of users to a defect before anyone has to notice it. The same change deployed to a three-zone fleet with no cell staging exposes 100 percent, and the three zones did not help, because the change was applied to all of them at the same time.

That comparison is the whole argument for staged rollout, and it is worth noticing that it is an argument about deployment mechanics rather than about geography. Cells and staged rollout answer this question. Zones and regions do not.

Control plane and data plane

This distinction explains a large share of confusing incident behaviour. The data plane serves your traffic. The control plane changes things: creating instances, attaching volumes, updating DNS records, scheduling pods. Providers separate them deliberately so that existing capacity keeps serving when the machinery for changing it is unavailable.

The consequence is that during a control-plane incident, a service can look completely healthy right up to the moment it needs to change. Existing Kubernetes workloads keep running through an API server outage, while reconciliation, scaling and any application operation that calls the API fail. And a design that survives a traffic spike by autoscaling is depending on the control plane at precisely the moment a correlated event makes it least likely to be available. That is not an argument against autoscaling; it is an argument for knowing whether your peak plan needs a working control plane, and for holding some headroom that does not.

What the boundaries cost

Spreading a stateless fleet across zones may add little compute cost by itself, but surviving the loss of a zone means carrying spare capacity somewhere, and the arithmetic for how much is in saturation and utilisation targets. Cross-zone application traffic can also attract data transfer charges depending on the path.

For managed state the cost is more explicit. A traditional RDS Multi-AZ instance adds a synchronous standby with its own instance and storage charges, and that standby cannot serve reads, so it buys availability rather than capacity. RDS does not charge transfer for its own Multi-AZ replication, which is worth knowing and does not make the deployment free. The RDS pricing page separates deployment charges from transfer charges; price the specific service and the specific traffic paths rather than reasoning from the general shape.

Multi-region cost depends entirely on which recovery model you choose, from restoring backups at one end to a fully provisioned second stack at the other. Synchronous cross-region operations also pay the physical latency of the region pair, which no amount of provisioning removes. Multi-region should be justified by a named requirement, usually a regulatory obligation or a recovery objective that one region cannot meet.

Translate a failure-domain choice into a testable promise with RTO, RPO and recovery exercises, including the dependencies needed for a business operation to work again.

Managed database failover follows the interruption through promotion, endpoint resolution and application reconnection, where recovery often extends beyond the database event.

Self-check

A service runs in three zones behind a load balancer, with a Multi-AZ managed database. Two things happen on separate days. First, one zone loses power. Second, a release goes out that returns an error for 30 percent of requests. For each, say which boundary contained it, what the user impact was, and what would have reduced the second one. Work it through before reading on.

The zone power failure is contained by the zone boundary. The load balancer stops sending to the failed zone's targets, the database fails over to its standby in another zone with an interruption measured in a minute or two, and the surviving zones carry the traffic provided they were sized for it. User impact is a short window of errors during failover plus degraded headroom afterwards.

The bad release is contained by nothing in that description. It reached all three zones because the deployment put it there, the database is irrelevant to it, and 30 percent of requests fail everywhere until somebody rolls back. What would have reduced it is a mechanism in the deployment path rather than in the topology: releasing to one cell or a small traffic share first, with an automatic check on error rate that halts promotion. Note also what the Multi-AZ database contributed to the second case, which is nothing at all. Availability boundaries are specific about what they contain, and reading them as general insurance is how the runbook in the opening came to be wrong.

Next: size for a zone loss does the capacity half of this as an exercise, and the multi-AZ question works through a real impairment that crossed the boundary anyway.

For persistent data, block, file and object storage separates the access interface from concurrent-write safety and recoverability.