Typically, the overhead in starting a Lambda invocation — commonly called a cold start — consists of two components.
The first is the time taken to set up the execution environment for your function’s code, which is entirely controlled by AWS.
The second is the code initialization duration, which is managed by the developer — yes, you and me.
This is impacted by code outside of the main Lambda handler function, and is often responsible for tasks like setting up database connections, initializing objects, downloading reference data, or loading heavy frameworks like Spring Boot. According to the analysis done by folks at AWS, this causes by far the largest share of overall cold start latency. It also cannot be automatically optimized by AWS in a typical on-demand Lambda execution.
AWS Microservices developers often complain about a constant delay when invoking an endpoint connected to their lambda functions. Well, this is due to the **cold start **issue in lambdas. But there are ways to overcome this challenge in a very cost-effective manner.
I have recently experimented with one such solution for my own microservice running in AWS lambda. I use a Serverless framework for deploying resources and setting up roles and deploying my lambda functions.
Below is my functions block in serverless.
Image of serverless.yml functions block
In this, I have two different lambda functions that create an auction and another one lists all existing auctions from my DynamoDB database. If you notice, I have used **Amazon Event Bridge **to map one of my lambda functions. This will allow **getAuctions **function to invoke itself with a warmup event of name — get-auctions-warmer.
Since this event is scheduled to run every 5 minutes, it will invoke getAuctions lambda function every 5 minutes and keep it warm.
But, isn’t this going to unnecessarily run my lambdas and increase cost?
Actually, for that, I have utilized a node package called — lambda-warmer. Also, in the getAuctions.js handler I have one piece of code that helps me avoid getting billed for warmup executions. You just need to install this package and import in your handlers which you wish to keep warm.
Handling warmup events in lambda handler
Now, every time warmup events are detected by this handler, it will simply return and not run the business logic defined further down in the handler. This will prevent too much execution time of the lambdas and hence preventing too much increase in cost.
Cloudwatch logs showing warmup event recieved
In Cloud watch logs, you can see once warmup event is received, it contains an action — warmer. This is detected by the package lambda-warmer utility — warmer(event). Due to this, now the lambda container need not be reinitialized every time an API call is made via any event — manual trigger or API Gateway. In my case, it is API Gateway.
Improved performance can be achieved by using lambda warmers
Let us have a look at the execution time when calling an API that invokes **getAuctions **without using warmer event bridge.
2.7 seconds without lambda warmer
According to AWS docs, it can take up to 5 seconds if invoking the lambda for the first time. Also, if a lambda function is kept idle for more than 15 minutes the existing container of that lambda dies. After that, if the same lambda is invoked, again it can take up to 5 seconds to return a response unless it is a long-running function, in which case one should not consider using warmers.
Now let's see the API performance when using lambda warmers.
Approx. 700 milliseconds execution time with warmer deployed
Woo hoo! Look at the time it took once I configure lambda-warmer for — **getAuctions **function — 700 milliseconds. The reason for this is that the getAuctions lambda container is not reinitialized every time it is invoked.
Hence, lambda warmer can help microservices developers like you (and potentially me) to build performant services in the AWS ecosystem.
More About The Author😄
I am a full-time software engineer with 4+ years of experience in Python, AWS, and many more technologies. I have started writing recently as it helps me to read more. I am looking forward to sharing technical knowledge and my life experiences with people out there.
Register Here for my Programmer Weekly newsletter where I share interesting tutorials, python libraries, and tools, etc.
Github | LinkedIn | Twitter | Facebook | Quora | Programmer Weekly