Introduction
Almost every scenario question on the AWS Certified Solutions Architect – Professional (SAP-C02) exam eventually comes down to one decision: what runs the workload? The exam rarely tests a compute service in isolation. Instead it hands you a paragraph full of constraints — a 15-minute processing window, a “no servers to manage” mandate, an existing Kubernetes investment, a spiky and unpredictable traffic pattern — and expects you to eliminate three answer choices and pick the compute service that fits.
This is a skill, not a memory test. Two answers will always be technically possible; your job is to pick the one that’s best given the constraints. This guide gives you a repeatable framework for AWS compute selection and then walks through EC2, Lambda, ECS, EKS, Fargate, and Batch — what each is for, where each breaks down, and the exact scenario signals that point to it.
If you’re assembling your full prep, start with the AWS Solutions Architect Professional guide for 2026 and the SAP-C02 study plan. For the deeper serverless patterns this article touches, see SAP-C02 serverless architecture patterns.
The Compute Selection Framework
Before looking at services, internalize the questions the exam is really asking. Run every scenario through this filter:
- How much control do you need? Custom kernels, specific OS, licensed software, or GPU drivers push you toward EC2. “No infrastructure to manage” pushes you toward serverless.
- What’s the execution shape? Short, event-driven, bursty tasks favor Lambda. Long-running services favor containers or EC2. Massive parallel batch jobs favor AWS Batch.
- Is it containerized — and do you need Kubernetes? Containers without Kubernetes → ECS. Containers with Kubernetes (portability, existing skills, the broader ecosystem) → EKS.
- Who manages the servers? If the answer must be “AWS,” you want Fargate or Lambda. If you need node-level access, you want the EC2 launch type.
- What’s the cost and operational pressure? Steady-state, predictable load rewards Reserved Instances or Savings Plans on EC2. Spiky or unpredictable load rewards pay-per-use serverless.
Hold these five questions in your head and most “best compute” questions resolve quickly.
The Compute Spectrum at a Glance
AWS compute runs along a spectrum from “you manage everything” to “AWS manages everything”:
| Service | Abstraction | You manage | AWS manages | Best execution shape |
|---|---|---|---|---|
| EC2 | Virtual machines (IaaS) | OS, patching, scaling, capacity | Hardware, hypervisor | Anything; full control |
| ECS on EC2 | Container orchestration | Container hosts (EC2) | Orchestration control plane | Long-running containers |
| EKS on EC2 | Managed Kubernetes | Worker nodes, K8s objects | K8s control plane | Containers needing Kubernetes |
| Fargate | Serverless containers | Task definitions only | Servers, scaling, patching | Containers, no node ops |
| Lambda | Functions (FaaS) | Code + config | Everything else | Short, event-driven tasks |
| AWS Batch | Managed batch | Job definitions | Scheduling + provisioning | Large parallel batch jobs |
The further down this table you go, the less you operate and the more constraints you accept. The exam is constantly asking you to find the lowest-operational-overhead option that still meets the requirements.
Amazon EC2: Maximum Control
EC2 gives you virtual machines you fully control — any OS, any software, any kernel module, GPUs, and persistent or ephemeral storage. On the SAP-C02, EC2 is the right answer when a scenario demands something the serverless options can’t give you:
- A specific operating system or kernel version, custom drivers, or a licensed/legacy application.
- GPU or specialized hardware for ML training, rendering, or HPC.
- Long-running, steady-state workloads where Reserved Instances or Savings Plans deliver the best price.
- Lift-and-shift migrations where re-architecting to containers or serverless isn’t yet on the table.
The professional exam tests EC2 pricing models heavily, because cost optimization is a major theme:
| Pricing model | When the exam picks it |
|---|---|
| On-Demand | Short-term, unpredictable, can’t be interrupted; no commitment |
| Reserved Instances | Steady-state, predictable usage for 1–3 years; up to ~72% savings |
| Savings Plans | Predictable spend with flexibility across instance families/regions/compute types |
| Spot Instances | Fault-tolerant, interruptible workloads; up to ~90% savings, 2-minute interruption notice |
| Dedicated Hosts | Compliance, licensing (BYOL), or per-socket/per-core licensing requirements |
A classic SAP-C02 signal: “fault-tolerant, stateless, can tolerate interruption, minimize cost” → Spot. “Steady 24/7 baseline” → Reserved Instances or a Savings Plan. “BYOL Windows licensing tied to physical cores” → Dedicated Hosts. For the broader picture, see SAP-C02 cost optimization strategies.
AWS Lambda: Event-Driven and Serverless
Lambda runs your code in response to events with zero server management and pay-per-use billing (requests + GB-seconds of duration). It’s the default answer when a scenario emphasizes “no servers,” “event-driven,” “scale to zero,” or “only pay when it runs.”
But Lambda has hard constraints the exam loves to exploit:
| Constraint | Limit | Exam implication |
|---|---|---|
| Max execution time | 15 minutes | A 30-minute job cannot run on a single Lambda invocation |
| Memory | Up to 10 GB | CPU scales with memory; memory-bound jobs may not fit |
Ephemeral /tmp | Up to 10 GB | Large local working sets may exceed it |
| Deployment package | 250 MB unzipped (or 10 GB container image) | Big dependencies need container packaging |
The 15-minute timeout is the single most-tested Lambda fact. If a scenario describes video transcoding, a large ETL job, or anything that “takes up to an hour,” Lambda is almost certainly a distractor — the correct answer routes that work to Fargate, ECS, EC2, or AWS Batch, often with Step Functions orchestrating the pipeline.
Lambda shines for:
- API backends behind API Gateway or an ALB.
- Event processing from S3, DynamoDB Streams, Kinesis, SQS, and EventBridge.
- Glue code and lightweight automation between services.
- Spiky, unpredictable traffic where paying for idle EC2 capacity would be wasteful.
ECS vs. EKS: The Container Orchestration Choice
When a workload is containerized and needs orchestration, the exam splits on one question: do you need Kubernetes?
Amazon ECS is AWS’s native container orchestrator. It’s simpler, deeply integrated with AWS services (IAM roles per task, ALB, CloudWatch), and has no control-plane cost. Choose ECS when:
- The team wants the lowest operational overhead for containers and has no Kubernetes requirement.
- The workload is AWS-only and benefits from tight native integration.
- Simplicity and fast onboarding matter more than ecosystem portability.
Amazon EKS is managed Kubernetes. AWS runs the control plane (for an hourly per-cluster fee); you get the full Kubernetes API and ecosystem. Choose EKS when:
- You need Kubernetes specifically — existing K8s skills, Helm charts, operators, or multi-cloud/hybrid portability.
- You’re standardizing on the CNCF ecosystem (service meshes, GitOps, custom controllers).
- Workloads may need to move between on-prem and cloud, or across clouds.
| Factor | ECS | EKS |
|---|---|---|
| Orchestrator | AWS-proprietary | Kubernetes (CNCF) |
| Control-plane cost | None | Hourly per cluster |
| Operational complexity | Lower | Higher |
| Portability | AWS-centric | Multi-cloud / hybrid |
| Best for | AWS-native containers, simplicity | K8s skills, portability, ecosystem |
The exam signal is almost always explicit: words like “Kubernetes,” “existing Helm charts,” “portability across clouds,” or “the team already runs Kubernetes on-prem” point to EKS. The absence of any Kubernetes requirement, paired with “minimize operational overhead,” points to ECS.
AWS Fargate: Serverless Containers
Here’s the distinction candidates miss most: Fargate is not a separate orchestrator — it’s a launch type. It’s the serverless data plane for both ECS and EKS. You still use ECS or EKS to define and orchestrate your containers; Fargate just means AWS provisions and manages the underlying compute, so you never touch an EC2 instance.
ECS or EKS = the orchestrator (control plane / how containers are scheduled)
Fargate = a launch type (who runs the servers: AWS, serverlessly)
EC2 = the alternative launch type (you manage the nodes)Choose Fargate when the scenario says “no servers to manage,” “no node patching,” or “reduce operational overhead” for a containerized workload. Choose the EC2 launch type when you need:
- GPUs or specialized instances (Fargate doesn’t offer GPU instances).
- Daemon-style workloads or privileged containers that need host access.
- Maximum cost efficiency at steady, high utilization, where reserved EC2 capacity beats per-task Fargate pricing.
- Fine-grained control over the host, kernel, or networking.
A frequent SAP-C02 pattern: a team running ECS on EC2 complains about patching and capacity management. The lowest-overhead fix is to migrate those tasks to Fargate — same ECS service definitions, no servers to manage.
AWS Batch: Large-Scale Parallel Jobs
AWS Batch is purpose-built for batch computing — running hundreds or thousands of jobs that each have a start and an end. It provisions the right amount and type of compute (across EC2, Spot, and Fargate), queues jobs, handles dependencies, and tears capacity down when the queue drains.
Choose AWS Batch when a scenario describes:
- High-throughput scientific or financial computing (HPC, genomics, risk modeling, rendering).
- Large numbers of independent jobs that need a managed queue and scheduler.
- Cost-sensitive batch work that can run on Spot to slash compute cost.
If a scenario mentions “thousands of batch jobs,” “job queue,” or “process a large dataset overnight as parallel jobs,” Batch is usually the cleanest answer — more so than hand-rolling the same thing on raw EC2 with custom queuing.
A Side-by-Side Decision Table
| If the scenario says… | Lean toward |
|---|---|
| ”No servers to manage,” short event-driven tasks | Lambda |
| Processing that runs longer than 15 minutes | Fargate / ECS / EC2 / Batch (not Lambda) |
| Containers, no Kubernetes, minimize ops | ECS (on Fargate) |
| Containers, “we use Kubernetes” or need portability | EKS |
| ”No node patching / no servers” for containers | Fargate launch type |
| GPU, custom kernel, licensed/legacy software | EC2 |
| Steady 24/7 baseline, minimize cost | EC2 with Reserved Instances / Savings Plans |
| Fault-tolerant, interruptible, cheapest | EC2 Spot |
| Thousands of parallel batch jobs | AWS Batch |
| BYOL licensing tied to physical cores | EC2 Dedicated Hosts |
This table is your eliminator. On exam day, match the strongest signal in the question stem to a row, then verify the remaining constraints don’t disqualify it.
How This Shows Up in Scenario Questions
Consider a representative SAP-C02-style prompt:
A company runs a nightly data-processing pipeline that takes 40 minutes per run, is fully containerized, must not require the team to manage or patch any servers, and should minimize cost. Which compute option best fits?
Walk the framework:
- 40 minutes → eliminates Lambda (15-minute cap).
- Containerized, no Kubernetes mentioned → ECS over EKS.
- No servers to manage / no patching → Fargate launch type, not EC2.
- Minimize cost → Fargate Spot for the interruptible batch run.
Answer: ECS on Fargate (Spot). The 15-minute limit kills the tempting “Lambda” distractor, and the absence of any Kubernetes requirement makes EKS unnecessary overhead. This is the exact reasoning the exam wants — and the kind of multi-constraint elimination you build through repetition. For more worked examples, see how to pass the SAP-C02 on your first attempt.
Conclusion
Compute selection is the connective tissue of the SAP-C02 exam. Master the five-question framework — control, execution shape, Kubernetes-or-not, who-manages-servers, and cost pressure — and you’ll cut through scenarios that are designed to make two answers look equally valid. Remember the load-bearing facts: Lambda’s 15-minute ceiling, Fargate as a launch type (not an orchestrator), ECS-vs-EKS hinging on whether Kubernetes is required, and EC2’s pricing models mapping directly to workload predictability.
The services are the easy part. The exam difficulty lives in reading constraints precisely and eliminating the almost-right answer — a muscle you build by doing dozens of scenario questions, not by re-reading service docs.
Practice With Realistic SAP-C02 Scenarios
Compute selection is best learned the way the exam tests it: through multi-constraint scenarios where you have to eliminate plausible distractors under time pressure. Reading this framework gives you the model; timed practice questions show you whether you can actually apply it when the clock is running.
Sailor.sh’s SAP-C02 mock exam bundle is built around realistic, scenario-based questions — including the compute-selection trade-offs covered here — each with a detailed explanation of why the best answer wins and why the others fall short. Start by gauging your level with the free SAP-C02 practice questions, then reinforce the architecture fundamentals with the Well-Architected Framework deep dive and database selection guide.
Frequently Asked Questions
What’s the difference between Fargate and EC2 for containers?
Both are launch types for ECS and EKS, not separate orchestrators. With the EC2 launch type, you provision and manage the underlying instances (patching, scaling, capacity). With Fargate, AWS runs the servers for you — you only define the task. Choose Fargate to eliminate node management; choose EC2 for GPUs, privileged/daemon workloads, or maximum cost efficiency at steady high utilization.
When should I choose ECS over EKS on the SAP-C02 exam?
Choose ECS when the workload is containerized but has no Kubernetes requirement and the priority is the lowest operational overhead and tight AWS integration. Choose EKS when the scenario explicitly needs Kubernetes — existing K8s skills, Helm/operators, or portability across clouds and on-prem. The keyword “Kubernetes” (or signals like Helm charts) almost always points to EKS.
Why does Lambda’s 15-minute limit matter so much on the exam?
Because it’s the cleanest way to eliminate Lambda as a distractor. Any workload that runs longer than 15 minutes — large ETL, video transcoding, long batch jobs — cannot complete in a single Lambda invocation. When a scenario gives you a duration over 15 minutes, the correct compute is usually Fargate, ECS, EC2, or AWS Batch, often orchestrated by Step Functions.
Which EC2 pricing model should I pick for a steady, predictable workload?
Reserved Instances or a Savings Plan. Both reward a 1- or 3-year commitment with significant discounts versus On-Demand. Savings Plans add flexibility across instance families, regions, and compute types. Use Spot only for fault-tolerant, interruptible work, and Dedicated Hosts for licensing or compliance requirements tied to physical hardware.
When is AWS Batch the right answer instead of ECS or Lambda?
AWS Batch is purpose-built for large numbers of independent, finite jobs that need a managed queue, scheduler, and dependency handling — HPC, genomics, financial modeling, rendering. If a scenario describes thousands of parallel batch jobs or “process a large dataset overnight,” Batch is cleaner than hand-rolling queuing on EC2 or hitting Lambda’s limits.
Is serverless always the best answer on the SAP-C02?
No. The exam rewards the lowest-overhead option that meets all constraints — which is often serverless, but not when you need GPUs, custom kernels, licensed software, sustained high utilization where reserved capacity is cheaper, or long-running stateful processes. Read every constraint before defaulting to Lambda or Fargate.
Ready to turn compute trade-offs into easy points? Practice realistic, explained scenarios with the Sailor.sh SAP-C02 mock exams, then map your full prep with the AWS Solutions Architect Professional guide for 2026.