ServerlessArchitecture#04 AWS Lambda Cold Starts#PART-1 When it Occurs and Strategies to Optimize

ServerlessArchitecture#04 AWS Lambda Cold Starts#PART-1 When it Occurs and Strategies to Optimize

One of the great promises of serverless has always been that it would free developers to focus on writing code without having to give too much consideration to the underlying infrastructure. But Infinitely salable nature of serverless come with limitations and unique considerations that you need to take into account.

Among the biggest issues we – a 100% serverless company – have faced, are AWS Lambda cold starts, the extra time it takes for a function to execute when it hasn’t recently been invoked.


To summarize, the blog Use-Cases are:

  1. Cold Start - Is your funciton in a "Sleeping State"?
  2. Do you know Lambda functions are kept warm for a limited amount of time (usually 30-45 minutes)?
  3. Major Issue: Cold starts account for less than 0.25% of requests but the impact can be huge
  4. Strategies To Optimize AWS Lambda function cold starts
  5. Hack the Cold State: Automatic fan-out for initializing concurrent functions - Think like a PING Hacker {lambda:InvokeFunction permissions}
  6. How Bad Lambda Architect You Are? - if you want to keep {several concurrent functions warm}, that you need to {invoke the same function multiple times} with delayed executions
  7. Best advice for reducing cold starts

NOTE: Non-VPC functions are kept warm for approximately 5 minutes whereas VPC-based functions are kept warm for 15 minutes.


Selection_026.png

A cold start will happen when your function is considered to be in a “sleeping state”. This means that when your function has not been executed in the last little while, there is reserved infrastructure behind it. This is done to save you money by only spinning up infrastructure when you need it.

1. Understanding the Cold Start Time Issue

When we invoke a Lambda function for the first time, it downloads the code from S3, downloads all the dependencies, creates a container and starts the application before it executes the code. This whole duration (except the execution of code) is the cold start time.

image.png

A cold start accounts for a significant amount of total execution time, and can significantly affect the performance and latency of your Lambda functions.

To address this issue, AWS launched Provisioned Concurrency for Lambda at re:Invent 2019 to handle these types of use cases, which can warm up the Lambda execution environments in advance. Environments will be available for applications to do immediate code execution, with no need to wait for functions to start up.


NOTES

Lambda functions are kept warm for a limited amount of time (usually 30 – 45 minutes) after executing, before being spun down so that container is ready for any new function to be invoked.

AWS needs a ready supply of containers to spin up when functions are invoked.


Cold starts account for less than 0.25% of requests but the impact can be huge, sometimes requiring 5 seconds to execute the code.

This issue is particularly relevant to applications that need to run executions in real-time, or those that rely on split-second timing.

2. Strategies To Optimize AWS Lambda function cold starts

StrategyAction
Monitor

Put monitoring in place using CloudWatch and X-Ray
and fine tune the timeout values as applicable.
- Both CloudWatch Logs and X-Ray can help you to identify where and when cold starts are occurring in your application.
- It will also help you identify which Lambda cold starts are truly problematic to the smooth running of your application and satisfaction of users,
and which can be safely ignored
Keep Lambdas Warm

Warm Lambdas will always give you faster execution times
- to guard against cold starts, ensure that your Lambdas do not become inactive
- invoke the lambdas at a given interval to ensure that the containers aren’t destroyed.
Reduce development packages

The more packages you use, the longer it will take for the container to load them.
- What makes it even more interesting, is that a lot of your development choices can heavily impact the cold start of your application (e.g.
- the size of your code,
- the number of dependencies,
- the environment of your choice, etc.)
- Tools such as Browserify and Serverless Plugin Optimize can help you reduce the number of packages.
Choose the right language

choice of programming language will have an effect on the length of the AWS Lambda cold start times
In one experiment, Nathan Malishev found that
- Python, Node.js and Go took much less time to initialize than Java or .NET,
- with Python performing at least twice as quickly compared to Java, depending on memory allocation.
- (Source: Lambda Cold Starts, A Language Comparison – Nathan Malishev)
image.png
Get Lambdas out of VPC


Unless it’s really necessary (for instance, to access resources within a VPC)
- try to get your Lambdas running outside of your VPC,
- as the attachment of the ENI interfaces can have a huge impact on Lambda cold start times.
> Yan Cui pointed out in a recent article, while VPCs provide necessary protection to EC2s,
they aren’t required to provide that kind of security to Lambdas.
Learn more about Lambda performance in our guides: AWS Lambda Concurrency
image.png

Hack the Cold State: Automatic fan-out for initializing concurrent functions - Think like a PING Hacker

At a recent AWS Startup Day event in Boston, MA, Chris Munns, the Senior Developer Advocate for Serverless at AWS, discussed Cold Starts and how to mitigate them. According to Chris (although he acknowledged that it is a "hack") using the CloudWatch Events "ping" method is really the only way to do it right now. He gave a number of good tips on how to do this "correctly":

  • Don’t ping more often than every 5 minutes
  • Invoke the function directly (i.e. don’t use API Gateway to invoke it)
  • Pass in a test payload that can be identified as such
  • Create handler logic that replies accordingly without running the whole function

Lambda Warmer will invoke the function multiple times using the AWS-SDK in order to scale concurrency (if you want to). Your functions MUST have lambda:InvokeFunction permissions so that they can invoke themselves. Following the Principle of Least Privilege, you should limit the Resource to the function itself, e.g.:

- Effect: "Allow"
  Action:
    - "lambda:InvokeFunction"
  Resource: "arn:aws:lambda:us-east-1:{AWS-ACCOUNT-ID}:function:my-test-function"

Non-VPC functions are kept warm for approximately 5 minutes whereas VPC-based functions are kept warm for 15 minutes.


How Bad Lambda Architect You Are? - if you want to keep {several concurrent functions warm}, that you need to {invoke the same function multiple times} with delayed executions. This prevents the system from reusing the same container.

3. Conclusion

As we’ve seen, there are a variety of ways to reduce the impact of cold starts, but unfortunately none of them can be relied on to completely solve the problem in every situation.

The best advice is to monitor your application and focus most effort only on the cold starts that have a direct effect on user experience or the smooth running of your application.

Lambda cold start times have become something of an obsession of the first wave of serverless adopters, and that’s not likely to change anytime soon. It’s one of the few niggles affecting a really exciting new way to build software.

But there’s little doubt that Amazon (and the other cloud platform providers) will continue to work away on this problem until it’s no longer an issue.