EC2 vs Lambda vs Containers: Picking a Compute Model
Compute questions describe workload shape — duration, traffic pattern, control requirements — and expect the fitting platform. Think of a spectrum: EC2 = maximum control, containers = packaged services without VM management, Lambda = pure event-driven code.
EC2 — full control
Choose EC2 when the workload needs OS-level access: custom kernels, specific AMIs, licensing tied to hardware, GPUs, or persistent instance state. It suits steady, predictable, long-running services. You own patching, scaling, and capacity.
Lambda — zero-ops functions
Choose Lambda for event-driven, short-lived work (under 15 minutes): S3 triggers, stream processing, API backends, scheduled jobs. It scales automatically from zero and bills per request — cheapest for intermittent traffic. It cannot run kernel modules and cold starts matter for ultra-latency-sensitive paths.
ECS/EKS on Fargate — containers
Choose containers when you need to package an application and its dependencies but want longer-running processes, custom runtimes, or orchestration without managing servers (Fargate) or with managed nodes. ECS is AWS-native and simpler; EKS is managed Kubernetes for teams needing Kubernetes APIs/ecosystem.
Exam shortcuts
- 'Event-driven, seconds-long, bursty' → Lambda
- 'Full OS control / custom kernel / licensing' → EC2
- 'Long-running microservice, packaged app, Kubernetes requirement' → ECS/EKS on Fargate
- 'Batch of thousands of parallel interruptible jobs' → Spot + AWS Batch