When does a serverless (pay-per-invocation) compute model come out cheaper than running an always-on server or container for the same workload, and when does it flip to being more expensive?

## Cost as a function of utilization The cleanest way to reason about this is to model cost as a function of **utilization** — the fraction of time compute capacity is actually doing work. - An always-on server or reserved container has a fixed monthly cost that doesn't change whether it's handling zero requests or running flat-out; graph that as a horizontal line. - Serverless cost, by contrast, is strictly proportional to actual usage: at zero utilization it costs zero, and it rises linearly as invocation volume and duration increase, because every GB-second is billed individually. Plotting both against utilization produces two lines that cross at a specific **break-even utilization percentage**: below that point, serverless is cheaper because the always-on option is wasting money on idle capacity that serverless simply never pays for; above that point, always-on becomes cheaper because serverless's continuous per-unit rate premium, compounding across near-constant traffic, adds up to more than a flat or reserved-capacity rate would have cost for the same total compute-seconds delivered. ## Why the premium exists Why does serverless carry that per-unit premium at all? It isn't arbitrary — it's the price of the elasticity the platform has to maintain on your behalf. The provider has to: - keep spare physical capacity available to absorb sudden bursts from any of its customers at any moment, - manage strict multi-tenant isolation between invocations, - and support extremely fine-grained metering (down to milliseconds). All of that operational overhead gets priced into the per-GB-second rate, which ends up higher than what you'd pay for the equivalent slice of a reserved or committed-use always-on instance bought in bulk. ## The trade-off on each side The trade-offs, named explicitly on both sides — what each option buys, and at what price: | Option | Buys | Costs | |---|---|---| | **Choosing serverless** | zero idle cost, no capacity forecasting, and near-instant absorption of traffic bursts | at the price of a higher rate per unit of compute actually consumed and a bill that can spike unpredictably (and, in a worst case, expensively) if traffic spikes far beyond expectations | | **Choosing always-on** | a flat, predictable monthly bill and a lower cost per unit of compute at scale | at the price of paying for capacity you aren't using during quiet periods, needing to forecast and provision headroom ahead of peaks, and reacting to sudden bursts more slowly than a platform designed for near-instant elastic scale-out | ## Failure modes - **Migrating an already fully utilized workload.** A very common and costly failure mode is migrating a workload that is already running at consistently high, near-continuous utilization — a data-processing pipeline running nearly 24/7, for example — onto serverless expecting the marketing promise of 'pay only for what you use' to translate into savings. Because that workload was already close to fully utilized, there's little idle time for serverless to eliminate, so the team ends up paying serverless's per-unit premium on essentially every second of compute it would have used anyway, and the bill can land several times higher than the container fleet it replaced — a frequently repeated cautionary story in serverless cost post-mortems. - **Keeping an admin API on a dedicated always-on machine.** The mirror-image failure is the opposite: keeping a rarely invoked internal tool — an admin API called a handful of times a day — on a dedicated always-on virtual machine 'for consistency' with the rest of the fleet, quietly paying 24 hours a day for a service that's actually busy for a few minutes total. - **Over-provision function memory.** A subtler failure worth naming: teams estimating serverless cost sometimes over-provision function memory 'to be safe,' which multiplies the per-invocation GB-second cost even when duration doesn't improve proportionally, silently dragging the break-even point down and making always-on look cheaper than it needed to. ## Where it shows up Concrete examples on each side make the pattern intuitive: - A **nightly batch job** that runs for 30 minutes once a day is an obvious serverless win, since an always-on VM sized for that job would sit idle roughly 23.5 hours a day, all of it billed. - On the other end, a **video-transcoding service** continuously processing a steady stream of uploads near its concurrency ceiling around the clock is a textbook candidate to move off pure pay-per-invocation serverless toward reserved compute — containers with autoscaling, or heavily provisioned-concurrency serverless — once traffic sustains high utilization, because the per-GB-second premium compounds continuously with essentially no idle time left to offset it. In practice, mature systems are rarely all-or-nothing about this choice: many mix scale-to-zero serverless for spiky or low-traffic paths with always-on or autoscaled compute for the sustained, high-throughput core, and deliberately revisit that mix as a product's traffic pattern matures from unpredictable — which favors serverless — toward large and predictable — which favors reserved always-on capacity.