RDS Proxy for connection-driven CPU spikes

A database whose CPU rises with the number of connections rather than the volume of work is usually spending that CPU on connection setup: authentication, TLS handshakes and per-session memory allocation. Amazon RDS Proxy removes most of that cost.

How it reduces load

• Connection pooling. The proxy holds a pool of established connections to the database and hands them out, instead of the database opening a new one per client session.
• Connection reuse. Sessions that finish return their connection to the pool rather than tearing it down, so the engine avoids the memory and CPU overhead of opening a new connection each time.
• Multiplexing. Several client sessions can share one database connection when none of them holds session state that would force pinning.
• Load shedding. Requests that cannot be served immediately are queued or throttled at the proxy, so a connection storm degrades latency rather than overwhelming the database.

The proxy also handles credential retrieval — from IAM database authentication or Secrets Manager — on the database’s behalf, which is part of what makes each new connection expensive without it.

Where it fits

RDS Proxy suits workloads that open and close connections rapidly: Lambda functions, container tasks that scale horizontally, and any application without its own long-lived pool. It is also a failover aid, because it reconnects to a promoted standby while preserving the application’s connection to the proxy.

Constraints worth knowing before you design around it

• The proxy must sit in the same VPC as the database and cannot be publicly accessible.
• A proxy attaches to the writer instance, not to a read replica.
• Statements larger than 16 KB, and several session-state operations, pin a client to its connection and defeat multiplexing for the life of that session.
• Default proxy endpoints are provisioned across two Availability Zones.

Reference

• Amazon RDS Proxy
• Avoiding pinning an RDS Proxy