Best Practices for AWS Lambda Container Reuse
Optimizing Warm Starts When Connecting AWS Lambda to Other Services
--
AWS Lambda provides high scalability due to being serverless and stateless, allowing many copies of the lambda function to be spawned instantaneously (as described here). However, when writing application code, you are likely to want access to some stateful data. This means connecting to a datastore such as an RDS instance or S3. However, connecting to other services from AWS Lambda adds time to your function code. There may also be side effects from high scalability such as reaching the maximum number of allowed connections to an RDS instance. One option to counter this is to use container reuse in AWS Lambda to persist the connection and reduce lambda running time.
There are some useful diagrams here to explain the lifecycle of a lambda request.
The following occur during a cold start, when your function is invoked for the first time or after a period of inactivity:
- The code and dependencies are downloaded.
- A new container is started.
- The runtime is bootstrapped.
The final action is to start your code, which happens every time the lambda function is invoked. If the container is reused for a subsequent invocation of the lambda function, we can skip ahead to starting the code. This is called a warm start, and this is the step we can optimize when connecting to other services by defining the connection outside the scope of the handler method.
Connecting to Other AWS Services from Lambda
We have a basic and common example to run through — we want to connect to a container resource to fetch enrichment data. In this example, a JSON payload comes in with an ID and the Lambda Function connects to an RDS instance running PostgreSQL to find the corresponding name of the ID so we can return the enriched payload. Because the lambda function is connecting to RDS, which lives in a VPC, the lambda function now needs to live in a private subnet too…
