A Lambda function backed by an Amazon RDS database starts failing with "too many connections" whenever traffic spikes. What is RDS Proxy, and how does putting it in front of the database fix this?

## Why serverless and databases collide AWS Lambda scales by adding *execution environments* — isolated sandboxes, each running one invocation at a time. There is no shared process, so there is no shared connection pool: a library that opens a connection on cold start opens one per environment. Scale to a thousand concurrent invocations and you have asked the database for up to a thousand connections, arriving in a burst. RDS caps concurrent connections, and on the managed engines that cap is derived from the instance's memory through the default parameter group — a small instance class permits far fewer connections than people expect. Worse, each connection is expensive on the server side in memory and setup work, so the failure is not a clean "limit reached" but a slide into degradation: slow connects, timeouts inside the function, retries that open still more connections, and eventually outright rejection. Raising the connection limit in a parameter group trades one failure for another — the database runs out of memory instead. ## What RDS Proxy is RDS Proxy is a fully managed, VPC-resident proxy for RDS and Aurora. You create it, point it at a target database, and it gives you an endpoint that speaks the database's own wire protocol. Clients — Lambda functions, containers, anything — connect to the proxy exactly as they would to the database. ```bash aws rds create-db-proxy \ --db-proxy-name orders-proxy \ --engine-family POSTGRESQL \ --auth '[{"AuthScheme":"SECRETS","SecretArn":"arn:aws:secretsmanager:eu-west-1:123456789012:secret:orders-db","IAMAuth":"REQUIRED"}]' \ --role-arn arn:aws:iam::123456789012:role/rds-proxy-role \ --vpc-subnet-ids subnet-aaa subnet-bbb ``` Behind that endpoint the proxy keeps a pool of established connections to the database and reuses them. A function that connects, runs one query, and returns borrows a warm database connection for the duration of its transaction rather than causing a new one to be built. Thousands of ephemeral client connections can therefore ride on a modest number of database connections. ## The three things it actually buys you **Connection multiplexing.** The headline benefit and the answer to the outage above. Concurrency at the function tier is decoupled from connection count at the database tier. **Faster, gentler failover.** During an RDS failover the writer moves to another host. Without a proxy, every client's socket breaks and every client must detect the failure, re-resolve DNS, and reconnect — the thundering-herd reconnect is often more disruptive than the failover itself. RDS Proxy holds the client connections open, reconnects to the new writer on their behalf, and lets in-flight requests continue, so applications see a pause rather than a storm of errors. **Credential handling.** The proxy pulls database credentials from AWS Secrets Manager using an IAM role you supply, and can require **IAM authentication** from clients. The Lambda function then authenticates with its execution role and never holds a database password, which also means secret rotation is a proxy-side concern rather than a redeploy. ## Pinning: the caveat that separates real experience from a brochure Multiplexing only works while a client connection is stateless between transactions. If a client does something that leaves **session state** on the database connection, the proxy can no longer safely hand that connection to anyone else, so it *pins* the database connection to that one client until the client disconnects. Common causes are temporary tables, session-level `SET` statements, certain prepared-statement and large-object usage, and other engine-specific session features. A pinned workload gets the credential and failover benefits but loses the connection saving — which is exactly the benefit you bought the proxy for. Diagnosing this is a normal part of running a proxy: RDS Proxy emits CloudWatch metrics for pinned connections, and the fix is on the application side, removing the session state or scoping it inside a transaction. ## What RDS Proxy is not It is not a fix for a database that is genuinely out of CPU or I/O — it manages connections, not query cost. It is not a read/write splitter for RDS instances: you point traffic at the proxy's endpoint for the target you configured. It is not free, being billed per vCPU of the target database instance. And it does not remove the need for sensible client-side behaviour — short transactions, prompt release, and idle timeouts still matter. ## Alternatives to name If you cannot use the proxy, the levers are: cap the function's concurrency with reserved concurrency so the database is never asked for more connections than it has; move to an interface that does not hold connections at all, such as the Data API where the engine supports it; or restructure so that a long-lived compute tier, which can hold a conventional pool, fronts the database and the functions call it. Naming reserved concurrency as the crude-but-effective backstop is a good sign in an interview: it makes the blast radius of a traffic spike a queueing problem rather than a database outage.