Design Resilient Architectures

The foundation: Regions, Availability Zones, and multi-AZ thinking

AWS is organized into Regions (geographic areas) each containing multiple Availability Zones (AZs) — physically separate data centers with independent power and networking, connected by low-latency links. The single most important resilience reflex on the whole exam is: to survive the loss of an Availability Zone, deploy across at least two (ideally three) AZs. A stateless fleet in a single AZ is a wrong answer whenever "must survive an AZ failure with no manual intervention" appears.

This reflex shows up everywhere: load balancers span multiple AZs; Auto Scaling groups place instances in multiple AZs; RDS Multi-AZ keeps a standby in another AZ; NAT gateways must be deployed one per AZ (not a single shared one) to survive an AZ failure.

Elastic Load Balancing: which balancer, and why it matters for health

Elastic Load Balancing (ELB) distributes incoming traffic across targets in multiple AZs and — critically for resilience — performs health checks, routing only to healthy targets and pulling unhealthy ones out of rotation. When a scenario says "an instance is unhealthy but still receiving traffic and causing errors," the fix is the load balancer's health check removing it.

Know the three balancers and when each wins:

• Application Load Balancer (ALB) — layer 7 (HTTP/HTTPS). Supports path-based and host-based routing (/api to one target group, /images to another behind one entry point), and is the default for web applications and containers. Reflex: "HTTP path/host routing" → ALB.
• Network Load Balancer (NLB) — layer 4 (TCP/UDP). Handles millions of requests per second at ultra-low latency, preserves the client source IP, and provides a static IP per AZ. Reflex: "extreme throughput / TCP / static IP / preserve source IP" → NLB.
• Gateway Load Balancer (GWLB) — for deploying third-party network virtual appliances (firewalls, IDS/IPS) transparently. Reflex: "insert third-party security appliances inline" → GWLB.

A subtle resilience feature: cross-zone load balancing distributes traffic evenly across all healthy targets in all AZs even when AZs have different target counts. And a common startup bug the exam tests: an Auto Scaling group keeps terminating instances that are still booting because they fail the ALB health check during startup — the fix is a health check grace period long enough to let instances finish initializing.

Auto Scaling: self-healing and elasticity

EC2 Auto Scaling maintains a desired number of healthy instances, automatically replacing any that fail health checks and scaling capacity up or down with demand. The canonical resilient, elastic web tier is: an Auto Scaling group spanning multiple AZs behind an Application Load Balancer, with a minimum of two instances and scaling policies on a metric like average CPU. This pattern is the answer to a huge family of questions: "automatically replace unhealthy instances and adjust to demand," "survive an AZ failure with no manual intervention," "keep at least two instances running and scale on CPU."

Two scaling nuances the exam tests:

• Target tracking keeps a metric (e.g., 50% CPU) at a set point — the simplest, most common policy.
• When scaling reacts too slowly to sharp surges, step scaling or a shorter evaluation, and warm pools, help capacity match sudden demand faster.

Decoupling: SQS, SNS, and EventBridge

Decoupling is a resilience superpower: if tiers communicate through a durable intermediary instead of calling each other directly, a spike or an outage in one tier can't cascade. Three services, three distinct patterns:

• Amazon SQS (Simple Queue Service) — a queue: one producer writes messages, one consumer (or one consumer group) pulls and processes them at its own pace. It absorbs spikes (the queue buffers), prevents lost work (a message stays until processed and deleted), and lets the processing tier scale on queue depth. Reflex: "decouple so a spike doesn't overwhelm the processing tier" or "never lose an order if the downstream is temporarily down" → SQS. Standard queues give best-effort ordering and at-least-once delivery; FIFO queues guarantee exact ordering and exactly-once processing (deduplication) — choose FIFO when the scenario says "strict order" and "no duplicates," e.g., a payment workflow.
• Amazon SNS (Simple Notification Service) — pub/sub fan-out: one published message is delivered to many subscribers at once (email, SQS queues, HTTPS webhooks, Lambda). Reflex: "several independent systems must each receive a copy of the event" or "fan one message out to email + a queue + a webhook" → SNS. The classic fan-out pattern is SNS → multiple SQS queues, giving each consumer its own durable buffer.
• Amazon EventBridge — an event bus that routes events from AWS services and SaaS partners to different targets based on content rules and schemas, with no polling infrastructure. Reflex: "route events by content to different targets, from AWS and SaaS sources, serverless" → EventBridge.

Two more messaging details:

• A dead-letter queue (DLQ) isolates "poison" messages that repeatedly fail processing, so they stop blocking the queue and can be inspected later. Reflex: "messages failing endlessly and blocking the queue" → configure a DLQ.
• AWS Step Functions orchestrates multi-step workflows with retries, error handling, branching, and even waits for human approval. Reflex: "coordinate a sequence of steps reliably with retries and error handling" → Step Functions.

Resilient databases: RDS Multi-AZ, read replicas, Aurora, and DynamoDB

The database is where "read the constraint carefully" pays off most, because Multi-AZ and read replicas solve different problems and the exam loves to swap them:

• RDS Multi-AZ is for high availability / failover. It keeps a synchronous standby in another AZ and automatically fails over to it (typically within a minute or two) if the primary or its AZ fails, with no data loss on committed transactions. The standby does not serve reads — its only job is standby. Reflex: "automatic failover to another AZ with minimal downtime" → Multi-AZ.
• RDS read replicas are for read scaling, not automatic failover. They offload read-heavy or reporting queries from the primary via asynchronous replication. A team surprised that a primary failure caused downtime "even though we have read replicas" has confused the two — the fix is to add Multi-AZ. When a scenario wants both to offload reporting reads and survive an AZ loss, the answer combines a read replica for scale + Multi-AZ for failover (or Aurora, below).
• Amazon Aurora is AWS's cloud-native MySQL/PostgreSQL-compatible engine that stores six copies of data across three AZs, self-heals storage, and fails over to a replica in seconds. Aurora replicas serve reads and act as failover targets (up to 15 of them). Reflex: "MySQL/PostgreSQL-compatible, six copies across three AZs, fast automated failover, scale reads" → Aurora.
• Amazon DynamoDB is a fully managed NoSQL database that is inherently multi-AZ. Its resilience headline feature is global tables — active-active multi-Region replication so each Region accepts local writes with single-digit-millisecond latency and replicates to the others. Reflex: "low-latency reads and writes to users in multiple Regions, each Region accepts writes" → DynamoDB global tables. Point-in-time recovery (PITR) lets you restore to any second in a recent window after a bad data change.

For RDS specifically, automated backups with point-in-time recovery let you recover to any point within the retention window after an accidental bad change — a different tool than Multi-AZ (which is about availability, not undo).

Resilient storage: S3 durability, versioning, and replication

Amazon S3 stores objects redundantly across multiple facilities (AZs) within a Region, giving very high durability (the famous "eleven nines" design) and protection against the loss of a single facility. Resilience features to know:

• Versioning — keeps every version of an object so accidental overwrites or deletes are recoverable; a delete just adds a delete marker and the prior version can be restored. Reflex: "recover from accidental overwrite/delete" → enable versioning.
• MFA Delete — requires a second authentication factor before any object version can be permanently removed, guarding versioned buckets against malicious/accidental permanent deletion.
• Cross-Region Replication (CRR) — automatically copies objects to a bucket in another Region for DR/compliance; enabling it also lets you backfill existing objects via an S3 Batch Replication job. Same-Region Replication (SRR) copies within a Region. Reflex: "objects written in us-east-1 must be copied to eu-west-1" → CRR.

Amazon EFS and shared file systems for resilience

When many instances across multiple AZs must share the same files concurrently, the resilient answer is Amazon EFS — a fully managed, elastic, multi-AZ NFS file system that any number of Linux instances can mount at once and that scales storage automatically. Reflex: "shared POSIX file system mounted by an Auto Scaling group across AZs, survives an AZ failure" → EFS. (EBS volumes attach to a single instance in a single AZ and are the wrong answer for multi-instance sharing; see Chapter 3 for EBS.)

Route 53: DNS-level resilience and failover

Amazon Route 53 is DNS with health checks and multiple routing policies that provide availability at the DNS layer:

• Failover routing — active-passive: send all traffic to the primary while its health check passes, and automatically switch to a standby (often in another Region) when the primary fails. Reflex: "active-passive, fail over to a standby endpoint automatically" → failover routing + health checks.
• Latency-based routing — send each user to the Region giving them the lowest latency. Reflex: "route users to the lowest-latency Region." (Performance, but often paired with resilience.)
• Multivalue answer routing — return several healthy IPs at once, omitting any that fail health checks, for simple client-side spreading and improved availability. Reflex: "return multiple healthy records, drop unhealthy ones."
• Weighted routing — split traffic by assigned weights (blue/green, canary).
• Geolocation / geoproximity — route by user location.

Common thread: Route 53 health checks detect endpoint failure and stop returning the failed endpoint, steering users to healthy ones.

Disaster recovery: matching strategy to RTO and RPO

The exam expects you to know the four DR strategies and to pick by RTO (how fast you must recover), RPO (how much data loss is tolerable), and cost, ordered from cheapest/slowest to costliest/fastest:

1. Backup and restore — cheapest; back up data and redeploy from scratch on disaster. High RTO/RPO (hours). For when downtime is tolerable.
2. Pilot light — a minimal core (e.g., a replicated database) runs in the second Region; the rest is provisioned on failover. Lower RTO than backup/restore, modest cost.
3. Warm standby — a scaled-down but running full copy in the second Region, scaled up on failover. Faster RTO, higher cost.
4. Multi-site active-active — full capacity running in two Regions simultaneously; a Regional failure is nearly invisible (lowest RTO/RPO). Costliest.

Reflex: "modest RTO/RPO without running full duplicate capacity" → pilot light (or warm standby). "Lowest possible RTO/RPO, willing to pay for full capacity in two Regions, failure nearly invisible" → multi-site active-active.

AWS Backup centrally schedules, enforces, and audits backups with consistent retention across EBS, RDS, DynamoDB, EFS, and more. Reflex: "centrally manage and audit backups across many services with retention policies" → AWS Backup.

Worked scenario — durability guarantees and protecting against permanent deletion

A company stores critical objects in S3 Standard and wants to understand what protects them against the loss of a single facility, and separately wants any accidental permanent deletion of a version to require a second authentication factor. What is correct?

Two facts combine. On durability: S3 Standard stores objects redundantly across multiple facilities (Availability Zones) within the Region, giving its very high (eleven-nines) design durability and protecting against the loss of any single facility automatically — nothing extra to configure. On accidental-deletion protection: enabling versioning makes overwrites and deletes recoverable (a delete just adds a delete marker), and layering MFA Delete on the versioned bucket requires a second authentication factor before any version can be permanently removed. So the pairing is versioning + MFA Delete for deletion protection, on top of S3's built-in multi-facility durability. A common distractor is "replicate to another Region for facility protection" — replication is for Regional DR and compliance, not for single-facility protection within a Region, which S3 already provides.

For block storage, the parallel durability tool is the EBS snapshot: point-in-time, incremental backups stored in S3, from which a volume can be restored (in the same or another AZ, and copied cross-Region for DR). When a scenario needs to protect or migrate EBS data, snapshots are the mechanism; AWS Backup or Data Lifecycle Manager automates their schedule and retention.