Design High-Performing And Elastic Compute Solutions

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

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

---

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

🚀