Hundreds of concurrent Lambdas each open a new RDS connection per invoke and exhaust max_connections. What should the team implement?
Select an answer to reveal the explanation.
Short Explanation
Lambda scales out; naive one-connection-per-invoke knocks over RDS. Put RDS Proxy (and smart reuse) between the functions and the database so connections are pooled.
Full Explanation
Hundreds of concurrent Lambdas each opening a new RDS connection per invoke will exhaust max_connections quickly. Use Amazon RDS Proxy for connection pooling and reuse connections carefully inside warm execution environments so invokes borrow from a managed pool instead of opening a raw database connection every time. That pattern is the standard fix for serverless-to-RDS connection storms in county payment and permitting APIs.
Raising Lambda reserved concurrency without changing connection behavior can increase simultaneous connects and make exhaustion worse. Switching every query to DynamoDB Scan in the same release abandons the relational data model to dodge connections rather than fixing pooling. Storing the database password in plaintext environment variables does nothing for pooling and weakens secrets hygiene.
Exam caveat: even with Proxy, bound concurrency and pool sizing; also prefer Secrets Manager/SSM for credentials rather than embedding secrets in function config. Operational check: load-test concurrent invokes watching RDS ClientConnections versus Proxy metrics, confirm max_connections is no longer hit, and verify failed connects disappear from Lambda errors during enrollment peaks.