Lambda vs ECS in AWS
Lambda and ECS Fargate both eliminate server management, but they solve different problems. Lambda is a function execution service — short-lived, event-triggered, and stateless. ECS runs containers as long-running services or one-off tasks with no execution time ceiling. The choice between them often comes down to a single question: does your workload fit in 15 minutes?
What each service actually is
Lambda is a function execution service. You write a handler function, attach it to an event source (API Gateway, SQS, S3, EventBridge, etc.), and AWS runs it when the event fires. Each invocation is isolated — your function starts, handles the event, and stops. Lambda manages compute, scaling, and infrastructure entirely. You pay per invocation and per GB-second of execution time.
ECS (Elastic Container Service) is a container orchestration service. You package your application in a Docker image, define how much CPU and memory it needs in a task definition, and ECS runs it as a service (continuously, with load balancing) or as a one-off task (starts, runs, stops). With Fargate, you don’t manage EC2 instances — AWS handles the underlying compute. You pay per vCPU-hour and memory-hour while the container is running.
The fundamental difference: Lambda runs code in response to events. ECS runs containers as services or tasks with full control over execution time.
Lambda vs ECS Fargate comparison
| Dimension | Lambda | ECS Fargate |
|---|---|---|
| Maximum execution time | 15 minutes (hard limit) | No limit |
| Cold start | Yes — 100ms–3s for first invocation | Minimal — containers start in seconds and stay running |
| Pricing model | Per invocation + per GB-second | Per vCPU-hour + per GB-hour while running |
| Idle cost | Zero — you pay only when code runs | Full price even when handling no traffic |
| Scaling | Automatic — no configuration needed | Manual or via Application Auto Scaling |
| Persistent connections | Not supported (WebSockets, DB connection pools) | Fully supported |
| Max memory | 10 GB | 120 GB (Fargate supports up to 120 GB for some configurations) |
| Deployment unit | ZIP archive or container image | Docker container image |
| Event-driven triggers | Native — SQS, S3, DynamoDB Streams, EventBridge | Via external integration (ECS tasks triggered by EventBridge) |
When Lambda is the right choice
Webhook handlers and API callbacks. An incoming webhook from Stripe, GitHub, or Twilio triggers a Lambda function. The function runs in under a second, processes the event, writes to a database, and returns a 200 response. There’s nothing to keep running between webhooks. Lambda’s per-invocation pricing means you pay nearly nothing for this workload.
Event-driven data processing. A file uploaded to S3 triggers Lambda to resize it, extract metadata, and write results to DynamoDB. A message arrives in SQS and Lambda processes it. These patterns are Lambda’s core use case — each event triggers exactly one invocation, scales to however many events arrive simultaneously, and costs nothing when idle.
Scheduled jobs under 15 minutes. Daily email digests, hourly metric aggregation, nightly cleanup tasks — if these complete in under 15 minutes, Lambda with EventBridge Scheduler is simpler and cheaper than an ECS task.
Variable or unpredictable traffic. Lambda scales to zero at night and to thousands of concurrent invocations during a traffic spike with no configuration. An ECS service running at low traffic still incurs compute costs. For workloads with significant idle time, Lambda’s zero-idle-cost model is a real advantage.
See Lambda scaling for how Lambda manages concurrent execution and reserved capacity.
When ECS Fargate is the right choice
Workloads over 15 minutes. Lambda’s hard 15-minute limit is the most common reason to move to ECS. A video transcoding job, a large data export, a model training pipeline, a web scraper running against hundreds of URLs — anything with an uncertain or long execution time belongs on ECS Fargate tasks.
Persistent HTTP services. A REST API or GraphQL server that needs to maintain database connection pools, hold in-memory caches, and handle persistent WebSocket connections runs better as an ECS service behind an ALB. Lambda can serve HTTP, but each invocation is isolated — no shared connection pool, no in-memory cache that persists across requests.
WebSocket servers. Lambda doesn’t support persistent WebSocket connections directly. You can work around this with API Gateway WebSocket APIs + Lambda, but the complexity is significant. An ECS container running a WebSocket server (Socket.IO, ws, etc.) handles this naturally with persistent TCP connections.
Consistent latency requirements. ECS containers are always running — no cold starts. For latency-sensitive paths where even a 500ms cold start is unacceptable, ECS (or Lambda Provisioned Concurrency) is necessary. ECS is simpler for this scenario.
Applications that are already containerized. If your application is a Docker container (web server, background worker, whatever), deploying it to ECS Fargate requires almost no code changes. Adapting it to Lambda may require significant refactoring. The path of least resistance for existing containerized apps is ECS.
Real scenario: video processing that breaks Lambda
A team builds a video processing pipeline. When a user uploads a video to S3, the processing should start automatically. The team naturally reaches for Lambda — it’s the standard S3 trigger pattern.
The Lambda function downloads the video from S3 to /tmp, runs ffmpeg to transcode it, and uploads the result. For short videos (under 2 minutes), this works fine in under 15 minutes.
Three months later, users start uploading 1-hour presentations. The Lambda function hits the 15-minute timeout and fails. The /tmp directory also fills up — 1-hour videos are often over 1 GB before encoding.
The fix: ECS Fargate task triggered by EventBridge Pipe or a Lambda kickoff function.
When a video is uploaded to S3, a small Lambda function (which runs in under a second) creates an ECS Fargate task passing the S3 key as an environment variable. The ECS task container downloads the video, processes it for however long it takes, and uploads the result. No time limit. The Lambda function just needs to start the task — it doesn’t do the work.
This is the correct pattern: Lambda as an orchestrator, ECS as the executor for heavy workloads.
Decision matrix: workload type to service
| Workload type | Use Lambda | Use ECS Fargate |
|---|---|---|
| Webhook handler | Yes — runs in milliseconds | Overkill |
| REST API, moderate traffic | Yes — stateless, cost-effective | Valid if you need persistent connections |
| REST API, high traffic | Yes, but compare costs | Yes — no per-invocation cost at high volume |
| Scheduled job, under 15 min | Yes | Valid but more complex setup |
| Scheduled job, over 15 min | No — time limit | Yes — scheduled ECS task |
| Video/file processing | Only if small and fast | Yes — no time or storage limit |
| WebSocket server | Workaround required | Yes — native persistent connections |
| ML inference (model in memory) | Only with Provisioned Concurrency | Yes — model loaded once, reused |
| Idle most of the time | Yes — zero idle cost | No — Fargate charges while running |
Quick decision guide
- Choose Lambda if: your workload runs in under 15 minutes, is event-triggered, is stateless, and has significant idle time where zero-cost matters.
- Choose ECS Fargate if: your workload runs longer than 15 minutes, needs persistent connections, is already a Docker container, or serves sustained traffic where idle cost is acceptable.
- Hybrid pattern: use Lambda to trigger ECS tasks for heavy workloads — Lambda handles the event/orchestration; ECS does the long-running work.
- For long-running APIs: ECS Fargate beats Lambda for WebSocket servers and services with database connection pooling needs.
Frequently asked questions
What is ECS Fargate?
ECS (Elastic Container Service) is AWS's managed container orchestration service. Fargate is the serverless compute engine for ECS — instead of managing EC2 instances, you define a task (a Docker container with CPU/memory requirements) and AWS runs it on managed infrastructure. You pay per vCPU and memory per second, with no EC2 instances to provision or patch.
When should I use ECS instead of Lambda?
Use ECS when your workload runs longer than 15 minutes, needs persistent connections (WebSockets), requires more than 10 GB of memory or 6 vCPUs, or is a long-running service rather than an event-triggered function. ECS is also better for workloads where cold starts are unacceptable and you can't use Provisioned Concurrency.
Can ECS Fargate run on a schedule like Lambda?
Yes. You can trigger ECS tasks on a schedule using EventBridge Scheduler (formerly CloudWatch Events). A scheduled ECS task starts a container, runs to completion, and stops — similar to a Lambda function but without the 15-minute limit. This is the right pattern for long-running scheduled jobs.