EC2, ECS, EKS and Lambda compared honestly

AWS gives you several ways to run your code — EC2, ECS, EKS, Lambda — and choosing wrongly is expensive, in both money and complexity. Most teams over-choose: they reach for Kubernetes because it is fashionable, when a simpler option would serve them better for years. This lesson is an honest comparison of the compute options, so you can match the tool to the workload rather than to the hype. It opens the compute module, and the honesty is deliberate — the next lesson is specifically about when Kubernetes is the wrong answer.

The spectrum: from most control to least management

The compute options form a spectrum, trading control against how much you have to manage:

EC2 (virtual machines) — you rent virtual servers and run whatever you like on them. Maximum control and flexibility; you manage the OS, patching, scaling, and everything on the machine. It is the lowest-level option and the most operational work.
ECS (Elastic Container Service) — AWS's own container orchestrator. You give it containers and it runs them across your infrastructure. Simpler than Kubernetes, deeply integrated with AWS, less to manage.
EKS (managed Kubernetes) — Kubernetes (the DevOps Foundation module) as a managed service. Maximum portability and ecosystem, but the full complexity of Kubernetes to operate.
Lambda (serverless functions) — you give AWS a function; it runs on demand, scales automatically, and you pay only per invocation. No servers to manage at all; the least operational work, but a specific programming model and constraints.

As you move down that list you generally do less server management and get more AWS abstraction — but you also trade away some control and portability. The art is picking the right point for the workload, not the lowest or the trendiest.

What each is good for

Matching workload to option:

EC2 — when you need full control of the machine: specialised software, unusual OS configuration, GPU workloads, a legacy app that expects a real server, or fine-grained performance tuning. Also the substrate the others often run on. The cost is that you run and patch the servers.
ECS (especially on Fargate) — the pragmatic default for running containers on AWS when you do not need Kubernetes. It runs your containers, integrates natively with AWS (load balancers, IAM, logging), and is far simpler to operate than EKS. For most teams shipping containerised services, ECS on Fargate is the lowest-effort way to production, and the next lesson makes this case.
EKS — when you genuinely need Kubernetes: multi-cloud portability, the Kubernetes ecosystem (Helm, operators, a particular tool), an existing Kubernetes investment or team expertise, or complex orchestration that Kubernetes does well. Powerful, but you take on Kubernetes' operational complexity (the whole EKS module is about doing this well).
Lambda — for event-driven and spiky workloads: responding to events (a file uploaded, a queue message, an API request), scheduled jobs, glue between services, and anything with variable or low-and-bursty traffic where paying per-invocation beats paying for idle servers. Not for long-running processes or workloads needing lots of memory/CPU for sustained periods.

The honest summary: EC2 for full control, ECS/Fargate for straightforward containers, EKS when you truly need Kubernetes, Lambda for event-driven work. Most web/API services are well served by ECS/Fargate or EKS; Lambda excels at the event-driven edges.

Managed vs self-managed, and Fargate

A cross-cutting choice is how much of the underlying infrastructure AWS manages:

With plain EC2, you manage the servers.
With ECS or EKS on EC2 nodes, you still manage the pool of EC2 instances the containers run on (patching, scaling the node pool).
With Fargate — AWS's serverless container compute — you give ECS or EKS your containers and AWS runs them with no EC2 instances for you to manage at all. You specify CPU and memory per task; AWS handles the servers underneath.

Fargate is a big simplification: it removes the "manage a fleet of EC2 nodes" work from running containers. The trade-off is a slightly higher per-unit compute cost than running your own tightly-packed EC2 nodes, in exchange for eliminating node management. For many teams — especially smaller ones — Fargate's operational saving is well worth it; for large, steady, cost-sensitive fleets, self-managed EC2 nodes packed efficiently can be cheaper. This is a real cost-vs-effort trade-off (the cost-of-compute lesson returns to it).

How to choose: match the workload, resist the hype

A decision approach that keeps you honest:

Is it event-driven or spiky? → consider Lambda (pay per use, no idle cost).
Is it a containerised service, and do you need Kubernetes specifically?
- No → ECS on Fargate (simplest path to production containers on AWS).
- Yes (portability, ecosystem, existing K8s) → EKS.
Do you need full control of the machine, or have non-container workloads? → EC2.
Default to the simplest option that fits, not the most powerful. Every layer of capability you take on is operational work you must sustain.

The recurring theme — and the reason this module leads with it — is that teams routinely choose more complexity than they need, usually Kubernetes, because it is what everyone talks about. The disciplined choice is the simplest option that meets the real requirement, because complexity you do not need is a cost you pay forever in operations, cognitive load and money. Choose compute the way you choose everything else in this course: for the workload in front of you, with cost and effort as first-class concerns.

Check your work

The spectrum (control ↔ management): EC2 (full control, you manage everything — most work), ECS (AWS container orchestrator, simpler, AWS-integrated), EKS (managed Kubernetes — portable/powerful, full K8s complexity), Lambda (serverless functions, per-invocation, no servers — least work, specific model). Down the list = less management, more abstraction, less control/portability.

Good for: EC2 = full machine control / legacy / GPU; ECS/Fargate = the pragmatic default for containers when you don't need K8s; EKS = when you genuinely need Kubernetes (portability, ecosystem, expertise); Lambda = event-driven/spiky/scheduled work.

Managed vs self-managed: EC2 nodes = you manage the fleet; Fargate = serverless containers, no EC2 to manage (slightly higher per-unit cost for big saving in effort; self-managed EC2 nodes cheaper at large steady scale).

Choosing: event-driven → Lambda; container + need K8s? no → ECS/Fargate, yes → EKS; full machine control → EC2. Default to the simplest option that fits, resist the hype — unneeded complexity is a forever cost.

Practice

Place EC2, ECS, EKS and Lambda on the control-vs-management spectrum and describe the trade-off.
For four workloads (a spiky event handler, a standard containerised API, a multi-cloud platform, a GPU job), pick a compute option and justify it.
Explain what Fargate removes and the cost-vs-effort trade-off versus self-managed EC2 nodes.
Explain why ECS on Fargate is often the pragmatic default for containers on AWS.
Walk through the decision approach for a new containerised service and reach a recommendation.
Explain why "default to the simplest option that fits" matters, in terms of ongoing operational cost.

Official documentation

AWS — Compute services overview — EC2, ECS, EKS, Lambda and Fargate at a glance.
AWS — Choosing an AWS container service — ECS vs EKS vs Fargate decision guide.
AWS Lambda — When to use — What serverless functions are for.

Next: when Kubernetes is not worth it.