AWS Lambda vs ECS: which compute model is right for your workload?

When to choose Lambda vs ECS

That's the generic picture. Your traffic pattern, cold start tolerance, and execution duration will tip this one way or the other. ↓

Lambda vs ECS: cold starts in production, the real numbers

Cold start latency is the most misunderstood dimension of the Lambda vs ECS decision. A cold start occurs when Lambda needs to initialize a new execution environment, provisioning compute, downloading your deployment package, starting the runtime, and executing your initialization code outside the handler. The duration depends heavily on runtime, package size, and network configuration.

By runtime, typical cold start times break down as follows: Node.js functions cold start in 100–500ms; Python in 100–400ms; Go in 50–200ms (the fastest native runtime); Java without SnapStart in 1–5 seconds (the heaviest JVM initialization). These figures assume a small to medium deployment package deployed as a zip archive, no VPC attachment, and a function that hasn't been idle for more than 15 minutes.

VPC attachment historically added a significant cold start penalty, 1–10 additional seconds, because Lambda needed to provision an elastic network interface. AWS addressed this in 2019 with Hyperplane ENIs, which pre-provision and cache network interfaces across functions. The penalty today is roughly 100–500ms for VPC cold starts, down from multiple seconds. Still, if you need to access a VPC resource (RDS, ElastiCache), expect cold starts to run at the higher end of the range for your runtime.

AWS provides two mechanisms to eliminate cold starts. Provisioned Concurrency pre-initializes a specified number of execution environments, keeping them warm and ready to serve requests instantly. The cost is approximately $0.015 per GB-hour of provisioned memory, on top of normal execution charges. A common production pattern is to apply Provisioned Concurrency only on critical-path functions, the customer-facing API endpoint, while letting background workers and async processors cold-start freely. Lambda SnapStart (currently Java only) snapshots the initialized runtime state after the init phase and restores from that snapshot on cold start, typically bringing Java cold starts under 1 second without the ongoing cost of Provisioned Concurrency.

The honest bottom line: for most web APIs serving end users, a 300ms occasional cold start is barely perceptible and fully acceptable. For financial transaction processing, real-time gaming, or high-frequency trading systems where every millisecond counts, the cold start is a hard blocker, and ECS is the right answer.

Lambda vs ECS: cost comparison at different scales

The Lambda and ECS cost models are structured so differently that the cheaper option can flip depending entirely on request volume and execution duration. Getting the cost comparison right requires running the numbers for your specific workload.

Lambda's pricing has two components: request charges ($0.20 per 1 million requests) and compute charges ($0.0000166667 per GB-second). Lambda includes a permanent free tier of 1 million requests and 400,000 GB-seconds per month, enough to run a lightly used API or background job for free indefinitely. At 10 million requests per month with an average execution duration of 200ms at 512MB memory allocation, the math works out to approximately $1.60 in compute charges plus $2.00 in request charges, totaling roughly $3.60 per month.

The equivalent ECS workload running on Fargate with 0.25 vCPU and 512MB of memory running continuously costs approximately $9 per month for compute alone, before data transfer, load balancer, or ECR storage charges. At this scale, Lambda wins decisively, and the workload may even qualify for the free tier.

Scale that workload up to 100 million requests per month at the same execution profile: Lambda compute comes to roughly $16 plus $20 in request charges, approximately $36 per month. A reserved Fargate task at 0.5 vCPU and 1GB memory running continuously with a 1-year reservation costs around $12 per month. At this volume, ECS wins on raw compute cost by a factor of three.

One cost that frequently surprises teams building Lambda APIs: API Gateway charges $3.50 per million API calls on the REST API tier ($1.00 per million on HTTP API). At 10 million requests per month, API Gateway adds $35 or $10 to the bill, often more than the Lambda compute cost itself. Teams running high-volume Lambda APIs typically replace API Gateway with an Application Load Balancer ($0.008 per LCU-hour) to reduce per-request costs at scale.

The general principle: Lambda is cheaper at low-to-moderate volume (under 50–100 million requests per month at typical durations). ECS on reserved Fargate or EC2 wins at sustained high throughput. The crossover depends on your average execution duration and memory allocation.

Lambda vs ECS: hybrid architectures

In practice, the Lambda vs ECS decision is rarely an either/or choice at the application level. Most mature production AWS architectures use both services simultaneously, each handling the workloads they're best suited for. The real question is often which service should own which part of your system.

The most common hybrid pattern is ECS for synchronous customer-facing APIs and Lambda for asynchronous event processing. Your ECS service handles low-latency HTTP endpoints where cold starts would hurt user experience. Lambda handles the surrounding event-driven workloads: S3 object processing when files are uploaded, SQS consumers that process job queues, EventBridge rules that react to state changes, and CloudWatch scheduled events that replace cron jobs. This combination gives you consistent latency on the critical path and cost efficiency on the async work.

Another common pattern pairs Lambda for scheduled batch jobs and ECS for the core application. Rather than running a long-lived scheduled task container, a Lambda function on a cron EventBridge rule kicks off nightly reports, data exports, or cache warmup routines, then terminates. No idle container cost, no scheduler infrastructure to maintain.

AWS Step Functions is a natural complement to Lambda-heavy architectures. It orchestrates multi-step workflows across multiple Lambda functions, retry logic, branching, parallel execution, and error handling, without any of that logic living in application code. Step Functions works with both Lambda and ECS tasks, making it the right abstraction layer when a workflow spans both compute models.

Amazon EventBridge serves as the event bus that routes events between Lambda functions, ECS services, SQS queues, and external destinations. A single EventBridge event can trigger a Lambda function for lightweight processing, put a message on an SQS queue consumed by an ECS service, and archive to S3, all simultaneously. This decouples your compute choices from your event routing, making it easy to migrate a Lambda consumer to ECS later if throughput demands grow.

The Lambda vs ECS choice is a per-workload decision, not a per-application one. Most teams end up using both, and the teams that try to force everything into one model typically end up paying more or operating more complexity than necessary.

Common questions about Lambda vs ECS