Provisioned concurrency break-even math: when warmth pays for itself

Provisioned concurrency is sold as a latency feature, and it is. But it is also a billing model change, and the change is bigger than most teams realize. On-demand Lambda charges only when code runs. Provisioned concurrency charges continuously for reserved warm environments and then charges a discounted rate for execution on top. Whether that is cheaper or more expensive comes down to one number: how busy the reserved capacity actually is.

The two price lists

Note that the warm charge runs for the entire time the provisioned concurrency is configured, 24 hours a day unless you schedule it down. One provisioned environment at 1024 MB costs 1 GB times 2,592,000 seconds in a 30 day month times $0.0000041667, which is $10.80 per month, before a single request is served.

Deriving the break-even

Let U be utilization: the fraction of reserved warm-seconds during which the environment is actually executing. Per warm-second, provisioned concurrency costs 0.0000041667 plus U times 0.0000097222. On-demand costs U times 0.0000166667 for the same work. Setting them equal gives U equal to 0.0000041667 divided by (0.0000166667 minus 0.0000097222), which is about 0.60.

So the rule is simple: provisioned concurrency is cheaper only above roughly 60 percent utilization, and the same ratio holds on Arm. Below that, on-demand wins on price and you are paying a premium for predictable latency.

Why real utilization is so low

Utilization of a provisioned environment equals average concurrency divided by provisioned concurrency. Average concurrency is invocations per second times average duration in seconds. A function handling 50 requests per second with a 100 ms duration has an average concurrency of 5. If you provision 20 to cover the peak, utilization is 25 percent and you are paying about 1.4 times the on-demand price.

Worse, teams typically provision for peak concurrency across the whole day, while traffic follows business hours. A function with a 4 to 1 peak-to-trough ratio provisioned at peak runs at well under 30 percent average utilization over 24 hours. That is the common case, and it is why provisioned concurrency bills surprise people.

Making the numbers work

Three moves push utilization up. Schedule it: use Application Auto Scaling to set provisioned concurrency to zero or a floor outside business hours. Cutting 16 hours a day of warm charges removes two thirds of the capacity cost and lifts effective utilization dramatically. Provision the floor, not the peak: cover the steady base of concurrency with provisioned capacity and let on-demand absorb the spikes, since Lambda spills over automatically. And target only the functions that need it, typically the synchronous, user-facing ones behind an API, not asynchronous consumers where a 500 ms cold start is invisible.

There is also a savings plan angle. Compute Savings Plans cover Lambda duration and provisioned concurrency, so a one-year no-upfront commitment shaves roughly 12 to 17 percent off both rates. That does not change the break-even ratio, since both sides scale, but it lowers the absolute number.

What spillover does to the estimate

Provisioned concurrency is not a ceiling. When demand exceeds the provisioned level, Lambda serves the extra requests on standard on-demand environments at the full $0.0000166667 per GB-second rate, with cold starts. This is helpful because it means under-provisioning degrades gracefully rather than failing, but it also means a bill can contain both models at once and a quick estimate that assumes all traffic lands on provisioned capacity will be wrong. Model the two streams separately: the provisioned share at the reduced rate plus the warm charge, and the spillover share at on-demand rates. For most workloads the cheapest configuration provisions somewhere between average and peak concurrency, accepting cold starts on the top slice of traffic that arrives least often.

A worked example

An API-backed function at 1024 MB serves 20 million requests a month at 180 ms average. On-demand: 20 million times 0.18 seconds times 1 GB equals 3.6 million GB-seconds, which is $60.00, plus $4.00 in request charges, so $64.00. Average concurrency is about 1.39. Provisioning 10 environments costs 10 times $10.80 equals $108.00 in warm charges plus $35.00 of discounted duration, roughly $147.00 all in, more than double. Provisioning 2 instead costs $21.60 warm, covers the base load, and lets on-demand handle the rest for around $70 total. The shape of the reservation matters more than the decision to reserve, the same lesson that shows up in anyprovisioned concurrency analysis. Price both configurations against the resource catalog before committing.

FAQ

What to do next

See the capacity bill before you reserve it. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.