AWS Compute: picking the right engine for your workload
AWS Compute: picking the right engine for your workload
Series: AWS Field Guide · Part 1 of 6 — Compute This series: 01 — Overview · 02 — EC2 · 03 — Lambda · 04 — ECS & Fargate · 05 — EKS · 06 — Wrap-up
The scenario
Your team just greenlit a new service. It needs to run code. Someone opens the AWS console and immediately hits a wall: EC2, Lambda, ECS, Fargate, EKS, Elastic Beanstalk, Lightsail, App Runner, Batch...
Four services cover 90% of real-world workloads. The rest is noise — for now.
This article is the map. It won't go deep on any one service — that's what the next four articles are for. What it will do is give you a clear mental model for when each one makes sense, so that by the time you read the deep dives, you already know which one you're rooting for.
TL;DR: AWS has four main compute services worth knowing — EC2 (virtual machines), Lambda (functions), ECS/Fargate (managed containers), and EKS (Kubernetes). They're not interchangeable. Pick the wrong one and you'll either overpay, over-engineer, or spend your weekends managing infrastructure that should manage itself.
The four engines
EC2 — a computer in the cloud
EC2 is the foundation. It gives you a virtual machine: pick an OS, pick a size, and you have a server you control completely. You install software, manage updates, handle scaling, and pay by the hour (or second).
Everything else in this list is, at some level, an abstraction built on top of EC2. Understanding EC2 makes the other three make sense.
Best mental model: a rented server in a data centre — except you can get one in 60 seconds and return it when you're done.
Lambda — just the function
Lambda flips the model. You don't provision a server. You upload a function, attach a trigger (an HTTP request, an S3 upload, a scheduled event), and AWS runs it when needed. You pay only for the milliseconds it actually executes.
The tradeoff: Lambda has sharp edges. Functions can only run for up to 15 minutes. Cold starts add latency when a function hasn't been invoked recently. And anything stateful — long-running processes, websockets, background workers — is awkward or impossible.
Best mental model: a vending machine. Put in a request, get back a result. No machine to maintain. But it can only make what the machine is built for.
ECS + Fargate — containers without the cluster admin
ECS (Elastic Container Service) runs Docker containers on AWS. Fargate is the launch type that removes the need to manage the underlying EC2 instances — AWS handles the servers; you just define your container and how many copies you want running.
This is the sweet spot for teams already using Docker who want to deploy without becoming Kubernetes experts. You get the portability of containers, the reliability of a managed service, and a billing model that scales with usage.
Best mental model: a managed fleet of delivery vans. You load the cargo (your container image). AWS drives the vans, maintains the fleet, and scales up when demand spikes.
EKS — Kubernetes, fully managed
EKS (Elastic Kubernetes Service) gives you a managed Kubernetes control plane on AWS. If your team is already running Kubernetes or your workload genuinely needs what Kubernetes offers — advanced scheduling, custom operators, multi-cluster federation — EKS is the right choice.
The honest caveat: EKS is powerful and complex. The managed control plane removes some of the operational burden, but you're still responsible for node groups, networking, add-ons, and upgrades. Don't reach for EKS because it sounds impressive. Reach for it when ECS isn't enough.
Best mental model: hiring a professional logistics company that lets you write your own routing algorithms. Maximum control, but you need to know what you're doing.
The decision framework
Here's the one-page version. Use this when a new workload lands on your desk:
Is it a short, stateless task (< 15 min, event-driven)?
└─ Yes → Lambda
Does your team use Docker and want minimal ops overhead?
└─ Yes, and Kubernetes isn't needed → ECS + Fargate
└─ Yes, and you need Kubernetes specifically → EKS
Do you need full control over the OS, long-running processes,
GPU access, or specialised hardware?
└─ Yes → EC2
In practice, most products use a combination. A typical architecture might have EC2 for a stateful background worker, Lambda for event-driven processing, and ECS for the core API. The goal isn't to pick one — it's to know which fits each job.
Side-by-side comparison
| EC2 | Lambda | ECS + Fargate | EKS | |
|---|---|---|---|---|
| Unit of work | VM instance | Function invocation | Container task | Pod |
| You manage | OS, runtime, scaling | Just the code | Container image, task config | Workloads, node groups |
| Startup time | Minutes | Milliseconds–seconds | Seconds | Seconds–minutes |
| Max run time | Indefinite | 15 minutes | Indefinite | Indefinite |
| Pricing model | Per second (instance size) | Per invocation + duration | Per vCPU/memory (task) | Control plane + nodes |
| Kubernetes | No | No | No | Yes |
| Best for | Full control, legacy apps | Event-driven, short tasks | Containerised APIs & workers | Complex container orchestration |
What about the others?
AWS has a long tail of compute services. Here's a quick orientation so they don't cause confusion:
Elastic Beanstalk — a Platform-as-a-Service wrapper around EC2. Handles deployment and scaling for you. Fine for simple apps, but limited flexibility and rarely used for new projects.
App Runner — a newer, simpler way to run containers directly from a source repo or image. Less configurable than ECS but faster to get started. Worth knowing for small internal tools.
AWS Batch — designed specifically for large-scale batch processing jobs. Think ETL pipelines, scientific computing, or nightly data processing. It's EC2 under the hood, scheduled and managed for you.
Lightsail — simplified VPS hosting aimed at developers who want something closer to a traditional web host. Good for simple WordPress sites or tiny projects. Not for production backend services.
For the rest of this series, we're ignoring these. They're either niche, deprecated in spirit, or a thin wrapper over one of the core four.
Common gotchas at this stage
Jumping to Lambda for everything. Serverless is fashionable. It's also genuinely great — for the right workloads. Teams that default to Lambda for their entire backend eventually hit the concurrency limits, 15-minute timeout, and cold start problems in production.
Picking EKS because "we might need it later." EKS is operationally heavy. If you're a team of five running a single API, ECS + Fargate will serve you until you're fifty engineers. Premature Kubernetes adoption is a real thing.
Underestimating EC2 networking costs. Data transfer between EC2 instances in different availability zones isn't free. Teams used to running everything on a single machine are often surprised by their first bill.
Key takeaways
EC2 is the foundation — a virtual machine you fully control, billed by the second.
Lambda is for short, stateless, event-driven tasks — the lowest ops overhead of any option.
ECS + Fargate is the pragmatic container choice — Docker without Kubernetes complexity.
EKS is for teams who specifically need Kubernetes — powerful, but carries real operational weight.
Most real architectures combine two or more of these. Know the tradeoffs, not just the names.
Up next
Part 2 → AWS EC2: the workhorse you should understand before anything else
We go deep on EC2 — instance types, AMIs, pricing models (and the On-demand vs Reserved vs Spot decision that trips up most teams on their first AWS bill).
Part of the AWS Field Guide series. Tags: #aws #cloud #compute #devops #aws-field-guide
