RDS Proxy pooling design
Connection pooling for Aurora PostgreSQL behind a Lambda-heavy API layer — warm pools, failover boundaries, and IAM auth wiring.
Why RDS Proxy
Lambda functions open a new TCP handshake and PostgreSQL auth round-trip on every cold start. At scale this saturates Aurora's connection slots and spikes latency. RDS Proxy maintains a warm pool of persistent connections, multiplexing thousands of short-lived client connections over a few dozen database connections.
Pool configuration
- MaxConnectionsPercent: 60–70% of the instance's max_connections. Leave headroom for direct maintenance connections.
- IdleClientTimeout: 10 minutes. Drops stale Lambda clients that forgot to close.
- ConnectionBorrowTimeout: 5 seconds. Fails fast when the pool is exhausted instead of queueing indefinitely.
- SessionPinningFilters: exclude SET, RESET, and DEALLOCATE to avoid pinning every connection.
IAM authentication
Enable IAM database authentication on the RDS instance and the proxy. Generate a 15-minute auth token with rds.generate_db_auth_token. The proxy handles token refresh transparently — your Lambda only passes the token at connect time. No long-lived passwords in Secrets Manager.
Failover boundaries
Deploy one proxy per AZ and pin each Lambda to its local proxy endpoint. On Aurora failover the proxy reconnects to the new writer in under 30 seconds. Cross-AZ proxy traffic during a failover adds single-digit millisecond latency — acceptable for most workloads.
Monitoring
- DatabaseConnections: should stay flat regardless of Lambda concurrency.
- ClientConnectionsReceived: tracks incoming demand.
- ClientConnectionsClosedNoWork: spikes indicate Lambda functions opening connections they never use — fix the client code.