SysPad › Lessons › database lessons › RDS Proxy

How RDS Proxy works

Fully-managed connection pooler for RDS and Aurora. Multiplexes many client connections onto a small pool of database connections, relieving max-connection limits and speeding failover. Billed per vCPU-hour of the proxied database.

RDS Proxy isn’t a database, it’s the bouncer at the door. Databases can only hold so many open connections, and modern apps (especially Lambda) love to open thousands of short-lived ones. The proxy keeps a small pool of warm connections and shares them around, so your database stops drowning in connection churn.

What you will learn

Why do connections, not CPU, so often become the database’s breaking point?
How does pooling let thousands of clients share a handful of DB connections?
Why is RDS Proxy almost mandatory in front of Lambda?
What’s "pinning", and why can it quietly undo the benefit?

The connection problem

Every open database connection costs memory, so RDS/Aurora cap how many you can have. Opening and closing connections is also surprisingly expensive (authentication, setup). Apps that open a fresh connection per request can exhaust the limit while CPU sits idle.

Pooling: share a few warm connections

RDS Proxy sits between your app and the database and keeps a pool of established connections. Many client connections are multiplexed onto far fewer database connections, which the proxy reuses instead of constantly reopening.

The database sees a small, stable set of connections no matter how many clients come and go.

⚓ Standard in front of RDS/Aurora for serverless and high-concurrency applications.

Why Lambda needs it

Serverless functions scale out to many concurrent instances, and each one wants its own database connection. A traffic spike becomes a connection storm that can knock the database over.

With RDS Proxy in front, those functions share the warm pool, so scaling Lambda no longer means scaling raw connections. As a bonus, the proxy can speed up failover by holding client connections open while the database fails over underneath.

How does it also help with security and failover?

RDS Proxy integrates with IAM authentication and Secrets Manager, so apps can connect without embedding database passwords. During a failover it keeps client connections alive and routes them to the new primary, cutting the disruption clients see.

The catch: connection pinning

Multiplexing works because the proxy can hand any client the next free connection. But some session-state operations (certain temporary tables, session variables, some prepared-statement or transaction patterns) force the proxy to dedicate a connection to one client, called pinning.

Flashcards

An app opens a new DB connection per request and fails at moderate load, CPU is fine. Why?: It exhausts the connection limit. Connections cost memory and are capped; per-request opening burns through them regardless of CPU.
How does RDS Proxy let thousands of clients use a small database connection budget?: It keeps a pool of warm connections and multiplexes many client connections onto a few reused DB connections.
Why is RDS Proxy near-essential in front of Lambda + RDS?: Lambda scales to many concurrent instances, each wanting a connection, a connection storm. The proxy makes them share a warm pool instead.
How does RDS Proxy improve failover and auth?: It holds client connections open and reroutes to the new primary on failover, and supports IAM auth + Secrets Manager so no DB password is embedded.
What is connection "pinning" and why care?: Session-state operations force the proxy to dedicate a connection to one client. Heavy pinning reduces reuse and weakens the pooling benefit.

Sources

Open the SysPad canvas · Official RDS Proxy documentation