AWS Lambda Provisioned Concurrency: When It's Worth the Cost
Compare Lambda provisioned concurrency with other cold-start options using measured latency, traffic patterns, spillover, and capacity costs.
If cold starts are responsible for unacceptable p99 latency, compare provisioned concurrency with initialization improvements and other options for your runtime. The decision depends on measured latency, traffic patterns, and the cost of idle capacity.
What Provisioned Concurrency Is
When Lambda has no warm execution environment for a function, it initializes one from scratch — runtime boot, package load, initialization code. This is the cold start.
Provisioned concurrency prepares a configured number of execution environments ahead of requests. Traffic beyond that capacity can spill over to on-demand environments and experience cold starts. AWS provisioned concurrency documentation.
Configure provisioned concurrency on a published function version or alias and invoke that target. Monitor allocation and spillover as traffic changes.
The Cost Model
Provisioned concurrency has two billing dimensions:
-
Provisioned Concurrency-Hours: You pay for the concurrency you provision, for every hour it is provisioned, whether or not it handles any invocations. This is the baseline cost that exists even at zero traffic.
-
Invocation duration at a discounted rate: Invocations use provisioned-concurrency duration pricing. Compare the current rate for your Region and architecture with on-demand pricing.
The net effect: provisioned concurrency adds a fixed floor cost in exchange for eliminating cold starts and reducing per-invocation compute cost. The economics favor provisioned concurrency when:
- The function receives enough invocations that the discounted invocation rate offsets the idle provisioning cost
- Or the latency requirement is strict enough that the cost is justified regardless of invocation volume
When Provisioned Concurrency Is Worth It
User-Facing APIs with Strict Latency SLAs
If your function is on the critical path of a user interaction — authentication, payment initiation, initial page API — and your SLA defines p99 latency requirements, cold starts are an unacceptable variance. A cold start that adds 500ms-2 seconds to a user-facing request is a product problem, not just an infrastructure metric.
For these workloads, compare the cost of provisioned capacity with the latency target and the effect of missed requests on users.
Predictable Traffic Spikes
If your traffic pattern is forecastable — business hours for a B2B SaaS, morning rush for a consumer app, known promotional events — you can schedule provisioned concurrency to be active during high-traffic periods and scaled back during quiet periods.
Use Application Auto Scaling with a scheduled scaling policy:
aws application-autoscaling put-scheduled-action \
--service-namespace lambda \
--resource-id function:my-function:prod \
--scheduled-action-name scale-up-morning \
--schedule "cron(0 8 * * ? *)" \
--scalable-target-action MinCapacity=50,MaxCapacity=50
This approach reduces the idle cost significantly. If you provision concurrency for 12 hours per day instead of 24, you cut the provisioning cost in half.
Functions Where Cold Starts Are Frequent
Measure cold-start frequency from your workload. Lambda can reuse an execution environment, but AWS does not promise a fixed idle lifetime; regular invocations do not guarantee that an environment persists. Lambda execution lifecycle.
For rarely invoked functions, compare the latency requirement with the cost of keeping provisioned capacity idle. Periodic warm-up calls are not a guarantee against cold starts.
When Provisioned Concurrency Is Not Worth It
When SnapStart Applies
Check SnapStart support for the runtime, deployment format, and Region you use. Current supported managed runtimes include Java 11+, Python 3.12+, and .NET 8+. Pricing varies by runtime, and SnapStart cannot be combined with provisioned concurrency. Benchmark the function before choosing. AWS SnapStart documentation.
When Code Optimization Has Not Been Applied First
Profile initialization before deciding how much provisioned capacity to purchase:
- Hoist all client initialization to module scope
- Reduce package size with a bundler
- Choose a fast runtime (Node.js or Python if you have flexibility)
- Profile your initialization code and remove unnecessary work from the cold path
A function that cold-starts in 150ms after optimization may not need provisioned concurrency even for user-facing workloads.
When Traffic Is Sparse and Unpredictable
If your function is invoked irregularly — a few times per day, at unpredictable times — provisioned concurrency runs idle most of the time. The cost is continuous regardless of traffic. A background job, an admin tool, or an infrequently triggered webhook handler is a poor fit for provisioned concurrency unless the cold start latency is genuinely problematic for that use case.
When You Have Not Measured the Problem
Cold start latency is reported in CloudWatch Logs in the REPORT line as Init Duration. Before provisioning concurrency, verify:
- What percentage of your invocations are cold starts
- What the actual cold start duration is in milliseconds
- What the p99 latency is for your function, including cold and warm invocations
Sometimes the cold start problem is smaller than assumed. Sometimes the problem is in the handler logic rather than initialization. Measure before spending.
Sizing Provisioned Concurrency
Size provisioned concurrency against measured peak concurrency and your latency target. Requests above the provisioned capacity use on-demand concurrency, which may require initialization.
Use CloudWatch metrics to find your actual peak concurrency:
ConcurrentExecutions— current concurrent invocationsProvisionedConcurrencySpilloverInvocations— invocations that did not hit a provisioned environment (you want this near zero)
Size provisioned concurrency to keep spillover invocations near zero during your target traffic windows.
Auto-Scaling Provisioned Concurrency
Application Auto Scaling supports target tracking for provisioned concurrency based on ProvisionedConcurrencyUtilization. Setting a target utilization of 70% means Auto Scaling will add provisioned concurrency when more than 70% of provisioned environments are in use, giving headroom before requests spill to cold starts.
Combine target tracking with scheduled actions to handle both gradual scaling and known traffic patterns.
Use measured cold-start frequency, peak concurrency, and latency targets to size capacity. Revisit the configuration as traffic changes.