Exam Guide: Solutions Architect - Associate
⚡ Domain 3: Design High-Performing Architectures
📘 Task Statement 3.2
🎯 Designing High-Performing And Elastic Compute Solutions is about choosing compute that:
- Performs well
- Scales automatically
- Avoids bottlenecks by decoupling components
Pick the compute runtime first: EC2 vs containers vs serverless, then pick the scaling model: Auto Scaling vs event-based scaling, then tune performance: instance family / memory / concurrency / batching.
Knowledge
1 | AWS Compute Services With Appropriate Use Cases
Amazon EC2
Best for:
- Full control over OS/runtime
- Legacy apps, custom networking/agents, special drivers
- Predictable long-running services
AWS Lambda
Best for:
- Event-driven tasks: APIs, SQS processing, EventBridge, file processing
- Spiky or unpredictable traffic
- Minimal ops
Amazon ECS / Amazon EKS (containers)
Best for:
- Microservices and long-running container workloads
- Standardized packaging and predictable scaling
- When Lambda constraints don’t fit (timeouts, runtime, dependencies)
AWS Fargate (serverless containers)
Best for:
- Containers without managing EC2 instances
- Common “high-performing + elastic” answer for containerized apps
AWS Batch
Best for:
- Batch jobs, large-scale job queues, compute-intensive processing
- Automatically provisions compute (often EC2/Spot) to run jobs
Amazon EMR
Best for:
- Big data processing frameworks (Spark, Hadoop)
- Distributed ETL / analytics workloads
Spark/Hadoop _→ EMR.
_“run 10,000 batch jobs” → Batch.
2 | Distributed Computing Concepts Supported By Global Infrastructure And Edge Services
Compute performance can depend on where compute runs:
- Multi-AZ architectures reduce impact of AZ failure and allow scale-out
- Edge services reduce latency for users
Common Edge And Global Services
CloudFront: caching and edge delivery
Global Accelerator: Anycast routing for TCP/UDP apps
3 | Queuing And Messaging Concepts (Pub/Sub)
Queues and events are a core scaling tool because they buffer spikes.
1 SQS: decouple producer/consumer; scale workers on queue depth
2 SNS: pub/sub fan-out
3 EventBridge: event routing
4 | Scalability Capabilities
EC2 Auto Scaling And AWS Auto Scaling
EC2 Auto Scaling scales EC2 instances in an Auto Scaling Group (ASG)
AWS Auto Scaling provides scaling for multiple services (ECS, DynamoDB, Aurora replicas, etc.)
5 | Serverless Technologies And Patterns
Lambda And Fargate
Lambda scales by concurrency and can be event-driven and bursty
Fargate scales containers without managing servers and scales via ECS/EKS configuration
6 | The Orchestration Of Containers
Amazon ECS And Amazon EKS
Container Orchestration is how you deploy, run, scale, and heal containers.
ECS (AWS-native) concepts:
- Cluster → Service → Tasks
- Task definition is the blueprint
EKS (Kubernetes) concepts: Cluster → Deployments → Pods
If Kubernetes is not required, ECS is usually simpler.
Skills
A | Decouple Workloads So Components Can Scale Independently
Decoupling Patterns
1 SQS between web tier and workers: buffer spikes, retry, DLQ)
2 SNS fan-out to multiple consumers
3 EventBridge for event-driven integration
4 Step Functions for orchestration when coordination is needed
Frontend scales with traffic, workers scale with queue depth.
B | Identify Metrics And Conditions To Perform Scaling Actions
Common Scaling Signals
1 CPU / memory (EC2/ECS)
2 Request count / target response time (ALB target metrics)
3 Queue depth / age of oldest message (SQS-based worker scaling)
4 Lambda concurrency / duration / throttles
5 Custom CloudWatch metrics (business-driven scaling, e.g., “jobs waiting”)
C | Select Appropriate Compute Options And Features To Meet Business Requirements
EC2 Instance Types
| Need | Common EC2 Family |
|---|---|
| General purpose | t, m |
| Compute-heavy | c |
| Memory-heavy | r, x |
| Storage / IOPS-heavy | i |
| GPU/ML/graphics | p, g |
Other EC2 Options
Spot Instances for fault-tolerant workloads (batch, stateless, flexible)
Graviton (Arm) for price/performance
D | Select The Appropriate Resource Type And Size To Meet Business Requirements
Lambda Memory
1 Memory also affects CPU allocation.
2 Increase memory when execution time is too slow (often improves performance).
3 Watch for throttles and concurrency limits.
Container Memory
1 Right-size task/pod CPU and memory
2 Scale task count rather than over-sizing single tasks (where possible)
Cheat Sheet
| Requirement | Compute |
|---|---|
| Event-driven, spiky traffic, minimal ops | Lambda |
| Run containers without managing servers | ECS on Fargate |
| Must use Kubernetes | EKS |
| Need OS control / legacy app | EC2 (+ Auto Scaling) |
| Run many batch jobs / job queue | AWS Batch |
| Spark/Hadoop big data processing | EMR |
| Scale workers based on backlog | SQS + autoscaled consumers |
| Need global performance improvement | CloudFront / Global Accelerator |
Recap Checklist ✅
1. [ ] Workload is decoupled so components can scale independently (queues/events)
2. [ ] Compute choice matches runtime needs (EC2 vs containers vs serverless)
3. [ ] Scaling strategy is explicit (Auto Scaling, queue-based, event-based)
4. [ ] Scaling metrics are chosen appropriately (CPU, requests, queue depth, concurrency)
5. [ ] EC2 instances are selected by workload profile (compute/memory/storage/GPU)
6. [ ] Lambda/container resources are right-sized (memory/CPU) and adjusted based on performance
AWS Whitepapers and Official Documentation
These are the primary AWS documents behind Task Statement 3.2
You do not need to memorize them, use them to understand how to Design High-Performing And Elastic Compute Solutions
Compute services
1. EC2
2. Lambda
3. ECS
4. EKS
5. Fargate
6. AWS Batch
7. EMR
Scaling
1. EC2 Auto Scaling
2. AWS Auto Scaling
3. CloudWatch
Decoupling And Messaging
1. SQS
2. SNS
3. EventBridge
Edge And Global Performance
1. CloudFront
2. Global Accelerator
🚀