Amazon RDS Proxy

TL;DR: RDS Proxy sits between your app and RDS, keeping a small pool of long-lived database connections and multiplexing thousands of client connections onto them. It matters for the bill because connection count — not CPU or query load — is often what forces an upsize: a db.t3.medium can serve the queries fine but caps around 450 PostgreSQL connections, so teams jump to a db.r5.large just for headroom. The proxy breaks that chain, and the fee usually covers only 10–25% of the upsize it avoids.

The numbers

• Proxy fee: ~$0.015 per vCPU-hour of the target database — db.t3.medium (2 vCPU) ≈ $22/mo; db.r5.2xlarge (8 vCPU) ≈ $88/mo. It tracks vCPU count, not client connections or query volume.
• PostgreSQL connection ceilings scale with memory: db.t3.small (~220), db.t3.medium (~450), db.r5.large (~1,800). The trap: a workload needing 200 active connections can peak at 600 open ones, forcing an upsize purely for the ceiling.
• Field examples: a Lambda API kept a db.t3.medium instead of jumping to db.r5.large — ~$170/mo net after the fee; 15 microservices downsized db.m5.large → medium (~$80/mo); a nightly 50-worker batch downsized db.r5.xlarge → large ($100+/mo).

Do this

1. Find the tell: connections near max_connections while CPU sits low — that instance was upsized for headroom, not work.
2. Create the proxy (RDS console → Proxies), pointing at the target instance or Aurora cluster.
3. Tune pool behavior — max connections percentage, borrow timeout, init queries.
4. Enable IAM auth (especially for Lambda) — connect with the execution role, no DB passwords in env vars or Secrets Manager round-trips per cold start.
5. Repoint the app at the proxy endpoint, then monitor DatabaseConnections, ClientConnections, and DatabaseConnectionsBorrowLatency to confirm the pool is sized right — and downsize the instance once load proves calm.

Gotchas

• Lambda is the canonical case — stateless invocations can't hold their own pool, so 800 concurrent invocations = 800 DB connections without a proxy. Monoliths and long-lived pods already pool well and gain little.
• It's not a cure for real compute pressure — if the instance is genuinely CPU-bound, the proxy won't help; fix the actual bottleneck.
• Sub-millisecond added latency — negligible for nearly everyone, but direct is better if you're chasing microsecond reads.
• RDS Oracle is unsupported; SQL Server support is limited — verify against current docs.

Skip this if

• Your app already pools connections efficiently (healthy Rails/Spring pool) and the instance is sized for the queries — there's little to gain.
• The database has plenty of connection headroom (a big instance using 50 of 7,000 slots) — you don't have the problem the proxy solves.
• The real waste is elsewhere on the same instance — pair with RDS Storage Auto-Scaling to stop over-provisioning disk and RDS Instance Stop/Start to stop billing dev/test nights and weekends.