Exam Guide: Developer - Associate
🏗️ Domain 4: Troubleshooting And Optimization
📘 Task 3: Optimize Applications By Using AWS Services And Features
This task is about making applications faster, cheaper, and more efficient. You need to understand Lambda concurrency and memory tuning, caching at every layer (CloudFront, API Gateway, ElastiCache), messaging optimization with SNS filter policies, and how to read metrics to find bottlenecks. Choose the right optimization for a given symptom such as high latency, throttling, slow stream processing, or runaway cost, and etc.
📘 Concepts
Lambda Concurrency Types
| Type | What It Does | Cost | Use Case |
|---|---|---|---|
| Unreserved | Shared pool (default 1,000 per region) | Pay per invocation | Default for most functions |
| Reserved | Guarantees capacity AND caps the function | No extra cost | Protect downstream services, guarantee capacity |
| Provisioned | Pre-warms execution environments | Pay even when idle | Eliminate cold starts for latency-sensitive functions |
💡 Reserved concurrency does double duty. It guarantees a function gets that many concurrent executions AND prevents it from exceeding that number. Use it to stop a busy function from starving others, or to protect a downstream database from too many connections. Provisioned concurrency is the only thing that eliminates cold starts, but you pay for it 24/7.
The Concurrency Formula
Concurrent executions = (invocations per second) × (average duration in seconds)
Example: 100 requests/second × 0.5 seconds = 50 concurrent executions needed.
Memory and CPU Relationship
Lambda allocates CPU proportionally to memory. At 1,769 MB you get one full vCPU. More memory means more CPU, which can make a function run faster. Sometimes fast enough that the higher per-ms cost is offset by the shorter duration.
Memory | Relative CPU | Typical Result |
|---|---|---|
128 MB | Fraction of a vCPU | Cheapest per-ms, slowest |
512 MB | ~0.3 vCPU | Often the sweet spot |
1,769 MB | 1 full vCPU | Fast, higher per-ms cost |
10,240 MB | ~6 vCPUs | Fastest, for CPU-bound work |
Caching Layers
| Layer | Service | What It Caches | TTL Control |
|---|---|---|---|
| Edge | CloudFront | Static content, API responses | Cache policies, headers |
| API | API Gateway cache | Endpoint responses | Per-stage, per-method |
| Application | ElastiCache (Redis/Memcached) | Query results, sessions | Set in code |
| Database | DAX (DynamoDB only) | DynamoDB reads | Item + query cache TTL |
Caching Patterns
| Pattern | How It Works | Best For |
|---|---|---|
| Cache-aside (lazy loading) | Check cache → miss → fetch from DB → store | Read-heavy, tolerates some staleness |
| Write-through | Write to cache AND DB simultaneously | Consistency-sensitive reads |
| Write-behind | Write to cache, async write to DB | High write throughput |
| TTL-based | Entries expire after a set time | Most general-purpose caching |
💡 Cache-aside is the most common pattern. The risk is a cache stampede (many simultaneous misses hitting the DB). Write-through keeps the cache fresh but adds write latency.
CloudFront Cache Keys
The cache key determines what makes a request unique. The fewer components in the key, the higher the cache hit rate.
| Cache Key Component | Effect on Hit Rate |
|---|---|
| No headers or query strings | Highest hit rate |
| Whitelist only what matters | Balanced |
| Forward everything | Lowest hit rate (every request unique) |
SNS Subscription Filter Policies
Filter policies let each subscriber receive only the messages it cares about, reducing downstream processing and cost.
| Filter Scope | Filters On |
|---|---|
MessageAttributes (default) | Message attribute key/value pairs |
| MessageBody | Fields inside the message body JSON |
Key Metrics for Finding Bottlenecks
Metric | Service | What It Signals |
|---|---|---|
Duration | Lambda | Slow function or slow downstream call |
IteratorAge | Lambda (Kinesis/DynamoDB) | Consumer falling behind the stream |
ApproximateAgeOfOldestMessage | SQS | Consumer too slow, queue backing up |
Throttles | Lambda | Hitting concurrency limits |
ConsumedReadCapacityUnits | DynamoDB | Hot partition or under-provisioning |
CacheHitRate | CloudFront / API Gateway | Cache effectiveness |
🏗️ Build A Performance Optimization Lab
Build a Performance Optimization Lab using the AWS Console:
- A Lambda function tuned across memory settings to find the cost/performance sweet spot
- Reserved concurrency configured to protect a downstream service
- API Gateway caching enabled and tested for cache hits
- An SNS topic with subscription filter policies routing messages selectively
- CloudWatch metrics queries to identify bottlenecks
Prerequisites
🏗️
SOCIAL SHARE CARD GENERATOR