Compute Options: Lambda vs EC2 vs ECS/Fargate

The plain-language idea

Every AWS compute option sits somewhere on a single spectrum: how much infrastructure do you manage versus how much control do you have over it?

• Lambda — you provide only a function. AWS handles the server, scaling, and patching entirely; you're billed per invocation and per millisecond of execution. No control over the underlying machine at all — and a hard execution time limit (15 minutes maximum) that rules it out for long-running work.
• EC2 — a virtual machine you fully control: OS, installed software, networking, everything. Maximum control, and maximum responsibility — you patch it, you scale it (or wire up Auto Scaling yourself), you pay for it whether it's busy or idle.
• ECS/Fargate — containers (the same Docker images from this platform's Docker track) running without managing the underlying servers. Fargate specifically removes even the "which EC2 instances back this" question — you specify a container and its resource needs, AWS runs it. A middle ground: more control than Lambda (a real, persistent process, no 15-minute cap), less operational burden than raw EC2.

See it in a real thing: the same API, three ways

Lambda: no server to manage at all, billed per invocation, a hard 15-minute execution cap.

BackNext

An API endpoint that resizes an uploaded image could run as:

• A Lambda function triggered by an S3 upload event — ideal if resizing takes seconds and traffic is spiky (pay only when it actually runs, scales to zero when idle).
• A container on Fargate behind a load balancer — better if the service needs to stay warm (no cold starts), run longer than 15 minutes, or is one service among several sharing infrastructure patterns from this platform's own Docker orchestration lesson.
• An EC2 instance running a custom image-processing daemon — makes sense only if it needs something Lambda and Fargate can't offer, like a specific GPU, a licensed piece of software with unusual installation requirements, or extremely fine-grained OS-level tuning.

What people usually miss

Watch out

• Lambda's 15-minute execution limit is a hard cap, not a soft default. A workload that occasionally runs long — a large batch job, a slow third-party API call under bad conditions — needs a fundamentally different compute option, not a longer timeout setting, because no such setting exists past that ceiling.
• "Serverless" never means "no server" — it means "not your server to manage." Lambda functions still run on real EC2 instances underneath, owned and operated by AWS. The name describes who's responsible for the server, not whether one exists.
• Fargate and "ECS on EC2" are two different things people conflate. ECS is the orchestration layer (deciding what runs where — the same job this platform's Docker track covers generically); Fargate is one way to supply the underlying compute for ECS, without managing EC2 instances yourself. ECS can also run on EC2 instances you do manage — the orchestrator and the compute layer are separate choices.
• Cold starts apply to Lambda, not meaningfully to EC2 or long-running Fargate tasks. A persistent process (EC2, or a Fargate service that's always running) has no equivalent to a Lambda cold start, since it never fully stops between requests — this is a real, concrete latency tradeoff, not just an operational one.

Why this matters in interviews

"Would you use Lambda or a container for this?" tests whether a candidate reasons from the workload's actual shape — traffic pattern, execution duration, cost at scale — rather than defaulting to whichever option is trendiest. Naming the specific tradeoff (spiky and short vs. sustained and long-running) is a stronger answer than a blanket preference for either.