Availability and durability are not the same property
Durability is about not losing data. Availability is about the system responding to requests. S3 makes the distinction unusually explicit: S3 Standard is “designed to provide 99.999999999% durability and 99.99% availability of objects over a given year,” achieved by storing objects redundantly across a minimum of three Availability Zones (Data protection in Amazon S3, AWS docs). Eleven nines of durability and four nines of availability are seven orders of magnitude apart, and that gap is the point — durability and availability are engineered and stated separately, and your architecture needs to account for both independently.
A system can be highly durable and poorly available (your data survives, but nobody can reach it during an incident), or available with weak durability guarantees (fast and responsive, but a bug or failure loses data permanently). Design each property on its own terms: durability through backups, replication, and versioning; availability through redundancy and failover across failure domains.
AZ failure modes: what actually happens
An Availability Zone failure is rarely a clean “the whole AZ goes dark” event. In practice, AZ-level degradation shows up as:
- Power or cooling events affecting a subset of facilities within the AZ — some capacity is unavailable, the rest is fine, but you can’t easily tell which from outside.
- Network partition — the AZ’s compute is running, but connectivity to other AZs or to the internet degrades, which looks like an outage to dependent services even though nothing in that AZ “failed” in the traditional sense.
- Capacity exhaustion during a regional event — when one AZ degrades, everyone’s Auto Scaling Groups try to launch replacement capacity in the surviving AZs simultaneously, and you can hit EC2 capacity limits for the instance types/families you need, in the AZs you need them, at the exact moment you need them most.
That last one is underappreciated: Multi-AZ protects you from the first failure, but a true regional-scale AZ event creates a thundering herd across every customer in the remaining AZs. Reserved capacity (On-Demand Capacity Reservations) for your critical minimum footprint is worth considering specifically for this scenario if your workload cannot tolerate a launch failure during exactly the moment it needs to scale.
Multi-AZ patterns, per service class
| Service class | Multi-AZ pattern | What it actually protects against |
|---|---|---|
| Stateless compute (EC2, ECS, EKS) | ASG / service spread across ≥2 (ideally 3) AZ subnets, behind a load balancer that health-checks and routes around unhealthy targets | AZ-level compute or network failure — traffic shifts to healthy AZs automatically |
| RDS | Multi-AZ DB instance deployment — RDS “automatically provisions and maintains a synchronous standby replica in a different Availability Zone” and fails over without intervention | AZ failure of the primary. Failover is automatic but not instant: AWS states failover times are “typically 60–120 seconds,” and large transactions or a lengthy recovery can extend that (RDS Multi-AZ failover, AWS docs). The standby cannot serve reads, so it is not a scaling tier |
| DynamoDB | Multi-AZ by default — “DynamoDB automatically replicates your data across three Availability Zones,” backed by a 99.99% availability SLA (DynamoDB resilience, AWS docs) | AZ failure, with no configuration required; this one you get for free |
| S3 | Multi-AZ by default — a minimum of three AZs for S3 Standard and the other multi-AZ classes; S3 One Zone-IA deliberately is not | Loss of an entire Availability Zone, which the multi-AZ classes are designed to sustain. One Zone-IA is the exception to check for in an HA review |
| ElastiCache | Multi-AZ with automatic failover, on Valkey and Redis OSS; enabled by default with cluster mode enabled, and requiring at least one replica in a different AZ from the primary (Multi-AZ in ElastiCache, AWS docs) | AZ failure of the primary node. Promotion is faster than RDS failover — AWS describes writes resuming “typically just a few seconds” after promotion — but replication is asynchronous, so a small amount of data can be lost to replication lag unless durability is enabled |
| Load balancers (ALB/NLB) | Inherently multi-AZ when subnets in multiple AZs are attached | AZ failure of the LB’s own infrastructure — this is mostly automatic, your job is just attaching the right subnets |
The common thread: AWS makes Multi-AZ either default (DynamoDB, S3) or a straightforward configuration flag (RDS, ElastiCache) for its managed services. The place teams actually get this wrong is the compute tier — an ASG that’s configured to span 3 AZs but is actually running at a size of 1, or a service that’s Multi-AZ on paper but has an unexamined single point of failure (a self-hosted cache, a singleton cron job, a hardcoded connection to one specific instance) that nobody accounted for when they called the architecture “highly available.”
What multi-region actually costs in complexity
Multi-region is frequently proposed as the obvious next step after Multi-AZ. It is not a scaled-up version of the same pattern — it introduces categorically different problems:
- Data consistency. Within a region, Multi-AZ replication for RDS is synchronous — the standby is never behind. Cross-region replication (read replicas, Aurora global database, DynamoDB global tables) is asynchronous by necessity — the speed of light alone puts a floor on cross-region replication lag. AWS’s own figures give the shape: Aurora global database replicates to a secondary Region with “typical latency of under a second” and can promote a secondary to read/write “in less than one minute,” while promoting a non-Aurora RDS read replica “takes a few minutes to complete and rebooting is part of the process” (Disaster recovery options in the cloud, AWS whitepaper). Your application now needs an explicit answer for “what if the region I failed over to is a few seconds (or longer, under load) behind,” and for many transactional workloads that answer is genuinely hard — reconciling in-flight transactions after a failover is a design problem, not a configuration flag.
- Failover orchestration. Someone (or something) has to detect the failure, decide it’s real (not a transient blip — flapping into a region failover and back is its own outage), redirect traffic (DNS-based failover has the TTL problem discussed in the migration planning reference; Route 53 health checks help but add their own latency to detection), and verify the failover region can actually absorb full production load — which means the failover region needs standing capacity sized for that, sitting mostly idle most of the time. AWS is specific about why that idle capacity is not pure waste: relying on Auto Scaling to reach production capacity during the event is “a control plane activity, [so] taking a dependency on it will lower the resiliency of your overall recovery strategy,” and the guidance is to use only data plane operations in a failover path. Route 53 health-check-driven DNS failover is a data plane operation; changing routing weights is not.
- Testing burden. A failover path you haven’t tested is a hope, not a capability. Testing multi-region failover properly means periodically actually failing over — or at minimum running realistic failure injection — because the failure modes that matter (partial replication lag, split-brain during a flapping network partition, a dependent service that’s only deployed in one region) don’t show up in a tabletop exercise. This testing has to repeat on an ongoing basis as the architecture changes, not once at launch.
- Operational doubling. Every region-specific configuration, IAM policy, service quota, and deployment pipeline step now exists twice, and drift between them is a standing risk — the classic failure mode is a region that works fine until the day you actually need it, because a deploy three months ago only went to the primary region.
The case for most workloads: tested backups beat multi-region
Here’s the honest assessment this topic needs: most workloads do not need multi-region, and the engineering effort multi-region demands is better spent making backup and recovery actually reliable.
The reasoning: full regional failures are rare relative to the universe of things that actually take down production — a bad deploy, an expired certificate, a misconfigured security group, a dependency’s outage, human error during a routine change. Multi-region protects against exactly one failure mode (the region itself becoming unavailable) while doing nothing for the much more common ones, and it does so at a cost — in engineering time, ongoing testing burden, and architectural complexity — that’s often disproportionate to how rarely that specific failure occurs.
For most workloads, the better investment is:
- Multi-AZ for availability within the region (handles the AZ-level failures that are meaningfully more frequent than regional ones)
- Automated, tested backups with a verified recovery procedure — not just backups that run, but backups you’ve actually restored from, on a schedule, so “restore” isn’t a theory
- A documented, practiced recovery time objective (RTO) and recovery point objective (RPO) that’s honest about what a regional outage would mean, even if the answer is “we’d be down for N hours and restore from backup in another region” rather than “we’d fail over seamlessly”
That last option — an honest, tested cold-start recovery plan into a second region, rather than a live, warm multi-region architecture — covers the regional-failure scenario at a small fraction of the engineering cost, and the capacity you’re not paying to keep idle in a standby region can go toward making the backup/restore path actually reliable, which protects you against the failures that happen far more often.
Build true multi-region (active-active or warm-standby with automated failover) when you have a specific, quantified reason: a regulatory RTO/RPO that a cold-start recovery genuinely can’t meet, a global user base where regional latency is itself the business requirement (not a DR requirement), or a measured cost of downtime high enough that the ongoing complexity cost is clearly justified by the math. Don’t build it because “best practice” articles say highly-available systems are multi-region — that’s optimizing for a resume line, not for your actual risk profile.
Health checks and failover testing
Whatever tier of HA you land on, the health check and testing discipline is where the architecture earns its keep or quietly rots:
- Health checks should verify the thing that actually matters (can this instance serve a real request end-to-end) not just that a process is running — a health check that only pings a port passes right up until the database connection pool is exhausted and every real request fails.
- Set health check intervals and thresholds deliberately — too aggressive and you get false-positive failovers from transient blips; too lenient and real failures take too long to detect.
- Schedule actual failover tests — chaos-engineering style failure injection, or at minimum a planned AZ-evacuation drill — on a recurring cadence. An HA architecture that has never been tested under real failure conditions is a set of assumptions, not a verified capability.