If you've read our cold-start modelling post, you know what the problem looks like. This piece is the companion: what actually fixes it. There are three real options on the table in 2026 — provisioned concurrency, SnapStart (now available for Java, Python, and .NET), and DIY warmers — and they have very different cost-to-effect curves.
The three mitigation tools
- Provisioned Concurrency (PC) — keep N execution environments pre-initialized. Reliable sub-50 ms cold start. Bills per GB-second of provisioned capacity, ~30% cheaper than equivalent always-on duration cost when Savings Plan applied.
- SnapStart — pre-initialise once, restore from snapshot per cold start. ~10× faster cold starts than vanilla. Free to enable. Now supports Java, Python 3.12+, and .NET 8+.
- DIY warmers — EventBridge ping every 5 minutes to keep a function warm. Cheap and crude. Solves the "first request" problem but does nothing for concurrency-driven cold starts.
Cost and effect, simulated
Same Java 21 Lambda, 1024 MB, 50 ms warm execution. Traffic: 5 RPS baseline, 3× spike twice daily.
| Mitigation | Monthly cost | p50 cold | p99 cold | Spike resilience |
|---|---|---|---|---|
| None | $42 | 1.4s | 3.2s | Poor |
| DIY warmer (1 ping/5min) | $45 | 50ms (single-instance only) | 3.2s under spike | Useless |
| SnapStart | $42 (free) | 180ms | 320ms | Good |
| PC = 5 (covers baseline) | $95 | 50ms | 50ms (within PC) | Good for baseline, bad above |
| PC = 5 + SnapStart | $95 | 50ms | 320ms (spike overflow) | Excellent |
When each is right
SnapStart (default)
Java/Python/.NET, no upfront cost, 10× cold-start improvement. Should be default on for almost every JVM Lambda. Engineering tax: minimal.
Provisioned Concurrency
Tight p99 SLOs (<100 ms), known traffic baseline, can't use SnapStart (Node, Ruby, custom runtimes). Pair with auto-scaling for spike coverage.
DIY warmers
Solve a problem that no longer exists in the way they were designed for. Once you have any non-trivial concurrent traffic, warmers don't help. Don't reach for them in 2026.
The combinations that work
- SnapStart + auto-scaling. Default for Java/Python/.NET APIs. Cheap, effective, low engineering tax.
- PC for baseline + auto-scale on top. Best for traffic with a known floor and predictable spikes. PC covers floor; overflow tolerates slightly worse cold starts.
- PC + SnapStart together. Tightest p99 you can get. Worth it for revenue-critical hot paths.
SnapStart's expansion to Python and .NET, plus Provisioned Concurrency under Savings Plans, changes the economics. Most "cold start" posts pre-2025 over-recommend warmers. In 2026, SnapStart-first is the default; PC is the surgical add-on.
Simulating the mitigation on pinpole
On the canvas, the Lambda node exposes PC count and SnapStart toggle. Run a spike traffic pattern and the simulator returns p50/p99 latency with and without each mitigation, alongside monthly cost. The right mitigation surfaces in the diff — usually within two runs.
Cold starts are a solved problem. Most teams haven't updated their solution.
Simulate SnapStart, Provisioned Concurrency, and the combinations on the canvas. Pick the cheapest one that hits your SLO.
Start 14-day free trial →