AWS Lambda vs Fargate vs ECS vs EKS: Serverless and Container Compute Compared

AWS Lambda runs individual functions in response to events with no servers to manage at all, while AWS Fargate runs containers without requiring you to manage the underlying virtual machines. Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS) are the orchestrators that decide where and how those containers run, and each can place containers either on Amazon EC2 instances you manage or on Fargate capacity that AWS manages. The CLF-C02 exam tests whether you can match a workload description to the right layer of this stack.

The compute spectrum: how much do you want to manage?

AWS compute options sit on a spectrum of operational responsibility. At one end, Amazon Elastic Compute Cloud (EC2) gives you a virtual server where you patch the operating system, size the instance, and scale the fleet yourself. At the other end, Lambda hands AWS everything except your code. Containers sit in the middle, and the ECS, EKS, and Fargate combination determines exactly where in that middle you land.

A container packages an application together with its dependencies so it runs identically anywhere. Containers alone are not enough for production, though: something has to start them, restart them when they fail, spread them across machines, and scale them. That “something” is an orchestrator, and AWS offers two.

• Amazon ECS is the AWS-native orchestrator. It is deeply integrated with AWS services, has a gentler learning curve, and uses AWS-specific concepts (task definitions, services, clusters).
• Amazon EKS is managed Kubernetes. AWS runs the Kubernetes control plane for you, and your teams use standard Kubernetes tooling. EKS is the answer when a scenario mentions Kubernetes by name, an existing Kubernetes investment, or portability across on-premises and cloud.

Both orchestrators need compute capacity to place containers on, and that is where launch types come in.

Launch types: EC2 vs Fargate

Both ECS and EKS support two launch types. With the EC2 launch type, you provision and manage a fleet of EC2 instances that serve as the cluster’s worker capacity. You choose instance sizes, patch the hosts, and pay for the instances whether containers are running or not. With the Fargate launch type, you specify the CPU and memory each containerized task needs and AWS provisions the underlying capacity invisibly. There are no instances to see, patch, or right-size, and you pay for the vCPU and memory your tasks actually request while they run.

This is why AWS calls Fargate a “serverless compute engine for containers.” Fargate is not an orchestrator and it is not something you use by itself: it is the capacity option underneath ECS or EKS. When an exam question says “run containers without provisioning or managing servers,” the answer is Fargate. When it says “orchestrate containers” or “manage a Kubernetes cluster,” the answer is ECS or EKS.

One more container service rounds out the family: Amazon Elastic Container Registry (ECR) stores, versions, and serves container images. It does not run anything. A question about “where to store Docker images” points to ECR every time.

Where AWS Lambda fits

AWS Lambda is Function as a Service (FaaS): you upload code, and Lambda runs it in response to events such as an object landing in an Amazon S3 bucket, an HTTP request through Amazon API Gateway, a message arriving in a queue, or a schedule firing. You never see the execution environment. Lambda scales automatically from zero to thousands of concurrent executions and back to zero, and billing is based on the number of requests plus the compute duration consumed, metered in milliseconds. When your code is not running, you pay nothing for compute.

The tradeoff is the execution model. Lambda functions are short-lived (executions are capped at 15 minutes), event-driven, and stateless. A long-running web server, a process that must hold state in memory, or an application that needs a full custom runtime environment is a poor fit for Lambda and a natural fit for containers. Conversely, a small piece of glue logic that fires when something happens (resize an uploaded image, process a record, respond to an API call) is exactly what Lambda was built for.

It also helps to know where AWS Elastic Beanstalk sits, because the exam likes to include it as a distractor. Elastic Beanstalk is a Platform as a Service (PaaS) layer: you upload application code and it provisions and manages the EC2 instances, load balancing, and scaling on your behalf, while still letting you retain control of the underlying resources. It is convenience on top of servers, not serverless.

Side-by-side comparison

Service	What it is	You manage	Billing basis
Lambda	Serverless function execution	Code only	Requests + duration (ms)
Fargate	Serverless capacity for containers	Container images and task sizing	vCPU + memory per running task
ECS	AWS-native container orchestrator	Tasks/services; hosts only if EC2 launch type	Free itself; you pay for capacity
EKS	Managed Kubernetes control plane	Kubernetes workloads; nodes only if EC2 launch type	Cluster fee + capacity

Note the pattern in the last column: the orchestrators are the brains, and the money mostly follows the capacity (EC2 instances or Fargate tasks) underneath them. If you want the fuller picture of instance families and purchasing options on the EC2 side, see EC2 instance types and purchasing options.

How the CLF-C02 exam tests this

• A scenario describes code that must run “only when triggered” or “without provisioning any infrastructure,” often with sporadic traffic, and asks for the most cost-effective compute. The answer is Lambda, because it bills per request and scales to zero.
• A scenario says a company runs Docker containers and wants to stop patching and managing the EC2 instances underneath them. The answer is Fargate, the serverless launch type, not a different orchestrator.
• A scenario mentions Kubernetes explicitly (existing Kubernetes skills, kubectl, portability with an on-premises Kubernetes deployment) and asks for the managed AWS service. The answer is EKS. If Kubernetes is not mentioned and the company wants the simplest AWS-integrated orchestration, ECS is the better fit.
• A scenario asks where to store and version container images before deployment. The answer is ECR, and the exam expects you not to confuse the registry with the services that actually run containers.

Quick reference

• Lambda: run code as event-driven functions, 15-minute execution cap, pay per request and per millisecond of duration, scales to zero.
• Fargate: serverless compute engine for containers; removes EC2 host management; used through ECS or EKS, never alone.
• ECS: AWS-native container orchestrator; simplest path if you are not committed to Kubernetes.
• EKS: managed Kubernetes; choose it when the question names Kubernetes or portability of Kubernetes workloads.
• ECR: managed container image registry; stores images, runs nothing.
• Elastic Beanstalk: PaaS that deploys and manages the infrastructure for your application code; you keep visibility into the EC2 resources.
• Both ECS and EKS offer a choice of EC2 launch type (you manage hosts) or Fargate (AWS manages hosts).