AWS Lambda : Solving the cold start problems while accessing DB in VPC.
With great power comes great responsibility.
AWS Lambda plays a key role in any of the modern architectures. It can be used to build powerful backend pipelines for websites, apps , build data pipelines for analytical solutions and much more.
It comes with a lot of advantages like reducing dependency on devops teams, continuous deployment, supporting polyglot (ability to use different programming languages like python, java, nodejs etc ). Sounds all good. It also comes with some major challenges like being stateless, cold start problems. In this blog I would like to introduce some of the cold start problems that you may face when using AWS Lambda or any other cloud based FAAS(Function as a service from platforms like GCP, Azure).
What is cold start problem:
In the server based world we have server up and running all the time. In the world of AWS Lambda we bring up the service only when required. The server stays up, running for a short period of time. In case of AWS Lambda it stays alive for maximum of 15 minutes from the last request it served. This reduces cost and also push the responsibility of scaling up and down to AWS, while we can focus on business needs. Sounds all good, not really it also comes with a challenge due to this design. Every time a user hits your backend the Lambda has to be brought up unless it is already running and free. The time that takes for the service to be up in general is around 20 ms. Which should be ideal for a lot of business applications. This gradually increases to 10s in the particular cases, where the Lambda has to access a DB in a VPC. 10s cold start for user facing service is a clear no for a lot of business cases. This problem has made architects rethink the usage of AWS Lambda.
Some of the solutions for AWS Lambda cold start problems:
When we faced a similar problem we started looking into possible solutions. After a lot of research, we identified 3 different solutions with its own pros and cons.
- AWS has announced in the 2018 ReInvent conference, that they are redesigning the AWS Lambda architecture to overcome the cold start problem when accessing database inside a VPC. Sounds good for a company which can bear with the cold start problem till the launch. AWS did not commit to a particular date, but it is expected to be launched anytime this year(2019). If the 10s cold start problem is not acceptable for your use case like us, then this solution of waiting may not work.
- AWS announced last year(2018) Aurora serverless DB. Sounds very exciting. It basically allows architects and DBA teams not to worry about provisioning the right size for DB or worry about scaling the DB up and down. The serverless DB lets you configure your DB to scale up or down based on the business needs automatically. Saving precious dollars to the business. Serverless DB has to be only private by default and can be accessed with AWS Lambda through AWS SDK. If serverless db sounds good for your use case, it also comes with another advantage. It allows AWS Lambda to access serverless DB in a secure way even without having it in a separate VPC. This approach also solves the cold start problem.
- The last solution is to have a seperate Lambda whose core functionality is to access the DB in the VPC. This Lambda alone suffers from cold start problem, which can be temporarily solved by keeping a few instances of Lambda warm. One of the strategy to keep AWS Lambda warm is by using Cloudwatch. All the other Lambda which needs access to DB can do so by accessing the Lambda which alone has access to DB.
Feel free to share if you have solved the Lambda cold start problems using a different approach.