7 · Compute Choices¶
Domain 3 — Design High-Performing Architectures · 24%
This topic is almost entirely a matching exercise: given a workload, pick EC2, containers (ECS/EKS on EC2 or Fargate), or Lambda. The exam leans on a few hard limits — especially Lambda's 15-minute timeout — to rule options in or out. Learn the decision cues and those limits and you're set.
Core concept¶
AWS compute is a spectrum from most control / most ops to least ops / most managed:
EC2 (you manage the OS) → Containers (ECS/EKS; on EC2 you manage nodes, on Fargate you don't) → Lambda (fully serverless, event-driven, no infrastructure at all).
The right choice trades control against operational burden and matches the workload's shape (steady vs spiky, long vs short, server vs function vs container).
When to use what¶
| Workload | Best fit | Why |
|---|---|---|
| Steady, long-running server; need OS/kernel control, specific instance types, or licensing | EC2 | Full control; cheapest at steady high utilization with RIs/Savings Plans |
| Short, event-driven, sporadic tasks (≤ 15 min) | Lambda | No servers, scales to zero, pay per request + duration |
| Containerized microservices, don't want to manage servers | ECS/EKS on Fargate | Serverless containers — no EC2 fleet to patch or scale |
| Containers where you need node-level control or maximum density/cost tuning | ECS/EKS on EC2 | You manage the instances |
| You standardize on Kubernetes | EKS | Managed Kubernetes control plane |
| Large-scale batch jobs | AWS Batch (often on Fargate/EC2/Spot) | Managed batch scheduling |
Two reflexes:
- "No servers to manage" + short/event-driven → Lambda. "No servers to manage" + long-running container → Fargate.
- Steady, predictable, high utilization → EC2 (with a commitment for cost — see Topic 11).
EC2 instance families¶
You don't memorize instance sizes, but you should map the family letter → what it's optimized for, because questions describe a bottleneck and expect the matching family:
| Family | Optimized for | Example need |
|---|---|---|
| T, M (general purpose) | Balanced; T = burstable | Web servers, small/medium apps, dev |
| C (compute optimized) | High CPU per dollar | Batch, HPC, gaming, media encoding |
| R, X (memory optimized) | Large RAM | In-memory DBs, big caches, analytics |
| I, D (storage optimized) | High local disk IOPS/throughput | NoSQL, data warehouses, big local datasets |
| P, G (accelerated) | GPUs | ML training/inference, graphics |
Cue words: "high memory / in-memory database" → R/X; "CPU-bound / batch" → C; "GPU / ML" → P/G; "burstable cheap web server" → T.
Lambda — the limits that decide questions¶
Serverless functions triggered by events (API Gateway, S3, SQS, EventBridge, etc.). You pay per request and GB-second of duration; it scales automatically and to zero.
| Limit | Value |
|---|---|
| Max timeout | 15 minutes (900 s) |
| Memory | 128 MB – 10 GB (CPU scales with memory) |
Ephemeral /tmp |
512 MB – 10 GB |
| Deployment | 50 MB zipped / 250 MB unzipped; or a container image up to 10 GB |
| Default concurrency | 1,000 per Region (soft limit; request increases) |
The 15-minute timeout is the single most common rule-out on the exam. Anything that must run longer than 15 minutes cannot be Lambda → use Fargate, EC2, or Batch. Watch for cold starts on latency-sensitive functions (mitigate with provisioned concurrency).
Containers — ECS, EKS, and the Fargate distinction¶
- Amazon ECS — AWS's own container orchestrator. Simpler if you're all-in on AWS.
- Amazon EKS — managed Kubernetes. Choose it when you need k8s (portability, existing k8s tooling/skills).
- Launch type is the axis that matters most for the exam:
- Fargate — serverless; AWS runs the containers, you don't provision or patch EC2. Pick it for "run containers without managing servers."
- EC2 launch type — you run and manage the EC2 instances in the cluster; more control, more ops, can be cheaper at high steady density (especially with Spot).
ECS also uses a task role (for the app's AWS permissions) vs an execution role (to pull images / write logs) — see IAM.
Worked example — same job, three wrong-sized answers¶
A team needs to run a video-transcoding job that takes ~40 minutes per file, triggered whenever a new file lands in S3, a few times an hour. They want minimal server management.
Lambda, Fargate, or EC2?
Answer
Fargate (run a container task per job). Lambda is ruled out immediately — a 40-minute job exceeds the 15-minute timeout. Plain EC2 would work but means managing and scaling instances for a bursty, few-times-an-hour workload (wasteful when idle). Fargate runs the transcoding container on demand with no servers to manage, scales per job, and has no 15-minute cap. (You'd trigger it via S3 → EventBridge/Lambda → run the Fargate task, or S3 → Batch on Fargate.)
Exam traps¶
- Lambda caps at 15 minutes — longer job ⇒ Fargate/EC2/Batch, never Lambda.
- "Serverless containers" = Fargate; "serverless functions" = Lambda. Don't blur them.
- Need Kubernetes → EKS; happy with AWS-native → ECS. Both can run on Fargate or EC2.
- Match the EC2 family to the bottleneck (memory → R/X, CPU → C, GPU → P/G, burstable → T).
- Cold starts hit latency-sensitive Lambdas → provisioned concurrency.
- Steady, high-utilization, always-on → EC2 (cheapest with a commitment); spiky/event-driven → serverless (pay only when running).
- Fargate removes server management but not cost awareness — long-running high-throughput containers can be cheaper on EC2/Spot.
Practice questions¶
Q1. A data-processing job runs for about 25 minutes each time it's triggered. The team wants to avoid managing servers. Which compute option is appropriate?
- A. AWS Lambda
- B. A container task on AWS Fargate
- C. A single always-on EC2 instance
- D. Amazon S3
Answer: B
B. A 25-minute job exceeds Lambda's 15-minute timeout (A is out). Fargate runs the job as a serverless container with no servers to manage and no such time cap. An always-on EC2 instance (C) wastes money between runs and adds management. S3 (D) is storage, not compute.
Q2. An application is event-driven, runs thousands of short (< 5 s) tasks per minute in bursts, and should scale to zero when idle with no infrastructure to manage. Best fit?
- A. EC2 Auto Scaling group
- B. AWS Lambda
- C. Amazon EKS on EC2
- D. A fleet of Reserved Instances
Answer: B
B. Short, bursty, event-driven tasks that should scale to zero are the textbook Lambda use case — pay per request/duration, no servers. An ASG (A) and EKS-on-EC2 (C) keep instances running and require management. Reserved Instances (D) are a billing commitment for steady usage, the opposite of bursty scale-to-zero.
Q3. A workload runs an in-memory analytics database that needs a very large amount of RAM. Which EC2 instance family is most appropriate?
- A. C family (compute optimized)
- B. R or X family (memory optimized)
- C. T family (burstable)
- D. P family (GPU)
Answer: B
B. Memory-optimized R/X families are built for large-RAM, in-memory workloads. C (A) is for CPU-bound work, T (C) is burstable general purpose, P (D) is for GPU/ML. Match the family to the bottleneck — here, memory.
Q4. A company is migrating microservices that are already packaged as Docker containers and standardized on Kubernetes, and wants to avoid managing the Kubernetes control plane and the worker nodes. What should they use?
- A. Amazon ECS on EC2
- B. Amazon EKS with Fargate
- C. EC2 instances with Docker installed
- D. AWS Lambda
Answer: B
B. EKS gives a managed Kubernetes control plane, and Fargate removes worker-node management — matching "Kubernetes, no servers to manage." ECS (A) isn't Kubernetes and EC2 launch type still means managing nodes. Self-managed Docker on EC2 (C) manages everything yourself. Lambda (D) isn't a container orchestrator for existing k8s workloads.
Q5. Which statement about AWS Lambda is correct?
- A. Functions can run for up to 1 hour.
- B. Functions can run for a maximum of 15 minutes and scale automatically with no servers to manage.
- C. Lambda requires you to provision EC2 capacity.
- D. Lambda is best for steady, always-on, high-CPU workloads.
Answer: B
B. Lambda has a 15-minute max execution time, scales automatically, and is fully serverless. A overstates the timeout; C is false (no capacity to provision); D describes an EC2 (with a commitment) workload, not Lambda's event-driven sweet spot.