High availability

High availability is about surviving the failures that happen routinely: an instance that stops responding, an Availability Zone that becomes unreachable, a dependency that starts timing out. It is distinct from disaster recovery, which deals with the rarer and larger events, and from fault tolerance, which targets no user-visible disruption at all and costs accordingly.

The pages here work through the layers. Start with high availability and disaster recovery concepts for the vocabulary — RTO, RPO, BC versus DR — that the rest depend on. Then take the tiers in whichever order matters for the design in front of you: compute (Auto Scaling groups, load balancers, AMI currency, Route 53 failover), databases (what DynamoDB, Aurora, RDS and Redshift each give you), and the network (multi-AZ subnets, redundant Direct Connect and VPN paths, per-zone NAT gateways).

Highly available TCP service with static IPs is a worked example that puts several of those pieces together against a specific and common requirement.

Once the availability design is settled, the recovery design follows from it: see disaster recovery.