Module 12 · SAA-C03

Architecture patterns: high availability, disaster recovery, decoupling

Multi-AZ, multi-Region, 4 DR strategies by RTO / RPO, serverless and event-driven architecture, multi-layer caching.

DomainResilient architectures
DomainHigh-performing architectures
12 diagrams
10 scenarios
16 services

5-minute essentials

RPO is the maximum acceptable data loss (measured in time); RTO is the maximum acceptable time to restore service.An RPO of 15 minutes means the data copy must be no older than 15 minutes. The question gives RPO / RTO and a budget; you pick the DR strategy.
High availability (HA) within a Region = spread every tier across at least 2 AZs. Disaster recovery (DR) = have a plan in another Region.ALB + multi-AZ Auto Scaling group + RDS Multi-AZ survives losing one AZ. Losing a whole Region needs DR.
Backup & restore: only back up data (and configuration) to another Region; cheapest, longest RTO / RPO (on the order of hours).To rebuild fast and correctly, infrastructure must be written as IaC (CloudFormation, CDK); back up AMIs and configuration too.
Pilot light: data is replicated continuously and always running in the DR Region; application servers are "off" (not deployed or 0 instances), turned on when needed.RTO on the order of tens of minutes. Elastic Disaster Recovery is exactly the pilot light approach for servers.
Warm standby: a scaled-down but fully functional copy running in the DR Region that can take traffic immediately, just needing to scale up.Unlike pilot light: pilot light must start servers before serving, warm standby can serve right away at low capacity.
Multi-site active/active: full capacity running in multiple Regions at once; RTO near 0, most expensive and most complex.Deleted / corrupted data still propagates to every Region: you still need point-in-time backups.
Aurora Global Database: replicates to another Region typically in under 1 second, promotes a secondary Region to primary in under 1 minute.RPO of seconds, RTO of minutes for a multi-Region relational database. DynamoDB global tables allow writes in every Region (last writer wins).
Shifting traffic during an incident: Route 53 failover (health checks), Application Recovery Controller (proactive failover switch), Global Accelerator (static IPs, switches endpoints instantly).Route 53 depends on DNS TTL; Global Accelerator is not affected by DNS caching. CloudFront origin failover only tries the secondary origin per failed request.
Decoupling with SQS: the sender drops work into a queue, workers process at their own pace; the queue absorbs load peaks.Workers in an Auto Scaling group scale on the number of waiting messages (ApproximateNumberOfMessagesVisible / backlog per instance).
Fan-out: one event to several independent processors → SNS delivers to multiple SQS queues (or EventBridge with multiple rules).Each consumer has its own queue, so a slow / failing one does not affect the others.
Stateless application: keep no session on the instance; move sessions to ElastiCache or DynamoDB.Auto Scaling can add / remove / replace instances freely; no sticky sessions needed.
Multi-layer caching: CloudFront at the edge, ElastiCache in front of the database, DAX in front of DynamoDB, read replicas for read load.When asked to cut read latency / database load: pick the cache layer closest to the bottleneck.
Serverless (API Gateway + Lambda + DynamoDB + S3) scales automatically, is pay-per-use, and needs no server management."Uneven load, small ops team, pay for usage" → serverless.

Diagrams

High availability in one Region: every tier across 2 AZs

The ALB spans two AZs, the Auto Scaling group keeps a minimum number of instances in both AZs, and RDS Multi-AZ has a synchronous standby. Lose one AZ and the system keeps running.

Step by step

The ALB spreads load across instances in both AZs and skips unhealthy ones.
RDS writes synchronously to the standby in the other AZ; if AZ a fails the standby is promoted automatically and Auto Scaling replaces capacity in AZ b.

Backup & restore DR

The DR Region holds only backups. In a disaster, rebuild infrastructure with CloudFormation and then restore data: cheapest but slowest.

Step by step

AWS Backup backs up EC2, RDS, etc. on a schedule: backup frequency determines RPO.
Backups are copied to the DR Region.
Disaster: run CloudFormation to build infrastructure, then restore data; RTO is measured in hours.

Pilot light DR

In the DR Region, data is always running and replicated continuously; app servers are configured but not running. Failover: start app servers, promote the database, switch DNS.

Step by step

Normally all traffic goes to the primary Region.
Data replicates continuously to the DR Region (RPO of seconds).
Failover: raise Auto Scaling from 0, promote Aurora in the DR Region, switch DNS. RTO on the order of tens of minutes.

Warm standby DR

The DR Region has a scaled-down, fully functional copy. Route 53 failover shifts traffic as soon as the health check fails, then Auto Scaling grows to full capacity.

Step by step

The primary Region serves all traffic.
The DR Region already runs a small copy, with data replicating continuously.
Health check fails: Route 53 switches to the DR Region; the small copy serves immediately, Auto Scaling grows gradually. RTO of a few minutes.

Multi-site active/active with DynamoDB global tables

Both Regions serve traffic. Route 53 latency routing sends users to the nearest Region; DynamoDB global tables allow writes in both places.

Step by step

Route 53 returns the lowest-latency Region for each user.
Each Region processes requests and writes to its own global table replica.
DynamoDB replicates both ways; if a Region fails, Route 53 drops it, RTO near 0.

Decoupling with SQS: workers scale on the queue

The web tier accepts orders and replies immediately; heavy work waits in the queue. Workers scale on waiting messages per instance, and repeatedly failing messages go to a dead-letter queue.

Step by step

The web tier puts the order in the queue and replies to the customer immediately.
A worker takes a message, processes it, and deletes it when done.
When waiting messages per worker rise, Auto Scaling adds workers.
Messages that fail more than the allowed number of times move to the dead-letter queue for review.

Fan-out: SNS to multiple SQS queues

An "order created" event is pushed by SNS to three queues. Each service has its own queue, so slowness or failure in one does not affect the others.

Step by step

The order service just publishes one event, without needing to know who listens.
SNS delivers a copy to each subscribed queue.
Each consumer processes at its own pace, and retries from its own queue on failure.

Multi-layer caching and sessions off the server

CloudFront caches at the edge; ElastiCache holds frequently used query results and sessions; the database gets only the rest, with read replicas absorbing extra read load.

Step by step

Cacheable content is returned immediately by CloudFront at the edge; only the rest goes to the ALB.
The app checks ElastiCache first (cache-aside); sessions live here too, so the app holds no state.
Only on a cache miss does it query the database and then write back to the cache; read replicas absorb extra read load.

Serverless web application

Static front end on S3 via CloudFront; API Gateway invokes Lambda; data in DynamoDB. Every component scales automatically and is billed by usage.

Step by step

Static pages are cached at the edge, fetched from a private S3 bucket.
API call: API Gateway triggers Lambda, Lambda reads / writes DynamoDB. No server runs when there are no requests.

Microservices on ECS Fargate: path-based ALB, Cloud Map, one database per service

The ALB routes by path to each service. Services call each other by name via Cloud Map (returning only healthy tasks), without knowing IPs. Each service keeps its own database, so deployment and scaling are independent.

Step by step

The ALB reads the path: /orders/* goes to the orders service, /users/* to the users service.
Payments tasks register themselves in Cloud Map; orders looks up payments.shop.local and calls it directly, receiving only healthy tasks.
One database per service: changing a schema or scaling one service does not drag others along.

Hybrid architecture: on-prem connected to multiple VPCs via Transit Gateway

Direct Connect is the primary path, Site-to-Site VPN the backup; both attach to Transit Gateway so on-prem reaches every VPC. Two-way DNS through Route 53 Resolver endpoints.

Step by step

Normally: on-prem goes over Direct Connect (transit VIF via a Direct Connect gateway) into Transit Gateway.
If Direct Connect fails: BGP switches to the VPN over the internet.
Transit Gateway connects on-prem to every attached VPC, per its route table.
Names in a private hosted zone are resolved from on-prem through the inbound endpoint.

Choosing a disaster recovery strategy

The four strategies run from cheapest with the slowest recovery to most expensive with almost no interruption. Pick the cheapest one that still meets the RTO / RPO the business requires.

Step by step

RPO in seconds but you can wait for servers to be built: pilot light (database replicating continuously, app started when needed).
No interruption allowed: multi-Region active/active, the most expensive.

Quick comparisons

4 disaster recovery strategies

Strategy	What exists in the DR Region	Typical RPO / RTO	Cost	Common services
Backup & restore	Backups only	Hours	Lowest	AWS Backup (copy to another Region), snapshots, S3 CRR, CloudFormation
Pilot light	Data running and replicating continuously; app servers off	Tens of minutes	Low	Aurora Global Database, cross-Region RDS read replica, Elastic Disaster Recovery
Warm standby	Scaled-down, fully functional copy running	Minutes	Medium	Like pilot light + Auto Scaling, Route 53 failover
Multi-site active/active	Full copy, all serving traffic	Near 0	Highest	DynamoDB global tables, Aurora Global Database, Route 53 / Global Accelerator

Database replication: fault tolerance or read scaling?

	RDS Multi-AZ (instance)	Read replica	Aurora Global Database	DynamoDB global tables
Purpose	Fault tolerance within a Region	Read scaling (and DR if cross-Region)	Multi-Region DR, reads near users	Writes / reads in multiple Regions
Replication	Synchronous	Asynchronous	Asynchronous, typically under 1 second	Asynchronous
Secondary serves reads	No (standby)	Yes	Yes	Yes, writes too
Switchover	Automatic failover	Manual promotion	Promote secondary Region (under 1 minute)	Not needed: any Region accepts writes

Decoupling: choosing how to pass work

	SQS	SNS	EventBridge	Kinesis Data Streams
Type	Queue (one consumer processes each message)	Pub/sub push to many consumers	Event bus, content-based filtering	Ordered stream, replayable
Good for	Absorbing load peaks, scaling workers	Fan-out, notifications	Integrating AWS services / SaaS, rules	High-volume real-time data
Retention	Up to 14 days	Not retained	Can archive and replay	24 hours – 365 days

Where to cache

Layer	Service	Reduces
Edge (near users)	CloudFront	Latency and origin load for cacheable static content / APIs
Application	ElastiCache (Redis OSS / Valkey / Memcached)	Repeated database queries, session storage
In front of DynamoDB	DAX	Read latency down to microseconds
Database	Read replica	Read load on the primary

Exam scenarios

1A web application runs on one EC2 instance in one AZ; it must survive losing an AZ at reasonable cost.

Show answer

Right: ALB + Auto Scaling group spanning at least 2 AZs, RDS Multi-AZ database
Every tier exists in two AZs; if an AZ fails, the ALB sends traffic only to healthy instances and RDS fails over automatically.

Wrong: Move to a larger instance
Still one instance, one AZ.

Wrong: Build a replica in another Region
Overkill for the loss of one AZ, and costlier.

2An internal system accepts an RPO of 24 hours and an RTO of 8 hours if a whole Region is lost; wants the lowest DR cost.

Show answer

Right: Backup & restore: AWS Backup copies backups to another Region, infrastructure written in CloudFormation
With RPO / RTO measured in hours, backup & restore is enough and cheapest.

Wrong: Warm standby
Runs a scaled-down copy continuously: costs more than needed.

3An application using Aurora MySQL needs an RPO of seconds and an RTO of about 30 minutes if a Region is lost; lowest possible cost.

Show answer

Right: Pilot light: Aurora Global Database to the DR Region; app servers prebuilt with IaC but not running, started at failover
Data replicates continuously (RPO of seconds); the rest only needs to be started (RTO of tens of minutes).

Wrong: Backup & restore with daily snapshots
RPO up to one day.

Wrong: Multi-site active/active
Meets the need but costs far more.

4An application must serve again within minutes if a Region is lost, and can accept running at low capacity at first.

Show answer

Right: Warm standby: a scaled-down copy already running in the DR Region, Route 53 failover, Auto Scaling increases capacity after switching
Takes traffic immediately, just needs to scale up.

Wrong: Pilot light
App servers are off and must be started and configured before they can serve.

5A global application needs an RTO near 0, with users in Asia and Europe both served from the nearest Region; data must be writable everywhere.

Show answer

Right: Multi-site active/active with DynamoDB global tables and Route 53 latency routing
Every Region reads / writes; if a Region fails, Route 53 drops it.

Wrong: Aurora Global Database with writes in the primary Region
Only one Region accepts writes (other Regions are read-only or forward writes).

6A flood of orders during a promotion overloads the back-end processing system and orders are lost.

Show answer

Right: Put SQS between web and workers; Auto Scaling workers on the number of waiting messages
The queue holds orders safely, workers process at their own pace and scale with the backlog.

Wrong: Increase the worker instance size
Still limited, and costs money during off-peak.

7Each new order must simultaneously send an email, update inventory and record analytics; one consumer failing must not break the others.

Show answer

Right: An SNS topic delivering to three SQS queues, one per consumer
Fan-out: each consumer receives its own copy, processes and retries independently.

Wrong: One SQS queue for all three
Each message is processed by only one consumer.

8Users get logged out every time Auto Scaling replaces an instance.

Show answer

Right: Store sessions in ElastiCache (or DynamoDB), keep application instances stateless
Any instance can read the session; adding / removing instances does not affect users.

Wrong: Enable sticky sessions on the ALB
A replaced instance still loses its sessions; load also becomes uneven across instances.

9A relational database is overloaded because the same few read queries repeat constantly.

Show answer

Right: ElastiCache in front of the database (cache-aside), add read replicas if needed
Repeated queries are served from memory; the database only handles writes and rare queries.

Wrong: Add IOPS to the disk
Does not solve the repeated queries.

10An API has very uneven call volume, and a small team does not want to manage servers.

Show answer

Right: API Gateway + Lambda + DynamoDB
Scales automatically down to 0, pay per request.

Wrong: EC2 Auto Scaling with large always-on instances
You pay even when nobody calls, and must manage the OS.

Quick picks

What must you survive, and how fast?

When you need	Use
Loss of one AZ	Multi-AZ: ALB + multi-AZ Auto Scaling, RDS Multi-AZ · see diagram
Loss of a Region, RPO / RTO in hours, cheapest	Backup & restore (AWS Backup copy to another Region + IaC) · see diagram
Loss of a Region, RPO of seconds, RTO of tens of minutes	Pilot light · see diagram
Loss of a Region, RTO of a few minutes	Warm standby · see diagram
RTO near 0, global serving	Multi-site active/active · see diagram
Load peaks overload the back end	SQS + workers scaling on the queue · see diagram
One event, many consumers	SNS → multiple SQS (fan-out) or EventBridge · see diagram
Slow reads, overloaded database	CloudFront / ElastiCache / DAX / read replica · see diagram
Uneven load, no server management	Serverless: API Gateway + Lambda + DynamoDB · see diagram
Proactive, safe DNS failover during incidents	Application Recovery Controller + Route 53

Common pitfalls

Confusing HA with DR: Multi-AZ does not protect you when a whole Region is lost.
Choosing an RDS read replica for automatic fault tolerance within a Region: that is Multi-AZ; a read replica is for read scaling and must be promoted manually.
Confusing pilot light and warm standby: pilot light must start app servers before serving, warm standby can serve right away.
Doing backup & restore without IaC: rebuilding by hand misses the RTO.
Believing active/active or continuous replication replaces backups: deleted / corrupted data is replicated too.
Not testing DR regularly: a plan that has never been run gives no certainty it meets the RTO.
Using sticky sessions instead of moving sessions off the instance.
One SQS queue for several consumers that all need the same event: you need fan-out with SNS / EventBridge.
Scaling workers on CPU when the real work is in the queue length.
Forgetting that DNS failover depends on TTL: if you need low switchover latency independent of DNS caching, use Global Accelerator.
Forgetting service quotas in the DR Region: you only discover insufficient limits when you scale up.

Services in this module

Numbers that change (checked against AWS docs)

Pilot light cannot serve requests until more resources are started; warm standby serves immediately at low capacity, only needing to scale up. checked 2026-10-16 ↗
Aurora Global Database replicates to a secondary Region with latency typically under 1 second and promotes a secondary Region in under 1 minute. checked 2026-10-16 ↗
DynamoDB global tables allow reads and writes in every Region, resolving concurrent writes with last writer wins. checked 2026-10-16 ↗
AWS Elastic Disaster Recovery replicates continuously at the block level and uses the pilot light strategy. checked 2026-10-16 ↗
CloudFront origin failover switches each failed request to the secondary origin; subsequent requests still go to the primary origin. checked 2026-10-16 ↗
AWS Backup copies backups to other Regions and accounts; it does not restore on a schedule by itself. checked 2026-10-16 ↗
Cloud Map lets applications find resources via API or DNS and, with health checks enabled, returns only healthy resources. checked 2026-10-19 ↗

Practice this module →