Q. AWS lambda - Share database connection pool between lambda functions

Viewed 2129

I have a question about AWS lambda, and the best practice when it does database connection.

I want to write some lambda functions each which will handle CRUD operations. So for function A it will do CRUD for one data model, and function B will do CRUD for another data model.

Now my question is, can the two lambda functions share the connection pool to a database? I know that it is possible to reuse connection pool within a lambda when it is in a warm state. Or would my option here to disconnect database when the request is finished?

2 Answers

Two important points have already been mentioned by deceze and Jens in the comments, I'm going to summarize some of the options you have and add my own take.

Each instance of a Lambda function (aka. execution context) is a separate Micro-VM based on AWS' firecracker framework, which means they can't share "process-level" information like active database connections among each other. The connection pool reuse you correctly referred to is therefore limited to a single execution-context, i.e. a warm Lambda instance.

Since opening up a connection to a database is a rather costly endeavor, AWS has some options to help you here. All of those that I'm aware of require you to use a RDS-managed database.

  1. Use RDS Proxy, which essentially acts as a reverse proxy in front of your database and "bundles" connections to it as well has does connection pooling. At the time of writing, this is available for the MySQL and Postgres versions of regular RDS as well as Aurora
  2. Use the Data-API to talk to your Aurora Serverless Cluster. This allows you to connect to talk to your database using the HTTP(S) protocol and handles some of the underlying connection mechanisms. It's currently (late 2020) available for the Aurora Serverless versions of Postgres and MySQL - you can find more details about availability here.

Since 2019 you can use RDS Proxy. It is similar to a connection pool. It always to share connection for different AWS Lambdas. Another benefit is it caps your database connections to a certain limit. Your AWS Lambdas might scale faster than your database can handle. We use it in production an it works quite well. Small downsite, if you use RDS Proxy with Aurora and read replicas: your connections always talk to the writer.

Another practice we used quite successfully is having one connection per Lambda function open and reuse that one. Sure, you need to write your own logic to setup and verify a database connection, but it is not that hard to do.

Related