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 isolate physical infrastructure, regions isolate geography and most control planes, and cells isolate your own blast radius. Multi-AZ deployments need enough surviving capacity and incur service-specific costs. Multi-region adds replication and operational complexity; justify both against recovery requirements.

The boundaries, and what each one contains

Availability zone. One or more datacentres with independent power, cooling and network, connected by low-latency links; do not assume every application round trip is below a millisecond. It contains a power failure, a cooling failure, a fire, a switch failure. It does not contain a bad configuration pushed to every zone at once, which is a far more common cause of outage than a datacentre burning down.

Region. A geographic area containing several zones. It contains a natural disaster or a regional power event. Many provisioning APIs are regional, so a region can lose the ability to create capacity while existing instances keep serving. Check each dependency: AWS IAM has a global control plane, Route 53 authoritative DNS uses a globally distributed data plane, and STS offers regional endpoints. A region boundary alone does not isolate every identity or DNS dependency. AWS describes these control-plane and data-plane scopes.

Cell. Not a cloud primitive but a design one: partitioning your own users onto independent stacks so a fault affects one partition rather than everyone. This is the boundary that contains the failures you cause yourself, such as a bad change limited to one cell. Shared dependencies or simultaneous rollout can still defeat that isolation.

The distinction that matters most

Zone and region failures are rare. Your own changes are not. A configuration error, a bad release, a schema migration or an expired certificate propagates to every zone in seconds because that is what a deployment does. Multi-AZ alone does not stop it.

So the useful availability question is rarely "what if a zone fails" but "what is the largest number of users one mistake can affect". That is answered by cells and by staged rollout, not by geography. A simultaneous deploy across three zones can still affect every replica.

Control plane and data plane

Worth internalising because it explains a lot of incident behaviour. The data plane serves your traffic; the control plane changes things. Separating them lets existing instances keep running when a provisioning API is down. Existing Kubernetes workloads can also continue during an API-server outage, although reconciliation and API-dependent application operations may fail.

The practical consequence is that during a control-plane-only incident, existing capacity may continue serving while operations that need the affected APIs fail. Designs that depend on autoscaling to survive a spike are depending on the control plane, and that is the moment it is least likely to be there.

What this costs

Spreading an existing stateless fleet across zones may add little compute cost, but surviving a zone loss requires spare capacity somewhere. A traditional RDS Multi-AZ DB instance adds a synchronous standby with associated instance and storage charges; the standby cannot serve reads. Cross-zone application traffic may also incur transfer charges. RDS waives transfer charges for its own Multi-AZ replication, which does not make the deployment free. Price the actual service and traffic paths. RDS pricing distinguishes deployment and transfer charges.

Multi-region cost depends on whether recovery uses backups, a small standby, or a fully provisioned second stack. Synchronous cross-region operations also add network latency; measure the region pair and replication path. It should be justified by a named requirement, usually a regulatory one or a recovery objective that a single region cannot meet.

Self-check

Name a failure that multi-AZ does not protect against, and say which mechanism does. Then: during a regional control-plane outage, what still works and what does not?