AWS Compute Compared: EC2, ECS, EKS, Fargate, Lambda, App Runner
Fast recall
Quick revision
Core answer
Practical compute selection across workload patterns and operational maturity
Defaulting to EKS for everything (operational complexity), or sticking with EC2 because 'it's how we've always done it' when Fargate or Lambda would be simpler
Discuss the cost crossover (Lambda gets expensive past certain RPS), cold start trade-offs, vendor lock-in (Lambda is most locked-in), Spot vs On-Demand, and Graviton (ARM) for cost savings
Interview-ready guide
Interview answer
AWS gives you six main compute options. The choice depends on workload shape, your appetite for operational burden, and cost model. The spectrum runs from most-managed (Lambda) to most-control (EC2).
Lambda — event-driven, spiky, short
- You provide a function; AWS provides everything else — servers, scaling, patching
- Pay per invocation plus execution time; cheapest at low usage; gets expensive past sustained 1000+ RPS
- Limits: 15-minute max execution, 10GB memory, cold starts
- Java cold starts are the main pain — 1 to 3 seconds; mitigate with SnapStart (drops to ~200ms), provisioned concurrency (always warm but you pay for idle), or GraalVM native image
- Best for API Gateway endpoints with bursty traffic, S3 event triggers, scheduled tasks; not great for sustained high-RPS production APIs
App Runner — stateless web services, simplest container option
- Push a Dockerfile or image, AWS gives you an HTTPS URL with auto-scaling
- Lacks advanced features like VPC complexity, sidecars; outgrow it = migrate to Fargate
Fargate — serverless containers
- Containers running on ECS or EKS without managing the underlying EC2 instances
- Slight premium over EC2 but no node management; perfect when you want containers without K8s overhead
- Fargate Spot exists but is less cost-effective than EC2 Spot — if you need real Spot pricing, ECS on EC2 or EKS on EC2
ECS on EC2 — cost-optimized container fleet
- ECS orchestrator with EC2 instances you manage; capacity providers let you mix On-Demand and Spot
- Spot saves 50 to 90 percent for interruption-tolerant workloads; Graviton (ARM) instances 20 to 40 percent cheaper than x86
- Best when scale is high enough that the Fargate premium adds up
EKS — Kubernetes ecosystem, multi-cloud portability
- AWS-managed control plane at $0.10 per hour per cluster ($73 per month); you (or Fargate) run the data plane
- Standard K8s manifests run on GKE, AKS, on-prem — the portability story
- Best when you need K8s features (CRDs, Operators, service mesh) and have the ops to manage the complexity
- Anti-pattern: 5-engineer startup adopting EKS for 3 services; over-engineering
EC2 — raw VMs, full control
- The escape hatch — GPU workloads for ML, HPC, specialized hardware (FPGA, Inferentia), Windows GUI, software that doesn't containerize cleanly
- You manage everything — OS patches, AMIs, scaling, monitoring
The cost crossovers everyone misses
- Lambda is cheaper than Fargate at low utilization; the crossover is around 30 to 50 percent sustained utilization
- Fargate is easier than EC2 at low scale; EC2 wins on cost at high scale with Spot, Reserved, and Graviton
- EKS control plane at $73 per month per cluster — negligible at scale, significant for many small clusters
Vendor lock-in is real
- Lambda is the most locked-in — code calls AWS SDK directly, uses AWS-specific event payloads, integrates tightly with API Gateway; migration means rewriting dispatch
- EKS is the most portable — same K8s manifests run anywhere; the open-source standard
- Factor lock-in into long-term strategy alongside cost and ops burden
Default recommendation by stage
- Startup with bursty workloads: Lambda + App Runner; minimal ops, pay only when used
- Mid-size with steady workloads: Fargate or ECS on EC2; balance cost and ops
- Mature org with K8s expertise and multi-cloud goals: EKS
- Specialized needs: EC2 with the right instance type
AWS Compute Compared: EC2, ECS, EKS, Fargate, Lambda, App Runner
Direct Answer
Pick by workload shape, ops appetite, and cost model. Lambda for event-driven, short, spiky workloads (request-response under 15min, no warm-state). App Runner / Fargate for stateless containers without managing servers. ECS on EC2 when you want container orchestration with control over instances. EKS when you need Kubernetes ecosystem (multi-cloud portability, complex deployments). EC2 when you need full OS control, GPU/specialized hardware, or run software that doesn't containerize cleanly.
Common Mistakes & Pitfalls
Defaulting to EKS for everything (operational complexity), or sticking with EC2 because 'it's how we've always done it' when Fargate or Lambda would be simpler
Check your understanding
Answer these without looking back at the article.
- How does Lambda SnapStart reduce Java cold-start latency?
- What's the cost crossover between Lambda and Fargate for a constantly-busy API?
- When is EKS justified over ECS for a single-cloud team?
- What are AWS Compute Savings Plans and how do they differ from Reserved Instances?
Related interview prep categories
1Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.