AWS Compute Services Explained: EC2, Lambda, ECS, EKS, and Fargate (CLF-C02)

Every compute question on CLF-C02 is really asking one thing: given this workload, which service is the best fit? To answer quickly, sort the AWS compute portfolio into a small mental map before memorizing details.

At one end sits Amazon EC2 — virtual servers where you control the operating system and everything above it. At the other end sits AWS Lambda — serverless functions where you upload code and AWS handles every server concern. Between them are the container services: Amazon ECS and Amazon EKS orchestrate containers, and each can run those containers either on EC2 instances you manage or on AWS Fargate, which removes instance management entirely. Around this core sit convenience services — AWS Elastic Beanstalk (upload your code, AWS provisions the infrastructure), Amazon Lightsail (simple, low-cost virtual private servers with bundled pricing), and AWS Batch (runs large numbers of batch computing jobs) — plus two capabilities that make compute production-ready: auto scaling, which adjusts capacity to match demand, and Elastic Load Balancing, which distributes traffic across that capacity.

The single most useful axis is management responsibility. With EC2 you patch the guest OS, size the instance, and pay while it runs. With Lambda and Fargate there are no instances to see, patch, or right-size. When a question emphasizes phrases like "no server management", "focus on code, not infrastructure", or "minimal operational overhead", the answer moves toward the serverless end. When it emphasizes "full control of the operating system" or "custom software on the server", it moves toward EC2. Keep this axis in mind; every section below plugs into it.

Amazon Elastic Compute Cloud (Amazon EC2) provides resizable virtual servers — called instances — in the AWS Cloud. You choose an Amazon Machine Image (AMI) that defines the operating system and preinstalled software, pick an instance type that defines the CPU, memory, storage, and network profile, and launch. From that point you have administrative (root) access: you can install anything, tune the OS, and run the instance for as long as you like. That combination — full OS control plus long-running capacity — is EC2's identity on the exam.

Because you control the instance, you also carry more responsibility than with any other compute option. Under the shared responsibility model, you patch the guest operating system, manage the software you install, and decide when to scale. You pay for instances while they run (billing stops when you stop or terminate them), and you can change an instance's type to resize it as needs change. That flexibility makes EC2 the default answer for workloads that do not fit a more managed service: migrated (lift-and-shift) applications, software that needs a specific OS configuration, long-running application servers, and anything requiring specialized licensing or agents installed on the host.

Trigger phrases that point to EC2 include "complete control over the operating system", "choice of instance type", "install custom software on the server", and "long-running application with steady traffic". Conversely, if a question stresses that the team wants to avoid provisioning or managing servers altogether, EC2 is the distractor, not the answer. One boundary note: EC2 instances live inside your network environment (Amazon VPC) and across Availability Zones — the networking and global-infrastructure details belong to other task statements, so here you only need to know that EC2 capacity can be spread across multiple Availability Zones for resilience.

CLF-C02 does not test specific instance sizes or model numbers. It tests whether you can hear a workload description and name the right family. Learn the matching logic, not a catalog.

The exam's own examples are compute optimized and storage optimized, so give those two extra attention. The classic trap is confusing memory optimized with storage optimized: memory optimized means the dataset lives in RAM (in-memory database); storage optimized means the workload hammers fast local disks (data warehousing, distributed file systems). Read the question for whether the bottleneck is RAM or disk I/O, and the answer falls out. If no special need is stated at all, general purpose is the safe pick.

The second trap is the accelerator question. GPUs always mean accelerated computing. Compute optimized and HPC optimized instances get their speed from processors (and, for HPC optimized, fast networking between instances), not from GPUs, so a machine learning training job or a framework that needs GPUs belongs on accelerated computing instances, however long each run lasts. The HPC optimized family (instance types such as Hpc7a and Hpc7g) is a newer, specialist family; most CPU-heavy work at this level still points to compute optimized.

The exam guide states the skill plainly: recognize that auto scaling provides elasticity. Elasticity means capacity grows when demand grows and shrinks when demand falls — automatically, without a human forecasting or intervening. On AWS, the service that delivers this for virtual servers is Amazon EC2 Auto Scaling.

With EC2 Auto Scaling you define an Auto Scaling group: a collection of EC2 instances with a minimum, maximum, and desired count. Scaling policies watch demand signals such as average CPU utilization and add instances (scale out) when load rises, then remove them (scale in) when load drops. The group also performs health checks and automatically replaces instances that fail, which improves fault tolerance as a side benefit. The business payoff is the pairing the exam loves: performance during peaks, savings during troughs — you stop paying for idle capacity you provisioned "just in case".

One line of wider context: AWS Auto Scaling is an umbrella service that can manage scaling for several resource types beyond EC2 (for example, ECS services and DynamoDB throughput) from a single place — at this level you only need to recognize the name. Serverless options scale differently: Lambda scales automatically per request with no scaling group to configure, which is part of why it counts as serverless.

Trigger phrases that map to auto scaling: "automatically adjust capacity", "handle unpredictable or spiky traffic", "pay only for the capacity you need", "add and remove instances based on demand", and the word "elasticity" itself. If a question asks which AWS Cloud benefit auto scaling demonstrates, the answer is elasticity — not high availability, not agility, even though those sound plausible.

Elastic Load Balancing (ELB) automatically distributes incoming application traffic across multiple targets — such as EC2 instances, containers, or Lambda functions — and can spread those targets across multiple Availability Zones. Its purposes, as the exam frames them: increase availability and fault tolerance by ensuring no single target is overwhelmed and by routing around unhealthy ones, and present a single point of contact (one endpoint) for clients regardless of how many servers sit behind it.

Health checks are central to that story. The load balancer continuously probes its targets and stops sending traffic to any that fail, so users are shielded from individual server failures. Combined with targets in more than one Availability Zone, this is a foundational high-availability pattern at the Cloud Practitioner level.

Know the current types at recognition depth:

You may also see the Classic Load Balancer. It is the previous generation, kept for older applications; it is not the choice for new designs and is not built for the Network Load Balancer's scale of Layer 4 performance.

Now the classic pair confusion, which CLF-C02 tests directly: auto scaling adjusts capacity; load balancing distributes traffic. Auto scaling changes how many instances exist; a load balancer decides which existing instance receives each request. A load balancer never launches servers, and an Auto Scaling group never routes requests. In real architectures they work as a pair — the load balancer spreads traffic across whatever instances the Auto Scaling group currently maintains — but on the exam, match "distribute traffic" to ELB and "add or remove capacity" to auto scaling every time. When a requirement combines a traffic-distribution need with a capacity need, the answer combines the two services rather than picking one: the load balancer type is chosen by how it must route, and auto scaling supplies the changing number of targets behind it.

A container packages an application with its dependencies into a single portable unit that runs identically on a laptop, a test server, or the cloud. Containers start faster and pack more densely than virtual machines, but once you run many of them you need an orchestrator — software that decides where containers run, restarts failed ones, and scales them. AWS offers two managed orchestrators, and the exam wants you to tell them apart.

Amazon Elastic Container Service (Amazon ECS) is the AWS-native orchestrator. It is fully managed, deeply integrated with AWS services such as Elastic Load Balancing and IAM, and has no separate control-plane software for you to learn or operate. Choose ECS when a question describes a team that wants the simplest way to run containers on AWS and has no requirement for Kubernetes.

Amazon Elastic Kubernetes Service (Amazon EKS) is managed Kubernetes — AWS runs the Kubernetes control plane for you, and your workloads use standard Kubernetes APIs and tooling. Choose EKS when the question mentions Kubernetes by name, an existing investment in Kubernetes tooling, or a desire for portability of the orchestration layer across environments. That is the entire ECS-versus-EKS decision at this level: AWS-native simplicity (ECS) versus the Kubernetes standard (EKS).

Both orchestrators still need somewhere for the containers to execute — the capacity choice. The options run from most to least management:

If the question says "run containers without managing servers or clusters" or "no instances at all", the answer is Fargate; if it says the team needs control over the underlying container hosts, it is the EC2 launch type (or self-managed EKS nodes). The managed-instance options sit in between: less work than the EC2 launch type, but still EC2 instances in the account, which is why they are not "serverless". One-line neighbor to recognize: Amazon ECR (Elastic Container Registry) stores container images — it is a registry, not a compute service.

Serverless does not mean there are no servers — it means you never see, provision, patch, or scale them. AWS operates the fleet; you bring code or containers. CLF-C02 names two serverless compute options: AWS Lambda and AWS Fargate.

AWS Lambda runs your code as functions in response to events — an object landing in an S3 bucket, an HTTP request through API Gateway, a message on a queue, or a schedule. You upload the function, and Lambda handles everything else: it runs the code only when triggered, scales automatically from zero to thousands of parallel executions, and charges you per request and per unit of compute time consumed. When nothing invokes the function, you pay nothing for compute. That pay-per-use, scale-to-zero model describes Lambda's default compute. Since late 2025 Lambda also offers Lambda Managed Instances, which run functions on EC2 instances in your account and are billed at EC2 instance prices plus a management fee (Lambda request charges still apply) — a cost option for steady, high-volume functions, not the default. The trade-off is that Lambda is built for short-running tasks — a function execution is capped at minutes (15 at most), not hours — so it suits event handlers, file processing, lightweight APIs, and glue logic rather than long-lived processes.

That sets up the exam's favorite comparison, Lambda vs EC2. Choose Lambda when the question describes event-driven, intermittent, or short-duration work and stresses zero server management or pay-per-use billing ("run code only when a file is uploaded", "no infrastructure to manage"). Choose EC2 when the workload runs continuously for long periods, needs a full operating system, custom runtime software on the host, or execution beyond Lambda's short-task model. "A script that runs for a few seconds whenever an image is uploaded" is Lambda; "an application server that must run 24/7 with a customized OS" is EC2.

AWS Fargate is the serverless option for containers: it provides the compute engine underneath Amazon ECS or Amazon EKS so you run containers without managing EC2 instances. The quick rule is Lambda runs functions; Fargate runs containers — but packaging alone does not decide it, because a Lambda function can itself be packaged as a container image. The real difference is the execution model:

The general rule: long-lived container services with no hosts to manage belong on Fargate; short, event-triggered pieces of code belong on Lambda. Fargate also shows up underneath other services: AWS Batch can run jobs on Fargate capacity, but Batch is for finite jobs that start, finish and exit — not for a service that stays up. And Fargate is not an orchestrator itself; it is the serverless place where ECS- or EKS-managed containers execute.

Three more services appear in compute questions, and one line of recognition each is genuinely all CLF-C02 asks for — but that line has to be exact, because each service is a well-crafted distractor for the others.

AWS Elastic Beanstalk is a platform as a service (PaaS) for deploying web applications: you upload your code, and Elastic Beanstalk automatically handles the provisioning — EC2 instances, capacity, auto scaling, load balancing, and health monitoring — while you retain full visibility into, and control over, the underlying resources it creates. Because those resources live in your account, Beanstalk is a convenience layer rather than a lock-in: the environment’s configuration stays adjustable after launch. It supports several language platforms as well as Docker, so an application does not need to be containerized to use it. The trigger is a developer who wants to deploy code quickly without configuring infrastructure, using familiar servers underneath. Distinguish it from Lambda: Beanstalk deploys a whole, always-on application onto managed EC2 infrastructure; Lambda runs individual short functions. And from Fargate: Beanstalk's Docker support still runs on EC2 instances in your account, whereas Fargate has no instances at all. Beyond web servers, Beanstalk has a worker environment tier that processes background messages from an Amazon SQS queue — useful for background tasks, but it is not a batch job scheduler.

Amazon Lightsail offers simple virtual private servers (VPS) with everything bundled — compute, storage, networking, and a predictable low monthly price — plus one-click application blueprints such as WordPress. Its trigger words are "simple", "small project or website", "predictable monthly cost", and "minimal AWS experience". If a question describes a beginner launching a small blog with straightforward pricing, Lightsail beats EC2 even though both are virtual servers.

AWS Batch runs batch computing workloads at any scale: you submit jobs to a queue, and Batch plans, schedules, and provisions the right amount of compute — EC2 instances, Spot capacity or serverless Fargate capacity — to execute hundreds or thousands of them, then scales that compute down when the queue empties, so no fixed fleet sits idle between runs. Jobs can run for hours, which is why long-running jobs that would break Lambda's 15-minute limit point to Batch. The trigger is "large numbers of batch jobs" — think overnight financial risk calculations or scientific simulations — with no desire to manage job-scheduling infrastructure. Do not confuse the service AWS Batch with the instance family suited to CPU-heavy batch work (compute optimized); a question about picking an EC2 family for batch processing wants compute optimized, while a question about a managed service to schedule and run thousands of jobs wants AWS Batch.

Bring it together with the decision logic you will actually use in the exam room. Read the question for three signals — management appetite (who patches and scales?), duration and trigger (always-on, or event-driven and short?), and packaging (raw code, a container, or a whole application?) — then consult this map.

Now a realistic scenario. A media startup runs three workloads. First, whenever a user uploads a video, a short piece of code must generate a thumbnail — event-driven, seconds long, spiky: Lambda. Second, its main API is containerized, and the platform team already operates Kubernetes elsewhere and wants the same tooling without running a control plane — EKS, and because they refuse to manage worker instances, the containers run on Fargate. Third, its public website runs on virtual servers that must handle unpredictable evening traffic spikes: EC2 in an Auto Scaling group (elastic capacity) behind an Application Load Balancer (traffic distribution across Availability Zones). Every choice traces back to the three signals — practice reducing scenarios to those signals and Task 3.3 questions become mechanical.