📚 AWS DVA-C02 Exam Study Guide
Comprehensive Summary Organized by AWS Services
Last Updated: March 27, 2026
📊 Exam Focus Areas
🔥 Heavy Focus (Multiple Questions)
- Lambda - Serverless compute
- API Gateway - RESTful API management
- SNS - Notification service
- SQS - Message queuing
- KMS - Key management
- CloudWatch - Monitoring & logging
- IAM - Identity & access management
📝 1-2 Questions Each
- CI/CD (CodeDeploy, CodePipeline, CodeBuild)
- S3, DynamoDB, RDS
- Secrets Manager, Systems Manager (SSM)
- Elastic Beanstalk, CloudFormation
- ECS/EKS, ElastiCache
⚠️ Variable Coverage
- X-Ray, Step Functions, Kinesis, AppConfig
- Note: Question distribution varies by exam set
🔐 IAM & Security
IAM Roles & Policies
┌─────────────────────────────────────────────────────────┐
│ IAM Role Types │
├─────────────────────────────────────────────────────────┤
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Instance Profile │ │ Execution Role │ │
│ │ │ │ │ │
│ │ EC2 → IAM Role │ │ Lambda/ECS Perms │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Task Role │ │ Service Role │ │
│ │ │ │ │ │
│ │ ECS Task Perms │ │ AWS Service Perms│ │
│ └──────────────────┘ └──────────────────┘ │
└─────────────────────────────────────────────────────────┘Best Practice: Assign separate IAM roles per task/function (Principle of Least Privilege)
AWS STS (Security Token Service)
┌──────────────────────────────────────────────────────────┐
│ STS Token Types & Use Cases │
├──────────────────────────────────────────────────────────┤
│ │
│ GetSessionToken │
│ ├─ Use: IAM user temp credentials │
│ ├─ Duration: 15 min - 36 hours (default 12 hrs) │
│ └─ Scenario: MFA-protected API calls │
│ │
│ GetFederationToken │
│ ├─ Use: Grant temp access to federated users │
│ └─ Scenario: App giving access to others │
│ │
│ AssumeRoleWithWebIdentity │
│ ├─ Use: Social login (Google, Facebook) │
│ └─ Scenario: Mobile app authentication │
│ │
│ AssumeRoleWithSAML │
│ ├─ Use: Corporate SSO/SAML IdP │
│ └─ Scenario: Enterprise federation │
│ │
└──────────────────────────────────────────────────────────┘Cross-Account Access Pattern
┌────────────────────────────────────────────────────────────┐
│ Cross-Account Resource Access Flow │
└────────────────────────────────────────────────────────────┘
Account A (Dev) Account B (Production)
┌──────────────┐ ┌──────────────────────┐
│ │ │ │
│ IAM User │ │ IAM Role │
│ (Developer) │ │ (S3AccessRole) │
│ │ │ │
└──────┬───────┘ └──────────┬───────────┘
│ │
│ 1. AssumeRole (STS) │
├───────────────────────────────>│
│ │
│ 2. Temporary Credentials │
│<───────────────────────────────┤
│ │
│ 3. Access S3 with Temp Creds │
├───────────────────────────────>│
│ │
│ 4. Resource Access Granted │
│<───────────────────────────────┤
│ │
└────────────────────────────────┘Configuration:
- Create IAM role in Account B with trust policy for Account A
- Attach S3 permissions to the role
- Grant Account A users permission to assume the role
🗄️ DynamoDB
Table Structure & Keys
┌──────────────────────────────────────────────────────────┐
│ DynamoDB Table Architecture │
├──────────────────────────────────────────────────────────┤
│ │
│ ┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓ │
│ ┃ Table: OrdersTable ┃ │
│ ┣━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┫ │
│ ┃ Partition Key: UserID ┃ │
│ ┃ Sort Key: OrderDate ┃ │
│ ┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛ │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ Partition 1 │ │ Partition 2 │ │
│ ├─────────────────────┤ ├─────────────────────┤ │
│ │ UserID: user-123 │ │ UserID: user-456 │ │
│ │ Orders: [....] │ │ Orders: [....] │ │
│ │ Max: 10 GB │ │ Max: 10 GB │ │
│ │ 3000 RCU / 1000 WCU │ │ 3000 RCU / 1000 WCU │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘Secondary Indexes Comparison
| Feature | GSI (Global) | LSI (Local) |
|---|---|---|
| Partition Key | Can be different | Must be same as table |
| Sort Key | Can be different | Must be different |
| Scope | Spans all partitions | Local to partition |
| Creation | Anytime | Only at table creation |
| Limit | No limit | 5 per table |
| Size | No limit | 10 GB per partition |
| Throughput | Separate capacity | Shares with table |
| Consistency | Eventually consistent | Strongly or eventually consistent |
DynamoDB Streams
┌──────────────────────────────────────────────────────────┐
│ DynamoDB Streams Architecture │
└──────────────────────────────────────────────────────────┘
DynamoDB Table
┌────────────────┐
│ Item Modified │
└────────┬───────┘
│
▼
┌────────────────┐ StreamViewType Options:
│ DynamoDB │ ┌─────────────────────────────┐
│ Stream │ │ KEYS_ONLY │
│ (24 hrs) │ │ NEW_IMAGE (after modify) │
└────────┬───────┘ │ OLD_IMAGE (before modify)│
│ │ NEW_AND_OLD_IMAGES │
│ └─────────────────────────────┘
▼
┌────────────────┐
│ Lambda │
│ Trigger │
│ (Process) │
└────────────────┘Use Case: Capture item-level changes for audit, backup, or replication
Hot Partition Problem & Solutions
❌ BAD: Hot Partition
┌────────────────────────────────────────┐
│ Partition Key: OrderDate │
│ Problem: All orders on same date │
│ go to same partition │
├────────────────────────────────────────┤
│ 2024-03-27 → Partition 1 [OVERLOAD]│
│ 2024-03-27 → Partition 1 [OVERLOAD]│
│ 2024-03-27 → Partition 1 [OVERLOAD]│
└────────────────────────────────────────┘
✅ GOOD: Distributed Load
┌────────────────────────────────────────┐
│ Partition Key: OrderDate + Random(1-10)│
│ Solution: Distributes writes evenly │
├────────────────────────────────────────┤
│ 2024-03-27#1 → Partition 1 │
│ 2024-03-27#5 → Partition 5 │
│ 2024-03-27#3 → Partition 3 │
└────────────────────────────────────────┘Solutions for Hot Partitions:
- Add random suffix to partition key
- Use high cardinality attributes (email, user_id)
- Use composite attributes
- Cache popular items
Query vs Scan
┌──────────────────────────────────────────────────────────┐
│ Query vs Scan │
├──────────────────────────────────────────────────────────┤
│ │
│ QUERY (Efficient ✅) │
│ ┌─────────────────────────────────────────────┐ │
│ │ SELECT * FROM Orders │ │
│ │ WHERE UserID = "user-123" │ │
│ │ AND OrderDate > "2024-01-01" │ │
│ └─────────────────────────────────────────────┘ │
│ • Uses partition key (required) │
│ • Optional sort key condition │
│ • Fast, low RCU consumption │
│ │
│ SCAN (Inefficient ❌) │
│ ┌─────────────────────────────────────────────┐ │
│ │ SELECT * FROM Orders │ │
│ │ // Reads entire table, then filters │ │
│ └─────────────────────────────────────────────┘ │
│ • Reads all items, then filters │
│ • Slow, high RCU consumption │
│ • Use smaller page size to reduce impact │
│ • Consider parallel scans for large tables │
│ │
└──────────────────────────────────────────────────────────┘Batch Operations
| Operation | Description | Limit |
|---|---|---|
| BatchGetItem | Read multiple items | 100 items, 16 MB max |
| BatchWriteItem | Write/Delete multiple items | 25 items |
| Query | Get items with same partition key | 1 MB per request |
| Scan | Read entire table | 1 MB per page |
Optimistic Locking Pattern
┌──────────────────────────────────────────────────────────┐
│ Optimistic Locking Flow (Prevents Overwrites) │
└──────────────────────────────────────────────────────────┘
User A DynamoDB Table User B
┌──────┐ ┌──────────┐ ┌──────┐
│ │ │ Item: │ │ │
│ │ 1. Read │ id=123 │ 1. Read │ │
│ ├─────────────────>│ version=5├──────────────>│ │
│ │ │ │ │ │
│ │ 2. Modify └──────────┘ 2. Modify │ │
│ │ locally locally │ │
│ │ │ │
│ │ 3. Write (v=5) │ │
│ ├─────────────────> │ │
│ │ ✅ Success! │ │
│ │ version=6 │ │
│ │ │ │
│ │ 4. Write (v=5) ❌ │ │
│ │ <──────────────────────────┤ │
│ │ FAILS! Version mismatch │ │
│ │ (expected 5, found 6) │ │
└──────┘ └──────┘Implementation: Use a version number attribute and conditional writes
🔥 AWS Lambda
Lambda Execution Model
┌──────────────────────────────────────────────────────────┐
│ Lambda Invocation Types │
└──────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ RequestResponse (Synchronous) │
├─────────────────────────────────────────────────────────┤
│ Client → Lambda → [Processing] → Response → Client │
│ • Wait for result │
│ • Return value to caller │
│ • Use: API calls, immediate response needed │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ Event (Asynchronous) │
├─────────────────────────────────────────────────────────┤
│ Client → Lambda → [202 Accepted] → Client │
│ [Processing in background] │
│ • Don't wait for result │
│ • Lambda handles retries │
│ • Use: Background jobs, parallel processing │
└─────────────────────────────────────────────────────────┘
┌─────────────────────────────────────────────────────────┐
│ DryRun (Validation) │
├─────────────────────────────────────────────────────────┤
│ Client → Lambda → [Validate only] → Response │
│ • No execution │
│ • Check permissions & parameters │
│ • Use: Testing without running │
└─────────────────────────────────────────────────────────┘Lambda Event Source Mapping
Event Source → Lambda Polls → Lambda Function Executes
┌─────────────┐ ┌──────────────┐ ┌──────────────┐
│ Kinesis │ │ Lambda │ │ Lambda │
│ Stream │<────│ Service │────>│ Function │
│ (Shards) │ │ (Polls) │ │ │
└─────────────┘ └──────────────┘ └──────────────┘
│
│ ┌──────────────┐
│ │ DynamoDB │
└──────────────│ Streams │
└──────────────┘
│
┌──────────────┐
│ SQS │
│ Queue │
└──────────────┘ Key Point: 1 Lambda execution per Kinesis/DynamoDB shard (concurrency = shard count)
Lambda Concurrency
┌──────────────────────────────────────────────────────────┐
│ Lambda Concurrency Limits │
├──────────────────────────────────────────────────────────┤
│ │
│ Account Limit: 1,000 concurrent executions │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Reserved: 900 (max) │ │
│ │ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ Function A │ │ Function B │ │ │
│ │ │ Reserved: │ │ Reserved: │ │ │
│ │ │ 450 │ │ 450 │ │ │
│ │ └─────────────┘ └─────────────┘ │ │
│ └─────────────────────────────────────────────────┘ │
│ Unreserved: 100 (minimum, always available) │
│ ┌─────────────────────────────────────────────────┐ │
│ │ Shared by all other functions │ │
│ └─────────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘Rule: Cannot reserve more than 900 (must leave 100 unreserved)
Lambda@Edge
┌──────────────────────────────────────────────────────────┐
│ Lambda@Edge with CloudFront │
└──────────────────────────────────────────────────────────┘
Global Users
│
▼
┌───────────────────────────────┐
│ CloudFront Edge Location │
├───────────────────────────────┤
│ │
│ 1. Viewer Request │
│ ↓ │
│ [Lambda@Edge] ← Auth Check │
│ ↓ │
│ 2. Origin Request │
│ ↓ │
│ [Lambda@Edge] ← Add Headers │
└───────────────┬───────────────┘
│
▼
Origin ServerUse Cases:
- User authentication at edge
- Request/response manipulation
- A/B testing
- Bot detection
🌐 API Gateway
Integration Types
┌──────────────────────────────────────────────────────────┐
│ API Gateway Integration Types │
├──────────────────────────────────────────────────────────┤
│ │
│ HTTP_PROXY (Pass-through) │
│ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ │ Client │──────>│ API │──────>│ HTTP │ │
│ │ │<──────│ Gateway │<──────│ Endpoint │ │
│ └─────────┘ └─────────┘ └──────────┘ │
│ • No transformation │
│ │
│ HTTP (Custom) │
│ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ │ Client │──────>│ API │──────>│ HTTP │ │
│ │ │<──────│ Gateway │<──────│ Endpoint │ │
│ └─────────┘ └─────────┘ └──────────┘ │
│ • With mapping templates │
│ │
│ AWS_PROXY (Lambda Proxy) ⭐ Most Common │
│ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ │ Client │──────>│ API │──────>│ Lambda │ │
│ │ │<──────│ Gateway │<──────│ Function │ │
│ └─────────┘ └─────────┘ └──────────┘ │
│ • Entire request passed to Lambda │
│ • No mapping needed │
│ │
│ AWS (Custom) │
│ ┌─────────┐ ┌─────────┐ ┌──────────┐ │
│ │ Client │──────>│ API │──────>│ AWS │ │
│ │ │<──────│ Gateway │<──────│ Service │ │
│ └─────────┘ └─────────┘ └──────────┘ │
│ • With VTL mapping templates │
│ │
└──────────────────────────────────────────────────────────┘Lambda Proxy Integration Event Structure
{
"resource": "/users/{userId}",
"path": "/users/123",
"httpMethod": "GET",
"headers": {
"Accept": "application/json",
"Host": "api.example.com"
},
"queryStringParameters": {
"page": "1"
},
"pathParameters": {
"userId": "123"
},
"stageVariables": {
"environment": "prod"
},
"body": null,
"isBase64Encoded": false
}API Gateway Authorization
┌──────────────────────────────────────────────────────────┐
│ API Gateway Authorization Methods │
└──────────────────────────────────────────────────────────┘
1. IAM Authorization
┌────────┐ SigV4 Signed Request ┌─────────────┐
│ Client │──────────────────────────> │ API Gateway │
└────────┘ (IAM Credentials) └─────────────┘
2. Lambda Authorizer (Custom)
┌────────┐ Token/Request Params ┌─────────────┐
│ Client │──────────────────────────> │ API Gateway │
└────────┘ └──────┬──────┘
│
▼
┌─────────────┐
│ Lambda │
│ Authorizer │
└──────┬──────┘
│
Returns IAM Policy
3. Cognito User Pool
┌────────┐ JWT Token ┌─────────────┐
│ Client │──────────────────────────> │ API Gateway │
└────────┘ (from Cognito login) └─────────────┘
4. API Keys + Usage Plans
┌────────┐ x-api-key Header ┌─────────────┐
│ Client │──────────────────────────> │ API Gateway │
└────────┘ (Rate limiting) └─────────────┘API Gateway Stages & Deployment
┌──────────────────────────────────────────────────────────┐
│ API Gateway Stages │
└──────────────────────────────────────────────────────────┘
API Definition
│
├─── Deployment 1
│ │
│ ├─── Stage: dev
│ │ URL: https://api.example.com/dev
│ │ Variables: { lambdaArn: "arn:...dev" }
│ │
│ ├─── Stage: test
│ │ URL: https://api.example.com/test
│ │ Variables: { lambdaArn: "arn:...test" }
│ │
│ └─── Stage: prod
│ URL: https://api.example.com/prod
│ Variables: { lambdaArn: "arn:...prod" }
│ Caching: Enabled (TTL: 300s)
│
└─── Deployment 2 (new version)
│
└─── Stage: v2
URL: https://api.example.com/v2API Gateway Caching
┌──────────────────────────────────────────────────────────┐
│ API Gateway Cache Flow │
└──────────────────────────────────────────────────────────┘
Request 1 (Cache Miss)
┌────────┐ ┌─────────────┐ ┌──────────┐
│ Client │────────>│ API Gateway │────────>│ Lambda │
│ │ │ [Cache] │ │ │
│ │<────────│ Empty │<────────│ │
└────────┘ └─────────────┘ └──────────┘
│
└─ Store in cache (TTL: 300s)
Request 2 (Cache Hit)
┌────────┐ ┌─────────────┐
│ Client │────────>│ API Gateway │
│ │ │ [Cache] │ (No Lambda call!)
│ │<────────│ ✅ Hit! │
└────────┘ └─────────────┘
Cache Invalidation:
• Client sends: Cache-Control: max-age=0
• Requires authorization checkbox enabled📨 SQS (Simple Queue Service)
Queue Types Comparison
┌──────────────────────────────────────────────────────────┐
│ Standard Queue vs FIFO Queue │
├──────────────────────────────────────────────────────────┤
│ │
│ STANDARD QUEUE │
│ ┌──────────────────────────────────────────────┐ │
│ │ [Msg1] [Msg2] [Msg3] [Msg4] [Msg5] │ │
│ │ ↓ ↓ ↓ ↓ ↓ │ │
│ │ Order NOT guaranteed │ │
│ │ Delivery: At-least-once (possible duplicates)│ │
│ │ Throughput: Unlimited │ │
│ │ Use: High throughput, order doesn't matter │ │
│ └──────────────────────────────────────────────┘ │
│ │
│ FIFO QUEUE (.fifo suffix required) │
│ ┌──────────────────────────────────────────────┐ │
│ │ [Msg1] → [Msg2] → [Msg3] → [Msg4] → [Msg5] │ │
│ │ ↓ ↓ ↓ ↓ ↓ │ │
│ │ Order GUARANTEED (FIFO) │ │
│ │ Delivery: Exactly-once (no duplicates) │ │
│ │ Throughput: 300 TPS (3000 with batching) │ │
│ │ Use: Order critical, financial transactions │ │
│ └──────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘SQS Message Lifecycle
┌──────────────────────────────────────────────────────────┐
│ SQS Message Lifecycle │
└──────────────────────────────────────────────────────────┘
Producer SQS Queue Consumer
│ │ │
│ 1. SendMessage │ │
├────────────────────────>│ │
│ │ │
│ [Message] │
│ Retention: 4 days │
│ │ │
│ │ 2. ReceiveMessage │
│ │<────────────────────────┤
│ │ │
│ Visibility Timeout │
│ (Hidden: 30s) │
│ │ │
│ │ 3. Processing... │
│ │ │
│ │ 4. DeleteMessage │
│ │<────────────────────────┤
│ │ │
│ Message Deleted │
│ │ │
Visibility Timeout Expiry (if not deleted):
│ │
│ Message becomes
│ visible again
│ (retry mechanism) Long Polling vs Short Polling
SHORT POLLING (WaitTimeSeconds = 0)
┌────────┐ ┌─────────┐
│Consumer│───────>│ SQS │
│ │ Query │ Queue │
│ │<───────│ (Empty) │
└────────┘ Instant└─────────┘
Response
• Returns immediately (even if empty)
• More API calls = Higher cost
• May miss messages
LONG POLLING (WaitTimeSeconds = 1-20) ⭐ Recommended
┌────────┐ ┌─────────┐
│Consumer│───────>│ SQS │
│ │ Wait │ Queue │
│ │ up to │ (Wait..)│
│ │ 20s │ │
│ │<───────│[Message]│
└────────┘ └─────────┘
• Waits until message arrives or timeout
• Fewer API calls = Lower cost
• More efficientSQS Extended Client Library
Large Message Handling (> 256 KB, up to 2 GB)
┌─────────────────────────────────────────────────────────┐
│ Producer │
│ ┌──────────┐ │
│ │ Large │ 1. Upload to S3 │
│ │ Payload │─────────────────────┐ │
│ │ (500MB) │ ▼ │
│ └──────────┘ ┌──────────┐ │
│ │ S3 │ │
│ │ │ Bucket │ │
│ │ └──────────┘ │
│ │ 2. Send S3 pointer │ │
│ ▼ │ │
│ ┌──────────┐ │ │
│ │ SQS │ │ │
│ │ Queue │ │ │
│ │ (S3 ref) │ │ │
│ └──────────┘ │ │
│ │ │ │
│ │ 3. Receive pointer │ │
│ ▼ │ │
│ ┌──────────┐ │ │
│ │Consumer │ 4. Download │ │
│ │ │<───────────────────┘ │
│ └──────────┘ │
└─────────────────────────────────────────────────────────┘📣 SNS (Simple Notification Service)
SNS Pub/Sub Pattern
┌──────────────────────────────────────────────────────────┐
│ SNS Topic Fan-Out Pattern │
└──────────────────────────────────────────────────────────┘
┌─────────────┐
│ Publisher │
└──────┬──────┘
│
│ Publish
▼
┌─────────────┐
│ SNS Topic │
└──────┬──────┘
│
┏━━━━━━━━━━┻━━━━━━━━━━┓
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Lambda │ │ SQS │ │ Email │
│Function │ │ Queue │ │ Sub │
└─────────┘ └─────────┘ └─────────┘
│ │ │
▼ ▼ ▼
[Process] [Decouple] [Notify User]
Benefits:
• 1 message → Multiple subscribers
• Decouple services
• Parallel processing🔑 KMS (Key Management Service)
KMS Key Types
┌──────────────────────────────────────────────────────────┐
│ KMS Key Types │
├──────────────────────────────────────────────────────────┤
│ │
│ AWS Managed Keys │
│ ┌────────────────────────────────────────────┐ │
│ │ aws/s3, aws/lambda, aws/rds │ │
│ │ • Free │ │
│ │ • Auto rotation (every 3 years) │ │
│ │ • Cannot modify │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Customer Managed Keys (CMK) │
│ ┌────────────────────────────────────────────┐ │
│ │ You create and manage │ │
│ │ • $1/month │ │
│ │ • Optional auto rotation (annual) │ │
│ │ • Full control over policies │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Key Types: │
│ ┌──────────────────┐ ┌──────────────────┐ │
│ │ Symmetric │ │ Asymmetric │ │
│ │ (256-bit) │ │ (RSA/ECC) │ │
│ │ │ │ │ │
│ │ • Single key │ │ • Public/Private │ │
│ │ • Encrypt/Decrypt│ │ • Sign/Verify │ │
│ │ • Most common ✅ │ │ • Cannot import │ │
│ └──────────────────┘ └──────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘Data Key Generation Flow
┌──────────────────────────────────────────────────────────┐
│ KMS Envelope Encryption Pattern │
└──────────────────────────────────────────────────────────┘
Application KMS S3
│ │ │
│ 1. GenerateDataKey │ │
├─────────────────────>│ │
│ │ │
│ 2. Returns: │ │
│ - Plaintext Key │ │
│ - Encrypted Key │ │
│<─────────────────────┤ │
│ │ │
│ 3. Encrypt data │ │
│ with plaintext │ │
│ key (locally) │ │
│ │ │
│ 4. Upload: │ │
│ - Encrypted data │ │
│ - Encrypted key │ │
├───────────────────────────────────────────>│
│ │ │
│ 5. Delete plaintext │ │
│ key from memory │ │
│ │ │
Download & Decrypt:
│ 1. Get encrypted │ │
│ data + key │ │
│<───────────────────────────────────────────┤
│ │ │
│ 2. Decrypt key │ │
├─────────────────────>│ │
│ │ │
│ 3. Returns plaintext │ │
│ data key │ │
│<─────────────────────┤ │
│ │ │
│ 4. Decrypt data │ │
│ locally │ │Key APIs:
GenerateDataKey: Returns plaintext + encrypted keyGenerateDataKeyWithoutPlaintext: Returns only encrypted key (decrypt later)Encrypt/Decrypt: Direct encryption (max 4 KB)
📦 S3 (Simple Storage Service)
S3 Encryption Options
┌──────────────────────────────────────────────────────────┐
│ S3 Server-Side Encryption (SSE) │
├──────────────────────────────────────────────────────────┤
│ │
│ SSE-S3 (Default, Simplest) │
│ ┌────────────────────────────────────────────┐ │
│ │ AWS manages keys automatically │ │
│ │ Header: x-amz-server-side-encryption: │ │
│ │ AES256 │ │
│ │ Use: Simple encryption, no key management │ │
│ └────────────────────────────────────────────┘ │
│ │
│ SSE-KMS (Most Common) ⭐ │
│ ┌────────────────────────────────────────────┐ │
│ │ Uses KMS keys (audit logs via CloudTrail) │ │
│ │ Headers: │ │
│ │ - x-amz-server-side-encryption: aws:kms │ │
│ │ - x-amz-server-side-encryption-aws- │ │
│ │ kms-key-id: <key-id> │ │
│ │ Use: Auditable encryption, key rotation │ │
│ └────────────────────────────────────────────┘ │
│ │
│ SSE-C (Customer Provides Key) │
│ ┌────────────────────────────────────────────┐ │
│ │ You provide key with EVERY request │ │
│ │ Headers (ALL required): │ │
│ │ - customer-algorithm: AES256 │ │
│ │ - customer-key: <your-base64-key> │ │
│ │ - customer-key-MD5: <md5-hash> │ │
│ │ AWS does NOT store your key │ │
│ │ Use: Complete key control │ │
│ └────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘S3 Event Notifications
┌──────────────────────────────────────────────────────────┐
│ S3 Event Notification Flow │
└──────────────────────────────────────────────────────────┘
S3 Bucket
┌─────────────┐
│ Events: │
│ │
Upload ────> │ • ObjectCreated
│ • ObjectRemoved
│ • ObjectRestore
│ • RRS Lost
│ │
└──────┬──────┘
│
┏━━━━━━━━━━━━━━━┻━━━━━━━━━━━━━━━┓
▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐
│ Lambda │ │ SNS │ │ SQS │
│Function │ │ Topic │ │ Queue │
└─────────┘ └─────────┘ └─────────┘
│ │ │
▼ ▼ ▼
[Process] [Notify] [Queue Work]S3 Object Lambda
┌──────────────────────────────────────────────────────────┐
│ S3 Object Lambda (Transform on-the-fly) │
└──────────────────────────────────────────────────────────┘
Application S3 Object Lambda S3 Bucket
│ │ │
│ 1. GET request │ │
├────────────────────────────>│ │
│ │ │
│ │ 2. Retrieve object │
│ ├───────────────────────>│
│ │ │
│ │ 3. Original data │
│ │<───────────────────────┤
│ │ │
│ ┌───────┴────────┐ │
│ │ Lambda Function │ │
│ │ • Redact PII │ │
│ │ • Resize images │ │
│ │ • Filter data │ │
│ └───────┬────────┘ │
│ │ │
│ 4. Transformed data │ │
│<────────────────────────────┤ │
│ │ │
Use Cases:
• Redact sensitive data (PII)
• Resize/watermark images
• Convert file formats
• Enrich data with metadataS3 Cross-Region Replication
Source Bucket (us-east-1) Destination Bucket (eu-west-1)
┌───────────────────────┐ ┌───────────────────────┐
│ ✅ Versioning ON │ │ ✅ Versioning ON │
│ │ │ │
│ New Object Upload │ │ │
│ │ │ │ │
│ ▼ │ │ │
│ [object.txt]────────┼───────>│ [object.txt] │
│ │ │ │
│ IAM Role with │ │ │
│ replication perms │ │ │
└───────────────────────┘ └───────────────────────┘
Requirements:
✅ Versioning enabled on both buckets
✅ Buckets in different regions
✅ IAM role with replication permissions
✅ Replication configuration on source bucket📊 CloudWatch
CloudWatch Metrics Resolution
┌──────────────────────────────────────────────────────────┐
│ CloudWatch Metrics Resolution │
├──────────────────────────────────────────────────────────┤
│ │
│ Standard Resolution (AWS Services) │
│ ┌────────────────────────────────────────────┐ │
│ │ Metric points every 1 minute │ │
│ │ ├─ 0s ─ 60s ─ 120s ─ 180s ─ 240s ─ │ │
│ │ └─ [●] [●] [●] [●] [●] │ │
│ │ Retention: 15 months │ │
│ │ Cost: Free for AWS services │ │
│ └────────────────────────────────────────────┘ │
│ │
│ High Resolution (Custom Metrics) │
│ ┌────────────────────────────────────────────┐ │
│ │ Metric points every 1 second │ │
│ │ ├─ 0s ─ 1s ─ 2s ─ 3s ─ 4s ─ 5s ─ │ │
│ │ └─ [●] [●] [●] [●] [●] [●] │ │
│ │ Use: Real-time monitoring │ │
│ │ Cost: Higher (more data points) │ │
│ └────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘CloudWatch Alarms
┌──────────────────────────────────────────────────────────┐
│ CloudWatch Alarm Configuration │
└──────────────────────────────────────────────────────────┘
Metric: CPUUtilization
Period: 5 minutes (300 seconds)
Evaluation Periods: 3
Datapoints to Alarm: 2
Timeline:
┌────┬────┬────┬────┬────┐
│ P1 │ P2 │ P3 │ P4 │ P5 │ Periods
├────┼────┼────┼────┼────┤
│ 45%│ 85%│ 90%│ 60%│ 88%│ CPU Values
├────┼────┼────┼────┼────┤
│ OK │ ⚠️ │ ⚠️ │ OK │ ⚠️ │ Status (threshold: 80%)
└────┴────┴────┴────┴────┘
└──Eval Periods──┘
(last 3)
Evaluation at P5:
• Last 3 periods: [P3=90%, P4=60%, P5=88%]
• Breaching datapoints: 2 (P3, P5)
• Threshold: 2 breaching required
• Result: 🔔 ALARM triggered!
Analogy: Checking Fever 🌡️
• Period: Check temperature every 1 hour
• Evaluation Periods: Look at last 5 readings
• Datapoints to Alarm: At least 3 must be fever
• Action: Call doctor if 3+ high readingsCloudWatch Embedded Metric Format (EMF)
┌──────────────────────────────────────────────────────────┐
│ CloudWatch EMF (Extract Metrics from Logs) │
└──────────────────────────────────────────────────────────┘
Lambda Function
┌────────────────────────────────────────┐
│ const metrics = require( │
│ 'aws-embedded-metrics' │
│ ); │
│ │
│ exports.handler = async (event) => { │
│ const metric = metrics.createMetric│
│ Namespace('MyApp'); │
│ │
│ metric.putMetric( │
│ 'ProcessingTime', │
│ 150, // milliseconds │
│ 'Milliseconds' │
│ ); │
│ │
│ metric.setProperty('orderId', 123); │
│ }; │
└────────────────┬───────────────────────┘
│
▼
CloudWatch Logs
┌─────────────┐
│ Structured │
│ JSON logs │
└──────┬──────┘
│
│ Auto-parsed
▼
CloudWatch Metrics
┌──────────────────┐
│ Namespace: MyApp │
│ Metric: │
│ ProcessingTime │
│ ├─ Value: 150ms │
│ └─ Dimension: │
│ orderId=123 │
└──────────────────┘
Benefits:
✅ No PutMetricData API calls
✅ Real-time metrics from logs
✅ Queryable in Logs Insights
✅ Automatic CloudWatch Metrics creation🔍 X-Ray
X-Ray Architecture
┌──────────────────────────────────────────────────────────┐
│ AWS X-Ray Tracing Flow │
└──────────────────────────────────────────────────────────┘
Client Request
│
▼
┌─────────────────┐
│ API Gateway │ ← Segment
├─────────────────┤
│ Trace ID: │
│ 1-abc-def │
└────────┬────────┘
│
▼
┌─────────────────┐
│ Lambda Fn │ ← Segment
├─────────────────┤
│ Parent ID: │
│ API Gateway │
│ │
│ ┌─────────────┐ │
│ │ DynamoDB │ │ ← Subsegment (namespace: aws)
│ │ Query │ │
│ └─────────────┘ │
│ │
│ ┌─────────────┐ │
│ │ External │ │ ← Subsegment (namespace: remote)
│ │ HTTP Call │ │
│ └─────────────┘ │
│ │
│ ┌─────────────┐ │
│ │ Business │ │ ← Subsegment (namespace: local)
│ │ Logic │ │
│ └─────────────┘ │
└────────┬────────┘
│
▼
┌─────────────────┐
│ DynamoDB │ ← Segment
└─────────────────┘
Hierarchy:
• Trace: End-to-end request (all services)
• Segment: Individual service (API Gateway, Lambda)
• Subsegment: Downstream calls within serviceX-Ray Annotations vs Metadata
┌──────────────────────────────────────────────────────────┐
│ X-Ray Annotations vs Metadata │
├──────────────────────────────────────────────────────────┤
│ │
│ Annotations (Searchable, Indexed) ⭐ │
│ ┌────────────────────────────────────────────┐ │
│ │ Key-Value pairs (up to 50 per trace) │ │
│ │ │ │
│ │ Example: │ │
│ │ { │ │
│ │ "user_id": "12345", │ │
│ │ "environment": "prod", │ │
│ │ "feature_flag": "enabled" │ │
│ │ } │ │
│ │ │ │
│ │ ✅ Use for: Filtering traces in console │ │
│ │ ✅ Use for: GetTraceSummaries API │ │
│ │ ✅ Indexed for fast queries │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Metadata (Not Indexed, Debugging Only) │
│ ┌────────────────────────────────────────────┐ │
│ │ Any data type (objects, arrays, etc.) │ │
│ │ │ │
│ │ Example: │ │
│ │ { │ │
│ │ "request_body": {...}, │ │
│ │ "config": {...}, │ │
│ │ "debug_info": [...] │ │
│ │ } │ │
│ │ │ │
│ │ ✅ Use for: Debugging details │ │
│ │ ❌ NOT searchable in console │ │
│ │ ❌ NOT indexed │ │
│ └────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘X-Ray Daemon
┌──────────────────────────────────────────────────────────┐
│ X-Ray Daemon Architecture │
└──────────────────────────────────────────────────────────┘
EC2 / ECS Instance
┌────────────────────────────────────────────┐
│ │
│ Application │
│ ┌──────────────┐ │
│ │ X-Ray SDK │ │
│ └──────┬───────┘ │
│ │ │
│ │ UDP 2000 │
│ ▼ │
│ ┌──────────────┐ │
│ │ X-Ray │ │
│ │ Daemon │ │
│ │ │ │
│ │ • Buffers │ │
│ │ • Batches │ │
│ └──────┬───────┘ │
│ │ │
│ │ HTTPS │
└─────────┼────────────────────────────────────┘
│
▼
┌──────────────┐
│ X-Ray API │
│ (AWS) │
└──────────────┘
Lambda: ❌ No daemon needed (built-in)
EC2/ECS: ✅ Daemon required
IAM Policy: AWSXRayDaemonWriteAccess
Environment Variables:
• _X_AMZN_TRACE_ID: Trace context
• AWS_XRAY_CONTEXT_MISSING: Error handling🐳 ECS (Elastic Container Service)
ECS Task Placement
┌──────────────────────────────────────────────────────────┐
│ ECS Task Placement Strategies │
└──────────────────────────────────────────────────────────┘
BINPACK (Minimize Instances)
┌────────────────────────────────────────────┐
│ Instance 1 Instance 2 Instance 3 │
│ [████████] [██░░] [░░░░] │
│ 80% CPU 20% CPU 0% CPU │
│ 8 tasks 2 tasks 0 tasks │
├────────────────────────────────────────────┤
│ • Fill instances before launching new │
│ • Cost optimization ✅ │
└────────────────────────────────────────────┘
SPREAD (Distribute Evenly)
┌────────────────────────────────────────────┐
│ AZ: us-east-1a AZ: us-east-1b │
│ [████] [████] │
│ 5 tasks 5 tasks │
├────────────────────────────────────────────┤
│ • High availability ✅ │
│ • Spread by: AZ, instance-id, custom attr │
└────────────────────────────────────────────┘
RANDOM (Random Placement)
┌────────────────────────────────────────────┐
│ Instance 1 Instance 2 Instance 3 │
│ [███░] [█████] [██░░] │
│ Random Random Random │
└────────────────────────────────────────────┘ECS Port Mappings
┌──────────────────────────────────────────────────────────┐
│ ECS Task Definition Port Mapping │
└──────────────────────────────────────────────────────────┘
EC2 Instance
┌───────────────────────────────────────────────┐
│ │
│ ┌─────────────────────────────────────┐ │
│ │ Task 1 │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Container │ │ │
│ │ │ containerPort: 80 ────┐ │ │ │
│ │ │ hostPort: 32768 ◄─────┘ │ │ │
│ │ └─────────────────────────────┘ │ │
│ └─────────────────────────────────────┘ │
│ │
│ ┌─────────────────────────────────────┐ │
│ │ Task 2 │ │
│ │ ┌─────────────────────────────┐ │ │
│ │ │ Container │ │ │
│ │ │ containerPort: 80 ────┐ │ │ │
│ │ │ hostPort: 32769 ◄─────┘ │ │ │
│ │ └─────────────────────────────┘ │ │
│ └─────────────────────────────────────┘ │
│ │
└───────────────────────────────────────────────┘
Dynamic Port Mapping:
• Set hostPort: 0 (ECS assigns random port)
• Allows multiple tasks per instance
• ALB uses dynamic port discovery
awsvpc Network Mode:
• hostPort = containerPort (or leave blank)
• Task gets own ENI with private IPECS IAM Roles
┌──────────────────────────────────────────────────────────┐
│ ECS IAM Roles (Best Practice) │
└──────────────────────────────────────────────────────────┘
┌────────────────────────────────────────────┐
│ Task Definition 1: Web Service │
│ ┌────────────────────────────────────┐ │
│ │ Task Role: WebServiceRole │ │
│ │ Permissions: │ │
│ │ • S3: Read/Write to web-bucket │ │
│ │ • DynamoDB: Full access to UserTable│ │
│ └────────────────────────────────────┘ │
└────────────────────────────────────────────┘
┌────────────────────────────────────────────┐
│ Task Definition 2: Analytics Service │
│ ┌────────────────────────────────────┐ │
│ │ Task Role: AnalyticsRole │ │
│ │ Permissions: │ │
│ │ • S3: Read from analytics-bucket │ │
│ │ • Athena: Query execution │ │
│ └────────────────────────────────────┘ │
└────────────────────────────────────────────┘
Best Practice:
✅ One IAM role per task definition
✅ Principle of least privilege
✅ No shared roles across services📦 Elastic Beanstalk
Deployment Strategies
┌──────────────────────────────────────────────────────────┐
│ Elastic Beanstalk Deployment Strategies │
├──────────────────────────────────────────────────────────┤
│ │
│ All-at-Once (Fastest, but downtime) │
│ ┌────────────────────────────────────────────┐ │
│ │ [v1] [v1] [v1] [v1] │ │
│ │ ↓ ↓ ↓ ↓ All update at once │ │
│ │ [v2] [v2] [v2] [v2] │ │
│ │ • Downtime: YES ❌ │ │
│ │ • Rollback: Redeploy │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Rolling (Gradual, partial capacity) │
│ ┌────────────────────────────────────────────┐ │
│ │ [v1] [v1] [v1] [v1] │ │
│ │ ↓ ↓ │ │
│ │ [v2] [v2] [v1] [v1] (Batch 1) │ │
│ │ ↓ ↓ │ │
│ │ [v2] [v2] [v2] [v2] (Batch 2) │ │
│ │ • Downtime: Partial (reduced capacity) │ │
│ │ • Rollback: Redeploy │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Rolling with Additional Batch │
│ ┌────────────────────────────────────────────┐ │
│ │ [v1] [v1] [v1] [v1] +[v2] [v2] │ │
│ │ (Launch new first, maintain capacity) │ │
│ │ • Downtime: NO ✅ │ │
│ │ • Cost: Temporary extra instances │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Immutable (Safest, full rollback) │
│ ┌────────────────────────────────────────────┐ │
│ │ Environment A: [v1] [v1] [v1] [v1] │ │
│ │ New ASG: [v2] [v2] [v2] [v2] │ │
│ │ If healthy: Swap, terminate old ASG │ │
│ │ If unhealthy: Terminate new ASG │ │
│ │ • Downtime: NO ✅ │ │
│ │ • Rollback: Easy ✅ │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Blue/Green (Zero downtime) │
│ ┌────────────────────────────────────────────┐ │
│ │ Blue Env (v1) ◄────── Traffic │ │
│ │ Green Env (v2) (Idle) │ │
│ │ │ │
│ │ Swap CNAME │ │
│ │ │ │
│ │ Blue Env (v1) (Idle) │ │
│ │ Green Env (v2) ◄───── Traffic │ │
│ │ • Downtime: NO ✅ │ │
│ │ • Rollback: Swap CNAME back ✅ │ │
│ └────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘Elastic Beanstalk Configuration Files
Project Structure:
┌────────────────────────────────────────┐
│ my-app/ │
│ ├── .ebextensions/ │
│ │ ├── 01-packages.config │
│ │ ├── 02-environment.config │
│ │ └── 03-scaling.config │
│ ├── env.yaml │
│ ├── application.zip │
│ └── ... │
└────────────────────────────────────────┘
env.yaml (Environment manifest):
---
AWSConfigurationTemplateVersion: 1.1.0.0
EnvironmentName: production
SolutionStack: "64bit Amazon Linux 2 v3.x"
EnvironmentLinks:
"WORKERQUEUE": "worker-env"
.ebextensions/*.config (Resource settings):
option_settings:
- namespace: aws:elasticbeanstalk:environment
option_name: EnvironmentType
value: LoadBalanced🚀 CodeDeploy
Deployment Types by Platform
┌──────────────────────────────────────────────────────────┐
│ CodeDeploy Deployment Configurations │
├──────────────────────────────────────────────────────────┤
│ │
│ EC2 / On-Premises │
│ ┌────────────────────────────────────────────┐ │
│ │ • In-Place │ │
│ │ └─ Stop app → Install → Start │ │
│ │ │ │
│ │ • Blue/Green │ │
│ │ └─ New instances → Test → Swap │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Lambda │
│ ┌────────────────────────────────────────────┐ │
│ │ • Canary (2 increments) │ │
│ │ └─ 10% → Wait → 90% │ │
│ │ │ │
│ │ • Linear (Equal increments) │ │
│ │ └─ 10% every 10 min │ │
│ │ │ │
│ │ • All-at-Once │ │
│ │ └─ 100% immediately │ │
│ └────────────────────────────────────────────┘ │
│ │
│ ECS │
│ ┌────────────────────────────────────────────┐ │
│ │ • Blue/Green │ │
│ │ └─ New task set → Test → Switch traffic │ │
│ │ │ │
│ │ • Canary / Linear │ │
│ │ └─ Gradual traffic shifting │ │
│ └────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘CodeDeploy Lifecycle Hooks
┌──────────────────────────────────────────────────────────┐
│ CodeDeploy Lifecycle Events │
└──────────────────────────────────────────────────────────┘
EC2 / On-Premises:
┌─────────────────────────────────────────┐
│ ApplicationStop │
│ ↓ │
│ DownloadBundle │
│ ↓ │
│ BeforeInstall │
│ ↓ │
│ Install │
│ ↓ │
│ AfterInstall │
│ ↓ │
│ ApplicationStart │
│ ↓ │
│ ValidateService │
└─────────────────────────────────────────┘
Lambda:
┌─────────────────────────────────────────┐
│ BeforeAllowTraffic │
│ ↓ │
│ AllowTraffic (Automatic) │
│ ↓ │
│ AfterAllowTraffic │
└─────────────────────────────────────────┘
ECS:
┌─────────────────────────────────────────┐
│ BeforeInstall │
│ ↓ │
│ Install (Automatic) │
│ ↓ │
│ AfterInstall │
│ ↓ │
│ AfterAllowTestTraffic │
│ ↓ │
│ BeforeAllowTraffic │
│ ↓ │
│ AllowTraffic (Automatic) │
│ ↓ │
│ AfterAllowTraffic │
└─────────────────────────────────────────┘Canary Deployment Example
┌──────────────────────────────────────────────────────────┐
│ Canary10Percent10Minutes Deployment │
└──────────────────────────────────────────────────────────┘
Time: 0 min
┌────────────────────────────────────────┐
│ Original Version (100%) │
│ [████████████████████████████████] │
└────────────────────────────────────────┘
Time: 0 min (immediate)
┌────────────────────────────────────────┐
│ Original (90%) │ New Version (10%) │
│ [██████████████████████░░░░] │
│ │
│ Monitor for errors... │
└────────────────────────────────────────┘
Time: 10 min (if healthy)
┌────────────────────────────────────────┐
│ New Version (100%) │
│ [████████████████████████████████] │
│ │
│ Deployment Complete! ✅ │
└────────────────────────────────────────┘
If errors detected:
┌────────────────────────────────────────┐
│ Automatic Rollback │
│ [████████████████████████████████] │
│ ← Back to Original Version │
└────────────────────────────────────────┘☁️ CloudFormation
CloudFormation Template Structure
AWSTemplateFormatVersion: '2010-09-09'
Description: 'My CloudFormation Stack'
Parameters:
EnvironmentType:
Type: String
Default: dev
AllowedValues: [dev, test, prod]
Resources:
MyBucket:
Type: AWS::S3::Bucket
Properties:
BucketName: !Sub 'my-bucket-${EnvironmentType}'
Outputs:
BucketName:
Value: !Ref MyBucket
Export:
Name: !Sub '${AWS::StackName}-BucketName'CloudFormation StackSets
┌──────────────────────────────────────────────────────────┐
│ CloudFormation StackSets │
│ (Deploy to Multiple Accounts/Regions) │
└──────────────────────────────────────────────────────────┘
Administrator Account
┌─────────────────────────────────────┐
│ StackSet │
│ ├─ Template: app-stack.yaml │
│ ├─ Parameters: {...} │
│ └─ Target Accounts: [123, 456, 789]│
└──────────────┬──────────────────────┘
│
┏━━━━━━━━┻━━━━━━━━┓
▼ ▼
┌──────────────┐ ┌──────────────┐
│ Account 123 │ │ Account 456 │
│ ├─ us-east-1 │ │ ├─ us-east-1 │
│ ├─ eu-west-1 │ │ ├─ eu-west-1 │
└──────────────┘ └──────────────┘
Operations:
• Create: Deploy to all targets
• Update: Update all stacks
• Delete: Remove from all targets
• Single Operation: Affects all accounts/regionsCloudFormation Drift Detection
┌──────────────────────────────────────────────────────────┐
│ CloudFormation Drift Detection │
└──────────────────────────────────────────────────────────┘
Template Definition Actual Resource
┌──────────────────┐ ┌──────────────────┐
│ S3 Bucket: │ │ S3 Bucket: │
│ • Versioning: ON │ VS │ • Versioning: OFF│
│ • Encryption: ON │ │ • Encryption: OFF│
└──────────────────┘ └──────────────────┘
│ │
└────────────┬───────────────┘
│
▼
┌────────────────────────┐
│ Drift Detected! ⚠️ │
│ • Versioning changed │
│ • Encryption disabled │
└────────────────────────┘
Use Case:
• Detect manual changes outside CloudFormation
• Maintain infrastructure compliance
• Identify configuration drift🔧 SAM (Serverless Application Model)
SAM Template Structure
Transform: AWS::Serverless-2016-10-31 # Required!
Globals: # Shared properties (optional)
Function:
Runtime: python3.9
Timeout: 30
Resources:
MyFunction:
Type: AWS::Serverless::Function
Properties:
Handler: index.handler
CodeUri: ./src
Events:
ApiEvent:
Type: Api
Properties:
Path: /hello
Method: get
MyApi:
Type: AWS::Serverless::Api
Properties:
StageName: prod
MyTable:
Type: AWS::Serverless::SimpleTableSAM CLI Workflow
┌──────────────────────────────────────────────────────────┐
│ SAM Development Workflow │
└──────────────────────────────────────────────────────────┘
1. Initialize
$ sam init
└─ Creates project template
2. Build
$ sam build
┌────────────────────────────────┐
│ • Compile code │
│ • Install dependencies │
│ • Create .aws-sam/build/ │
└────────────────────────────────┘
3. Test Locally
$ sam local invoke
$ sam local start-api
┌────────────────────────────────┐
│ • Run Lambda locally │
│ • Test API Gateway locally │
│ • No AWS charges! ✅ │
└────────────────────────────────┘
4. Package (Optional - for CloudFormation)
$ sam package \
--s3-bucket my-bucket \
--output-template-file packaged.yaml
┌────────────────────────────────┐
│ • Upload code to S3 │
│ • Generate deployment template │
└────────────────────────────────┘
5. Deploy
$ sam deploy --guided
┌────────────────────────────────┐
│ • Create CloudFormation stack │
│ • Deploy to AWS │
│ • Interactive prompts │
└────────────────────────────────┘
6. Fast Development (sync)
$ sam sync --watch
┌────────────────────────────────┐
│ • Direct sync to AWS │
│ • Skip CloudFormation │
│ • Faster iterations ⚡ │
└────────────────────────────────┘
7. Debug
$ sam logs --tail
└─ Fetch CloudWatch logs🔄 Step Functions
State Types
┌──────────────────────────────────────────────────────────┐
│ Step Functions State Types │
├──────────────────────────────────────────────────────────┤
│ │
│ Task State (Execute work) │
│ ┌────────────────────────────────────────────┐ │
│ │ "ProcessOrder": { │ │
│ │ "Type": "Task", │ │
│ │ "Resource": "arn:aws:lambda:..." │ │
│ │ } │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Choice State (Branch logic) │
│ ┌────────────────────────────────────────────┐ │
│ │ "IsApproved": { │ │
│ │ "Type": "Choice", │ │
│ │ "Choices": [ │ │
│ │ {"Variable": "$.status", │ │
│ │ "StringEquals": "approved", │ │
│ │ "Next": "ProcessPayment"} │ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Parallel State (Concurrent execution) │
│ ┌────────────────────────────────────────────┐ │
│ │ "ParallelProcessing": { │ │
│ │ "Type": "Parallel", │ │
│ │ "Branches": [ │ │
│ │ {"StartAt": "Task1"}, │ │
│ │ {"StartAt": "Task2"} │ │
│ │ ] │ │
│ │ } │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Wait State (Delay) │
│ ┌────────────────────────────────────────────┐ │
│ │ "WaitForApproval": { │ │
│ │ "Type": "Wait", │ │
│ │ "Seconds": 300 │ │
│ │ } │ │
│ └────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘Step Functions Wait for Callback Pattern
┌──────────────────────────────────────────────────────────┐
│ Step Functions waitForTaskToken Pattern │
└──────────────────────────────────────────────────────────┘
Step Functions Workflow
┌─────────────────────────────────────┐
│ "ProcessOrder": { │
│ "Type": "Task", │
│ "Resource": "arn:aws:sqs:... │
│ .waitForTaskToken", │ ← Note suffix
│ "Parameters": { │
│ "QueueUrl": "...", │
│ "MessageBody": { │
│ "orderId": "123", │
│ "token.$": "$$.Task.Token" ←──── Generate token
│ } │
│ } │
│ } │
└──────────────┬──────────────────────┘
│
│ 1. Send message with token
▼
┌─────────┐
│ SQS │
│ Queue │
└────┬────┘
│
│ 2. Worker processes
▼
┌─────────────┐
│ Worker │
│ (Lambda) │
└──────┬──────┘
│
│ 3. Call SendTaskSuccess/Failure
▼
┌─────────────────┐
│ Step Functions │
│ Resumes! ✅ │
└─────────────────┘
Benefits:
✅ No polling cost (paused workflow)
✅ Wait for external signals (webhooks, manual approval)
✅ Long-running processes (hours/days)Input/Output Processing
┌──────────────────────────────────────────────────────────┐
│ Step Functions Input/Output Processing │
└──────────────────────────────────────────────────────────┘
Input: { "orderId": "123", "amount": 100 }
│
│ InputPath: "$.orderId"
▼
Input to Task: "123"
│
│ [Task Execution]
▼
Task Result: { "status": "success", "transactionId": "abc" }
│
│ ResultPath: "$.transaction"
▼
Combined: {
"orderId": "123",
"amount": 100,
"transaction": {
"status": "success",
"transactionId": "abc"
}
}
│
│ OutputPath: "$.transaction"
▼
Final Output: { "status": "success", "transactionId": "abc" }
Summary:
• InputPath: Filter input
• Parameters: Transform input
• ResultPath: Merge result with original input ✅
• OutputPath: Filter final output💾 ElastiCache
Redis vs Memcached
┌──────────────────────────────────────────────────────────┐
│ ElastiCache: Redis vs Memcached │
├──────────────────────────────────────────────────────────┤
│ │
│ Redis ⭐ (Feature-Rich) │
│ ┌────────────────────────────────────────────┐ │
│ │ ✅ Data Types: Strings, Lists, Sets, Hashes│ │
│ │ ✅ Persistence (AOF, RDB) │ │
│ │ ✅ Replication (Primary/Replica) │ │
│ │ ✅ Multi-AZ with automatic failover │ │
│ │ ✅ Backup & Restore │ │
│ │ ✅ Pub/Sub messaging │ │
│ │ ✅ Transactions │ │
│ │ ✅ Sorted Sets (leaderboards) │ │
│ │ │ │
│ │ Use Cases: │ │
│ │ • Session store │ │
│ │ • Leaderboards │ │
│ │ • Real-time analytics │ │
│ │ • Message queues │ │
│ └────────────────────────────────────────────┘ │
│ │
│ Memcached (Simple, Multi-threaded) │
│ ┌────────────────────────────────────────────┐ │
│ │ ✅ Simple key-value store │ │
│ │ ✅ Multi-threaded │ │
│ │ ✅ Horizontal scaling (sharding) │ │
│ │ ❌ No persistence │ │
│ │ ❌ No replication │ │
│ │ ❌ No backup │ │
│ │ ❌ Only strings │ │
│ │ │ │
│ │ Use Cases: │ │
│ │ • Simple caching │ │
│ │ • Offload database reads │ │
│ │ • Temporary data │ │
│ └────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘Caching Strategies
┌──────────────────────────────────────────────────────────┐
│ ElastiCache Caching Strategies │
└──────────────────────────────────────────────────────────┘
1. LAZY LOADING (Cache-Aside)
App Cache Database
│ │ │
│ 1. Read │ │
├─────────────────>│ │
│ │ Cache Miss ❌ │
│<─────────────────┤ │
│ │ │
│ 2. Query DB │ │
├──────────────────────────────────────>│
│ │ │
│ 3. Data │ │
│<──────────────────────────────────────┤
│ │ │
│ 4. Write to cache│ │
├─────────────────>│ │
│ │ │
👍 Pros: Only cache used data
👎 Cons: Cache miss penalty, stale data
2. WRITE-THROUGH
App Cache Database
│ │ │
│ 1. Write │ │
├─────────────────>│ │
│ │ │
│ 2. Update cache │ │
│ │ 3. Write to DB │
│ ├─────────────────>│
│ │ │
│ 4. Confirm │ │
│<─────────────────┤ │
│ │ │
👍 Pros: Always fresh data
👎 Cons: Unused data cached, write penalty
3. WRITE-BEHIND (Write-Back)
App Cache Database
│ │ │
│ 1. Write │ │
├─────────────────>│ │
│ │ │
│ 2. Immediate OK │ │
│<─────────────────┤ │
│ │ │
│ │ 3. Async write │
│ ├─────────────────>│
│ │ (batched) │
👍 Pros: Fast writes, reduced DB load
👎 Cons: Risk of data loss, complexity👤 Cognito
Cognito Architecture
┌──────────────────────────────────────────────────────────┐
│ Amazon Cognito Architecture │
└──────────────────────────────────────────────────────────┘
USER POOLS (Authentication)
┌──────────────────────────────────────┐
│ • User directory │
│ • Sign-up / Sign-in │
│ • MFA │
│ • Password reset │
│ • Social login (Google, Facebook) │
│ • SAML federation │
│ │
│ Returns: JWT tokens │
│ ├─ ID Token (user identity) │
│ ├─ Access Token (API access) │
│ └─ Refresh Token │
└──────────────┬───────────────────────┘
│
│ JWT Token
▼
IDENTITY POOLS (Authorization)
┌──────────────────────────────────────┐
│ • Exchange JWT → AWS Credentials │
│ • IAM role mapping │
│ • Temporary credentials (STS) │
│ │
│ Returns: AWS credentials │
│ ├─ AccessKeyId │
│ ├─ SecretAccessKey │
│ └─ SessionToken │
└──────────────┬───────────────────────┘
│
│ Temp AWS Creds
▼
┌─────────┐
│ S3 │
│DynamoDB │
│ etc. │
└─────────┘
Flow:
1. User logs in → User Pool → JWT
2. App sends JWT → Identity Pool → AWS credentials
3. App uses credentials → Access AWS resourcesCognito Adaptive Authentication
┌──────────────────────────────────────────────────────────┐
│ Cognito Adaptive Authentication (Risk-Based) │
└──────────────────────────────────────────────────────────┘
Sign-In Attempt
│
▼
┌─────────────────────┐
│ Risk Assessment │
│ • IP address │
│ • Device │
│ • Location │
│ • User agent │
│ • Login history │
└──────┬──────────────┘
│
├──── Low Risk
│ └─> Allow login (no MFA)
│
├──── Medium Risk
│ └─> Optional MFA or Require MFA
│
└──── High Risk
└─> Require MFA or Block
Configuration:
• Set risk tolerance per risk level
• Automatic threat detection
• Compromised credentials check
• Advanced security features (paid)🌍 CloudFront
CloudFront Distribution Architecture
┌──────────────────────────────────────────────────────────┐
│ CloudFront Content Delivery │
└──────────────────────────────────────────────────────────┘
Global Users
│
┏━━━━━━━━━━━━┻━━━━━━━━━━━━┓
▼ ▼ ▼
┌────────┐ ┌────────┐ ┌────────┐
│ Edge │ │ Edge │ │ Edge │
│ Tokyo │ │ London │ │ N.Virginia
└────┬───┘ └────┬───┘ └────┬───┘
│ │ │
│ Cache Miss? │
└───────────┼─────────────┘
│
▼
┌───────────────┐
│ Origin Server │
│ • S3 Bucket │
│ • ALB │
│ • Custom │
└───────────────┘
Benefits:
✅ Low latency (content served from edge)
✅ Reduced origin load
✅ DDoS protection
✅ HTTPS encryptionCloudFront SSL/TLS
┌──────────────────────────────────────────────────────────┐
│ CloudFront SSL/TLS Configuration │
└──────────────────────────────────────────────────────────┘
Viewer → CloudFront → Origin
Viewer Protocol Policy:
┌────────────────────────────────────────┐
│ • HTTP and HTTPS (allow both) │
│ • Redirect HTTP to HTTPS ⭐ │
│ • HTTPS Only │
└────────────────────────────────────────┘
Origin Protocol Policy:
┌────────────────────────────────────────┐
│ • HTTP Only │
│ • HTTPS Only │
│ • Match Viewer │
└────────────────────────────────────────┘
Recommended: Redirect HTTP to HTTPS (viewer)
+ HTTPS Only (origin)🔄 Kinesis Data Streams
Kinesis Architecture
┌──────────────────────────────────────────────────────────┐
│ Kinesis Data Streams Flow │
└──────────────────────────────────────────────────────────┘
Producers Kinesis Stream Consumers
┌─────────┐ ┌──────────────┐ ┌─────────┐
│ IoT │─────────────>│ Shard 1 │──────────>│ Lambda │
│ Devices │ │ 1MB/s write │ │ │
└─────────┘ │ 2MB/s read │ └─────────┘
└──────────────┘
┌─────────┐ ┌──────────────┐ ┌─────────┐
│ App │─────────────>│ Shard 2 │──────────>│ EC2 │
│ Servers │ │ │ │ KCL │
└─────────┘ └──────────────┘ └─────────┘
┌──────────────┐ ┌─────────┐
┌─────────┐ │ Shard 3 │──────────>│ Kinesis │
│ Logs │─────────────>│ │ │Analytics│
└─────────┘ └──────────────┘ └─────────┘
Partition Key → Determines shard assignment
Sequence Number → Unique ID per record (ordering)
Concurrency: 1 Lambda execution per shard
Ordering: Use PutRecord with SequenceNumberForOrdering🔐 Secrets Manager & SSM Parameter Store
Comparison
┌──────────────────────────────────────────────────────────┐
│ Secrets Manager vs SSM Parameter Store │
├──────────────────────────────────────────────────────────┤
│ │
│ AWS Secrets Manager ⭐ │
│ ┌────────────────────────────────────────────┐ │
│ │ ✅ Automatic rotation │ │
│ │ ✅ Native RDS/Redshift integration │ │
│ │ ✅ Cross-account access │ │
│ │ ✅ Versioning │ │
│ │ ✅ KMS encryption │ │
│ │ 💰 Cost: $0.40/secret/month │ │
│ │ │ │
│ │ Use: Database credentials, API keys │ │
│ └────────────────────────────────────────────┘ │
│ │
│ SSM Parameter Store │
│ ┌────────────────────────────────────────────┐ │
│ │ ✅ Free (Standard tier) │ │
│ │ ✅ Parameter hierarchies (/prod/db/url) │ │
│ │ ✅ KMS encryption (SecureString) │ │
│ │ ❌ No automatic rotation │ │
│ │ │ │
│ │ Standard Tier: │ │
│ │ • 10,000 params │ │
│ │ • 4 KB max size │ │
│ │ • Free │ │
│ │ │ │
│ │ Advanced Tier: │ │
│ │ • 100,000 params │ │
│ │ • 8 KB max size │ │
│ │ • Parameter policies │ │
│ │ • $0.05/param/month │ │
│ │ │ │
│ │ Use: Configuration, non-sensitive data │ │
│ └────────────────────────────────────────────┘ │
│ │
└──────────────────────────────────────────────────────────┘🎯 Exam Tips & Common Patterns
Service Selection Patterns
┌──────────────────────────────────────────────────────────┐
│ Common Exam Question Patterns │
└──────────────────────────────────────────────────────────┘
Authentication Needed?
├─ Social Login (Google, FB) → Cognito User Pool
├─ Enterprise SSO → Cognito + SAML
└─ API Authentication → API Gateway Lambda Authorizer
Access AWS Resources?
├─ From mobile app → Cognito Identity Pool
├─ From Lambda → Execution Role
└─ From EC2 → Instance Profile
Decouple Services?
├─ Pub/Sub (multiple subscribers) → SNS
├─ Queue (single consumer) → SQS
└─ Stream (ordered, real-time) → Kinesis
Store Configuration?
├─ Secrets (rotation needed) → Secrets Manager
├─ Simple config → SSM Parameter Store
└─ Application config → AppConfig
Cache Layer?
├─ Complex data types → ElastiCache Redis
├─ Simple key-value → ElastiCache Memcached
└─ API responses → API Gateway caching
Monitoring?
├─ Application logs → CloudWatch Logs
├─ Custom metrics → CloudWatch EMF
├─ Distributed tracing → X-Ray
└─ Infrastructure metrics → CloudWatch
Deployment Strategy?
├─ Zero downtime → Blue/Green
├─ Gradual rollout → Canary/Linear
└─ Fast, accept downtime → All-at-once
Serverless?
├─ Compute → Lambda
├─ API → API Gateway
├─ Database → DynamoDB
└─ Orchestration → Step FunctionsKey Exam Keywords
┌──────────────────────────────────────────────────────────┐
│ Keyword → Service Mapping │
├──────────────────────────────────────────────────────────┤
│ "Serverless" → Lambda, DynamoDB, API Gateway, Step Fns │
│ "Decouple" → SQS, SNS │
│ "Cache" → ElastiCache, API Gateway caching │
│ "Ordered messages" → SQS FIFO, Kinesis │
│ "Real-time" → Kinesis, Lambda, WebSockets │
│ "Audit logs" → CloudTrail │
│ "Distributed tracing" → X-Ray │
│ "Secrets rotation" → Secrets Manager │
│ "Cross-account" → IAM roles, STS AssumeRole │
│ "Least privilege" → Separate IAM roles │
│ "Cost-effective" → Free tier, managed services │
│ "High availability" → Multi-AZ, Auto Scaling │
│ "Disaster recovery" → Cross-region replication │
└──────────────────────────────────────────────────────────┘📚 Quick Reference Tables
DynamoDB Capacity Units
| Operation | Calculation | Example |
|---|---|---|
| RCU (Eventually Consistent) | Item size (KB) / 4 | 8 KB item = 2 RCU |
| RCU (Strongly Consistent) | Item size (KB) / 4 × 2 | 8 KB item = 4 RCU |
| WCU | Item size (KB) / 1 | 3 KB item = 3 WCU |
Lambda Limits
| Limit | Value |
|---|---|
| Memory | 128 MB - 10 GB |
| Timeout | 15 minutes max |
| Deployment package | 50 MB (zipped), 250 MB (unzipped) |
| /tmp storage | 512 MB - 10 GB |
| Concurrent executions | 1,000 per account (soft limit) |
| Environment variables | 4 KB total |
API Gateway Limits
| Limit | Value |
|---|---|
| Timeout | 29 seconds (all integrations) |
| Payload size | 10 MB |
| Cache TTL | 0 - 3600 seconds |
| Throttle (default) | 10,000 RPS, 5,000 burst |
SQS Limits
| Feature | Standard | FIFO |
|---|---|---|
| Throughput | Unlimited | 300 TPS (3,000 with batching) |
| Message retention | 1 min - 14 days (default 4 days) | Same |
| Message size | 256 KB | 256 KB |
| Visibility timeout | 0 - 12 hours (default 30s) | Same |
| Long polling | 0 - 20 seconds | Same |
🔥 Last-Minute Review Checklist
Must-Know Concepts
Lambda
- Invocation types: RequestResponse, Event, DryRun
- Event source mapping (Kinesis, DynamoDB, SQS)
- Concurrency limits (1000 total, 900 max reserved)
- Environment variables (encrypted with KMS)
- Execution role vs Task role
- Lambda@Edge for CloudFront
API Gateway
- Integration types: HTTP_PROXY, AWS_PROXY (Lambda)
- Authorization: IAM, Lambda Authorizer, Cognito, API Keys
- Stages and stage variables
- Caching (per stage, TTL 0-3600s)
- 29-second timeout limit
DynamoDB
- GSI vs LSI (creation time, consistency)
- Hot partition solutions (add random suffix)
- Streams: OLD_IMAGE, NEW_IMAGE, KEYS_ONLY
- Query vs Scan (efficiency)
- Optimistic locking (version attribute)
- BatchGetItem (100 items), BatchWriteItem (25 items)
SQS
- Standard vs FIFO queues
- Visibility timeout vs Message retention
- Long polling (WaitTimeSeconds = 1-20)
- Extended Client Library (256 KB - 2 GB via S3)
CloudWatch
- Standard vs High-resolution metrics
- Alarm configuration (Period, Evaluation Periods, Datapoints)
- EMF (Embedded Metric Format) for custom metrics
- Metric filters (not retroactive)
X-Ray
- Trace → Segment → Subsegment hierarchy
- Annotations (searchable) vs Metadata (not searchable)
- Daemon required for EC2/ECS, not Lambda
- Namespaces: aws, remote, local
CodeDeploy
- Lifecycle hooks (EC2 vs Lambda vs ECS)
- Canary vs Linear deployment
- In-place vs Blue/Green
- AppSpec file requirements
Elastic Beanstalk
- Deployment strategies (All-at-once → Immutable → Blue/Green)
- env.yaml vs .ebextensions/*.config
- Worker tier (SQS + daemon)
Cognito
- User Pools (authentication) vs Identity Pools (authorization)
- JWT tokens → AWS credentials flow
- Adaptive authentication (risk-based MFA)
IAM & Security
- STS APIs: GetSessionToken, AssumeRole, AssumeRoleWithWebIdentity
- Cross-account access pattern
- KMS: Symmetric vs Asymmetric keys
- S3 encryption: SSE-S3, SSE-KMS, SSE-C
🎓 Final Tips
During the Exam
- Read carefully - One word can change the answer (e.g., “immediately” vs “eventually”)
- Eliminate wrong answers - Usually 2 are obviously wrong
- Look for keywords - “serverless”, “decouple”, “cost-effective”
- Don’t overthink - Choose the most AWS-native solution
- Time management - 130 minutes for 65 questions (~2 min/question)
Common Traps
- ❌ Overengineering - AWS exams prefer simple, managed solutions
- ❌ Self-hosted solutions - When AWS has a managed service, use it
- ❌ Complex architectures - Simpler is usually better
- ❌ Missing keywords - “real-time”, “ordered”, “strongly consistent”
AWS Best Practices Always Win
- ✅ Managed services over self-hosted
- ✅ Serverless over servers (when possible)
- ✅ Least privilege IAM policies
- ✅ Multi-AZ for high availability
- ✅ Caching to reduce latency/cost
- ✅ Monitoring and logging enabled
Good luck on your AWS DVA-C02 exam! 🚀
Remember: This is a summary based on exam focus areas. Always refer to official AWS documentation for detailed information.