Cold starts
A Lambda function runs on top of some virtual infrastructure. Before the handler code can be executed, the infrastructure has to be set up: a container needs to be provisioned, code and dependencies need to be copied onto it and other startup operations need to happen. This is known as a cold start.
Reasons
- Instead of using statically typed programming languages like Java and C#, you may prefer dynamically typed languages like Python, Node.js
- If you don’t have any obligation, avoid putting your Lambdas in VPC. VPC will definitely add some time to invocation and might cause a cold start
- Making HTTPS calls inside your lambda might cause cold starts. SSL handshake and other security-related calls are CPU bound and might create cold starts to your function. So use those wisely!
- If you prefer Java for your AWS Lambda functions, you should definitely avoid dependencies that scan classpaths, like Spring. This is an open invitation to a cold start. Moreover, loading classes of the Java function will take some time and might cause a cold start
When Cold Starts happens
- A new version of a function is deployed
- A new instance of the function is provisioned (e.g. when concurrency scales up)
- A certain amount of time has elapsed (shorter if the function is idle, longer if the function is regularly invoked)
