How does AWS Lambda's provisioned concurrency mitigate cold starts, and what are the cost and operational trade-offs of relying on it versus letting the platform auto-scale on demand?

## What the feature actually does **Provisioned concurrency** is AWS Lambda's mechanism for eliminating cold starts on a bounded slice of traffic by paying to keep environments pre-warmed continuously, rather than waiting for real invocations to trigger environment creation. Mechanically, when you configure provisioned concurrency for `N` on a specific function version or alias, Lambda immediately and continuously initializes `N` execution environments ahead of any traffic: - it provisions the microVMs; - it boots the runtime; - it runs your function's init-phase code (imports, static blocks, DI wiring, connection pool setup); so all `N` environments sit in a *warm and idle* state, ready to be invoked with zero setup latency the moment a request routes to them. As long as concurrent demand stays at or below `N`, every invocation is served by one of these already-initialized environments — the caller experiences only the handler's actual execution time, with the cold-start tax already paid up front and amortized across all subsequent invocations. ## The problem it buys off **Why this exists.** Some workloads simply cannot tolerate the occasional multi-second cold start that a standard on-demand Lambda might incur, particularly synchronous, user-facing, or latency-SLA-bound endpoints (a mobile app's login call, a payment authorization API) where an occasional 2-3 second stall is a customer-visible failure, not just a metric blip. Standard Lambda pricing lets you pay nothing when idle, but that flexibility is precisely what causes cold starts — there is no free way to guarantee *always instantly ready* without paying for readiness continuously, and provisioned concurrency buys exactly that guarantee, function by function. ## The trade-off The trade-off is the core of what makes this an interesting architectural decision rather than a free win. **First, cost model.** Provisioned concurrency is billed for the duration it's configured, per GB-second at a separate rate, regardless of whether it's actually invoked — an over-provisioned pool wastes money in exactly the way serverless is supposed to avoid, and this can eat into or exceed the cost savings that justified going serverless. Sizing it correctly requires understanding real traffic patterns (peak concurrency, not just average throughput), which reintroduces capacity-planning burden — teams commonly pair it with **AWS Application Auto Scaling** target-tracking or scheduled scaling policies to raise the provisioned pool ahead of known traffic patterns (e.g., before a 9am ramp), which itself is an operational surface to build, test, and monitor. ## Coverage is bounded **Second, coverage is bounded, not absolute.** Provisioned concurrency only guarantees warm environments up to `N` concurrent executions. If real traffic bursts past `N`, the overflow falls back to standard on-demand scaling and cold-starts normally — so provisioned concurrency reduces the cold-start rate, it does not categorically eliminate cold starts unless `N` is provisioned generously above realistic peak (which costs more). Teams need monitoring on metrics like `ProvisionedConcurrencyUtilization` and `ProvisionedConcurrencySpilloverInvocations` to know whether their pool is actually sized correctly, not just assume the feature solved the problem once configured. ## Deployment interaction **Third, deployment interaction.** Provisioned concurrency is tied to a specific published function version or an alias pointing to one — not to `$LATEST`. Every new deployment requires either 1. pre-warming a new version's provisioned pool before shifting traffic to it (e.g., via a weighted alias and gradual traffic shift, similar to a blue/green rollout), or 2. accepting that the cutover moment reintroduces cold starts until the new pool finishes initializing. Teams that naively update an alias to point at a freshly deployed version without waiting for its provisioned concurrency to finish initializing effectively defeat the feature during every release window — a subtle and common failure mode. ## In the field A concrete real-world scenario: a ride-hailing company's driver-matching API on Lambda had a strict p99 latency SLA because a slow match directly affected user-perceived reliability. They set provisioned concurrency sized to their historical p99 peak concurrent request count during rush hours, paired with a scheduled Application Auto Scaling policy that raised the pool ahead of morning and evening rush and lowered it overnight to control cost, and used a canary/linear deployment strategy via an alias with traffic shifting so the new version's provisioned pool was fully warmed before receiving production traffic. This cut cold-start-driven SLA violations to near zero during known peak windows, while still letting cost scale down during predictably quiet hours — an explicit acknowledgment that pure on-demand elasticity and zero-idle-cost weren't compatible with their latency requirements, so they bought back predictability where it mattered and let the rest of the system stay elastic.