Lambda provisioned concurrency cost: paying to kill cold starts

Quick answer

Provisioned concurrency keeps a set number of Lambda execution environments initialized and warm so requests skip the cold start. You pay two things: an hourly rate for each unit of provisioned concurrency you keep warm (charged whether or not it serves traffic) plus the normal per-request and per-GB-second duration cost when it runs. It is worth it for latency-sensitive, predictable workloads where cold starts hurt user experience, and wasteful for spiky or low-traffic functions where on-demand Lambda is cheaper.

Cold starts are the tax of serverless: when a Lambda function has no warm environment, AWS must initialize one before it can run your code, adding latency that hurts user-facing requests. Provisioned concurrency is the fix, keeping a pool of environments pre-initialized and warm, but that convenience is billed continuously, so understanding the cost model is the difference between a smart latency win and a wasteful standing charge.

How provisioned concurrency is billed

Charge	What you pay for
Provisioned concurrency	Hourly rate per warm unit, charged 24/7 while enabled
Duration	Per-GB-second while code actually executes (at a discounted rate)
Requests	Per-invocation fee, same as on-demand

The key line is the first one: you pay an hourly rate for every unit of concurrency you keep warm, around the clock, regardless of whether a single request arrives. When a warm environment does run your code, the duration is charged at a modestly discounted GB-second rate compared to on-demand. So provisioned concurrency trades a fixed standing cost for lower latency and a slightly cheaper execution rate.

When it is worth the standing cost

Provisioned concurrency pays off when the workload is latency-sensitive and reasonably predictable: a user-facing API where cold-start latency is unacceptable, and traffic is steady enough that the warm pool is actually used most of the time. If you keep 10 units warm and they serve near-continuous traffic, the standing cost is amortized across real work. Compare the tradeoffs with a broader Lambda versus Fargate cost analysis before committing.

When on-demand Lambda is cheaper

For spiky, unpredictable, or low-traffic functions, provisioned concurrency is usually a waste: you pay to keep environments warm during long idle periods when nothing runs. Plain on-demand Lambda, where you pay only per request and per GB-second of execution, is cheaper because it scales to zero. If cold starts are the only problem, consider right-sizing memory first, since more memory means faster init, as covered in the Lambda memory right-sizing guide.

Controlling the cost

Use application auto-scaling to schedule provisioned concurrency up during business hours and down overnight, so you are not paying for warm capacity while traffic is near zero. Provision only the concurrency you actually need at peak, not a generous buffer, and measure real cold-start impact before enabling it, since many functions do not need it. Left unchecked, the standing charge becomes one of the unexpected charges that surprise people on the invoice. Price these tradeoffs before you ship using the resource catalog, so the standing cost is a deliberate choice rather than a surprise on the invoice.

FAQ

What is Lambda provisioned concurrency?

It keeps a set number of Lambda execution environments initialized and warm so incoming requests skip the cold start (the initialization delay that happens when no warm environment exists). It eliminates cold-start latency for the provisioned units, at the cost of an hourly charge for keeping them warm whether or not they serve traffic.

How is provisioned concurrency priced?

You pay an hourly rate for each unit of provisioned concurrency you keep warm, charged around the clock while enabled regardless of traffic, plus the normal per-request fee and a per-GB-second duration charge (at a slightly discounted rate) when the warm environment actually runs your code. The standing hourly charge is the part that makes it expensive if underused.

Is provisioned concurrency worth the cost?

It is worth it for latency-sensitive, predictable workloads like user-facing APIs where cold-start latency is unacceptable and traffic is steady enough that the warm pool is actually used. It is wasteful for spiky, unpredictable, or low-traffic functions, where plain on-demand Lambda that scales to zero is cheaper because you avoid paying for idle warm capacity.

How can I reduce provisioned concurrency cost?

Use application auto-scaling to schedule concurrency up during peak hours and down overnight so you are not paying for warm capacity during idle periods, provision only what you need at peak rather than a generous buffer, and measure actual cold-start impact first since many functions do not need it. Right-sizing memory can also speed up cold starts without the standing charge.

Does more Lambda memory reduce cold starts?

More allocated memory also means more CPU, which speeds up the initialization phase, so higher memory can reduce cold-start duration. That can be a cheaper alternative to provisioned concurrency for some functions, since you pay only when the function runs. Right-sizing memory is the first lever to try before paying for warm capacity around the clock.

How does C3X help with Lambda concurrency cost?

C3X prices your Lambda configuration, including provisioned concurrency, before you deploy, so the standing hourly cost of keeping environments warm shows up in the pull request rather than on next month's invoice. That lets you decide whether the latency benefit justifies the continuous charge before it ships, instead of discovering the cost after the fact.

What to do next

Price Lambda provisioned concurrency before you enable it. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.