Cutting Lambda cold starts without going all-in on provisioned concurrency

This is a sample post — replace it with a real writeup — but the shape of the fix holds up: provisioned concurrency solves cold starts by paying for warm instances around the clock, which is overkill for a lot of traffic patterns. Two cheaper levers usually get you most of the way there first.

1. Shrink the deployment package

Lambda has to unpack and initialize your whole bundle before your handler runs. Tree-shaking, excluding dev dependencies from the zip, and lazy-requiring anything only used on rare code paths all shrink init time directly.

2. Pick a lighter runtime

Interpreted/JIT runtimes with a smaller startup footprint (Node, Python) generally cold-start faster than JVM-based ones out of the box. If you’re stuck on the JVM, look at SnapStart before reaching for provisioned concurrency — it snapshots an initialized execution environment instead of keeping instances warm.

When provisioned concurrency is still the right call

Latency-sensitive, low-and-steady traffic (a synchronous API a user is actively waiting on) is exactly the case provisioned concurrency was built for — just don’t reach for it as the first lever.