AWS High Availability & Disaster Recovery for SAA-C03 (2026)

Resilience is the second-largest SAA-C03 domain at 26%, and it has a signature question shape: "here is an architecture, make it survive failure X at the lowest cost that meets the requirement." Answering well means knowing the resilience toolkit and the disaster-recovery spectrum cold, because the exam constantly trades recovery speed against cost. This guide covers both.

For where this sits overall, see the domains breakdown; the decoupling guide covers the loosely-coupled patterns resilience depends on.

The Foundation: Design for Failure

AWS's core resilience principle is that everything fails eventually, so architect assuming it will. Three layers of the failure domain, from smallest to largest blast radius:

• Instance failure -> Auto Scaling replaces the instance; a load balancer stops routing to it via health checks.
• Availability Zone failure -> spread across multiple AZs (Multi-AZ) so the surviving AZ carries the load.
• Region failure -> replicate to another Region (multi-Region) for the rare but total outage, and for global latency.

The exam's default expectation is multi-AZ everything: instances in an Auto Scaling group across at least two AZs, behind a load balancer, with a Multi-AZ database. A single-AZ design is almost always the wrong answer when the stem mentions availability.

Availability Building Blocks

• Auto Scaling Groups maintain a target capacity, replace unhealthy instances, and scale on demand. Spanning multiple AZs is what makes them resilient, not just elastic.
• Elastic Load Balancing distributes traffic and, via health checks, removes failed targets. ALB for HTTP/HTTPS, NLB for extreme performance and static IPs.
• Route 53 health checks + failover routing provide DNS-level HA, swinging traffic to a standby endpoint or Region when the primary fails.
• Multi-AZ databases (RDS Multi-AZ, Aurora's cross-AZ storage) survive an AZ loss with automatic failover. Covered in the databases guide.
• Decoupling (SQS, SNS, EventBridge) makes components fail independently so one slow consumer does not topple the system.

The Four Disaster Recovery Strategies

This is the most-tested resilience concept, because each strategy is a different point on the cost-versus-recovery-time curve. Know all four and their order:

Two definitions the exam assumes:

• RTO (Recovery Time Objective): how long you can be down. Lower RTO costs more.
• RPO (Recovery Point Objective): how much data you can afford to lose. Lower RPO means more frequent replication.

The selection logic: match the strategy to the requirement, then pick the cheapest that meets it. "We can tolerate a few hours down and want minimum cost" is Backup & Restore. "Near-zero downtime, cost is secondary" is Multi-Site Active/Active. The exam loves handing you an RTO/RPO and a cost constraint and asking for the fit; over-provisioning (active/active when warm standby meets the RTO) is as wrong as under-provisioning.

Decoupling as Resilience

A tightly-coupled system fails as a unit: if the processing tier is down, the web tier's requests are lost. Insert a queue and the web tier keeps accepting work while the processing tier recovers:

• SQS buffers requests so a spike or a downstream outage does not drop work; consumers process when able.
• SNS fans a single event out to many subscribers, each failing independently.
• Auto Scaling can scale the consumer fleet on queue depth, absorbing load spikes gracefully.

"Make this synchronous, brittle pipeline resilient to backend slowdowns" is almost always "put a queue between the tiers." The full treatment is in the SQS vs SNS vs EventBridge guide.

How This Shows Up on the Exam

• A single-AZ web app must survive an AZ outage. (Auto Scaling group across multiple AZs behind an ELB, plus a Multi-AZ database.)
• DR requirement: tolerate several hours of downtime, minimize cost. (Backup & Restore.)
• DR requirement: recover in minutes without running full production idle. (Warm Standby, or Pilot Light if only core must stay warm.)
• Near-zero downtime and data loss, global users. (Multi-Site Active/Active across Regions.)
• A backend slowdown is causing dropped user requests. (Decouple with an SQS queue; scale consumers on queue depth.)

Key Takeaways

• Design for failure: Auto Scaling for instances, Multi-AZ for zones, multi-Region for Regions
• Default to multi-AZ; single-AZ is the wrong answer whenever availability is mentioned
• Know the four DR strategies in cost/RTO order: Backup & Restore, Pilot Light, Warm Standby, Multi-Site
• Match the DR strategy to the stated RTO/RPO, then choose the cheapest that meets it
• Decoupling with queues turns a system that fails as a unit into components that fail independently

Continue with decoupling patterns or cost optimization, and drill resilience scenarios in Preporato's SAA-C03 practice exams.

Sources:

• AWS Well-Architected Framework: Reliability Pillar
• AWS Disaster Recovery Options in the Cloud
• AWS SAA-C03 Exam Guide (PDF)

Last updated: July 10, 2026