Designing Highly Available Architectures on AWS
High availability means the workload keeps serving requests when components fail. On AWS, the recurring exam pattern is the same: distribute across Availability Zones, put a load balancer in front, auto-scale the fleet, and make the data layer multi-AZ.
The layered checklist
- Compute — Auto Scaling group across ≥2 AZs behind an ALB; never a single instance
- Load balancing — ALB for HTTP(S) path routing; NLB for TCP/UDP at ultra-low latency
- Database — RDS/Aurora Multi-AZ synchronous standby for automatic failover
- Storage — S3 and EFS are already multi-AZ; EBS snapshots span AZs
- DNS — Route 53 health checks + failover routing for multi-Region resilience
- State — keep instances stateless (sessions in DynamoDB/ElastiCache) so any instance can serve any request
Availability vs fault tolerance
The exam distinguishes the two loosely: high availability minimizes downtime (fast failover, some seconds of impact); fault tolerance aims for no interruption at all (active/active, redundant everything). More fault tolerance costs more — questions ask for the design matching the stated requirement and budget.
What breaks single points of failure
Look for these answers in scenarios: replace a single EC2 instance with an ASG; replace single-AZ RDS with Multi-AZ; add a health-checking load balancer; decouple a brittle synchronous call chain with SQS; replicate data cross-Region for regional DR.