principlejavascriptTip
ECS vs EKS vs Lambda: choosing the right compute for your workload
Viewed 0 times
ECS FargateEKSLambdacompute selectionserverlesscontainersworkload fitFargate vs Lambda
Problem
Teams default to Lambda for all serverless work or default to EKS because they know Kubernetes, without considering cost, operational complexity, and workload fit.
Solution
Use Lambda for event-driven, short-duration (<15 min), stateless functions with spiky or unpredictable traffic. Use ECS Fargate for long-running services, background workers, or apps that need more than 10GB memory or custom runtimes. Use EKS when you need Kubernetes-native tooling, complex scheduling, or multi-cloud portability.
Why
Lambda has zero idle cost but charges per invocation and duration. ECS Fargate charges per vCPU/memory second while tasks are running. EKS adds Kubernetes control plane cost ($0.10/hour) and requires more operational investment. Wrong choice leads to over-spending or over-engineering.
Gotchas
- Lambda max timeout is 15 minutes — use ECS for long batch jobs
- Lambda max memory is 10GB and max ephemeral storage is 10GB — ECS has no such limits
- ECS Fargate cold start (task launch) takes 30-60 seconds — not suitable for real-time event handling
- EKS requires deep Kubernetes knowledge for operations — do not use it just because you heard of it
- Graviton (arm64) is available for Lambda, ECS, and EKS — use it for 20-34% better price/performance
Context
Choosing AWS compute service for new application components
Revisions (0)
No revisions yet.