Design resilient architectures

Key terms

• High availability (HA): the system keeps working through a failure, with at most a short interruption. Fault tolerance: no interruption at all, which costs more because capacity is duplicated.
• Scale vertically = a bigger instance (needs a restart, has a ceiling). Scale horizontally = more instances (needs stateless design, no ceiling). Horizontal is the cloud answer.
• Stateless: any instance can serve any request, so you can add, remove or replace them freely. Keep session state in ElastiCache, DynamoDB or a signed cookie/JWT, uploads in S3, and shared files in EFS. Stateful instances hold up scaling and recovery.
• RPO (recovery point objective): how much data you can lose. RTO (recovery time objective): how long until service returns.
• Single point of failure: any one component whose loss stops the system. Remove it by duplicating it across AZs.

Loose coupling and integration

Queues, topics and events

SQS details that get tested

• Standard queue: nearly unlimited throughput, at-least-once delivery, best-effort ordering, so consumers must tolerate duplicates (idempotency). FIFO queue: strict order within a message group, exactly-once processing, name ends in .fifo, lower throughput (300 messages/s per API action, 3,000 with batching, higher in high-throughput mode).
• Visibility timeout (default 30 seconds, up to 12 hours): hides a message while a consumer works. If the consumer is slower, the message reappears and is processed twice. Raise the timeout to the longest processing time.
• Dead-letter queue (DLQ): after a set number of receives (maxReceiveCount) a message moves to the DLQ for inspection. DLQs for FIFO must be FIFO.
• Long polling (wait up to 20 seconds) cuts empty responses and cost. Delay queues hold messages up to 15 minutes. Retention is 4 days by default and up to 14 days. Messages can be up to 1 MiB (the old limit was 256 KB). For larger payloads, store in S3 and send a pointer.
• Scale a worker fleet on queue depth per instance (a custom metric made from ApproximateNumberOfMessagesVisible divided by running instances) with target tracking. This is the textbook decoupled Auto Scaling design.
• Encryption at rest with SSE-SQS or KMS, and access with queue policies.

SNS details: standard and FIFO topics, message filtering on subscriptions so each subscriber only receives what it needs. The fan-out pattern publishes to one SNS topic that feeds several SQS queues, so each downstream system processes independently and can be down without losing messages.

EventBridge replaces CloudWatch Events. Use it for “when X happens in AWS, do Y” (an EC2 state change, an S3 object event through S3 → EventBridge, a CodePipeline failure, a scheduled cron via EventBridge Scheduler). EventBridge Pipes connect a source (SQS, Kinesis, DynamoDB streams) to a target with optional filtering and enrichment.

Other integration services in scope: AppFlow (no-code SaaS to AWS data flows, for example Salesforce to S3), AppSync (managed GraphQL with real-time subscriptions), AWS Transfer Family (managed SFTP, FTPS, FTP and AS2 in front of S3 or EFS, so partners keep their existing tools).

Workflow orchestration

• Step Functions coordinates Lambda, ECS, Glue, SageMaker and 200+ services with built-in retry, catch, parallel, map and wait states. Use Standard workflows (up to one year, exactly-once, audit history) for long, business-critical flows and Express workflows (up to 5 minutes, at-least-once, very high rate, cheap) for high-volume event processing.
• Prefer Step Functions over chaining Lambdas that call each other, and over cron on EC2.
• SWF is legacy. Amazon MWAA (Airflow) is out of scope.

Event-driven and microservice design

• Components communicate through events and queues rather than direct synchronous calls. The producer doesn’t know who consumes, and a slow consumer doesn’t slow the producer.
• A microservice owns its data and scales on its own. Use API Gateway or an ALB as the front door, and containers or Lambda as the runtime.
• Multi-tier (web, app, data): each tier in its own subnets and security group, load balanced and scaled independently, with a queue or cache between tiers that run at different speeds.
• Caching strategies: CloudFront (edge, HTTP), API Gateway cache (per stage), ElastiCache (in-memory, between app and database), DAX (DynamoDB). Lazy loading (cache on miss) is simple and tolerates cache failure; write-through keeps the cache fresh but caches data that may never be read. Set TTLs.

Serverless and containers

Serverless building blocks

• Lambda: up to 15 minutes, 128 MB to 10,240 MB memory (CPU scales with it), /tmp up to 10 GB, 6 MB synchronous payload. Triggered synchronously (API Gateway, ALB), asynchronously (S3, SNS, EventBridge, with retries and a DLQ or on-failure destination) or by polling (SQS, Kinesis, DynamoDB streams). The default account concurrency is 1,000 per Region, reserved concurrency guarantees and caps a function (also protects a downstream database), provisioned concurrency removes cold starts. Put it in a VPC only when it must reach private resources.
• API Gateway: managed front door for REST, HTTP and WebSocket APIs. Handles auth (IAM, Cognito authorizers, Lambda authorizers), throttling (account default 10,000 requests/second; per-stage and per-key limits through usage plans and API keys), request validation, caching and canary stages. Integration timeout is 29 seconds by default, so long jobs go async. Endpoint types: edge-optimized (through CloudFront), regional, private (inside a VPC). Use an HTTP API for cheap, simple proxying and a REST API for the full feature set.
• DynamoDB: serverless key-value and document database with single-digit millisecond latency and effectively unlimited scale.
• Fargate: serverless compute for containers, with no instances to manage. S3, SQS, SNS, EventBridge, Step Functions, Cognito, Aurora Serverless complete the serverless toolbox.
• A canonical serverless web app: CloudFront + S3 (static front end), API Gateway + Lambda (API), DynamoDB or Aurora Serverless (data), Cognito (auth), SQS/EventBridge between steps.

Containers

• ECS: AWS’s own orchestrator, simple, deeply integrated with IAM and ALB. EKS: managed Kubernetes, pick it when you need Kubernetes portability or the Kubernetes ecosystem. Both run on EC2 (you manage the nodes, you can choose instance type, GPUs, Spot) or Fargate (no nodes, you pay per vCPU and memory per second). ECR stores images, with image scanning and lifecycle policies.
• Choose Fargate when “least operational overhead” and no need for node-level control. Choose EC2 for GPUs, very large steady fleets where Reserved or Spot pricing wins, or special kernel and daemon requirements.
• ECS tasks get permissions from a task role. The task execution role pulls images and writes logs. EKS pods use IAM roles for service accounts or EKS Pod Identity.
• Migrating applications into containers: package the app with a Dockerfile, push to ECR, run on ECS/Fargate (or Elastic Beanstalk, or App Runner for simple web services). Move config to environment variables and Secrets Manager, move local state to S3/EFS/a database, and send logs to stdout. Containers are the answer when an app needs portability, faster deployment, or higher density than one app per VM.
• ECS Anywhere, EKS Anywhere and EKS Distro run the same tooling on your own hardware.

Lambda vs containers vs EC2

Load balancing and scaling for availability

• Load balancers span subnets in multiple AZs, and health checks remove unhealthy targets. Cross-zone load balancing is on by default for ALB (free), off by default for NLB and GWLB.
• Deregistration delay (default 300 seconds) drains in-flight requests. Sticky sessions pin a client to a target but fight statelessness. Slow start eases new targets in.
• Auto Scaling groups span AZs and replace failed instances. Set the health check type to ELB so instances failing the load balancer check are replaced. Use a launch template, and keep min and max. A group of min 1, max 1 across AZs is the cheap self-healing single instance for legacy apps.
• Scaling policies: target tracking (keep a metric at a value, the default choice), step, scheduled (known peaks), predictive (forecast recurring patterns). Scale on the metric that reflects the bottleneck: CPU, ALBRequestCountPerTarget, or queue depth.
• Build an immutable fleet: bake an AMI (or container image), deploy by launching new instances and removing old ones (instance refresh or blue/green) instead of patching in place. This is “immutable infrastructure”, and it makes rollback and replacement trivial. CloudFormation repeats the whole environment identically in another AZ or Region.

High availability and fault-tolerant data

Databases

Backups: RDS automated backups (retention 0–35 days, point-in-time restore using transaction logs) plus manual snapshots, which you can copy cross-Region and cross-account. Restoring always creates a new instance. Test restores.

Storage durability and availability

• S3 is designed for 11 nines durability and stores data across at least three AZs (except One Zone classes). It is strongly consistent. Versioning, Replication (SRR/CRR) and Multi-Region Access Points add recovery and multi-Region reads and writes.
• EBS volumes live in one AZ and are replicated within it. Take snapshots (stored in S3, incremental, can be copied to another AZ or Region) and automate with Data Lifecycle Manager. EBS Multi-Attach (io1/io2) lets several Nitro instances in one AZ share a volume for clustered apps.
• EFS stores data across multiple AZs (Regional) by default. FSx options offer Multi-AZ deployments. Instance store is ephemeral and lost when the instance stops, so never keep the only copy of data there.
• AWS Backup gives one policy-driven place for backups of EC2/EBS, RDS, Aurora, DynamoDB, EFS, FSx and S3, with cross-Region and cross-account copies and Vault Lock.

Networking for resilience

• Route 53 is a highly available DNS service with a 100% availability SLA. Routing policies:

Alias records point to AWS resources (ALB, CloudFront, S3 website) at the zone apex, are free, and follow IP changes. A CNAME can’t be used at the apex. Health checks can monitor endpoints, other health checks or CloudWatch alarms (so private resources can fail over too).

• Global Accelerator gives two static anycast IPs and fails over between Regional endpoints in seconds, with no DNS caching delay. CloudFront origin groups fail over to a secondary origin.
• Deploy one NAT gateway per AZ, redundant VPN tunnels, and Direct Connect with a VPN backup (or two Direct Connect locations for maximum resilience).
• Use Transit Gateway rather than a mesh of peering connections for many VPCs, and VPC peering for a simple one-to-one link (non-transitive, no overlapping CIDRs).

Disaster recovery

• Choose the cheapest strategy that meets the stated RTO and RPO. “Restore within hours, lowest cost” is backup and restore. “RPO of seconds and RTO of minutes with a relational database” is Aurora Global Database or warm standby. “Zero downtime across Regions” is active/active with Route 53 or Global Accelerator.
• AWS Elastic Disaster Recovery (DRS) continuously replicates servers (physical, virtual, other clouds, EC2) to low-cost staging in AWS and launches them on demand, for a low RPO (seconds) and RTO (minutes), as an alternative to a second always-on environment. AWS Application Migration Service (MGN) is the same replication engine for migrations.
• Service quotas and throttling in DR: quotas are per Region and per account, so a standby Region starts with default limits. Raise them ahead of time (EC2 vCPUs, EIPs, Lambda concurrency), because you can’t ask for more during an outage. API throttling and burst limits on API Gateway, Lambda and DynamoDB also protect dependencies, and clients should retry with exponential backoff and jitter.
• Distributed design patterns: retries with backoff and jitter, idempotent operations (safe to repeat), timeouts, circuit breakers, bulkheads (isolate failures), health checks, and graceful degradation. Prefer static stability: fail over using capacity that is already running rather than relying on a control-plane action during an incident.
• Chaos testing with AWS Fault Injection Service proves the design works (FIS is listed out of scope for the exam, but the concept is what a game day does).

Purpose-built services and legacy applications

• Pick the service built for the job: Rekognition (image and video analysis), Textract (extract text and tables from documents), Transcribe (speech to text), Polly (text to speech), Translate, Comprehend (language analysis: sentiment, entities, PII), Lex (chatbots), Kendra (enterprise search), SageMaker (build and deploy ML models), Bedrock (foundation models). Note that Forecast, Fraud Detector, QLDB, Elastic Transcoder and Pinpoint have been retired or closed to new customers, so recent questions favour their successors (Bedrock-based or SageMaker options, Aurora/DynamoDB with ledger design, MediaConvert, SNS/End User Messaging).
• Reliability for apps that can’t change: put the app behind a load balancer and an Auto Scaling group, use EFS for shared files, Multi-AZ RDS, RDS Proxy or ElastiCache to relieve the database, Storage Gateway or Transfer Family for old file protocols, Application Migration Service to lift and shift, EC2 auto recovery or an Auto Scaling group of one for single servers, and Route 53 failover or an Elastic IP/ENI re-attach for failover without code changes. “Without modifying the application” means an infrastructure-level fix.

Workload visibility

• CloudWatch: metrics, alarms, Logs (with metric filters and Insights queries), dashboards, Synthetics canaries for endpoint checks, Container Insights. Alarms drive Auto Scaling, EC2 recovery and SNS notifications.
• X-Ray traces requests across services (service map, latency by segment) to find the slow or failing hop in a microservice or serverless call chain.
• AWS Health Dashboard shows AWS service events affecting you. Trusted Advisor flags fault tolerance gaps (single-AZ RDS, no backups). Well-Architected Tool reviews a workload against the framework.
• Choose metrics from the business requirement: availability percentage, error rate, p99 latency, healthy host count, queue depth and age of oldest message, replica lag, and measured RPO and RTO from DR tests.