Domain 2: Design Resilient Architectures

AWS Certified Solutions Architect – Associate (SAA-C03) — Domain 2: Design Resilient Architectures

Exam Code: SAA-C03  |  Level: Associate
Domain Weight: 26%  |  Total Domains: 4  |  Passing Score: 720/1000

---

Table of Contents

1. Decoupling and Messaging Patterns
   • 1.1 Amazon SQS — Message Queuing
   • 1.2 Amazon SNS — Pub/Sub Messaging
   • 1.3 Amazon EventBridge
   • 1.4 Amazon MQ
2. Serverless and Event-Driven Architectures
   • 2.1 AWS Lambda — Deep Dive
   • 2.2 AWS Step Functions
   • 2.3 Container Orchestration — ECS and EKS
3. Load Balancing and API Management
   • 3.1 Elastic Load Balancing — Full Comparison
   • 3.2 Amazon API Gateway
   • 3.3 Caching Strategies
4. Highly Available and Fault-Tolerant Architecture
   • 4.1 Multi-AZ and Multi-Region Design Patterns
   • 4.2 Database High Availability
   • 4.3 EC2 Auto Scaling — Full Reference
   • 4.4 Route 53 for Availability
5. Storage Durability and Resilience
   • 5.1 S3 Durability, Storage Classes, and Replication
   • 5.2 Block and File Storage Resilience
   • 5.3 AWS Backup
6. Resilience Patterns and Observability
   • 6.1 Architectural Resilience Patterns
   • 6.2 Monitoring and Tracing
7. Exam Tips & Quick Reference

---

1. Decoupling and Messaging Patterns

Tight coupling means Service A calls Service B directly — if B is slow or down, A is blocked. Decoupling with queues or event buses breaks this dependency so each component scales and fails independently. This is one of the most tested architectural concepts on the SAA-C03.

1.1 Amazon SQS — Message Queuing

Standard vs. FIFO Queues

Key SQS Concepts

Exam Tip: SQS Visibility Timeout is a critical concept. If your consumer takes longer than the timeout to process, the message becomes visible again and another consumer may pick it up. Extend the timeout if processing is slow; don't rely on the 30-second default for complex workloads.

SQS Auto Scaling Integration

Custom CloudWatch Metric:
  ApproximateNumberOfMessagesVisible / NumberOfRunningInstances

Target Tracking Policy:
  Target = desired messages per instance (e.g., 100)
  
Result: ASG scales workers proportionally to queue backlog

SQS FIFO — Deduplication and Ordering

A MessageGroupId is required and determines ordering scope — messages with the same group ID are processed in strict FIFO order. Deduplication uses either content-based deduplication (SHA-256 hash of body, 5-minute window) or an explicit MessageDeduplicationId.

---

1.2 Amazon SNS — Pub/Sub Messaging

SNS is a push-based publish/subscribe service. Publishers send to a Topic; all subscribers receive the same message simultaneously.

SNS vs. SQS

Fan-Out Pattern (Frequently Tested)

Order Placed → SNS Topic
                    ├── SQS Queue A → Fulfillment Service
                    ├── SQS Queue B → Notification Service
                    └── SQS Queue C → Analytics Service

Each queue processes independently. A failure in one downstream service does not affect the others. This is the correct answer for "process one event in multiple systems simultaneously."

SNS Subscribers: SQS, Lambda, HTTP/HTTPS endpoint, email, SMS, mobile push notifications, Kinesis Data Firehose.

---

1.3 Amazon EventBridge

EventBridge is a serverless event bus for loosely coupled application integration. It is more powerful than SNS for complex routing scenarios.

Key Concept: EventBridge Pipes create direct point-to-point connections between a source (SQS, DynamoDB Stream, Kinesis) and a target with optional filtering and enrichment via Lambda. Use Pipes when you need to connect two services with minimal code.

---

1.4 Amazon MQ

Amazon MQ is a managed message broker for Apache ActiveMQ and RabbitMQ. Use it when migrating existing applications that use standard messaging protocols (AMQP, STOMP, MQTT, OpenWire, JMS) to avoid rewriting application code.

Exam Tip: For new applications, always choose SQS/SNS (more scalable, fully managed, AWS-native). Choose Amazon MQ only when the question mentions existing applications using standard broker protocols that cannot be refactored.

---

2. Serverless and Event-Driven Architectures

2.1 AWS Lambda — Deep Dive

Lambda Limits and Characteristics

Lambda Invocation Types

Lambda Concurrency Controls

• Reserved concurrency — limits the maximum concurrent executions for one function; prevents it from consuming the entire account concurrency (throttles excess requests).
• Provisioned concurrency — pre-initializes N function instances to eliminate cold starts; charged per hour provisioned; critical for latency-sensitive applications.

Key Concept: Cold starts occur when Lambda initializes a new execution environment for the first invocation. Mitigate with Provisioned Concurrency (any runtime) or Lambda SnapStart (Java — snapshots the initialized state for fast restore).

Lambda Best Practices

• Move expensive initialization (DB connections, SDK clients) outside the handler function so it is reused across warm invocations.
• Use Lambda Layers for shared libraries to reduce deployment package size.
• Store configuration in environment variables or SSM Parameter Store.
• When Lambda needs VPC resources (RDS, ElastiCache), attach it to the VPC — but add a NAT Gateway for internet access and VPC Endpoints for AWS service calls.

Lambda Destinations (Async Only)

Route the result of asynchronous invocations to a next step without polling:

• On Success → SQS, SNS, EventBridge, or another Lambda
• On Failure → SQS, SNS, EventBridge, or another Lambda

---

2.2 AWS Step Functions

Step Functions orchestrates multi-step workflows as state machines, coordinating Lambda functions and AWS services with built-in error handling, retries, and parallel execution.

---

2.3 Container Orchestration — ECS and EKS

ECS Launch Types

ECS Key Concepts

ECS Networking Modes:

• awsvpc (recommended) — each task gets its own ENI and security group; best isolation and control
• bridge — shared host network; port mapped via NAT on host
• host — task shares the host's ENI directly; maximum performance, minimal isolation

Exam Tip: ECS tasks have two IAM roles. The Execution Role allows ECS to pull the image from ECR and write logs. The Task Role gives your application code permissions to call AWS services. These are separate and both may be required.

Amazon EKS

Managed Kubernetes control plane. Worker nodes run on EC2 node groups or Fargate. More complex than ECS but portable (standard Kubernetes API) across cloud providers. Use when the team is already Kubernetes-native or when workloads must be portable.

Amazon ECR

Managed container registry integrated with IAM. Features: image scanning (basic on-push or enhanced/continuous via Inspector), lifecycle policies to automatically remove old images, and cross-region/cross-account replication.

---

3. Load Balancing and API Management

3.1 Elastic Load Balancing — Full Comparison

ALB Content-Based Routing

Listener Rules (evaluated top to bottom, first match wins):
├── IF path = /api/*       → forward to API target group
├── IF host = admin.co.com → forward to Admin target group
├── IF header X-Version=v2 → forward to V2 target group
├── IF query ?color=blue   → weighted: 80% Blue TG, 20% Green TG
└── DEFAULT                → forward to Main target group

Target Types: EC2 instances, IP addresses (including on-premises via Direct Connect), Lambda functions, or another ALB.

---

3.2 Amazon API Gateway

API Types

Key Features

• Throttling — default 10,000 req/sec per account; burst limit 5,000; configurable per stage and per method
• Caching — cache responses at the API Gateway level; configurable TTL (default 300 seconds); reduces backend load
• Usage Plans — throttle and quota per API key; used for API monetization and partner access tiers
• Stages — separate environments (dev/staging/prod) each with independent settings, throttling, and logging

API Gateway Authorizers

---

3.3 Caching Strategies

Amazon ElastiCache — Redis vs. Memcached

Choose Redis when you need persistence, HA, pub/sub, rich data structures, or leaderboards. Choose Memcached when you need simple, pure caching with multi-threaded performance and no durability requirements.

Caching Patterns

Amazon DAX (DynamoDB Accelerator)

In-memory write-through cache for DynamoDB. Uses the same DynamoDB API — transparent to the application. Provides microsecond read latency for frequently accessed items. Does not help write-heavy workloads. Cluster size: 1–10 nodes, multi-AZ.

---

4. Highly Available and Fault-Tolerant Architecture

4.1 Multi-AZ and Multi-Region Design Patterns

Availability Zones

AZs are physically separate data centers within a Region with independent power, cooling, and networking. Design all production workloads to span at least 2 AZs (3 recommended for critical applications). Auto Scaling groups automatically rebalance instances across specified AZs.

Disaster Recovery Strategy Comparison

Key Concept: RPO is the maximum acceptable data loss (measured in time). RTO is the maximum acceptable downtime. Lower RPO and RTO = higher cost. The exam often presents a cost constraint and asks which DR strategy fits.

---

4.2 Database High Availability

RDS Multi-AZ vs. Read Replicas

Exam Tip: Multi-AZ standby is NOT readable. If a question asks about offloading read traffic, the answer is Read Replicas. If a question asks about automatic failover or high availability, the answer is Multi-AZ. These are different features that can (and should) both be used together.

Amazon Aurora HA Architecture

Aurora stores 6 copies of data across 3 AZs automatically (2 copies per AZ). It can sustain writes with 4/6 copies and reads with 3/6 copies, and self-heals corrupted blocks via peer-to-peer replication.

Amazon DynamoDB High Availability Features

DynamoDB replicates data across 3 AZs by default — no configuration needed.

---

4.3 EC2 Auto Scaling — Full Reference

Scaling Policy Types

Key Concept: Target Tracking is the simplest and recommended default. You specify a target metric value (e.g., 50% CPU) and AWS automatically adjusts capacity to maintain it. Predictive Scaling learns from 2 weeks of history and pre-warms capacity before demand spikes.

Auto Scaling Lifecycle Hooks

Lifecycle hooks allow custom actions during scale-out and scale-in events. The instance is paused in Pending:Wait (scale-out) or Terminating:Wait (scale-in) state.

• EC2_INSTANCE_LAUNCHING hook — configure the instance before it enters service (install agents, run tests)
• EC2_INSTANCE_TERMINATING hook — drain connections, copy logs to S3, or deregister from service discovery before termination

Launch Templates vs. Launch Configurations

---

4.4 Route 53 for Availability

Routing Policy Reference

Route 53 Health Checks

Route 53 health checkers are globally distributed. Supported check types: HTTP, HTTPS, TCP, and string matching (verify response body contains specific text). A Calculated health check combines multiple health checks with AND/OR logic. Use a CloudWatch alarm health check for resources that are not publicly accessible (e.g., internal ALBs).

---

5. Storage Durability and Resilience

5.1 S3 Durability, Storage Classes, and Replication

S3 Storage Class Durability and Availability

Exam Tip: All S3 storage classes share the same 11-nines (99.999999999%) durability except One Zone-IA, which has the same durability rating mathematically but will lose data if the single AZ is destroyed. Availability (uptime SLA) differs across classes.

S3 Replication

Both replication types require versioning enabled on both source and destination.

---

5.2 Block and File Storage Resilience

EBS Resilience

EBS volumes are AZ-specific — they exist in one AZ only. For resilience:

• Take snapshots (stored in S3, multi-AZ) at regular intervals
• Copy snapshots to another Region for cross-region DR
• Use AWS Data Lifecycle Manager (DLM) to automate snapshot schedules and retention

EFS Resilience

Amazon EFS automatically replicates data across multiple AZs in a Region (Standard tier). Use EFS Replication to create a read-only replica in a different Region for DR.

FSx for Windows — Multi-AZ

FSx for Windows File Server supports a Multi-AZ deployment with automatic failover between file servers in separate AZs.

---

5.3 AWS Backup

AWS Backup provides centralized, policy-driven backup management across: EC2, EBS, RDS, Aurora, DynamoDB, EFS, FSx, Storage Gateway, and S3.

---

6. Resilience Patterns and Observability

6.1 Architectural Resilience Patterns

Queue-Based Load Leveling

Place an SQS queue between a fast producer and a slow consumer. The producer never waits; the consumer processes at its own pace. Queue depth provides a scaling signal.

[Fast Producer] → [SQS Queue] → [Consumer Workers]
                                     ↑
                             (Auto Scaling based on
                             ApproximateNumberOfMessagesVisible)

Circuit Breaker Pattern

Stop calling a failing downstream service to prevent cascading failures. When the error rate exceeds a threshold, open the circuit (fail fast). Periodically allow a test request through to detect recovery.

Retry with Exponential Backoff and Jitter

Do not retry immediately on failure — wait an exponentially increasing interval. Add jitter (random delay) to prevent a "thundering herd" where all retrying clients hit the service simultaneously. AWS SDKs implement this by default.

Bulkhead Pattern

Isolate workloads so a failure in one does not affect others. Use separate SQS queues per consumer type, separate Lambda functions per purpose, and separate ECS services per workload. Avoid monoliths that fail entirely.

---

6.2 Monitoring and Tracing

Amazon CloudWatch

AWS X-Ray

Distributed tracing for microservices and serverless applications. Traces requests end-to-end across Lambda, ECS, EC2, API Gateway, SQS, and DynamoDB. The Service Map provides a visual representation of all components and inter-service latency. Use annotations (indexed) for filtering traces and metadata (non-indexed) for additional context. Sampling controls the fraction of traces collected to manage cost.

---

Exam Tips & Quick Reference

Scenario-to-Answer Mapping

---

Common Traps

• Multi-AZ standby not readable: The RDS Multi-AZ standby replica cannot serve read traffic. If the question mentions read scaling, use Read Replicas, not Multi-AZ.
• DynamoDB Global Tables require Streams: Always enable DynamoDB Streams before creating Global Tables — a frequently tested prerequisite.
• Amazon MQ vs. SQS: Only choose MQ when the scenario explicitly mentions existing applications using standard protocols (JMS, AMQP, STOMP). New applications should use SQS/SNS.
• Step Functions Express duration: Express Workflows max out at 5 minutes. Standard Workflows support up to 1 year. Confusing these two is a common exam mistake.
• SNS does not persist messages: SNS is fire-and-forget. If subscribers are unavailable, messages are lost. Add an SQS queue as a subscriber to provide durability.
• Lambda timeout in VPC: Lambda functions in a VPC cannot access the internet without a NAT Gateway and cannot reach AWS services without VPC Endpoints.
• S3 One Zone-IA risk: The 11-nines durability figure is misleading — data will be lost if the single AZ fails. Do not use One Zone-IA for data that cannot be recreated.

---

Key Terms — Domain 2

---

End of Domain 2. Continue to Domain 3: Design High-Performing Architectures →