Cutting Serverless Cold Start Time Without Rewriting Everything

A larger deployment package takes longer to download and initialize on a fresh execution environment, and this is often the single biggest lever available without any architectural change. Audit your function's dependencies for anything unused or only needed at build time, and split large, infrequently changed dependencies into a separate layer where your platform supports it, so a code change doesn't force re downloading dependencies that didn't actually change.

Measure the actual before and after cold start time when trimming package size, not just the package size itself. The relationship between package size and cold start time isn't perfectly linear, so it's worth confirming a given trimming effort is actually moving the number that matters.

Different language runtimes have meaningfully different baseline cold start characteristics, and a function written in a runtime with a heavier startup cost will carry that cost on every cold start regardless of how well tuned the rest of the code is. This isn't always worth rewriting an existing function over, but it's worth factoring into the decision for a new, latency sensitive function.

Code that runs at module load time, outside the actual handler function, executes on every cold start and adds directly to that latency. Move anything that isn't strictly required for the first invocation, a connection that can be lazily initialized, an expensive computation that could be cached instead, out of module load time and into the handler where it only runs when actually needed.

A function that opens a fresh database connection on every single invocation pays that connection cost repeatedly even on warm starts, not just cold ones. Initialize expensive resources, a database connection, an SDK client, outside the handler function but check for their existence before reinitializing, so a warm invocation reuses what a previous invocation already set up rather than repeating the work.

Be careful with this pattern against a connection pool ceiling, since a serverless function scaling out to many concurrent instances can each hold their own connection and collectively exhaust a downstream database's connection limit quickly, which connects directly back to the connection pooling problem covered elsewhere in this guide.

Provisioned concurrency keeps a set number of execution environments warm and ready, eliminating cold starts entirely for traffic within that provisioned capacity, at the direct cost of paying for that capacity whether or not it's actively being used. This is worth it specifically for a latency sensitive path with predictable minimum traffic, not for a function that runs rarely and can tolerate an occasional slower cold invocation.

Size provisioned concurrency against your actual traffic pattern's baseline, not its peak, and let burst traffic above that baseline fall back to on demand cold starts. Provisioning for peak traffic that only happens briefly each day usually costs far more than the latency problem it's solving is actually worth.

It's easy to make several of these changes at once and lose track of which one actually moved the needle. Change one thing at a time where practical, package size, then module load code, then connection reuse, and measure cold start latency after each change against a consistent baseline, so you know which fixes are worth carrying into your other functions and which weren't worth the effort.

Set a concrete target tied to what actually matters for the function's use case, a page load waiting on this function, an event that needs to process within a specific window, rather than chasing the lowest possible cold start time for its own sake. A function well within its actual latency budget doesn't need further optimization just because the number could theoretically go lower.

Work through the fixes in this order, measuring after each:

1. Trim package size by removing unused or build time only dependencies, and split large, stable ones into a separate layer where supported.
2. Move unnecessary work out of module load time, and factor runtime startup cost into decisions about new functions.
3. Initialize database connections and SDK clients outside the handler, and reuse them on warm invocations.
4. Pay for provisioned concurrency only on latency sensitive paths with predictable minimum traffic.
5. Record cold start latency against a consistent baseline after every change, so you know which fixes are worth repeating.