Study guide
Resilience makes up about 26% of the exam and asks whether you can keep a workload available when a server, an Availability Zone, or even an entire AWS Region fails. This chapter covers the building blocks AWS provides for redundancy and graceful failure recovery, along with the named disaster recovery strategies the exam expects you to be able to rank by cost and recovery speed.
Spreading Risk: Multi-AZ, Multi-Region, and Auto Scaling
An AWS Region is a geographic area containing multiple isolated data center clusters called Availability Zones (AZs), each with independent power, cooling, and networking so that a failure in one AZ does not take down another. A resilient architecture places redundant resources across at least two AZs within a Region, which protects against a single data center failure, while a multi-Region architecture goes further and duplicates infrastructure in a separate geographic Region entirely, protecting against a Region-wide event at higher cost and complexity. An Auto Scaling Group (ASG) maintains a defined number of EC2 instances automatically, replacing any instance that fails a health check and adjusting the instance count up or down based on demand, using scaling policies tied to metrics like average CPU utilization. Picture a ticketing startup called Harlow Events that runs its web tier in an ASG spanning three AZs with a minimum of two instances and a target tracking policy set to 50% CPU; if one AZ suffers an outage, the ASG launches replacement instances in the healthy AZs to maintain capacity automatically. Elastic Load Balancing distributes incoming traffic across these instances and comes in three flavors relevant to the exam: the Application Load Balancer (ALB) operates at layer 7 and understands HTTP/HTTPS content for routing decisions like path-based rules; the Network Load Balancer (NLB) operates at layer 4, handling extreme throughput and preserving the client's source IP for TCP/UDP traffic; and the Gateway Load Balancer (GWLB) is purpose-built for deploying and scaling third-party virtual security appliances transparently in line with traffic.
Database Resilience: RDS Multi-AZ, Read Replicas, and DynamoDB Global Tables
Amazon RDS Multi-AZ deployment maintains a synchronous standby replica of your database in a second Availability Zone purely for failover protection; the standby is not used for reads, and if the primary fails, RDS automatically promotes the standby and updates the DNS endpoint, typically within one to two minutes. This solves availability, not read scaling. A read replica, by contrast, is an asynchronously updated copy of the database that can serve read-only queries, letting you offload reporting or analytics traffic from the primary instance; you can create multiple read replicas, even in different Regions, but replication lag means replicas can briefly lag behind the source. A scenario emphasizing that the database must survive an AZ failure with no data loss and minimal downtime points to Multi-AZ; a scenario emphasizing that read-heavy reporting queries are overwhelming the primary points to read replicas, and the two are frequently combined in a single architecture. DynamoDB global tables extend this idea to a fully managed, multi-Region, multi-active NoSQL database: writes made in any participating Region propagate to all other Regions, giving applications low-latency local reads and writes worldwide along with resilience against a full Regional outage, at the cost of eventual consistency between Regions for most configurations. When a question describes a globally distributed user base needing single-digit-millisecond reads in each user's home Region plus survivability if one Region goes dark, DynamoDB global tables is the direct match, while RDS cross-Region read replicas or Aurora Global Database serve a similar need for relational workloads.
Decoupling with SQS, SNS, and EventBridge
Tightly coupled systems fail together: if a downstream service slows down or crashes, an upstream service calling it directly can back up or crash too. Amazon Simple Queue Service (SQS) breaks this coupling by acting as a durable buffer; a producer places messages on a queue and a consumer processes them at its own pace, so a burst of orders at a company like Fennwick Retail does not overwhelm the inventory service processing them. A standard queue offers at-least-once delivery and best-effort ordering at very high throughput, while a FIFO queue guarantees exactly-once processing and strict ordering within a message group at somewhat lower throughput. Amazon Simple Notification Service (SNS) provides publish/subscribe messaging: a single published message can fan out to many subscribers at once, such as an SQS queue, a Lambda function, and an email address simultaneously, which suits scenarios needing one event delivered to multiple independent consumers. Amazon EventBridge extends this further with an event bus that can route events based on content, filter them with rules, and integrate directly with dozens of AWS services and SaaS partners, making it the preferred choice when routing logic depends on the event's attributes rather than simply broadcasting to every subscriber. A common exam pattern combines SNS fan-out to multiple SQS queues, which lets each downstream consumer process the same event independently and at its own pace, without one slow consumer affecting the others or messages being lost if a consumer is temporarily unavailable.
Route 53 Failover and Disaster Recovery Strategies
Amazon Route 53 supports several routing policies relevant to resilience. A failover routing policy pairs a primary and secondary resource; Route 53 health checks continuously probe the primary endpoint, and if it fails, DNS answers automatically switch to the secondary. This is distinct from a weighted policy, which splits traffic by percentage, and a latency-based policy, which sends users to the Region with the lowest network latency. The exam expects you to know four named disaster recovery strategies, ranked by increasing cost and decreasing recovery time. Backup and restore is the cheapest: data is backed up regularly, but infrastructure is only provisioned after a disaster occurs, giving the longest recovery time objective (RTO), often hours. Pilot light keeps a minimal version of the core infrastructure, such as a database being continuously replicated, always running in the recovery Region, while the rest of the application stack is provisioned only when disaster strikes. Warm standby runs a fully functional, but scaled-down, copy of the full environment at all times, so failover means scaling up rather than building from scratch, cutting RTO further at higher ongoing cost. Multi-site active-active runs full-scale production capacity in more than one Region simultaneously, giving the fastest possible recovery, near-zero RTO, at the highest cost because you are paying for duplicate full capacity continuously. A scenario mentioning tight budget constraints and tolerance for hours of downtime points to backup and restore; a scenario demanding near-instant failover for a mission-critical system points to multi-site active-active.
S3 Durability Features and Step Functions
Amazon S3 versioning keeps every version of an object when it is overwritten or deleted, which protects against accidental deletion or application errors, since you can simply restore a prior version rather than relying solely on a separate backup. Cross-Region Replication (CRR) automatically copies objects from a bucket in one Region to a bucket in another, which supports both disaster recovery, keeping a live copy available if a Region becomes unreachable, and compliance requirements that mandate data reside in a specific geography. CRR requires versioning to be enabled on both the source and destination buckets. Same-Region Replication (SRR) offers the equivalent behavior within a single Region, useful for aggregating logs from multiple buckets or maintaining a copy in a separate account for isolation. For orchestrating multi-step application logic resiliently, AWS Step Functions coordinates a sequence of Lambda functions or other AWS service calls as a state machine, with built-in support for retries, catch blocks for error handling, and parallel branches. Imagine a media company, Verrado Studios, processing an uploaded video through several stages: transcoding, thumbnail generation, and content moderation. Without Step Functions, a failure partway through requires custom code to track state and resume; with Step Functions, each state's success or failure is tracked automatically, failed states can retry with exponential backoff, and the entire workflow's history is visible for troubleshooting. This turns a fragile chain of function calls into a resilient, observable workflow, which is why the exam often points to Step Functions whenever a scenario describes a multi-step process needing coordinated error handling across services.
Key terms
- Availability Zone (AZ)
- — One or more discrete data centers within an AWS Region with independent power, cooling, and networking.
- Auto Scaling Group (ASG)
- — A feature that maintains a target number of healthy EC2 instances, replacing failed ones and scaling capacity based on demand.
- RDS Multi-AZ
- — A synchronous standby database replica in a second AZ used purely for automatic failover, not for serving read traffic.
- Read replica
- — An asynchronously updated, read-only copy of a database used to offload read traffic from the primary instance.
- DynamoDB global tables
- — A fully managed, multi-Region, multi-active DynamoDB configuration that replicates writes across Regions automatically.
- SQS (Simple Queue Service)
- — A managed message queue that decouples producers from consumers, buffering messages so consumers can process at their own pace.
- SNS (Simple Notification Service)
- — A publish/subscribe messaging service that fans a single published message out to multiple subscribers.
- EventBridge
- — An event bus service that routes events between sources and targets based on content-matching rules.
- Route 53 failover routing
- — A DNS routing policy that redirects traffic from a primary to a secondary resource based on health check results.
- Pilot light (DR strategy)
- — A disaster recovery pattern keeping only core infrastructure, like a replicated database, running at all times in the recovery site.
- Warm standby (DR strategy)
- — A disaster recovery pattern running a full but scaled-down copy of the environment continuously, scaled up on failover.
- Cross-Region Replication (CRR)
- — An S3 feature that automatically copies objects to a bucket in a different Region, requiring versioning on both buckets.
Exam tips
- Match the DR strategy to the stated cost and downtime tolerance: backup and restore (cheapest, slowest) through pilot light, warm standby, up to multi-site active-active (priciest, fastest).
- RDS Multi-AZ solves availability during failure; read replicas solve read scaling during normal operation — do not confuse the two.
- When a scenario says one event must reach several independent downstream systems, look for SNS fan-out, often combined with SQS queues per subscriber.
- Route 53 failover routing depends on health checks; if health checks are not mentioned or configured, failover will not occur as expected.
- Step Functions is the likely answer whenever a question describes a multi-step, multi-service process that needs built-in retry and error-handling logic rather than custom orchestration code.