Compute is where AWS actually runs your code, and on the CLF-C02 exam it lives in the largest scored domain — Cloud Technology and Services. If you can confidently tell EC2 apart from Lambda, know why containers matter, and recognize the difference between paying On-Demand and buying a Savings Plan, you’ll pick up a reliable cluster of points. Better still, these concepts are the foundation for every other AWS certification you might take later.
This guide is written from a practitioner’s perspective. We’ll walk through the compute services the Cloud Practitioner exam expects you to recognize — EC2, Auto Scaling, Elastic Load Balancing, Lambda, the container trio (ECS, EKS, Fargate), and platform services like Elastic Beanstalk and Lightsail — and, more importantly, the decision framework that turns “which compute service should I use?” into a fast, confident answer. If you want the full exam picture first, start with the AWS Cloud Practitioner Exam Guide 2026, then come back here to go deep on compute.
Why Compute Sits at the Center of CLF-C02
The CLF-C02 blueprint has four domains:
| Domain | Weight | What it covers |
|---|---|---|
| Cloud Concepts | 24% | Value proposition, cloud economics, Well-Architected Framework |
| Security and Compliance | 30% | Shared Responsibility Model, IAM, encryption |
| Cloud Technology and Services | 34% | Compute, storage, networking, databases, deployment |
| Billing, Pricing, and Support | 12% | Pricing models, cost tools, support plans |
Compute is a big slice of that 34% technology domain. And it connects outward: purchasing options tie into pricing and cost management, while the Shared Responsibility Model changes depending on which compute service you pick — you patch the OS on EC2, but AWS patches it under Lambda. Keep that thread in mind as we go.
The AWS Compute Spectrum: From Servers to Serverless
The single most useful mental model is a spectrum of how much you manage versus how much AWS manages. As you move down this list, you hand more operational work to AWS and keep less control.
| Service | You manage | AWS manages | Best for |
|---|---|---|---|
| EC2 | OS, patching, scaling, capacity | Physical host, hypervisor, network | Full control, lift-and-shift, custom software |
| Elastic Beanstalk | Your application code | Provisioning, capacity, load balancing | Deploy code without wiring up infrastructure |
| Containers (ECS/EKS) | Containers, cluster config | Orchestration control plane | Microservices, portable workloads |
| Fargate | Containers only | Servers, patching, scaling | Containers without managing servers |
| Lambda | Function code | Everything else | Event-driven, short-lived tasks |
There is no “best” service — only the best fit for a workload. The exam rewards you for matching a scenario to the right point on this spectrum.
Amazon EC2: Virtual Servers in the Cloud
Amazon Elastic Compute Cloud (EC2) gives you resizable virtual servers — called instances — that you launch in minutes and pay for by the second or hour. EC2 is Infrastructure as a Service (IaaS): you get an operating system and full control, which also means you’re responsible for patching that OS, configuring security, and scaling.
EC2 Instance Families
AWS groups instance types into families optimized for different workloads. You don’t need to memorize specific instance names for CLF-C02, but you should recognize the categories:
| Family | Optimized for | Typical use |
|---|---|---|
| General Purpose | Balanced compute, memory, network | Web servers, small databases |
| Compute Optimized | High CPU | Batch processing, gaming servers, HPC |
| Memory Optimized | Large RAM | In-memory databases, real-time analytics |
| Storage Optimized | High disk throughput/IOPS | Data warehouses, large transactional DBs |
| Accelerated Computing | GPUs / hardware accelerators | Machine learning, rendering |
The takeaway for the exam: AWS offers purpose-built instance types, so you right-size to the workload instead of buying one oversized server for everything.
EC2 Purchasing Options — the high-value table
This is the EC2 topic the exam tests most, because it ties directly to cloud economics. Learn the trade-offs:
| Option | Commitment | Savings vs On-Demand | Best for |
|---|---|---|---|
| On-Demand | None | Baseline (most expensive per hour) | Short-term, spiky, unpredictable, dev/test |
| Reserved Instances (RI) | 1 or 3 years | Up to ~72% | Steady-state, predictable, always-on workloads |
| Savings Plans | 1 or 3 years ($/hour commitment) | Up to ~72% | Predictable spend with flexibility across EC2, Fargate, Lambda |
| Spot Instances | None (can be reclaimed) | Up to ~90% | Fault-tolerant, flexible, interruptible workloads |
| Dedicated Hosts | On-Demand or Reserved | — (premium) | Compliance, licensing (BYOL), physical isolation |
How to read the exam cues:
- “Unpredictable,” “short-term,” “can’t be interrupted” → On-Demand.
- “Steady-state,” “runs 24/7 for a year,” “predictable” → Reserved Instances or Savings Plans.
- “Fault-tolerant,” “can handle interruptions,” “batch/CI/big-data,” “cheapest possible” → Spot Instances.
- “Regulatory requirement for dedicated physical hardware,” “bring your own license” → Dedicated Hosts.
Savings Plans deserve a special note: Compute Savings Plans are more flexible than RIs because the discount applies across EC2 instance families and Fargate and Lambda. If a question stresses flexibility with a spend commitment, lean Savings Plans.
Scaling and Distributing Load: Auto Scaling & ELB
Two services almost always appear alongside EC2 because they make it elastic and resilient.
EC2 Auto Scaling automatically adds instances when demand rises and removes them when demand falls, based on rules you define (for example, target CPU utilization). This is elasticity in action — one of the core cloud value propositions covered in cloud concepts. It improves availability and controls cost: you don’t pay for capacity you aren’t using.
Elastic Load Balancing (ELB) distributes incoming traffic across multiple instances (often across multiple Availability Zones), so no single instance is overwhelmed and a failed instance is automatically bypassed. The main types worth recognizing:
| ELB type | Layer | Use |
|---|---|---|
| Application Load Balancer (ALB) | HTTP/HTTPS (Layer 7) | Web apps, path/host routing |
| Network Load Balancer (NLB) | TCP/UDP (Layer 4) | Extreme performance, static IPs |
| Gateway Load Balancer | Layer 3 | Third-party virtual appliances |
Together, Auto Scaling + ELB form the classic pattern for a highly available, elastic web tier. The exam loves to pair them.
AWS Lambda: Serverless Compute
AWS Lambda runs your code without any servers for you to provision or manage. You upload a function, choose how much memory it gets, and Lambda runs it in response to events — an file landing in S3, an HTTP request through API Gateway, a message on a queue. You pay only for the number of requests and the compute time your code actually uses (measured in GB-seconds); when nothing is running, you pay nothing.
Key facts the exam expects:
- No server management — AWS handles capacity, patching, and scaling automatically.
- Event-driven — functions run in response to triggers.
- Automatic scaling — from a few requests a day to thousands per second.
- Short-lived — a function has a maximum timeout of 15 minutes, so Lambda suits quick tasks, not long-running processes.
- Pay-per-use — no charge when idle.
Under the Shared Responsibility Model, Lambda pushes almost all operational responsibility to AWS — you own only your code and its configuration. If a scenario says “run code in response to events with no servers to manage,” the answer is Lambda.
Running Containers on AWS: ECS, EKS, Fargate & ECR
Containers package an application with its dependencies so it runs the same way everywhere. AWS offers several services, and the exam wants you to tell them apart:
- Amazon ECS (Elastic Container Service) — AWS’s own container orchestrator. Simple, deeply integrated with AWS, no Kubernetes knowledge required.
- Amazon EKS (Elastic Kubernetes Service) — managed Kubernetes. Choose this when a team wants the open-source Kubernetes ecosystem and portability. (If Kubernetes itself is new to you, the KCNA certification path is a good primer.)
- AWS Fargate — a serverless compute engine for containers. It works with both ECS and EKS and removes the need to manage EC2 servers for your containers. You define the container; AWS runs it.
- Amazon ECR (Elastic Container Registry) — a managed registry to store and pull your container images.
The distinction that trips people up: ECS/EKS are orchestrators (they decide where containers run), while Fargate is a launch type (it removes the servers under them). You can run ECS on EC2 (you manage the instances) or on Fargate (you don’t). If a question says “run containers without managing the underlying servers,” the answer is Fargate.
Platform Services: Elastic Beanstalk, Lightsail & App Runner
These services trade control for simplicity — ideal when you just want to ship an app.
AWS Elastic Beanstalk is a Platform as a Service (PaaS). You upload your application code, and Beanstalk automatically provisions the EC2 instances, load balancer, Auto Scaling group, and monitoring for you. You keep full access to the underlying resources if you need them, and Beanstalk itself is free — you pay only for the AWS resources it creates. Think: “deploy my code, handle the infrastructure, but don’t hide it from me.”
Amazon Lightsail is a simplified way to launch a virtual private server with a bundled, predictable monthly price that includes compute, storage, and data transfer. It’s aimed at beginners and simple workloads — a small website, a blog, a dev environment — where the full flexibility of EC2 would be overkill. Think: “the easiest way to get a simple app or website online.”
AWS App Runner is a fully managed service for deploying containerized web applications and APIs directly from source code or a container image, with automatic scaling and load balancing. It sits between Beanstalk and Fargate on the simplicity scale.
Batch and Edge Compute (Recognize, Don’t Memorize)
A few more names may appear as options:
- AWS Batch — runs large-scale batch computing jobs, provisioning compute automatically. Signal: “process thousands of batch jobs.”
- AWS Outposts — AWS compute running on-premises in your own data center. Signal: “hybrid,” “low latency to on-prem,” “data residency.”
- AWS Wavelength / Local Zones — compute closer to end users for ultra-low latency. This connects to AWS global infrastructure.
You won’t be asked to configure these; you just need to recognize the one-line signal for each.
The “Which Compute Service?” Decision Framework
Here’s the mental flowchart to run when a question describes a workload and asks for the right compute service:
- Do you need full control of the OS, or are you migrating an existing server? → EC2.
- Do you want to deploy code and let AWS build the infrastructure, but still access it? → Elastic Beanstalk.
- Is it event-driven and short-lived, with no servers to manage? → Lambda.
- Are you running containers?
- Want the Kubernetes ecosystem → EKS.
- Want a simpler AWS-native orchestrator → ECS.
- Don’t want to manage the servers under the containers → Fargate (with ECS or EKS).
- Is it a simple website or app, and you want a predictable low monthly price? → Lightsail.
- Is it large-scale batch processing? → AWS Batch.
Run that sequence and the vast majority of CLF-C02 compute questions collapse to a single answer.
How Compute Shows Up on the Exam
A few patterns worth internalizing before test day:
- Managed vs. unmanaged responsibility. Questions frequently probe the Shared Responsibility Model through compute. On EC2 you patch the guest OS; on Lambda and Fargate AWS does. Match the responsibility to the service.
- Cost optimization cues. “Steady-state for a year” points to Reserved/Savings Plans; “interruptible and cheapest” points to Spot; “unpredictable, short-term” points to On-Demand.
- Elasticity and availability. “Handle variable traffic automatically” → Auto Scaling. “Distribute traffic across instances/AZs” → Elastic Load Balancing.
- Serverless keywords. “No servers to manage,” “pay only for what you use,” “event-driven” → Lambda or Fargate.
For a broader view of how these fit the exam objectives, see the CLF-C02 domains breakdown and the core AWS services overview.
Frequently Asked Questions
What is the difference between EC2 and Lambda?
EC2 gives you a virtual server that you control and manage — you choose the OS, patch it, and decide how it scales, and you pay while it’s running. Lambda is serverless: you provide only your function code, AWS runs it in response to events, it scales automatically, and you pay only for the requests and compute time used. Choose EC2 for full control or long-running/legacy workloads; choose Lambda for short, event-driven tasks with no server management.
When should I use Spot Instances instead of On-Demand?
Use Spot Instances for workloads that can tolerate interruption — batch jobs, CI/CD runners, big-data processing, or any fault-tolerant, flexible task — because they can be reclaimed by AWS with a short warning but cost up to about 90% less. Use On-Demand when the workload is short-term, spiky, or cannot be interrupted, and you don’t want any long-term commitment.
What is the difference between ECS, EKS, and Fargate?
ECS and EKS are container orchestrators that decide where and how your containers run — ECS is AWS’s native orchestrator, EKS is managed Kubernetes. Fargate is a serverless launch type that runs containers without you managing any EC2 servers, and it works with both ECS and EKS. So the real question is two-part: which orchestrator (ECS vs. EKS), and do you want to manage the servers (EC2 launch type) or not (Fargate).
Is Elastic Beanstalk a paid service?
Elastic Beanstalk itself has no additional charge. You pay only for the underlying AWS resources it provisions on your behalf — the EC2 instances, load balancer, storage, and so on. That makes it a low-friction way to deploy an application without manually wiring up the infrastructure.
What is a Savings Plan and how is it different from a Reserved Instance?
A Savings Plan is a commitment to a consistent amount of compute spend (measured in dollars per hour) for a 1- or 3-year term, in exchange for a discount of up to about 72%. Compute Savings Plans are more flexible than Reserved Instances because the discount automatically applies across EC2 instance families, Fargate, and Lambda, rather than being tied to a specific instance configuration.
Do I need to know specific EC2 instance types for CLF-C02?
No. You should recognize the instance families and what each is optimized for — general purpose, compute optimized, memory optimized, storage optimized, and accelerated computing — but you won’t be asked to pick a specific instance size or name. The exam tests the concept of purpose-built, right-sized compute, not memorization of the instance catalog.
Conclusion and Next Steps
AWS compute looks like a long list of services, but it rewards a simple mental model: arrange the options on a spectrum from “you manage everything” (EC2) to “AWS manages everything” (Lambda), then match the scenario to the right point on that line. Nail the recurring distinctions — EC2 purchasing options, Auto Scaling vs. ELB, Lambda’s serverless model, ECS/EKS/Fargate, and the platform services — and compute becomes one of the most dependable scoring areas on CLF-C02.
The fastest way to turn this framework into exam-day reflexes is realistic practice. Sailor.sh’s AWS Certified Cloud Practitioner (CLF-C02) Mock Exam Bundle gives you exam-style questions that mirror the real format and difficulty — including the compute and cost trade-offs covered here — with detailed explanations that surface the exact distinctions the exam tests. Working through realistic questions is the surest way to find your gaps before they cost you points.
Pair the practice with the full Cloud Practitioner study plan, then round out the technology domain with core AWS services, AWS global infrastructure, and the pricing, billing & cost management guide.