When serverless stops being cheaper: the scale crossover
Serverless wins decisively at low and medium scale. There is a point where sustained, predictable load makes containers or instances cheaper, and it is more specific than most rules of thumb suggest.
Quick answer
The crossover is about sustained utilization, not request count. Lambda at 1769 MB costs $0.0000288 per second of execution, which is $0.1037 per hour of continuous single-vCPU compute. A Fargate task with 1 vCPU and 2 GB costs $0.04932 per hour, and a c7g.large on-demand is $0.0725 per hour for 2 vCPU. So Lambda costs roughly twice a Fargate task and four times a Savings Plan instance for the same continuous compute. The crossover arrives when average utilization of an equivalent always-on instance would exceed roughly 40 to 50 percent, which for a typical 150 ms API handler is around 8 to 12 million requests per month per vCPU.
Serverless is cheaper than servers for most workloads, and the reason is simple: you do not pay for idle. The corollary is equally simple. Once a workload stops being idle, that advantage disappears, and the premium you pay per unit of compute starts working against you. Knowing where that line sits stops both the premature migration to containers and the expensive refusal to leave functions.
Normalizing the price of compute
| Option | Cost per vCPU-hour | Notes |
|---|---|---|
| Lambda at 1769 MB (1 vCPU) | $0.1037 | Only while executing |
| Lambda Arm at 1769 MB | $0.0829 | About 20% cheaper |
| Fargate 1 vCPU + 2 GB | $0.04932 | Always on |
| Fargate Spot | ~$0.0148 | Interruptible |
| c7g.large on-demand | $0.03625 | Per vCPU, 2 vCPU instance |
| c7g.large, 1yr Savings Plan | ~$0.0229 | Commitment required |
Lambda is roughly 2.1 times Fargate and 4.5 times a committed instance per unit of delivered compute. That premium buys you zero idle cost, automatic scaling, no patching, and no capacity planning. Whether it is worth paying depends entirely on how much idle you would otherwise have.
The utilization break-even
An always-on 1 vCPU Fargate task costs $36 a month. Lambda delivering the same vCPU continuously would cost $75.70. Lambda becomes more expensive once its execution time exceeds 36 divided by 0.1037, which is about 347 hours a month out of 720, or 48 percent utilization. Against a Savings Plan instance the crossover falls to roughly 22 percent utilization.
| Effective utilization | Lambda monthly (1 vCPU equivalent) | Fargate 1 vCPU |
|---|---|---|
| 5% | $3.73 | $36.00 |
| 20% | $14.93 | $36.00 |
| 48% | $35.84 | $36.00 |
| 80% | $59.73 | $36.00 |
| 100% | $74.66 | $36.00 |
Translating that into requests
Utilization equals invocations per month times average duration divided by hours available. For a handler running 150 ms, reaching 48 percent utilization of one vCPU needs about 347 hours of execution, which is 1,249,200 seconds, which is roughly 8.3 million invocations a month at 1769 MB. Below that, Lambda is cheaper. Above it, a container starts to win, though not by much until you are well past the line.
| Average duration | Monthly invocations at crossover (per vCPU) |
|---|---|
| 50 ms | ~25 million |
| 150 ms | ~8.3 million |
| 500 ms | ~2.5 million |
| 2 s | ~625,000 |
Long-duration work crosses over much sooner, which is why batch jobs, media transcoding, and data processing tend to leave functions first, while short API handlers stay on Lambda far longer than people expect.
What the raw comparison leaves out
Containers need capacity headroom. A service running at 48 percent CPU has no room for a spike, so real deployments provision for peak and run at 30 to 40 percent average, meaning you buy two to three times the vCPU you use. Add a load balancer at about $18 a month minimum, cluster management where applicable, and at least two tasks for availability. A minimal highly available Fargate service is realistically $90 to $120 a month before traffic, against $0 for an idle function.
Containers also carry operational cost: base image patching, deployment pipelines, health checks, scaling policies, and the engineering time to maintain them. Functions carry their own overheads, notably cold starts and the discipline needed around concurrency limits and downstream connections.
The middle options
The choice is not binary. Lambda supports Compute Savings Plans, which apply to duration and provisioned concurrency and cut roughly 12 to 17 percent off the rate for a one-year no-upfront commitment, moving the crossover meaningfully to the right. Fargate Spot, at roughly 70 percent off standard Fargate, moves it sharply left for interruption-tolerant work. And container platforms that scale to zero sit between the two, keeping the idle advantage while charging container rates when running. Before rewriting anything, apply the discount that matches your commitment appetite, because a Savings Plan on an existing function estate is a configuration change that captures part of the gap with no engineering work and no operational change at all.
A practical decision rule
Stay serverless while traffic is bursty, unpredictable, low, or growing. Move the workload when three things are true at once: sustained utilization above roughly 50 percent of an equivalent instance, predictable traffic that lets you commit to capacity, and durations long enough that per-request overhead is a small fraction. Move the hot path only, since in most systems one or two functions account for the majority of invocations while dozens of others stay usefully idle. Splitting an estate this way captures most of the saving with a fraction of the migration. Compare candidates against thecrossover analysis and price both shapes against the resource catalog before moving anything.
FAQ
At what point does serverless become more expensive than containers?
At roughly 48 percent sustained utilization against Fargate and roughly 22 percent against a Savings Plan instance. Lambda at 1769 MB costs $0.1037 per vCPU-hour of execution while a 1 vCPU Fargate task costs $0.04932 per hour always on, so Lambda passes Fargate's $36 monthly cost once it executes for about 347 of the month's 720 hours.
How many requests does it take to reach the serverless crossover?
It depends on duration. Reaching 48 percent utilization of one vCPU takes about 347 hours of execution a month, which is roughly 25 million invocations at 50 ms, 8.3 million at 150 ms, 2.5 million at 500 ms, and 625,000 at 2 seconds. Long-running work crosses over far sooner than short API handlers.
Is Lambda really more expensive per unit of compute?
Yes, by about 2.1 times against Fargate and 4.5 times against a committed instance, when normalized to vCPU-hours. Lambda at 1769 MB costs $0.1037 per vCPU-hour, Fargate about $0.04932, and a c7g.large under a one-year Savings Plan about $0.0229. The premium buys zero idle cost, automatic scaling, and no capacity planning.
Do container costs include more than the compute?
Yes, and it changes the comparison. Containers need headroom, so services provisioned for peak typically run at 30 to 40 percent average utilization, meaning you buy two to three times the vCPU you consume. Add a load balancer at about $18 a month and at least two tasks for availability, and a minimal highly available Fargate service starts around $90 to $120 a month.
Should I migrate my whole serverless estate to containers?
Almost never. In most systems one or two functions account for the majority of invocations while dozens stay usefully idle and cost nearly nothing. Moving only the hot path captures most of the saving for a fraction of the migration effort, and keeps the scale-to-zero advantage for everything else in the estate.
How does C3X help find the serverless crossover?
C3X prices functions, Fargate tasks, and instances from Terraform against the same catalog, so both shapes of a workload can be compared directly at your expected volume. Because the comparison happens at review time, you can evaluate whether a growing function has passed its crossover before the bill makes the case for you.
What to do next
Find your crossover before the bill does. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.