Your first Lambda call takes three seconds and users notice

You shipped an API on AWS Lambda because it scales itself and you only pay when it runs. Then a customer refreshes a page that has been quiet for ten minutes, and the first request takes three seconds while nothing appears to happen. It is not your database and it is not the network - it is a cold start. AWS had to build a fresh execution environment before your code could run, and your user felt every millisecond of it. Cold starts are the tax serverless charges for scaling to zero. The good news: most of that tax is optional, and the part that is not has a precise price you can decide to pay.

What a cold start actually is

When a request arrives and no warm environment is free, Lambda has to create one from scratch. That means downloading your deployment package, starting the language runtime, and running your initialization code - the module imports, the SDK clients, the database connection setup that runs once before your handler. Only then does your function handle the request. When the environment is reused for the next request - a warm start - all of that is already done, and the call is fast.

The confusing part is that cold starts are invisible in your averages. Ninety-five percent of requests hit warm environments and return in 40 milliseconds, so your dashboard looks healthy. But the 5% that hit a cold start take two or three seconds, and those are disproportionately the requests a real user is waiting on - the first click of the day, the checkout after a lull. Your p99 latency, not your average, is where cold starts live, and p99 is what people actually feel.

When cold starts matter, and when they do not

Not every Lambda needs to care. Spending money to fix a cold start on a job nobody waits for is waste. The distinction is who is waiting:

• They matter for synchronous, user-facing paths: an API behind a web or mobile app, a login flow, a checkout, anything where a human is staring at a spinner. They also bite on sudden spikes, when a burst of traffic forces many new environments at once.
• They rarely matter for asynchronous and batch work: processing a queue, a nightly report, an event handler that writes to a database. A two-second cold start on a job that runs for thirty seconds and nobody is watching is noise.

So the first move is not a fix at all - it is triage. Find the functions on a user's critical path, and ignore cold starts everywhere else. This is the same cost-versus-latency thinking that decides Lambda versus ECS for a workload in the first place: the right tool depends on the traffic shape.

Cut cold starts for free before you pay for anything

Most teams reach for provisioned concurrency first. Do the free work first - it often makes the paid option unnecessary, and it makes it cheaper if you still need it.

• Shrink the deployment package. A smaller artifact downloads and initializes faster. Drop unused dependencies, avoid pulling in a whole SDK when you need one client, and bundle only what the function runs.
• Do less in init. Initialization runs on every cold start. Move heavy work out of the module top-level, create SDK clients lazily, and do not open connections you might not use on this request.
• Right-size memory. On Lambda, more memory also means more CPU, so a function can init and run faster at 512 MB than at 128 MB - and sometimes cost less overall because it finishes quicker. Measure it rather than guess.
• Pick a lighter runtime. Interpreted runtimes like Python and Node start faster than JVM-based ones for the same work. If cold start is your constraint and you have a choice, the runtime matters.

These four levers routinely turn a three-second cold start into a few hundred milliseconds - enough that many user-facing APIs never need to pay for warmth. The same instinct to trim before you scale applies across serverless, as in our guide to Lambda for e-commerce.

Provisioned concurrency: what you are buying, and when

Provisioned concurrency tells Lambda to keep a fixed number of execution environments initialized and ready. Requests up to that number skip the cold start entirely and start warm. The trade is money: you pay for those environments continuously, whether traffic arrives or not, which is the opposite of the pay-per-use promise that made Lambda attractive.

That trade is worth it in a specific shape of workload: latency-critical and reasonably predictable. A customer-facing API with steady daytime traffic, a checkout service during business hours, an endpoint with a strict latency SLA - these justify keeping a floor of warm environments sized to your normal concurrency. Pair it with scheduled scaling so you hold more capacity during peak hours and less overnight, and the provisioning follows your real traffic curve instead of a flat, always-on cost.

It is the wrong tool for spiky, unpredictable, or background work. If traffic is bursty and rare, you will pay for warm environments that sit idle most of the day to save a cold start that happens occasionally - the math rarely works. And if nobody is waiting on the response, you are buying speed no user will ever notice. When the traffic pattern is that unpredictable or heavy, that is often the signal to weigh a container platform instead, the way we frame Fargate versus EC2 for containers and the serverless-versus-provisioned database choice.

Cold starts are one part of a latency budget

Fixing cold starts in isolation misses the point. What a user experiences is the whole chain: cold start plus your function's own work plus every downstream call it makes. A warm Lambda that then waits on three serial database queries and an external API is still slow. Treat cold start as one line item in a latency budget for the request, and spend your effort where the biggest number is. For AI workloads especially, the same discipline - measure perceived latency, attack the largest contributor first - is what we lay out in cutting AI agent latency. The goal is not zero cold starts; it is a request that feels fast to the person waiting on it.

Frequently asked questions

Does "keep-warm" pinging the function still work?

Pinging a function on a timer to keep one environment alive was a common hack, and it helps a single-concurrency, low-traffic function a little. But it does not help under real concurrency - one warm environment does nothing for the tenth simultaneous request, which still cold-starts. For anything user-facing at scale, provisioned concurrency is the supported, predictable answer; keep-warm is a fragile workaround.

How much can free optimizations really cut?

Often enough to matter on their own. Trimming a bloated package and moving heavy setup out of the init phase can take a multi-second cold start down to a few hundred milliseconds. That is frequently the difference between "users complain" and "nobody notices", with no ongoing cost. Always exhaust these before turning on provisioned concurrency.

Is provisioned concurrency the same as reserved concurrency?

No, and the names are easy to confuse. Reserved concurrency caps how many concurrent executions a function can use - it is about limiting and guaranteeing capacity. Provisioned concurrency pre-initializes environments so they start warm - it is about latency. You can use both: reserve a ceiling and provision a warm floor.

Will moving off Lambda make cold starts disappear?

A long-running container does not cold-start per request, so for constant, latency-critical traffic a container platform can be both faster and cheaper than heavily provisioned Lambda. But you take on scaling and patching that Lambda handled for you. The honest answer is that it depends on your traffic shape - which is exactly the comparison to run before you assume serverless is the problem.

The short version: a cold start is real, but it is not a mystery and it is not always your problem. Find the functions users wait on, cut what you can for free, and pay for provisioned concurrency only where predictable, latency-critical traffic justifies it. If you want that profiled properly, our AWS consulting and cloud consulting teams do it as a matter of course.