AWS Lambda Cold Starts - Causes and Fixes

A DevOps interviewer asks this to see if you understand Lambda's execution model or just repeat blog-post advice. Cold starts are one of those topics where candidates often know a folk remedy (keep-warm pings) without understanding why it stopped working years ago.

The answer interviewers want

A cold start happens when Lambda has to spin up a fresh execution environment because no pre-warmed instance is available to handle the incoming request. The runtime matters a lot here. Java and .NET are the worst offenders for cold start latency, while Python and Node.js are much faster to initialize.

The real fix in production is Provisioned Concurrency. It pre-initializes a set number of execution environments ahead of time, so requests hitting those environments see zero cold start. For latency-sensitive or customer-facing functions, this is the actual answer, not a workaround.

What a lot of engineers miss: keep-warm pings (scheduling a dummy invocation every few minutes to keep one container alive) don't help once you have a real concurrency spike. A single warm container can only serve one request at a time. When traffic spikes and Lambda needs to handle multiple concurrent invocations, it still has to spin up new containers to meet that demand, and those new containers cold start regardless of your keep-warm pings. The ping hack only ever protected against the single idle-container case, which is not the scenario that actually hurts you in production.

So the answer an interviewer wants is: cold starts are caused by new environment initialization, runtime choice affects how bad they are, and Provisioned Concurrency is the only mechanism that reliably eliminates them for the functions that need it.

Why interviewers ask this

This question separates people who've read a Lambda overview from people who've actually run Lambda under real traffic patterns. It also tests whether you understand concurrency, not just a single invocation, since the keep-warm misconception only breaks down once you think about simultaneous requests.

Follow-ups to expect

Why do Java and .NET cold start slower than Python or Node? The source doesn't go into JVM/CLR internals, but the practical takeaway is runtime choice is a real lever: if cold starts are a problem, an interpreted, lighter-weight runtime will generally initialize faster than Java or .NET.

Would you put Provisioned Concurrency on every function? No, you'd target it at the functions where cold start latency actually matters to users, like synchronous, customer-facing paths, rather than applying it blanket across every Lambda in an account.

What happens during a traffic spike even with keep-warm pings in place? New containers still get spun up to meet the extra concurrent demand, and those still cold start, which is exactly why pings don't solve the problem at scale.

The common wrong answer

Most candidates answer with "just ping the function every few minutes to keep it warm." It sounds like a reasonable, battle-tested trick, and it does help in a narrow case with low, steady traffic and no concurrency. But it falls apart the moment traffic spikes, because Lambda still has to cold start additional containers to handle concurrent requests beyond the one warm instance. Saying this without the concurrency caveat signals you haven't actually debugged this in production.