Fargate vs Lambda: Containers or Functions?
Fargate runs serverless containers with no time limit; Lambda runs short-lived serverless functions billed per invocation and duration.
Lambda excels at event-driven, short-lived workloads with per-request billing and near-zero idle cost, but caps execution time and package size. Fargate runs long-lived containers (with ECS or EKS) for steady or long-running services without managing servers, using your existing container images. Lambda favors bursty event workloads; Fargate favors persistent containerized services.
| Fargate | Lambda | |
|---|---|---|
| Unit | Container task | Function |
| Duration | No hard limit | Up to 15 min |
| Billing | vCPU/memory per second | Per request + duration |
| Cold start | Task startup | Fast, mitigable |
| Best for | Long-running services | Bursty event-driven |
Use case and cost
Lambda fits APIs, event processing, and spiky traffic where you pay only when running. Fargate fits services that run continuously, exceed Lambda limits, or already ship as containers. For steady high utilization, Fargate (or EC2) often costs less; for bursty or idle-heavy workloads, Lambda wins.
In CI and deploy
Lambda deploys via zip/container images; Fargate via image pushes to ECR plus task-definition updates, all from CI with OIDC. Either deploys from managed runners, where faster runners shorten packaging, image builds, and rollouts.
The verdict
Short-lived, event-driven, or spiky workloads with near-zero idle cost: Lambda. Long-running, container-based services or anything past Lambda limits: Fargate. Many architectures mix both - Lambda for events and glue, Fargate for persistent services.