A lambda lives for a relatively short period of time, ephemeral. It only handles a single request at a time but will live long enough to serve multiple requests. If another request comes in while one is in process a new lambda can spin up.

As a lambda lives for a period of time you can create a pool for that individual lambda. That pool lives for the life of the lambda.

Now for things like HTTP clients this is generally OK.

If you have a Postgres pool etc, it's not ok. Postgress doesn't like lots of connections and you will have POOL_SIZE * NUMBER_OF_ACTIVE_LAMBDA connections.

So unless you limit the number of Lambda's you have using reserved capacity Lambda's are simply not a good fit for running a PG pool locally inside the lambda for web stuff.

If you have a batch job, that runs once a day, with a single lambda, inserts a bunch of records in to postgres or similar, then a small pool in the lambda is fine.

So a lot depends on what you are doing in the lambda, how many you have, what your downstream service you are connecting to us.

As you might have guessed, connection pools don't work well with Lambda. For database connection pool, they came up with another chargeable service, RDS Proxy, to fix the problem created by Lambda :)

There's no direct connection to the Lambda container, it goes through a load balancer. The load balancer can keep connections open for reuse.