Lambda has a much-discussed feature: cold starts. It’s the “price” sometimes paid for the on-demand model from subchapter 14.1. In this subchapter, you’ll understand what they are, why they happen, and what you can do to reduce their impact.

Remember how Lambda works: your code is not always running, but AWS starts it up when an event arrives. Well, that startup has two scenarios:

• Cold start: it’s the first time the function is invoked (or after a while without use). AWS has to prepare the environment from scratch: reserve resources, load your code, initialize the runtime (Python, Java...), load libraries. This adds an extra delay, usually a few hundred milliseconds to a couple of seconds.

• Warm start: if the function was used recently, AWS reuses the environment that was already prepared. Here there’s no preparation delay: the function responds instantly.

Analogy: a cold start is like starting a car on a winter morning: the cold engine takes a bit to get going. Once it’s running (warm), you start and accelerate instantly. If you leave it parked for a while, it cools down again.

The impact of cold starts depends on the type of application:

• It matters in interactive applications where the user expects a quick response (an API responding to a mobile app). A 1-2 second delay on the first request can be noticeable.
• It doesn’t matter for background or asynchronous tasks (processing an uploaded file, draining a queue). If the task takes a few extra seconds to start, nobody is affected.

It also depends on the language: lightweight runtimes like Python or Node.js have short cold starts; heavier runtimes like Java or .NET start up more slowly (though there are techniques to improve this).

This is the most direct solution: you tell AWS to keep a number of environments always warm and ready, waiting for requests. Thus, those invocations never suffer a cold start.

It’s like having several cars with the engine already running in the parking lot, ready to go. The trade-off: you pay to keep them warm (even if unused), so it’s used when first-request latency is critical.

A simple technique: schedule an invocation every few minutes (with CloudWatch, see subchapter 14.2) so the environment doesn’t cool down. It’s a cheap trick, though less reliable than provisioned concurrency, especially if there are many simultaneous requests.

The less code and libraries AWS has to load, the faster the startup. So it’s advisable to:

• Include only the libraries you actually use (see subchapter 14.3).
• Use layers to avoid inflating the package.
• Avoid unnecessary heavy dependencies.

If cold start is critical and you can choose the language, Python or Node.js usually start up faster than Java or .NET. (For Java there are specific optimizations, but by default it’s heavier.)

What you put outside the handler (connections, configuration) runs only once per environment and is reused in warm starts. Using this well avoids repeating costly work on every invocation:

Not at first. For most applications, occasional cold starts are perfectly manageable, and runtimes like Python or Node make them very bearable. Worry about them only if you have an interactive application sensitive to latency and you measure that cold starts bother users. Then apply provisioned concurrency and the other strategies. Remember: optimizing before you have a measured problem is usually wasted time.

• A cold start is the extra delay the first time a Lambda is invoked (or after a while without use), because AWS prepares the environment from scratch. In warm starts that environment is reused and there’s no delay.
• It matters in interactive applications sensitive to latency; it doesn’t matter in background tasks. Lightweight runtimes (Python, Node) start up faster.
• Strategies: Provisioned Concurrency (environments always warm), periodic invocations, reduce package size, lightweight runtime, and initialize connections outside the handler to reuse them.
• Don’t obsess at first: optimize cold starts only if you measure that they truly affect your users.

In the last subchapter of the chapter, we’ll look at Lambda’s limits and antipatterns: when Lambda is not the right tool.