AWS SAA · Domain 2 of 4

AWS SAA Domain 2: Design Resilient Architectures

This domain covers designing architectures that stay available and recover from failure. It covers scalable, loosely coupled designs using queues and events, and highly available, fault-tolerant designs across Availability Zones and Regions.

Exam format
26%
Official task statements
2
Assessment estimate
~13
Suggested study time estimate
25–35 hrs

About 10 min read Reviewed October 2026

Overview

Domain 2 covers resilience: keeping workloads available and able to recover. It has two task statements. Designing scalable and loosely coupled architectures covers decoupling with Amazon SQS and SNS, event-driven designs with EventBridge, auto scaling, load balancing, and serverless patterns that scale automatically. Designing highly available and fault-tolerant architectures covers multi-Availability-Zone and multi-Region designs, failover, data replication, backup and restore, and recovery objectives such as RTO and RPO.

At 26%, resilience is the second-largest domain. The exam rewards designs that remove single points of failure and absorb load through decoupling and scaling. Candidates must distinguish high availability from fault tolerance and from disaster recovery, and match recovery strategies to stated RTO and RPO. These designs build on the secure foundation from Domain 1.

How it's tested

SAA-C03 questions ask for the design that BEST meets availability, scalability or recovery requirements. In this domain they describe a resilience need and ask which decoupling, scaling or failover approach fits, favoring managed, multi-AZ and loosely coupled designs. Read the availability and scaling clues before choosing.

  • Decouple the components

    A tightly coupled or spiky workload is described, and you choose SQS, SNS or EventBridge to decouple and absorb load.

  • Remove single points of failure

    An availability requirement is described, and you choose multi-AZ, auto scaling or load balancing to eliminate single points of failure.

  • Match the recovery strategy

    RTO and RPO are given, and you choose the disaster-recovery approach, from backup and restore to multi-site, that fits.

Reasoning it through

A web tier calls a processing tier directly, and traffic spikes overwhelm the processors. Adding bigger instances is tempting, but it does not address coupling. Placing an Amazon SQS queue between the tiers decouples them, so the web tier enqueues work and the processing tier, behind an auto scaling group, consumes at its own pace and scales with the queue depth, absorbing spikes without data loss.

Task statements 2

Official task statements from the Amazon Web Services outline, in outline order.

2.1 Design scalable and loosely coupled architecturesDecoupling with SQS and SNS, event-driven designs, auto scaling, load balancing and serverless.
What it means
This covers decoupling components with Amazon SQS queues and SNS topics, event-driven architectures with Amazon EventBridge, horizontal scaling with EC2 Auto Scaling, distributing traffic with Elastic Load Balancing, and serverless patterns with Lambda and managed services that scale automatically.
What to understand
Loose coupling lets components fail or scale independently. A queue buffers work so a slow or failed consumer does not lose requests, while SNS fans out notifications to many subscribers. Auto scaling adds and removes capacity with demand, and load balancers spread traffic across healthy targets. Serverless scales without managing servers.
How it shows up
A coupling or scaling problem is described, and you must choose the decoupling service or scaling approach that absorbs load and removes bottlenecks.
Common confusion
Confusing SQS with SNS. SQS is a queue for one consumer group pulling messages, while SNS is pub/sub that pushes to many subscribers.
2.2 Design highly available and/or fault-tolerant architecturesMulti-AZ and multi-Region designs, failover, replication, backup and recovery objectives.
What it means
This covers deploying across multiple Availability Zones and Regions, failover mechanisms, data replication, backup and restore, and designing to recovery time and recovery point objectives (RTO and RPO). It includes services such as Route 53 for failover routing and multi-AZ databases.
What to understand
High availability spreads resources across Availability Zones so the loss of one does not cause an outage. Fault tolerance goes further, continuing to operate through failure with no interruption. Disaster recovery restores service after a major event, with strategies from backup and restore to pilot light, warm standby and multi-site, chosen by RTO and RPO.
How it shows up
An availability or recovery requirement is described, and you must choose multi-AZ, multi-Region or the disaster-recovery strategy that meets the stated objectives.
Common confusion
Confusing high availability with fault tolerance; high availability minimizes downtime, while fault tolerance continues without interruption.

High-yield concepts

The terms, rules and formulas this domain turns into questions most often.

  • SQS vs. SNS

    SQS is a message queue pulled by consumers; SNS is pub/sub that pushes to many subscribers.

    Remember
    Use SQS to buffer and decouple, SNS to fan out.
    Tested as
    Decoupling questions.
    Trap
    Confusing a queue with pub/sub.

  • EventBridge

    An event bus for event-driven, loosely coupled architectures.

    Remember
    It routes events between services by rules.
    Tested as
    Event-driven design questions.
    Trap
    Using direct calls where events decouple better.

  • EC2 Auto Scaling

    Adds and removes instances automatically based on demand.

    Remember
    It provides elasticity and self-healing of capacity.
    Tested as
    Scaling questions.
    Trap
    Scaling vertically instead of horizontally.

  • Elastic Load Balancing

    Distributes traffic across healthy targets in multiple Availability Zones.

    Remember
    It removes a single instance as a point of failure.
    Tested as
    Availability questions.
    Trap
    Pointing clients at one instance.

  • Multi-AZ vs. multi-Region

    Multi-AZ spreads across zones in one Region; multi-Region spans Regions.

    Remember
    Multi-AZ handles zone failure; multi-Region handles Regional events.
    Tested as
    Availability design questions.
    Trap
    Using multi-AZ for a Regional-outage requirement.

  • High availability vs. fault tolerance

    High availability minimizes downtime; fault tolerance continues through failure with no interruption.

    Remember
    Fault tolerance is stronger and usually costlier.
    Tested as
    Resilience questions.
    Trap
    Treating the two as the same.

  • RTO vs. RPO

    RTO is how quickly service must be restored; RPO is how much data loss, in time, is acceptable.

    Remember
    They drive the disaster-recovery strategy.
    Tested as
    Recovery questions.
    Trap
    Confusing recovery time with data loss.

  • Disaster recovery strategies

    Backup and restore, pilot light, warm standby and multi-site, in rising cost and decreasing RTO.

    Remember
    Lower RTO and RPO cost more.
    Tested as
    Recovery strategy questions.
    Trap
    Over-provisioning for a loose RTO.

  • Route 53 failover

    DNS-based health checks and failover routing between endpoints.

    Remember
    It redirects traffic when an endpoint is unhealthy.
    Tested as
    Failover questions.
    Trap
    Expecting instant failover with long DNS TTLs.

  • Multi-AZ database

    A standby replica in another Availability Zone with automatic failover.

    Remember
    It provides high availability for managed databases.
    Tested as
    Database resilience questions.
    Trap
    Confusing a multi-AZ standby with a read replica.

  • Read replica vs. standby

    Read replicas scale reads; a multi-AZ standby provides failover, not scaling.

    Remember
    Standby is for availability, replicas for read performance.
    Tested as
    Database design questions.
    Trap
    Using a read replica for high availability.

Side by side

Concepts candidates mix up, compared on the point that decides the answer.

SQS vs. SNS vs. EventBridge

ConceptMeaningKey differenceCommon trap
SQS A queue consumers pull messages from Buffers and decouples for one consumer group Expecting it to push to many subscribers
SNS Pub/sub that pushes to many subscribers Fans out one message to many Using it to buffer work
EventBridge An event bus routing events by rules Event-driven routing between services Using direct calls instead

High availability vs. fault tolerance vs. disaster recovery

ConceptMeaningKey differenceCommon trap
High availability Minimizes downtime, usually multi-AZ Fast recovery, brief interruptions possible Treating it as fault tolerance
Fault tolerance Continues operating through failure No interruption, higher cost Assuming HA provides it
Disaster recovery Restores service after a major event Driven by RTO and RPO Leaving the plan untested

Disaster recovery strategies by RTO and RPO

ConceptMeaningKey differenceCommon trap
Backup and restore Restore from backups after an event Lowest cost, highest RTO Using it where a short RTO is required
Pilot light / warm standby Minimal or scaled-down standby environment Balances cost and recovery speed Confusing the two scales
Multi-site active-active Full running environment in another Region Near-zero RTO, highest cost Over-provisioning for a loose RTO

Exam traps

Each trap is an answer that looks right. Learn the clue that should change your mind.

  1. Bigger instances for spikes

    What candidates pick
    Scale up instance size to handle spiky load between tiers.
    Why it looks right
    More capacity seems to solve overload.
    Why it's wrong
    It does not address tight coupling. A queue decouples the tiers and absorbs spikes while a consumer auto scales.

    Clue to watch for Traffic spikes overwhelm a directly called downstream tier.

  2. SQS fans out

    What candidates pick
    Use SQS to send one message to many independent subscribers.
    Why it looks right
    Both are messaging services.
    Why it's wrong
    SQS is a queue for a consumer group; SNS fans out to many subscribers.

    Clue to watch for One event must reach multiple independent subscribers.

  3. Multi-AZ for Regional outage

    What candidates pick
    Use multiple Availability Zones to survive a whole-Region failure.
    Why it looks right
    More zones sounds more resilient.
    Why it's wrong
    Zones are within one Region, so a Regional event affects all of them. Multi-Region is required.

    Clue to watch for The requirement is to survive a Regional outage.

  4. HA equals fault tolerant

    What candidates pick
    Treat a multi-AZ design as fully fault tolerant.
    Why it looks right
    Both improve resilience.
    Why it's wrong
    High availability minimizes downtime; fault tolerance continues with no interruption, which usually costs more.

    Clue to watch for The requirement is zero interruption versus fast recovery.

  5. Over-provisioned DR

    What candidates pick
    Build an active-active multi-site design for a 24-hour RTO.
    Why it looks right
    It gives the fastest recovery.
    Why it's wrong
    A loose RTO can be met more cheaply with backup and restore or pilot light; active-active over-provisions.

    Clue to watch for The RTO and RPO are generous and cost matters.

  6. Read replica for HA

    What candidates pick
    Use a read replica to provide database high availability.
    Why it looks right
    A replica is another copy.
    Why it's wrong
    Read replicas scale reads; a multi-AZ standby provides automatic failover for high availability.

    Clue to watch for The need is failover rather than read scaling.

Answer framework

For any Domain 2 resilience scenario, use these steps to find the answer SAA-C03 expects.

  1. Identify whether the need is scalability and coupling or availability and recovery, since each uses different patterns.
  2. For coupling and spikes, decouple with SQS to buffer work, SNS to fan out, or EventBridge for event routing, and add auto scaling.
  3. For availability, remove single points of failure with multi-AZ, load balancing and multi-AZ databases, using multi-Region only when Regional resilience is required.
  4. Distinguish high availability from fault tolerance, choosing the stronger, costlier option only when no interruption is required.
  5. For disaster recovery, read the RTO and RPO and choose the least costly strategy, from backup and restore to multi-site, that meets them.

Practice question

A web application sends each order directly to a processing service. During sales events, order volume spikes and the processing service becomes overwhelmed, dropping orders. Which change BEST improves resilience?

Want more like this? The AWS SAA practice test has questions for every domain.

Checklist

0 of 10

Tick each one you can do without notes. Your ticks stay in this browser.

Study strategy

Start with decoupling, because loose coupling is the recurring theme of resilient design. Learn exactly when to use SQS, SNS and EventBridge, and practice placing a queue between tiers so a slow consumer never drops work. Pair this with auto scaling and load balancing, which provide elasticity and remove single points of failure.

Next, get the resilience vocabulary precise: high availability, fault tolerance and disaster recovery differ in capability and cost, and the exam tests the difference. Learn the disaster-recovery strategies in order of cost and recovery speed, and practice matching them to stated RTO and RPO.

Build small multi-AZ and queue-based designs in a free-tier account to make these patterns concrete. Afterwards, move to Domain 3, high-performing architectures, which focuses on choosing the fastest, most scalable services. Hands-on practice in a free-tier AWS account cements these choices far faster than reading, and reviewing missed practice questions by domain shows where to focus next.

FAQ

How much of SAA-C03 is Domain 2?

Design Resilient Architectures is 26% of the scored content, the second-largest domain.

What is the difference between SQS and SNS?

SQS is a message queue that consumers pull from, used to buffer and decouple work. SNS is publish/subscribe that pushes one message to many subscribers, used to fan out notifications.

What is the difference between high availability and fault tolerance?

High availability minimizes downtime, usually by spreading across Availability Zones. Fault tolerance continues operating through failure with no interruption, which generally costs more.

When do I need multi-Region instead of multi-AZ?

When the requirement is to survive a whole-Region outage. Multi-AZ protects against the loss of an Availability Zone within one Region.

How do RTO and RPO choose a DR strategy?

A short RTO and RPO point to warm standby or active-active multi-site, while generous objectives can be met more cheaply with backup and restore or pilot light.

Is a read replica the same as a multi-AZ standby?

No. A read replica scales read traffic. A multi-AZ standby is a failover copy that provides high availability for the database.

How does Domain 2 connect to the rest of the exam?

It builds availability and scalability on Domain 1's secure foundation, and resilient designs must also be high-performing and cost-optimized, which the later domains address.

Other Cloud Computing certifications

Where the same subject shows up in other exams. Cards marked "Same subject" open the matching domain.

Test your Domain 2 knowledge

You have covered decoupling, scaling, high availability and disaster recovery. Test whether you can remove single points of failure and match recovery strategies to objectives under exam conditions.

Take the AWS SAA practice test Check your AWS SAA readiness

Keep going