Cut Your Lambda Cold Starts in Half

A cold start is the delay when Lambda has to spin up a fresh execution environment before your code runs. It hits the first request to a new container, and for latency-sensitive APIs it is the difference between snappy and sluggish. Here is how to bring it down.

Shrink Your Deployment Package

Initialization time scales with how much code and how many dependencies Lambda has to load. A 200 MB bundle full of unused libraries starts far slower than a lean one.

# Bundle only what you use, tree-shake, and drop dev dependencies
esbuild handler.js --bundle --minify --platform=node --outfile=dist/handler.js

Smaller package, faster init. This is usually the biggest single win.

Pick a Faster Runtime for the Cold Path

Interpreted and JIT runtimes that need heavy warm-up (large JVM apps) cold-start slower than lightweight ones. For latency-critical functions, Node.js, Python, or a compiled Go/Rust binary start fastest. You do not have to rewrite everything — just the functions on the hot user path.

Move Work Out of the Handler

Code at module scope runs once per cold start; code inside the handler runs every invocation. Initialize clients and load config outside the handler so warm invocations reuse them:

// Runs ONCE per container — reused across warm invocations
const db = new DynamoDBClient({});

export const handler = async (event) => {
  // Runs every invocation — keep it lean
  return db.send(new GetItemCommand(/* ... */));
};

Use Provisioned Concurrency for Critical Functions

When you cannot tolerate cold starts at all, provisioned concurrency keeps a set number of environments warm and ready:

Lambda → Configuration → Concurrency → Provisioned concurrency: 5

It costs money for the reserved capacity, so apply it only to the few functions that face users directly, not your whole account.

Summary

Cold starts come from Lambda building an environment from scratch. Attack them in order of leverage: shrink the package, choose a fast runtime for hot functions, hoist client setup out of the handler so warm calls skip it, and buy provisioned concurrency only where latency is non-negotiable. Do the free things first — most functions never need to pay for warm capacity.