The economics of migrating to serverless come down to duty cycle. Serverless platforms such as AWS Lambda, Azure Functions, GCP Cloud Run and Cloud Functions, and OCI Functions bill per request and per unit of compute time, with nothing charged while idle. That structure beats always on compute for spiky, event driven, and low utilization workloads, because the idle hours you would otherwise pay for disappear. It loses for steady, high utilization workloads, where a committed instance under Savings Plans, Reservations, Committed Use Discounts, or Universal Credits spreads a fixed rate over enough work to undercut the per request premium. The break even is the utilization level where the two pricing curves cross, and provisioned concurrency to defeat cold starts shifts a latency sensitive function toward the always on side. Model the real pattern, do not assume.
Serverless is often sold as automatically cheaper. It is automatically cheaper only for the right shape of workload. Here is how to tell which shape you have.
Why does serverless win for spiky workloads?
An always on instance bills every hour whether or not it is doing work, so a workload that is busy for two hours a day pays for twenty two idle ones. Serverless inverts this: you pay per invocation and per millisecond of execution, and a function that never runs costs nothing. For event driven work, scheduled jobs, webhooks, sporadic APIs, and bursty back ends, the idle elimination is the whole saving, and it can be large. The more time a workload spends doing nothing on a server you are renting, the more serverless saves by simply not charging for that nothing.
Why does serverless lose for steady workloads?
The per request and per duration rates of serverless carry a premium over raw instance compute, which is the price of never managing or paying for idle capacity. When a workload is busy most of the time, that premium applies to almost every unit of work, while a committed instance amortises its fixed hourly rate across continuous use and a deep commitment discount. Past a certain utilization, the always on instance is simply cheaper per unit of work delivered. Migrating a steady, high traffic service to serverless can quietly raise its cost even as it removes operational toil, so the operational benefit has to be weighed separately from the bill.
Where is the break even, with numbers?
The crossover is where per request serverless cost equals the hourly cost of an always on instance sized for the same peak. Consider a service handling a burst of traffic for part of the day and near silence the rest. Run it as an instance and it bills for the full day at a committed rate. Run it as functions and it bills only for the active portion. The illustrative table below shows how the cheaper option flips with duty cycle. These figures are indicative and meant to show the shape of the decision, not a quote; always model against current provider pricing and your real invocation profile.
| Workload duty cycle | Cheaper model | Why |
|---|---|---|
| Low, busy a few hours a day | Serverless | Idle hours cost nothing |
| Moderate, bursty with quiet gaps | Depends, model both | Near the break even |
| High, busy most hours | Committed instance | Fixed rate spreads over work |
| Latency critical, warm always | Committed or provisioned | Provisioned concurrency adds always on cost |
Table: indicative guide to which model wins by duty cycle. Verify against current provider pricing and your real request pattern.
How do cold starts and concurrency change the math?
A cold start is the delay when a serverless platform spins up a new execution environment for an idle function. For background and tolerant workloads it does not matter. For latency sensitive user facing functions it does, and the usual remedy, provisioned concurrency that keeps execution environments warm, reintroduces an always on charge. If a function needs concurrency kept warm continuously to meet its latency target, its cost profile starts to resemble an always on service, and the idle savings that justified serverless erode. Account for the concurrency you will actually need before concluding serverless is cheaper.
A worked example
A European SaaS company ran a mix of services on always on instances out of habit. Reviewing each by duty cycle showed two distinct groups. A set of event driven jobs and low traffic internal APIs sat idle most of the day yet billed around the clock; moving them to functions removed the idle cost entirely. A core customer API, by contrast, ran busy almost continuously, and a trial migration to serverless raised its cost because the per request premium applied to nearly every call, so it stayed on a committed instance instead. Matching each workload to the model its duty cycle favoured left the overall estate materially lighter without forcing a single architecture on everything. Figures are verified against billing data and anonymised.
Where this fits the wider decision
Serverless is one option inside a broader move, weighed using the migration decision framework, and for workloads where neither pure cloud model fits, see the hybrid estate cost model. After any migration, watch for the lines covered in post migration cost surprises. The full cross cloud picture lives in the cross cloud cost optimization guide.
Frequently asked questions
Is serverless always cheaper than running servers?
Where is the break even between serverless and always on?
Do cold starts change the cost decision?
Model your serverless move with us
We model each workload by duty cycle across AWS, Azure, GCP, and OCI and put it on the model its economics favour, with zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.