Utilisation Break-Even

Two teams in the same company argue about functions versus containers for a week. One says serverless is cheaper because you pay only for what you use. The other says containers are cheaper at scale. Both are right, and neither has computed the number where the answer changes — which for their workload is a ten-minute calculation.

Utilisation break-even is that number: the fraction of wall-clock time a workload must be busy before always-on capacity costs less than per-invocation capacity. Above it, containers or instances win and the gap widens with load. Below it, functions win and the gap widens with idleness.

Why it matters

It converts a taste argument into a measurement, and it is stable enough to reuse. Per-invocation platforms charge a premium per unit of CPU-time in exchange for charging nothing when idle. Express that premium as a ratio and the break-even is simply its inverse.

On major-cloud list prices in 2025, a function sized to receive roughly one full vCPU costs about twice a similarly sized container task running the same wall-clock hour, and roughly three to five times an instance under a committed-use discount. So break-even sits near 50% sustained utilisation against on-demand containers and near 20-25% against committed capacity. A workload busy 5% of the day is clearly serverless; one busy 60% of the day is clearly not; and the band between is where the second-order costs decide.

Implementation patterns

• Measure sustained utilisation, not peak. The input is total busy CPU-seconds over a day divided by the wall-clock seconds you would otherwise pay for. Teams routinely use peak and reach the wrong answer.
• Compute it per workload, never per estate. A single organisation will have webhooks at 2% and an order API at 70%, and one policy for both is wrong twice.
• Include the invocation fee and the waiting time. Functions bill occupied time, so a handler that waits 400 ms on a database pays for the wait. Reducing that wait moves the break-even more than a pricing change does.
• Add the compensating costs on the serverless side: a connection pooler, provisioned warm capacity to control cold starts, and a shared cache to replace the in-process one. These frequently exceed the invocation bill at high concurrency.
• Recompute at each pricing change and each traffic doubling, and record the current number in the decision record as a trigger condition.

Industry example

The most-cited public data point runs the other way and is widely over-read: in 2023 a video-streaming platform published an account of consolidating a distributed serverless pipeline for audio and video quality monitoring into a single process and cutting cost by over 90%. That workload sat far above any plausible break-even — high sustained utilisation with heavy data passing between steps, the exact profile where per-invocation billing and inter-service data transfer both punish you. It is evidence about one workload's utilisation, not about serverless as a category, and it is routinely quoted as the latter.

Failure scenarios

• Migrating a steady API to functions to save money and paying more, with the overrun landing on the first successful peak rather than on day one.
• Using peak utilisation as the input, which makes an idle workload look busy and blocks a saving worth taking.
• Ignoring waiting time, so an I/O-bound handler is priced as if it were CPU-bound.
• A break-even computed once in 2023 and never revisited, after both the traffic and the price list moved.
• Comparing against on-demand instance prices when the organisation buys committed capacity, which flatters serverless by a factor of two or more.

Trade-offs

The metric is only about money. It says nothing about operational load, deployment simplicity or team skill, and those frequently outweigh the bill. A four-person team above the break-even may still be right to stay on functions, because the alternative spends engineering time they do not have. The reverse trap is also real: chasing a small saving across the break-even adds a pooler, warm capacity and a cache, and the operational surface it introduces is not in the arithmetic.

When not to use it

Ignore it when the compute bill is a minor line item. Below roughly a few thousand dollars a month, the difference between the two models is smaller than one engineer-week a year, and the decision should be made on developer experience and operational fit instead. Ignore it too for workloads with a hard latency floor, where cold starts disqualify functions regardless of price, and for anything holding a scarce resource such as a database connection per request, where the binding constraint is concurrency rather than cost.

Interview question

Q: Your team wants to move a steady internal API from containers to functions "to save money". What number would you ask for before agreeing, and what would you expect to happen if the move went ahead anyway?

What a strong answer covers: ask for sustained utilisation over a representative week and the mean occupied duration per request, then compare against the per-vCPU-hour ratio for the capacity the company actually buys. For a steady internal API, expect utilisation above break-even and a higher bill. Expect the operational surprises to arrive before the invoice: connection exhaustion at concurrency, in-process caches that stop working, and cold starts on p99. Name the workloads next door where the move is correct, so the answer is a boundary rather than a veto.

Quick check

Quiz: Why is peak utilisation the wrong input to a break-even calculation? — Per-invocation billing charges for occupied time across the whole day, so the comparison needs total busy time over wall-clock time; peak flatters the always-on option and hides genuinely idle workloads.

Flashcard: Roughly where does the serverless-versus-container crossover sit? — Around 50% sustained utilisation against on-demand containers and 20-25% against committed capacity on 2025 major-cloud list prices, with the compensating costs of pooling and warm capacity deciding the band in between.