Strategies for Optimizing AWS Lambda Cold Starts
Tags: aws, lambda, serverless, cloud
Published: 2023-04-30 18:28:31

This article was originally authored by "Ismael Messa" on NumericaIdeas's [blog](https://medium.com/r/?url=https%3A%2F%2Fblog.numericaideas.com%2Flambda-cold-starts-optimization-strategies):

{% embed https://blog.numericaideas.com/lambda-cold-starts-optimization-strategies %}

## Introduction
**Cold Starts**, which refer to the delay in starting a Lambda invocation, are a common issue encountered by **Serverless** platforms. In situations where low latency is essential, Cold Starts can disrupt the smooth operation of workloads. To address this problem, various strategies have been developed, including **Lambda SnapStart**, **Provisioned Concurrency**, and **Custom Warmer**, each with its own approach. This article aims to compare and contrast these three strategies based on various factors.

The YouTube Channels in both English (En) and French (Fr) are now accessible, feel free to subscribe by clicking [here](https://www.youtube.com/@numericaideas/channels?sub_confirmation=1).

## Lambda SnapStart
### How it Works
As previously mentioned, **SnapStart** is a performance optimization technique designed to reduce the initialization time of a Lambda function. This strategy is fully supported by AWS and works by creating a snapshot of the function during the version release process. When the function is subsequently invoked, the cached version is reused, effectively preventing Cold Starts. By using SnapStart, **Cold Starts** can be improved by up to **90%**.

### Pricing
SnapStart is a **free** feature and does not require any additional cost.

### Supported Runtime
It's available for only Java(11) runtime (Correto) at the moment.

### Complexity to Set Up
It can be accessed via the **AWS console** and does not necessitate any modifications to your source code. Simply activate the feature and let it work its magic.

### Limit
One implication of using SnapStart's snapshot resuming approach is that ephemeral data or credentials may not have any expiry guarantees. This means that if your code utilizes a library that generates an expiring token at the function level, it could expire when a new instance of the function is launched via SnapStart.

Moreover, if your code establishes a long-term connection to a network service during the **init phase**, the connection will be lost during the invocation process.

Here's a more detailed article that covers its impacts and how to set it up:
{% embed https://blog.numericaideas.com/lambda-performance-improvement-with-snapstart %}

## Provisioned Concurrency
### How it Works
**Provisioned Concurrency** is an AWS feature that keeps your function warm and ready to respond in a matter of milliseconds at the scale you specify. With this feature enabled, you can select the number of instances of your function that run concurrently to handle incoming requests, rather than relying on Lambda to launch new instances as requests arrive (in-demand).

The distinctive aspect of Provisioned Concurrency is its rapid startup time, which is attributed to the fact that all setup processes, including the initialization code, occur before invocation. This ensures that the function remains in a state where your code is downloaded and the underlying container structure is configured. It is worth noting that this feature is only available with published versions or aliases of your function.

### Pricing
There are additional costs related to it :
- You pay for **how long** provisioned capacity is active.
- You pay **how many** concurrent instances should be available.

### Supported Runtime
It is available for all runtimes.

### Complexity to Set Up
The **Provisioned Concurrency** option can be accessed via various channels, including the AWS Console, Lambda API, AWS CLI, AWS CloudFormation, or Application Auto Scaling, and does not require any modifications to the existing source code.

### Limit
Provisioned Concurrency is not supported with [Lambda@Edge](https://aws.amazon.com/lambda/edge/).

## Custom Warmer
### How it Works
The **Custom Warmer** strategy aims to prevent **Cold Starts** by keeping the function warm through a **pinging mechanism**. This is achieved by utilizing [AWS EventBridge Rules](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-rules.html) to schedule function invocations at regular intervals. By selecting a specific frequency, typically every **15 minutes**, the function is automatically triggered, ensuring that it remains warm.

Also, it's generally implemented by some open-source libraries but you are free to built a custom one manually.

### Pricing
No cost is required! There are no additional charges for rules using **Amazon EventBridge**.

### Supported Runtime
You can use it with any runtime you need.

### Complexity to Set Up
To implement a Warming strategy, some changes to the source code are necessary since the Warmer triggers a function invocation after a specific period.

The function needs to identify whether it is a call from the Warmer and adjust its behavior accordingly, as demonstrated in the following example:

![Warmer Call Checker - NodeJS](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/267sfhy9ewkszuxf35q3.png)

A sample implementation is available in the following [repository](https://github.com/numerica-ideas/ni-microservice-nodejs) with the **NPM** script `npm run job:warm:env`.

{% embed https://github.com/numerica-ideas/ni-microservice-nodejs %}

### Limit
It is important to note that this approach does not guarantee a complete elimination of Cold Starts. For instance, if the function is behind a **Load Balancer**, it may not always be effective since the LB can direct traffic to instances that are not warmed. Additionally, in production environments where functions **scale out** to handle increased traffic, there is no assurance that the new instances will be warmed up in time.

- - - - - - -

We have just started our journey to build a network of professionals to grow even more our free knowledge-sharing community that'll give you a chance to learn interesting things about topics like cloud computing, software development, and software architectures while keeping the door open to more opportunities.

Does this speak to you? If **YES**, feel free to [Join our Discord Server](https://discord.numericaideas.com) to stay in touch with the community and be part of independently organized events.

- - - - - -

If the **Cloud** is of interest to you this [video](https://www.youtube.com/watch?v=0II0ikOZEYE) covers the 6 most **Important Concepts** you should know about it:
{% embed https://www.youtube.com/watch?v=0II0ikOZEYE %}

**Important**: other articles are published on NumericaIdeas's [blog](https://blog.numericaideas.com/).
{% embed https://blog.numericaideas.com/ %}

## Conclusion
In summary, each of these strategies has its own unique approach to mitigating Cold Starts:

- **SnapStart** takes advantage of the SnapShots technique.
- **Custom Warmer** implements a scheduled ping mechanism.
- **Provisioned Concurrency** uses provisioned functions instances.

It should be noted that **Cold Starts** are not a critical issue for most functions, as they occur in only about **1% of invocations**. Nonetheless, we hope to have covered the significant differences between these strategies. If you have any suggestions or comments, please feel free to share them in the comments section below.

Thanks for reading this article, recommend and share if you enjoyed it. Follow us on [Facebook](https://www.facebook.com/numericaideas), [Twitter](https://twitter.com/numericaideas), [LinkedIn](https://www.linkedin.com/company/numericaideas) for more content.