Lambda vs Fargate cost: which serverless compute is cheaper

Quick answer

Lambda bills per request plus per GB-second of execution and scales to zero, so it is cheapest for spiky, intermittent, or event-driven workloads. Fargate bills per vCPU-hour and GB-hour for the whole time a task runs, so it is cheapest for steady, long-running, or high-throughput workloads where a container is busy most of the time. The crossover is traffic pattern: bursty and idle-heavy favors Lambda, sustained and busy favors Fargate. Long-running or CPU-heavy jobs also hit Lambda's duration and memory limits, pushing them to Fargate.

Lambda and Fargate are both serverless, in the sense that you do not manage servers, but they bill in fundamentally different ways, and that difference decides which is cheaper for a given workload. Choosing wrong can multiply your compute bill, so the decision deserves a clear-eyed look at how each charges and which traffic patterns each rewards.

How each one bills

Dimension	Lambda	Fargate
Unit of billing	Per request plus per GB-second of execution	Per vCPU-hour and GB-hour while the task runs
Scales to zero	Yes, pay nothing when idle	No, you pay while the task is up
Best traffic	Spiky, intermittent, event-driven	Steady, long-running, high-throughput
Max duration	15 minutes per invocation	Unlimited

Lambda charges only while your code actually executes, so a function that runs a few times an hour costs almost nothing. Fargate charges for the entire lifetime of a running task, so a container sitting mostly idle still bills every second. This is the crux: Lambda punishes continuous busy work, Fargate punishes idle time.

When Lambda is cheaper

Lambda wins for spiky and intermittent workloads: event handlers, webhooks, scheduled jobs, and APIs with uneven or low traffic. Because it scales to zero, you never pay for idle capacity, which is exactly where Fargate bleeds money. If your workload is bursty and often idle, Lambda is almost always cheaper. Watch for cold starts though, and price the fix in the provisioned concurrency guide.

When Fargate is cheaper

Fargate wins for sustained, high-throughput, or long-running workloads: a service handling constant traffic, a long batch job, or anything exceeding Lambda's 15-minute limit or memory ceiling. Once a Lambda function runs near-continuously, its per-GB-second pricing overtakes a right-sized Fargate task doing the same work for a flat per-second rate. High steady request volumes tip the math toward Fargate, and for even lower cost you can run Fargate on Spot or compare with EC2-backed containers.

Making the call

Estimate monthly invocations and average duration for Lambda, and estimate task count, vCPU, memory, and uptime for Fargate, then price both. The answer follows the traffic shape: intermittent and idle-heavy goes to Lambda, steady and busy goes to Fargate. Do not forget right-sizing on either side, tune Lambda memory and container resources before comparing. Price both options against the live resource catalog so the choice is grounded in numbers, not intuition.

FAQ

Is Lambda or Fargate cheaper?

It depends on the traffic pattern. Lambda scales to zero and bills per request plus per GB-second of execution, so it is cheapest for spiky, intermittent, or event-driven workloads. Fargate bills per vCPU-hour and GB-hour for the whole time a task runs, so it is cheapest for steady, long-running, high-throughput workloads. Bursty and idle-heavy favors Lambda; sustained and busy favors Fargate.

When should I choose Lambda over Fargate?

Choose Lambda for spiky, intermittent, or event-driven workloads: webhooks, event handlers, scheduled jobs, and APIs with uneven or low traffic. Because Lambda scales to zero, you never pay for idle capacity, which is where Fargate loses money. If your workload is bursty and often idle, and each execution fits within 15 minutes and Lambda's memory limits, Lambda is almost always cheaper.

When should I choose Fargate over Lambda?

Choose Fargate for sustained, high-throughput, or long-running workloads: services handling constant traffic, long batch jobs, or anything exceeding Lambda's 15-minute per-invocation limit or memory ceiling. Once a function runs near-continuously, Lambda's per-GB-second pricing overtakes a right-sized Fargate task doing the same work at a flat per-second rate.

What are the limits that push work from Lambda to Fargate?

Lambda invocations are capped at 15 minutes each and have a maximum memory allocation, so long-running jobs, CPU-heavy or memory-heavy processing, and anything needing more than the memory ceiling must run on Fargate or another container platform. When your workload cannot fit those limits, Fargate (or EC2-backed containers) is the practical and often cheaper choice.

How do I compare Lambda and Fargate cost accurately?

Estimate monthly invocations and average execution duration and memory for Lambda, and estimate task count, vCPU, memory, and uptime for Fargate, then price both against current rates. The cheaper option follows the traffic shape. Include right-sizing on both sides and consider Fargate Spot for further savings before finalizing the comparison.

How does C3X help compare Lambda and Fargate cost?

C3X prices both Lambda and Fargate configurations from your Terraform before you deploy, so you can see the monthly cost of each approach in the pull request and pick the cheaper one for your traffic pattern. That turns the Lambda-versus-Fargate decision into a numbers-backed choice made at design time rather than a guess corrected on the invoice.

What to do next

Compare Lambda and Fargate cost before you commit. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.