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

We recently launched an open source project called X-Lambda. 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.

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

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. This metric is only available for functions with a reserved concurrency setting, 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:

{
    "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 on Dashbird (requires no credit card). Then, integrate Dashbird with your AWS account.

And voilá, Dashbird will automatically start monitoring your AWS Lambda functions. I strongly advise to setup alerting channels (email and/or Slack channel) alerts, so that you get notified 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. If you’d like to keep an eye on the project evolution, subscribe to our newsletter (bottom of the page).