Serverless vs VMs cost crossover: when functions get more expensive than a server

Quick answer

Serverless functions bill per request and per GB-second of execution, so they cost nothing at zero traffic and scale with load, but their effective per-hour-of-compute price is high. A VM bills a flat hourly rate whether it handles one request or millions, so it is expensive when idle but cheap at high, steady utilization. The crossover is utilization: below a threshold, serverless is cheaper because you pay nothing for idle time; above it, a well-utilized VM is cheaper. So use serverless for spiky, low, or unpredictable traffic and switch to VMs (or containers) once traffic is high and steady enough to keep a server busy.

Serverless and always-on VMs sit at opposite ends of the compute cost spectrum. A function costs nothing when no one calls it and scales instantly to demand, but each invocation is priced at a premium. A VM costs the same every hour regardless of load, so it wastes money when idle but is cheap per request when busy. Between them is a crossover point, and knowing roughly where it sits tells you which to use.

Two opposite cost shapes

Factor	Serverless functions	Always-on VM
Idle cost	Zero	Full hourly rate
Per-request cost	High	Low when busy
Scaling	Automatic, to zero and up	Manual or autoscaled
Best for	Spiky, low, unpredictable	High, steady, predictable

A small VM might cost around 30 to 60 dollars a month flat. Serverless handling a light or spiky load, a few hundred thousand requests, can cost a fraction of that or even land in a free tier, so serverless wins at low volume. But push to tens or hundreds of millions of requests a month at sustained load, and the per-request premium accumulates past what a busy VM would cost, as the Lambda versus Fargate comparison shows.

Why the crossover exists

Serverless trades a high per-unit price for zero idle cost, so it is cheapest exactly when utilization is low and idle time would otherwise be wasted on a VM. As traffic rises and steadies, that idle-time advantage disappears, and the VM's low per-request cost at high utilization takes over. The crossover is where the VM's flat cost divided by your request volume drops below the serverless per-request price, the same logic behind containers versus serverless.

Utilization and steadiness decide it

Two things push you past the crossover: high volume and steady load. A workload that is busy around the clock keeps a VM utilized and cheap, while a workload that spikes briefly and sits idle the rest of the time wastes VM capacity and belongs on serverless. Unpredictability also favors serverless, because you avoid provisioning for a peak that may not come, echoing the autoscaling trade-off.

Finding your crossover

Estimate your request volume and execution time, price the serverless cost, then price the smallest VM (or autoscaled group) that handles the steady load and compare. Below the crossover, serverless is cheaper and simpler; above it, move to VMs or containers, ideally keeping serverless for the spiky edges. Many teams start serverless and migrate hot paths to servers as volume grows. Price both the function and the VM alternative against the resource catalog so the crossover is a concrete number, not a guess.

FAQ

When is serverless cheaper than a VM?

At low, spiky, or unpredictable traffic. Serverless functions cost nothing when idle and scale to zero, so they are cheapest when a VM would sit underused. A light or bursty workload of a few hundred thousand requests can cost a fraction of a VM or land in a free tier. The idle-cost advantage is exactly what makes serverless win below the crossover point.

When does a VM become cheaper than serverless?

Above the crossover, when traffic is high and steady enough to keep a VM well-utilized. Serverless charges a premium per request, so at tens or hundreds of millions of sustained requests a month that premium accumulates past a busy VM's flat cost. A workload that runs busy around the clock keeps a VM cheap per request, so it belongs on a server, not functions.

How do I find the serverless-to-VM crossover?

Estimate your request volume and execution time, price the serverless cost from per-request and per-GB-second charges, then price the smallest VM or autoscaled group that handles your steady load and compare. The crossover is where the VM's flat cost divided by request volume drops below the serverless per-request price. Below it serverless wins; above it a VM wins.

Why does utilization determine which is cheaper?

Because serverless trades a high per-unit price for zero idle cost, so it is cheapest when utilization is low and a VM's idle time would be wasted. As load rises and steadies, the idle-time advantage disappears and the VM's low per-request cost at high utilization takes over. Steadiness and volume push you past the crossover; spikiness and low volume keep you below it.

How does C3X help find the serverless-versus-VM crossover?

C3X prices both the serverless functions and the VM alternative from Terraform before you deploy, so each option's cost at your expected request volume is a concrete number. That makes the crossover explicit in the pull request, letting you choose serverless for spiky low traffic and VMs for high steady traffic at design time, and keep serverless only on the parts that stay below the crossover.

What to do next

Find your serverless-to-VM crossover before you build. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.