Cold start billed duration: what initialization really costs you

Quick answer

On AWS Lambda, the initialization phase of a cold start is not billed as duration for functions using the standard on-demand model, but everything it causes is. A cold start adds work that runs inside billed duration: the first invocation pays for connection setup, config fetches, and lazy loading that a warm container skips. At $0.0000166667 per GB-second for x86, a 1 GB function whose first request spends an extra 400 ms fetching secrets and opening a database pool pays about $0.0000067 more for that request. That is trivial once, but a workload with 5 million cold starts a month at 400 ms of extra billed work costs about $33 a month in pure warm-up. The larger costs are indirect: oversized memory bought to shrink cold starts, provisioned concurrency, and retries triggered by cold-start timeouts.

Cold starts are almost always framed as a latency problem. They are also a cost problem, just not in the obvious way. The mental model most teams carry, that you pay for every millisecond the platform spends getting your code ready, is wrong for AWS Lambda's standard on-demand billing: the init phase itself is not charged as duration. What is charged is all the work a cold start pushes into your handler, plus the expensive habits teams adopt to avoid cold starts in the first place.

What you actually pay for

Phase	Billed?	Typical duration
Container provisioning	No	50 to 200 ms
Runtime bootstrap	No (on-demand)	50 to 500 ms
Module import / static init	No (on-demand)	100 ms to 3 s
Work moved into the handler	Yes	100 ms to 1 s
Retry after a cold-start timeout	Yes, fully	Whole invocation again

The boundary matters. If you open a database pool, fetch a parameter from Systems Manager, or decrypt a secret inside your handler, that work happens on every cold invocation and is billed at the full duration rate. Move it above the handler into module scope and it runs in the init phase, which on-demand Lambda does not charge as duration. This single refactor is the cheapest cold-start optimization available and it is free to make.

Putting numbers on it

Lambda charges $0.0000166667 per GB-second on x86 and $0.0000133334 per GB-second on Arm, plus $0.20 per million requests. Take a 1024 MB function that normally runs in 120 ms warm. On a cold invocation it spends an extra 400 ms inside the handler establishing connections and reading config. That extra 0.4 GB-seconds costs $0.0000067. One cold start is noise. The question is how many you have.

Cold starts per month	Extra billed time	Extra cost (1 GB, x86)
50,000	400 ms each	$0.33
500,000	400 ms each	$3.33
5,000,000	400 ms each	$33.33
5,000,000	1,200 ms each	$100.00

A steady, high-volume function has a low cold-start ratio, often under 1 percent, because containers stay warm. The workloads that accumulate real cold-start cost are the spiky ones: a function that goes from zero to 2,000 concurrent executions in a minute creates 2,000 cold starts, and it does that on every spike. Event fan-out, scheduled batch jobs, and traffic that arrives in bursts all produce cold-start ratios in the double digits.

The indirect costs are bigger

The direct billed-duration hit from cold starts is usually small. The decisions teams make in response are not. Three patterns dominate.

First, memory inflation. Because more memory means proportionally more CPU, teams raise a function from 512 MB to 2048 MB to cut init time. That quadruples the per-millisecond rate for every invocation, warm ones included, to fix a problem that affects a small fraction of requests. If a function runs 10 million times a month at 150 ms, going from 512 MB to 2048 MB takes the duration bill from $12.50 to $50.00, and the warm path rarely gets four times faster. Check the real curve before paying for it, the way anymemory right-sizing exercise should.

Second, provisioned concurrency. Keeping environments pre-initialized removes cold starts but converts a usage bill into a capacity bill, charged per GB-second whether or not a request arrives. It is the right answer for latency-critical paths with predictable shape, and an expensive one otherwise. The break-even depends on how many hours a day you actually need the warmth.

Third, timeout retries. A function with a 3 second timeout that takes 2.8 seconds warm will time out on cold invocations. Every timeout burns the full billed duration and then triggers a retry that burns it again. Asynchronous Lambda invocations retry twice by default, so one cold-start timeout can cost three full invocations plus whatever downstream work each attempt performed before failing.

Cheap fixes first

Shrink the deployment package: unused dependencies are imported at init and, more importantly, inflate the time before your code can serve anything. Move connection setup and config loading to module scope. Prefer Arm, which is about 20 percent cheaper per GB-second and often initializes faster for interpreted runtimes, the same saving available to anyGraviton migration. Lazy-load the SDK clients you only need on some code paths. Cache anything fetched from a parameter store in module scope so warm invocations skip it entirely.

Only after those, consider paying for warmth. Measure the cold-start ratio from your logs first: if it is under 1 percent, the cost case for provisioned concurrency is almost never there, and the latency case has to stand on its own. Price the function against theresource catalog at each memory size before you commit to a configuration.

FAQ

Does AWS bill you for Lambda cold start time?

For standard on-demand Lambda, the initialization phase is not charged as duration. What you do pay for is any work a cold start pushes into your handler, such as opening database connections, fetching secrets, or reading configuration, since handler execution is always billed. Moving that work into module scope, above the handler, shifts it into the unbilled init phase.

How much do cold starts add to a Lambda bill?

Directly, very little. At $0.0000166667 per GB-second on x86, a 1 GB function spending an extra 400 ms of billed handler work on each cold start pays about $0.0000067 per cold invocation. Five million cold starts a month at that rate is roughly $33. The indirect costs, oversized memory and provisioned concurrency bought to avoid cold starts, usually dwarf the direct charge.

Why do cold starts cost more on spiky workloads?

Because concurrency growth creates cold starts one per new execution environment. A function scaling from zero to 2,000 concurrent executions produces 2,000 cold starts on every spike. Steady high-volume functions keep containers warm and often see cold-start ratios under 1 percent, while bursty event fan-out, scheduled batches, and irregular traffic can see double-digit percentages.

Should I increase Lambda memory to reduce cold starts?

Usually not for cost reasons. Raising a function from 512 MB to 2048 MB quadruples the per-millisecond rate for every invocation, including the warm majority, to improve a small fraction of requests. A 10 million invocation per month function at 150 ms goes from about $12.50 to $50.00 in duration charges. Measure the actual duration curve at each memory size before paying for the change.

How do cold-start timeouts multiply cost?

A function sized so that warm execution nearly reaches its timeout will time out on cold invocations. Each timeout bills the full duration and then triggers a retry. Asynchronous Lambda invocations retry twice by default, so one cold-start-induced timeout can cost three complete invocations plus any downstream work each attempt performed before failing.

How does C3X help with cold start cost decisions?

C3X prices Lambda configuration from Terraform before deployment, so memory size, architecture, and provisioned concurrency settings show their cost in the pull request. That makes it obvious when a memory bump aimed at cold starts quadruples the bill for every warm invocation, and lets you compare Arm against x86 and on-demand against provisioned concurrency at design time.

What to do next

Know what a Lambda configuration costs before you ship it. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.