Reliability and Business Continuity
What you must know
Multi-AZ vs multi-Region design; RDS Multi-AZ (synchronous standby, automatic failover) vs read replicas (asynchronous, read scaling); Aurora replicas and global database; S3 durability, versioning, Cross-Region Replication, and Object Lock; EBS snapshots and AMIs; Route 53 health checks, failover, and latency routing; Backup plans and vaults; Elastic Disaster Recovery; SQS/SNS decoupling; Auto Scaling health checks.
Traps that show up in questions
- Multi-AZ is for availability, not read scaling. A question asking to offload reads needs read replicas. A question asking to survive an AZ failure with minimal RPO needs Multi-AZ.
- RPO vs RTO: RPO is tolerable data loss (drives replication frequency); RTO is tolerable downtime (drives failover speed). Read the question for which one is constrained.
- S3 CRR is asynchronous and requires versioning on both buckets. It is not a backup against accidental deletes unless combined with versioning/Object Lock.
- Route 53 failover requires a health check on the primary record; without it, DNS never shifts.
- ASG health check type: EC2 checks instance status; ELB checks target health. Set to ELB when you want the ASG to replace instances failing load-balancer checks.
- Backup vault lock enforces immutability (WORM) - the answer for ransomware/compliance retention.
Worked rule of thumb
Map the disaster-recovery strategy to cost and RTO: Backup & Restore (hours, cheapest) < Pilot Light (core data replicated, scale up on failover) < Warm Standby (scaled-down full stack running) < Multi-Site Active/Active (near-zero RTO, most expensive). When a question gives an RTO target, choose the cheapest strategy that meets it - not the most resilient one.