Design High-Performing Architectures
Elastic Compute, Containers, and Serverless
CoreSelect and scale EC2, batch, big-data, container, and function compute from workload metrics.
Aligned to the current SAA-C03 exam guide, verified August 16, 2026.
Why this matters
High-performing compute is chosen from execution shape and bottleneck, not from a favorite service. Classify duration, state, runtime control, parallelism, scheduling, data locality, and scaling signal before selecting instances, functions, containers, batch scheduling, or distributed data processing.
Must Know
- Select EC2 families from the dominant resource—general, compute, memory, storage, or acceleration—then right-size from observed demand rather than memorizing instance names.
- Lambda fits event-driven functions and scales through concurrency; memory selection also affects available compute resources, so test end-to-end duration and cost.
- ECS/EKS orchestrate containers; Fargate removes host capacity management. EC2-backed containers retain host and capacity control.
- AWS Batch schedules containerized batch jobs onto managed compute environments and is designed for queued, finite work.
- EMR runs distributed big-data frameworks and fits large-scale data processing whose framework and cluster model matter.
- Decouple producers and workers with queues so each scales independently; queue age or backlog per worker often reflects demand better than CPU.
- Choose scaling metrics and cooldown/stabilization behavior from the real bottleneck and account for startup time and downstream limits.
Compare and Distinguish
- EC2 vs Lambda vs Fargate: choose host control/long-running compatibility, event-driven functions, or serverless container processes.
- ECS vs EKS: AWS-native orchestration versus Kubernetes compatibility/ecosystem.
- Fargate vs EC2 capacity: minimum host operations versus host/specialized capacity and fleet-level control.
- Batch vs Lambda: Batch wins for queued container jobs with flexible duration/resources; Lambda wins for compatible event-driven functions.
- EMR vs Glue: EMR wins when distributed framework/cluster control matters; Glue wins for managed serverless data integration and catalog-oriented ETL.
- Scale on CPU vs queue depth vs concurrency: select the signal closest to the constrained work, not one universal metric.
Scenario examples
- Scenario: Image-render jobs can wait, use containers, and need varying CPU. Think: submit to Batch and use elastic compute, including interruption-tolerant capacity when allowed.
- Scenario: Events invoke brief transformations with spiky volume. Think: Lambda can scale without idle servers, but protect downstream concurrency.
- Scenario: A Spark workload processes a large S3 dataset and needs framework controls. Think: EMR matches the distributed processing model.
- Scenario: Queue age rises while worker CPU stays low because calls wait on a dependency. Think: scale or redesign from queue pressure and dependency capacity, not CPU alone.
Exam traps
- A larger instance is not automatically a scalable architecture.
- Lambda concurrency can move the bottleneck into a database or API.
- Fargate does not replace ECS/EKS orchestration.
- Batch is not a database scheduler and EMR is not the default for simple ETL.
- Average CPU can hide queue backlog, skew, memory pressure, or throttling.
Key takeaways
- Classify execution shape before choosing compute.
- Match instance family and size to observed bottlenecks.
- Decouple work so components scale independently.
- Use the least-managed model that still meets runtime and control constraints.
- Protect downstream systems when upstream compute scales quickly.
How it works
- Auto Scaling policies adjust supported capacity from metrics, schedules, or predictive signals.
- Container services reconcile desired tasks/pods and place them on selected capacity.
- Lambda creates execution capacity from events within concurrency and downstream constraints.
- Batch queues jobs and schedules eligible capacity; EMR coordinates distributed framework work.
When to use it
- Use EC2 for custom hosts and specialized resources, Lambda for compatible event functions, and Fargate for managed container capacity.
- Use Batch for queued finite jobs and EMR for distributed big-data frameworks.
- Use SQS between producers and workers when burst buffering and independent scale are needed.
Security and governance implications
- Use workload roles and restrict access to images, data, and event sources.
- Scan images/dependencies and patch instance fleets.
- Limit concurrency or use queues to protect sensitive downstream systems.
- Spread production capacity across AZs where the workload requires it.
Operational and diagnostic signals
- If scaling fails to improve throughput, locate the actual saturated dependency or serialization point.
- If Lambda throttles, inspect concurrency, event-source behavior, retries, and downstream capacity.
- If containers do not place, compare requested resources, capacity, networking, and health.
- If jobs queue, inspect scheduling constraints, capacity availability, and data bottlenecks.
More detail
- Performance optimization is iterative: measure the workload, select a resource model, load test, observe bottlenecks, and adjust.
- Distributed processing helps only when work and data can be partitioned effectively.
- Serverless and managed compute reduce infrastructure work but retain application responsibilities for retries, state, permissions, and observability.
Ready for the quiz?
- Which hard constraint forces EC2?
- When does Batch beat Lambda?
- Why does EMR fit some data workloads better than Glue?
- What metric should scale queue workers?
- How can Lambda sizing affect both duration and cost?
Related objectives
- D3.2.K1
- D3.2.K2
- D3.2.K3
- D3.2.K4
- D3.2.K5
- D3.2.K6
- D3.2.S1
- D3.2.S2
- D3.2.S3
- D3.2.S4