AWS Lambda vs ECS Fargate: Cost at 1M Requests
“Should we use Lambda or Fargate?” is one of the most-asked architecture questions in AWS, and almost every answer you’ll find online is wrong — not because the maths is hard, but because the answer depends entirely on assumptions that get glossed over.
This post does the comparison properly. We’ll price a typical workload — 1 million requests per month, 200ms average duration, 512 MB of memory — on both services, then show you exactly which dials change the answer.
All prices in this post are based on AWS public pricing in
us-east-1as of May 2026. Reserved capacity, Savings Plans, and Compute Savings Plans are addressed separately.
The workload we’re pricing
To make the comparison fair, both services run the same hypothetical API:
- Requests per month: 1,000,000
- Average request duration: 200ms
- Memory required: 512 MB
- Peak concurrency: 10 concurrent requests (during business hours)
- Cold start tolerance: yes (200-500ms acceptable)
Networking, observability, and storage are excluded from both sides — they cost roughly the same regardless of the compute choice.
AWS Lambda pricing at 1M requests
Lambda charges on three axes:
- Requests — $0.20 per 1M requests
- Compute — $0.0000166667 per GB-second
- Architecture — Graviton (
arm64) is ~20% cheaper than x86
For our workload:
| Line item | Calculation | Monthly cost |
|---|---|---|
| Requests | 1,000,000 × $0.20/1M | $0.20 |
| Compute (x86) | 1M × 0.2s × 0.5GB × $0.0000166667 | $1.67 |
| Compute (arm64) | 1M × 0.2s × 0.5GB × $0.0000133334 | $1.33 |
| Total (x86) | ~$1.87 | |
| Total (arm64) | ~$1.53 |
That’s it. Less than two dollars a month, in this scenario.
If you have a free tier (1M requests + 400,000 GB-seconds free per month, permanently, no expiry), your effective cost is $0.
ECS Fargate pricing at 1M requests
Fargate charges differently. You don’t pay per request — you pay for the lifetime of the task, regardless of whether it’s serving traffic.
For our workload, a single Fargate task with:
- 0.25 vCPU
- 0.5 GB memory
- Running 24/7
costs (x86):
| Line item | Calculation | Monthly cost |
|---|---|---|
| vCPU | 0.25 × $0.04048/hr × 730 hrs | ~$7.39 |
| Memory | 0.5 × $0.004445/hr × 730 hrs | ~$1.62 |
| Total per task | ~$9.01 |
Now: can a single 0.25 vCPU task handle 1M requests/month at 200ms each? Yes, comfortably. 1M × 0.2s = 200,000 CPU-seconds, or roughly 56 hours of CPU time spread across the month. A single small task is sufficient.
So at this volume, Fargate is ~$9, Lambda is ~$1.50. Lambda wins by roughly 6x.
Side-by-side at the same workload
| Configuration | Monthly cost | Cost per million requests |
|---|---|---|
| Lambda (arm64, 512MB, 200ms) | ~$1.53 | $1.53 |
| Lambda (x86, 512MB, 200ms) | ~$1.87 | $1.87 |
| Fargate (1 task, 0.25 vCPU, 0.5GB, 24/7) | ~$9.01 | $9.01 |
| Fargate Spot (1 task, 0.25 vCPU, 0.5GB, 24/7) | ~$2.70 | $2.70 |
So Lambda looks like a runaway winner. It is — at 1M requests. Now watch what happens when we change the assumptions.
When the answer flips
Higher request volume
Lambda cost scales linearly. Fargate cost is flat (until you add more tasks). At some point they cross.
| Requests per month | Lambda (arm64) | Fargate (1 task) |
|---|---|---|
| 1M | $1.53 | $9.01 |
| 10M | $13.53 | $9.01 |
| 100M | $133.34 | $9.01 — but you need more tasks |
| 100M (sized) | $133.34 | ~$80 (4 tasks) |
| 1B | $1,333 | ~$300 (12+ tasks) |
By the time you’re serving 100M+ requests/month, Fargate becomes meaningfully cheaper. By 1B+ requests, it’s not close.
Longer request duration
Lambda charges per GB-second, so a request that takes 2 seconds is 10x the compute cost of one that takes 200ms. Fargate doesn’t care how long a request takes — only how busy the task is. The break-even moves down sharply as request duration grows.
| Avg duration | Lambda cost at 1M req | Notes |
|---|---|---|
| 200ms | ~$1.53 | Lambda dominant |
| 1s | ~$6.87 | Closing in on a Fargate task |
| 5s | ~$33.53 | Fargate becomes cheaper |
| 30s | ~$200.13 | Don’t use Lambda for this |
Memory requirements
Lambda’s GB-second pricing means a 4 GB function costs 8x what a 0.5 GB function costs per request. A Fargate task with 4 GB memory costs an extra ~$13/month, regardless of request volume.
Sustained traffic
This is the big one. Lambda is genuinely cheap when traffic is bursty. If your traffic is sustained at high concurrency — say, 50 concurrent requests around the clock — you’re effectively running a 24/7 fleet of Lambda invocations and paying for every millisecond. A Fargate task running at high utilisation is dramatically cheaper at that point.
Compute Savings Plans
A 1-year, no-upfront Compute Savings Plan applies to both Lambda and Fargate, at roughly 17% discount. It does not change the relative comparison — both sides get the same discount — but it does meaningfully lower the absolute numbers.
A rough decision tree
The question is rarely “which is cheaper?” in isolation. It is “which is cheaper for this workload?”
- Bursty traffic, <10M requests/month, short duration (<1s), no warm-up needed → Lambda, almost always.
- Steady traffic, >50 concurrent requests, predictable load → Fargate, almost always.
- Long-running tasks, batch jobs, ML inference → Fargate (Lambda’s 15-minute limit alone disqualifies it for many cases).
- Highly variable traffic between zero and 100x peak → Lambda; you’d over-provision Fargate to handle the peaks.
- Workload that needs to run continuously → Fargate. Lambda is the wrong tool.
What the price comparison leaves out
A pure cost comparison ignores the rest of the bill:
- Cold starts on Lambda may require Provisioned Concurrency, which costs roughly the same as Fargate per warm instance.
- Fargate tasks need an ALB or NLB if they serve HTTP traffic. Lambda + API Gateway is its own additional cost.
- Operational complexity — Lambda has effectively no infrastructure to manage; Fargate has tasks, services, networking, and an orchestration layer.
A common pattern is workloads that started as a bursty proof-of-concept on Lambda, gradually grew into sustained production traffic, and were never re-evaluated. By the time anyone looks, they’ve quietly become significantly more expensive than they would have been on Fargate.
If you’d like a second opinion on which compute model is right for a specific workload — or want a cost model built for your actual traffic profile — get in touch. These comparisons are rarely as simple as the headline numbers suggest, and the answer is often workload-specific.