Amazon RDS Proxy Explained: When You Need It

What is RDS Proxy?

Amazon RDS Proxy is a fully managed database proxy for Amazon RDS and Aurora. Your application connects to the proxy endpoint instead of the database endpoint; the proxy keeps a pool of connections open to the database and lends them to client sessions. AWS lists three goals: scalability through pooling, availability through faster failover, and security through optional IAM authentication with credentials kept in AWS Secrets Manager.

The FAQs list support for Aurora MySQL, Aurora PostgreSQL, RDS for MariaDB, RDS for MySQL, RDS for PostgreSQL and RDS for SQL Server. Oracle and Db2 are not supported. The proxy's own compute is serverless and scales with the workload, and it runs across multiple Availability Zones independently of your DB instance.

The connection problem RDS Proxy solves

Every database connection uses memory and CPU on the server. The RDS User Guide shows how the default max_connections scales with instance memory: a MySQL DB instance on a db.t3.micro defaults to roughly 60 connections. An application that opens a new connection per request, or a fleet of Lambda functions that each hold one, can reach that ceiling quickly.

AWS's planning guidance names the candidates: instances that hit "too many connections" errors, small T-class instances at risk of running out of memory, applications that open and close many connections without their own pooling, applications that hold many idle connections open, and Lambda functions, which make frequent short connections. The Lambda Developer Guide says direct connections are fine for simple cases but proxies are recommended for production.

How RDS Proxy works: pooling, multiplexing and pinning

Pooling and multiplexing. By default the proxy can reuse a database connection after each transaction in a client session; AWS calls this multiplexing. Many client connections therefore share a much smaller number of database connections, which the RDS User Guide says reduces the chance of "too many connections" errors.

Pinning. When the proxy cannot be sure that sharing a connection is safe, for example because the session changed state, it keeps that session on one connection until it ends. Pinned sessions lose the benefit of multiplexing, so applications that change session settings heavily get less from the proxy. The User Guide notes, for example, that any statement larger than 16 KB pins the session.

Failover. The proxy tracks the current writer of a Multi-AZ deployment and routes to the new primary after a failover without relying on DNS caches. AWS states this reduces failover times by up to 66% for RDS Multi-AZ DB instances while preserving application connections. See Multi-AZ vs read replicas for how failover works underneath.

Security. Clients can be required to authenticate to the proxy with IAM, while the proxy connects to the database with credentials from Secrets Manager or with end-to-end IAM authentication. When you register a target, the proxy creates a protected database user called rdsproxyadmin; AWS warns that changing or deleting it can make the proxy unavailable.

Limits and when not to use RDS Proxy

The RDS FAQs say the proxy can add an average of 5 milliseconds of network latency, and suggest connecting directly if your application cannot tolerate that or does not need connection management. Other documented limits:

• Each proxy is associated with a single DB instance; for RDS instances in a replication setup it can only target the writer, not a read replica.
• The proxy must be in the same VPC as the database and cannot be publicly accessible, so you cannot reach it directly from a laptop outside the VPC.
• 20 proxies per account per Region by default (adjustable), and up to 200 Secrets Manager secrets per proxy.
• Engine-specific gaps exist; for PostgreSQL, for example, the proxy does not support cancelling a running query with a CancelRequest (Ctrl+C in psql).

Setting up RDS Proxy: the documented steps

AWS documents the setup in this order (we describe it from the RDS User Guide; we have not run it ourselves):

1. Network. Place the proxy in the database's VPC and keep at least two subnets; the default endpoint is provisioned across two Availability Zones chosen from them.
2. Credentials. Store the database user's credentials as a Secrets Manager secret, or plan to use end-to-end IAM authentication (MySQL, PostgreSQL and MariaDB engine families).
3. IAM role. Give the proxy a role that can read the secrets; the console can create it for you.
4. Create the proxy. In the RDS console choose Proxies, then Create proxy, select the engine family, the target database, the connection pool maximum (a percentage of max_connections), timeouts and whether to require TLS.
5. Connect. Point the application (or the Lambda function) at the proxy endpoint instead of the database endpoint.

For Lambda, the Lambda console can create and attach a proxy from the function's configuration; the function must run in the same VPC as the database.

RDS Proxy alternatives (including PgBouncer)

• Application-side pooling. Long-running application servers usually pool connections in their driver or framework; if the pool is sized correctly, a proxy adds cost and latency without much gain.
• PgBouncer. A lightweight, open-source connection pooler for PostgreSQL that you install and operate yourself, for example on EC2 or in containers. You manage its availability, patching and configuration. AWS has published an approach for using PgBouncer with RDS Multi-AZ DB clusters for fast switchovers.
• Other self-managed proxies such as ProxySQL for MySQL, which AWS also references for low-downtime upgrades of Multi-AZ DB clusters.
• A different database model. If connection limits are a symptom of a highly bursty serverless workload, a service with an HTTP or serverless API may suit better; see AWS database services compared.

Pricing

Prices from the provider's official pricing pages, checked 8 October 2026, region US East (N. Virginia), in USD, excluding tax. List prices only; discounts, commitments and your actual usage change the bill.

For provisioned instances on Aurora, RDS for PostgreSQL, MySQL, MariaDB and SQL Server, RDS Proxy is priced per vCPU of the underlying instance per hour; for Aurora Serverless it is priced per ACU-hour consumed. AWS's price data lists 0.015 USD per vCPU-hour and 0.015 USD per ACU-hour in US East (N. Virginia). Partial hours are billed per second with a 10-minute minimum. The default proxy endpoint has no extra charge; additional endpoints use AWS PrivateLink, which is billed separately.

Worked examples are estimates calculated from the list prices above; they are not quotes or measured bills.

Frequently asked questions

Sources

• Amazon RDS User Guide: Amazon RDS Proxy
• Amazon RDS User Guide: Planning where to use RDS Proxy
• Amazon RDS User Guide: RDS Proxy concepts and terminology
• Amazon RDS User Guide: Creating a proxy
• Amazon RDS User Guide: Quotas and constraints
• Amazon RDS FAQs (RDS Proxy)
• AWS Lambda Developer Guide: Using Lambda with Amazon RDS
• Amazon RDS Proxy pricing
• AWS price data: RDS Proxy (all Regions)
• AWS price data: RDS for PostgreSQL On-Demand (instance vCPUs)
• PgBouncer
• AWS Database Blog: Fast switchovers with PgBouncer on RDS Multi-AZ DB clusters
• Amazon RDS Multi-AZ features

Checked 8 October 2026.

How we research cloud database guides: our editorial method. CodeWithSQL earns nothing from the providers mentioned.