Right-size Lambda provisioned concurrency

Normally the appeal of serverless is that it costs nothing when nothing is running — you pay per execution, and an idle function is free. Provisioned concurrency breaks that rule on purpose. To make a function respond instantly with no warm-up delay, the team reserves a fixed number of always-ready environments. Reserving them costs money every second they're held, around the clock, whether or not any customer request ever uses them. So a function can have light overnight traffic and still bill steadily through the night for capacity sitting idle.

The non-obvious part is that this is a deliberate trade the team made for speed, and it's easy to over-buy. Reserving for the busiest minute of the busiest day and leaving that reservation in place 24/7 means paying peak rates during quiet hours and weekends. The right setting isn't "as much as possible to be safe" and it isn't zero — it's matched to the real concurrent demand, and ideally ramped up only during the hours that actually need it. A function reserved for peak but mostly idle is the serverless version of running a full data centre overnight for a workload that only matters at 10am.

From a budgeting standpoint the number to watch is utilization: what fraction of the reserved warm capacity is actually serving traffic. If a function reserves enough warm environments for 50 simultaneous requests but rarely exceeds 8, the other 42 are pure waste billing every hour. The right question at the cost review is not "how much do we spend on Lambda" but "which functions have provisioned concurrency, what's their utilization, and could the reservation follow the traffic instead of standing still at peak all day?"

Raj is the finance partner embedded with a fintech platform team. At the monthly cost review the Lambda line has a chunk that behaves oddly — it doesn't fall on weekends the way the rest of usage-based spend does. Instead of asking "why is Lambda flat at weekends," he asks the sharper version: "Which functions reserve warm capacity, and what's the utilization on it?" The engineering lead pulls it up: one fraud-scoring function reserves 80 always-on environments and hasn't been revisited since launch.

The conversation isn't technical. Raj doesn't ask about GB-seconds or scaling policies. He asks for one number — the percentage of that reserved warm capacity actually serving traffic — and whether the reservation could follow the traffic instead of standing at peak all day. The answer comes back: blended utilization is about 25%, and yes, the daily pattern is obvious enough to schedule against. That's enough to act.

A month later utilization on that function is around 70% and the warm-capacity charge has dropped by roughly two-thirds, with no latency trade-off to debate because spillover stayed at zero. Raj now tracks utilization on provisioned functions as a standing line, because the raw dollar total alone won't tell him whether warm capacity is well-sized. High utilization with scheduled ramps is the signal it's being managed; a reservation that bills flat through quiet hours is the prompt to ask which function hasn't been revisited.

The per-function impact is modest and the aggregate is real. Provisioned concurrency is usually a slice of the Lambda line, but it behaves unlike the rest of serverless: it's a fixed floor that doesn't fall when usage falls. A function over-provisioned by 50 units is several hundred dollars a month of pure idle reservation, and an org with a dozen latency-critical functions all sized for peak can carry five figures a month of warm capacity that traffic never reaches.

The unit to budget against is utilization, not the raw dollar total. A high PC bill on a function running at 70% utilization with scheduled ramps is money well spent — you're buying exactly the speed insurance you use. The same dollar amount at 15% blended utilization is mostly waste. The variance to chase is low utilization, especially the gap between weekday-peak utilization and the round-the-clock reservation, because that gap is the schedulable saving sitting in plain sight.

There's a commitment dimension finance owns directly. Compute Savings Plans discount the provisioned-concurrency dimension alongside on-demand Lambda, Fargate, and EC2. Committing against an over-provisioned, unscheduled baseline locks a discount onto idle warm capacity and strands part of the commitment the moment the function is right-sized. The sequencing rule mirrors EC2 right-sizing: right-size and schedule the reservation first, commit second, so the Savings Plan sits on the efficient run-rate.

Finally, treat the presence of always-on, unscheduled PC as a leading indicator. If the answer to "is this reservation scheduled to match traffic, and what's its utilization?" is "it's flat 24/7 and we've never checked," that usually correlates with set-and-forget habits in other categories. A team that right-sizes and schedules its warm capacity is signalling a healthy operating cadence; one that can't name its provisioned functions or their utilization is signalling the opposite, and this line is just where it surfaces.

Provisioned concurrency is a feature teams buy to guarantee that a few critical functions respond instantly, with no start-up lag. It works by keeping capacity permanently warm — which means it bills continuously, even overnight and at weekends when traffic is low. Unlike normal serverless, which costs nothing at idle, this charge runs whether the capacity is used or not, so over-buying it is a quiet, recurring drain.

This is an efficiency-discipline issue, not a big-ticket savings item. The headline is that warm capacity should be sized to real demand and ideally scheduled to match traffic, rather than reserved at peak levels around the clock. Where the discipline exists, the team can show high utilization on the capacity they pay for and reservations that ramp down off-hours; where it doesn't, the business is paying premium rates to keep environments warm that customers never reach.

At one company the cloud-cost review used to show a serverless line that, oddly, didn't dip on weekends like the rest of usage-based spend. The standing explanation was "that's the latency guarantee on our critical paths." That was partly true and partly an excuse — nobody could say whether the always-on capacity matched real demand or was simply set high once and left.

The exec sponsor stopped accepting "it's for latency" and started asking for a number: what fraction of the reserved warm capacity is actually used, and does the reservation follow the traffic? Within a quarter the team had right-sized the heavy functions and put them on schedules that ramped capacity down overnight and at weekends. Utilization climbed, the weekend charge fell, and critical-path latency was unchanged.

That's the right outcome state for provisioned concurrency. "Turn off the latency guarantee" is the wrong goal; "warm capacity is sized to real demand and scheduled to match traffic" is the right one. The cost line stops being an argument about whether speed is worth it and becomes a confidence signal that the team is buying exactly as much insurance as it needs.

The dollar amount in this category is rarely the headline on its own. The reason it's tracked is what its shape says about engineering's cost discipline. Warm capacity that bills flat around the clock, with low utilization and no schedule, signals that a speed feature was switched on once and never revisited; high utilization with reservations that ramp down off-hours signals a team actively matching cost to demand. The difference between those two states, on the same critical paths, is often a two-thirds cost gap with identical latency.

The second-order point is that provisioned concurrency is where teams most readily confuse "we bought the latency guarantee" with "the latency guarantee is sized correctly." It's a useful canary: if the always-on capacity has never been checked against real demand, the same buy-for-peak-and-forget habit likely runs through other reserved-capacity decisions. Asking for utilization and schedule on the provisioned functions costs leadership nothing and surfaces a discipline pattern early, while it's still cheap to fix.