Reliability and Business Continuity
Keep workloads running when demand spikes and components fail: load balancing and health checks, Auto Scaling, caching, database scaling, Multi-AZ fault tolerance, automated backups, and the four disaster recovery strategies from backup and restore to active/active.
An instance dies at 02:00, or a product launch triples your traffic in ten minutes. Whether anyone outside the ops team notices depends on decisions made long before the incident: how many Availability Zones the workload spans, whether a health check pulls the failing target out of rotation, whether capacity grows without a human, and how quickly you can restore data after someone drops the wrong table.
This domain carries 22% of SOA-C03 and it builds directly on the first one. A scaling policy is a CloudWatch alarm with an action attached, and a failover decision is a health check reading a metric. Here you turn that telemetry into workloads that absorb load and survive failure.
What This Domain Covers
- Elastic Load Balancing across ALB, NLB, and Gateway Load Balancer, target group health checks, and diagnosing targets stuck unhealthy
- Route 53 health checks, DNS failover, and zonal shift with Application Recovery Controller
- EC2 Auto Scaling groups, the target tracking, step, scheduled, and predictive policy types, lifecycle hooks, and instance refresh
- Scaling for containers and serverless: ECS service auto scaling, EKS, and Lambda concurrency
- Caching with CloudFront and ElastiCache, and relational scaling with read replicas and Aurora Serverless v2
- DynamoDB capacity modes, table auto scaling, and DAX
- Multi-AZ fault tolerance, AWS Backup and snapshots, point-in-time restore, and S3 versioning and replication
- The four disaster recovery strategies and the RTO and RPO targets that decide between them
Why It Matters
Exam questions here rarely ask you to define Multi-AZ. They hand you a constraint (an RPO of 5 minutes, a budget that rules out a second running fleet, a session-bound application that breaks when instances terminate) and ask which mechanism meets it. Answering means knowing what each option costs in money, recovery time, and operational work, not just what it does.
The same reasoning shows up on every on-call page. If you can tell a failed health check from a failed scaling policy, and a restore that meets the RPO from one that quietly loses an hour of writes, you spend the incident fixing the problem instead of discovering the design.