4 Steps to Solve Lambda Cold Starts
Tags: awslambda, serverless, coldstart
Published: 2019-07-08 14:09:29

---
title: 4 Steps to Solve Lambda Cold Starts
published: true
description: This is a step-by-step guide to implementing a winning strategy to keep your AWS Lambda functions warmed up, mitigating cold start latency issues.
tags: AWS Lambda, Serverless, Cold Start
---

If you love serverless and AWS Lambda, you probably also hate cold starts. This is a step-by-step guide to implementing a winning strategy to keep your AWS Lambda functions warmed up, mitigating cold start latency issues.


# Anatomy of cold starts

We know our Lambda functions run inside micro-containers. When a new invocation comes in, AWS will spin up a new container, load our code and dependencies in memory, only to then serve the incoming request. After it's done, this container will be kept alive for some time (from 5 minutes to a couple of hours). If a new invocation is received in the meanwhile, AWS won’t have to spin up a new container.

The first invocation in the story above was a "cold start". The second was in "warm state". The problem with a cold start is that it adds latency and inconsistency, which can be detrimental to the user experience.


# X-Lambda power to the rescue

![Ice cubes on fire](https://thepracticaldev.s3.amazonaws.com/i/hoatgeadvkwmvfulemc6.jpg)

We recently launched an open source project called [X-Lambda](https://github.com/dashbird/xlambda/). Here’s what it does in a nutshell:

1. Tracks of your Lambdas' invocation history;
2. Use statistics to predict short-term container demand for your functions;
3. Invoke Lambdas concurrently, on a scheduled basis, to keep just the right number of containers warmed up;

Below is a step by step guide to implement it in your AWS account. Before we dive in, go ahead and download or clone the project from our [public repo](https://github.com/dashbird/xlambda/).

> _Beware that the project is still in alpha, so we don’t recommend to rely on it for mission-critical, production applications._


## 1. Which functions to keep warm

![Fire](https://github.com/dashbird/xlambda/raw/master/images/fire.png "Fire")

In the `xlambda-config.yml` file, under `lambda_functions`, list the functions you want to keep warm.

X-Lambda relies on the _ConcurrentRequests_ measure from the CloudWatch API endpoint [GetMetricsData](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_GetMetricData.html). This metric is only available for functions with a [reserved concurrency setting](https://docs.aws.amazon.com/lambda/latest/dg/concurrent-executions.html), so the functions you list here will need to have this setting in place.

Also keep in mind that, in order to keep your functions warm, X-Lambda will need to invoke them from time to time (every 15 minutes by default), which will naturally cost money. We recommend to focus on the Lambdas you **really** need to keep warmed up, otherwise, it’s a waste of resources.


## 2. Customize scaling options

In the same `xlambda-config.yml` file, customize the scaling options.

Under `scaling`, you’ll find three parameters. They will be applied globally to all your functions:



*   `min_containers`: minimum number of containers to keep warm at every round;
*   `max_containers`: same as above, but a maximum threshold;
*   `max_concurrency`: limit the number of concurrent requests X-Lambda will send to your Lambdas, allowing you to control how much of your concurrency quota is consumed;

In the functions list, you can also set these parameters for each function, customizing the X-Lambda behavior on a per-function basis.


## 3. Minor adjustments to our function’s code to handle warming requests

X-Lambda will invoke your functions on a scheduled basis to keep them warm. It will send this JSON payload:

```json
{
    "xlambda": {
        "action": "warm_up",
        "settings": {
            "startup_time": 1234 # Milliseconds
        }
    }
}
```

We recommend setting a conditional check early in your Lambda handler to skip the execution of your code when X-Lambda is calling it.

You also need to make sure your function sleeps for the time set in the `startup_time` parameter (values come in milliseconds) before terminating the execution. This is important to make sure warmed up containers are not going to be reused during the warming process.


## 4. Make sure everything is running as expected

AWS Lambda is a beast in itself. Its massive scalability and idiosyncrasies (timeout and memory limits, for instance, can cause trouble) coupled with a pile of things that can go wrong in any application makes it hard to monitor and maintain the health of any serverless application.

In order to do that, first [create a free account](https://dashbird.io/register/) on Dashbird (requires no credit card). Then, [integrate Dashbird](https://dashbird.io/docs/get-started/quick-start/) with your AWS account.

And _voilá_, Dashbird will automatically start monitoring your AWS Lambda functions. I strongly advise to [setup alerting channels](https://dashbird.io/docs/user-guide/integrations/) (email and/or Slack channel) alerts, so that you [get notified](https://dashbird.io/docs/user-guide/alerting/) when things go south.


# Wrapping up

X-Lambda is in its early days and has room for lots of improvements. We are open to suggestions and contributions. You are welcome to interact with us on the [project issues page](https://github.com/dashbird/xlambda/issues). If you’d like to keep an eye on the project evolution, [subscribe to our newsletter](https://dashbird.io/#mc-embedded-subscribe-form) (bottom of the page).