A Lambda-heavy city API opens many short database connections and must ride through RDS failover without connection storms failing the app. Which service helps?

Amazon RDS Proxy helps a Lambda-heavy city API that opens many short database connections ride through RDS failover without connection storms failing the application. RDS Proxy works by pooling and multiplexing connections between ephemeral Lambda execution environments and RDS/Aurora, so hundreds of concurrent function invokes do not each hold a scarce database connection. During failover, the proxy can absorb some of the reconnection churn and present a more stable target to clients, reducing error spikes that otherwise hit citizen-facing APIs when the database endpoint flips. For municipal serverless data planes, the proxy is the resilience control that matches connection storm and failover concerns.

Disabling all connection pooling and opening a new TCP session per Lambda cold start forever fails by concept because it maximizes connection setup cost and is likely to exhaust DB max_connections under load. Replacing RDS with local SQLite files on each Lambda execution environment fails because SQLite on ephemeral runtimes is not a shared durable municipal database and cannot provide cross-invoke consistency for city API state. Exposing the RDS instance publicly and embedding the master password in code fails on security and operations: public exposure widens attack surface, hardcoded master credentials violate least privilege, and neither addresses pooling or failover smoothing.

Exam caveat: RDS Proxy adds a hop and has engine/feature constraints; pin Lambda concurrency and proxy sizing so you do not merely move the bottleneck. Operational check: point the city API Lambdas at the proxy endpoint with IAM auth where supported, load-test concurrent invokes, trigger a Multi-AZ failover, and compare error rates with and without the proxy.