Amazon RDS Proxy

Q: When should you use Amazon RDS Proxy?

Use it when serverless or bursty compute — Lambda , Fargate on ECS — opens and closes many short-lived database connections and can spike past the database's max_connections . It's also the way to get IAM authentication to the database instead of shipping a password to every client, and it makes Multi-AZ failovers less disruptive. Skip it for a steady EC2 tier that already keeps a small long-lived pool — that workload never hits the exhaustion problem, so the proxy is cost and an extra hop for nothing.

Q: Why is my application not benefiting from RDS Proxy?

Almost always because the client is pointed at the database endpoint instead of the proxy endpoint . A client wired straight to the database skips the pool entirely, so multiplexing does nothing and connection exhaustion comes right back — while you keep paying for the proxy. The DB instance endpoint should only be reached by the proxy itself. Design Beaver flags this as an anti-pattern as you draw.

What RDS Proxy is

RDS Proxy is a managed database proxy you put in front of an RDS or Aurora instance. Your application connects to the proxy’s endpoint instead of the database endpoint, and the proxy keeps a warm pool of real connections behind it. When many clients connect at once, the proxy multiplexes them over a much smaller set of database connections — after each transaction it can hand the same underlying connection to a different client.

It solves two specific problems. Connection exhaustion: Lambda can scale to thousands of concurrent execution environments in seconds, each wanting its own connection, which blows straight past max_connections. Failover disruption: the proxy holds the client-facing endpoint steady and preserves idle connections through a Multi-AZ failover, skipping the DNS-propagation delay a direct client would wait out.

It runs inside your VPC across subnets in multiple Availability Zones, and it has no existence outside one. Design Beaver models it as VPC-resident and validates as you draw that the compute, the proxy, and the database are wired in the right order.

When to use RDS Proxy (and when not to)

Reach for it when the compute in front of your database is bursty: Lambda or Fargate opening and closing short-lived connections at a concurrency the database can’t match. Reach for it when you’d rather authenticate with IAM than distribute a database password. Reach for it when you want failovers your clients barely notice.

Don’t add it to a steady EC2 app tier that already holds a small, long-lived pool. That workload doesn’t open a connection per request, so it never hits the failure mode the proxy exists to fix — you’d be paying for a hop that buys nothing. The same goes for a low-traffic workload sitting well under the connection limit. And if your sessions are state-heavy enough to force pinning, verify they multiplex cleanly before you count on the pool.

RDS Proxy pricing in plain English

The proxy’s bill tracks the size of the database it fronts, not your traffic. That’s the counterintuitive part, and it’s why an over-provisioned database quietly over-pays twice.

For provisioned RDS/Aurora instances, RDS Proxy is priced per vCPU per hour of the underlying (proxied) DB instance's size — a bigger DB instance means more vCPUs billed for the proxy fronting it. Billed per-second with a 10-minute minimum after a billable status change (create/start/modify). No separate charge for the pooled connections themselves.

Option	Representative rate
provisioned	~$0.015 per vCPU-hour of the proxied DB instance's size, billed on a minimum of 2 vCPUs per proxy.
aurora-serverless-v2	Billed per ACU-hour of the proxied Aurora Serverless v2 capacity rather than per vCPU-hour.

Keeping the bill down

Right-size the underlying DB instance — the proxy's bill scales with the DB instance's vCPU count, so an over-provisioned database also over-pays for its proxy
Only attach a proxy where pooling/failover/IAM-auth actually earns its keep (bursty Lambda/Fargate tiers); a steady low-connection workload pays for a proxy it doesn't benefit from

us-east-1 (rates vary by region). Rates as of 2026-09. Verify at the official pricing page before using for real cost estimates — this list is not kept in sync with AWS pricing changes.

The 2-vCPU floor is the detail that catches people out. In front of a small instance, the proxy can cost a meaningful fraction of the database itself — which is fine when you need the pooling and hard to justify when you don’t.

How RDS Proxy connects to other services

The proxy sits between compute and database, and that shape changes how you draw it — and what secures it.

Lambda
A Lambda function connects to the RDS Proxy endpoint instead of directly to the DB instance — the canonical RDS Proxy pattern. The proxy pools and multiplexes connections so bursty, high-concurrency invocations don't exhaust the database's max_connections.
ECS
A containerized ECS/Fargate application connects to the proxy endpoint for pooled, failover-resilient database connections — the container equivalent of the Lambda pattern
RDS
The proxy maintains a warm pool of connections to the backing RDS (or Aurora) DB instance and routes client queries to it
Secrets Manager
The proxy reads the database username/password from a Secrets Manager secret to authenticate to the database, so no raw password is handed to the proxy or the clients

None of these are SDK edges, which surprises people who expect an IAM policy on every arrow. Lambda and ECS reach the proxy over the ordinary Postgres or MySQL wire protocol, gated by security groups — not an execution-role API call. The proxy’s read from Secrets Manager uses the proxy’s own IAM role, not the client’s. So there’s no execution-role policy to attach here the way there is on a Lambda → DynamoDB edge.

The security groups need to reference each other in both directions: the proxy’s group allows the client’s group on the DB port, and the database’s group allows the proxy’s group on the same port — 5432 for PostgreSQL, 3306 for MySQL. Reference security groups, not raw CIDR blocks.

What RDS Proxy can’t connect to

A proxy endpoint looks connectable from anything. It only speaks one protocol, to one kind of target.

Application Load Balancer
An ALB is a layer-7 HTTP(S) load balancer that routes to registered targets over HTTP(S) — it has no database wire-protocol relationship with a proxy and never has an RDS Proxy as a backend target. The compute tier behind the ALB connects to the proxy, not the ALB itself.
API Gateway
API Gateway fronts HTTP/REST/WebSocket APIs and integrates with Lambda or HTTP backends — it speaks no database wire protocol and cannot connect to a database proxy. The Lambda behind the API connects to the proxy.
CloudFront
CloudFront is an HTTP(S) edge cache/CDN in front of a web origin — it has no database client relationship and an RDS Proxy is never a CloudFront origin.
Route 53
Not a valid DNS alias target and not something a domain resolves to for browsers — Route 53 points clients at HTTP(S) origins like CloudFront, S3, ALB, or API Gateway, never at a database proxy endpoint.
S3
No native direct integration — S3 is object storage accessed over its HTTP API, and an RDS Proxy only speaks the SQL database wire protocol to a relational DB instance. There is no drawable edge between them.
DynamoDB
DynamoDB is a NoSQL service accessed via its own SDK/API, not the SQL wire protocol the proxy pools — an RDS Proxy fronts RDS/Aurora only and has no relationship with a DynamoDB table.

Anti-patterns Design Beaver catches

All three are ways of paying for a proxy without getting one.

Putting an RDS Proxy in front of a steady, low-concurrency workload that doesn't need pooling

Why it breaksThe proxy solves connection exhaustion under bursty/high-concurrency load; a steady EC2 tier with a small long-lived pool never hits that limit, so the proxy adds cost and an extra network hop for no benefit

Do this insteadConnect that workload directly to the DB instance with an in-app connection pool; reserve the proxy for Lambda/Fargate-style bursty concurrency or when you need IAM auth / faster failover

Pointing the application at the DB instance endpoint while a proxy also exists, so pooling is bypassed

Why it breaksClients that connect straight to the database endpoint never go through the proxy — the pool and multiplexing do nothing, and the connection-exhaustion problem returns even though a proxy is provisioned

Do this insteadPoint every client at the proxy endpoint; the DB instance endpoint should only be reached by the proxy itself

Assuming multiplexing always applies for session-state-heavy workloads

Why it breaksCertain operations (setting session variables, holding temporary tables, prepared statements in some modes) force the proxy to pin a connection to one session, which disables multiplexing and cuts the pooling benefit

Do this insteadKeep sessions stateless where possible, and review the RDS Proxy pinning guidance to see which operations force pinning before relying on the pool

Gotchas that bite in production

Point at the proxy endpoint. The single most common mistake. A client wired to the database endpoint bypasses the pool and gains nothing.
Pinning quietly kills multiplexing. Session variables, temporary tables, and some prepared-statement modes tie a connection to one session. Enough of that and you’re back where you started.
Security groups reference each other. Client group → proxy group → database group, each on the DB port. Raw CIDRs are the fragile way to do this.
One proxy fronts one target. A proxy is associated with a specific instance or cluster. It isn’t a shared gateway to an arbitrary set of databases.
It isn’t free and it isn’t always worth it. Bursty concurrency, IAM auth, faster failover — if none of those apply to your workload, skip it.

Frequently asked questions

When should you use Amazon RDS Proxy?

Use it when serverless or bursty compute — Lambda, Fargate on ECS — opens and closes many short-lived database connections and can spike past the database's max_connections. It's also the way to get IAM authentication to the database instead of shipping a password to every client, and it makes Multi-AZ failovers less disruptive. Skip it for a steady EC2 tier that already keeps a small long-lived pool — that workload never hits the exhaustion problem, so the proxy is cost and an extra hop for nothing.

Why is my application not benefiting from RDS Proxy?

Almost always because the client is pointed at the database endpoint instead of the proxy endpoint. A client wired straight to the database skips the pool entirely, so multiplexing does nothing and connection exhaustion comes right back — while you keep paying for the proxy. The DB instance endpoint should only be reached by the proxy itself. Design Beaver flags this as an anti-pattern as you draw.

What is connection pinning in RDS Proxy?

Pinning is when the proxy stops sharing an underlying database connection and ties it to one client session. Setting session-level variables, holding temporary tables, or using prepared statements in certain modes can all trigger it. Enough pinning and you're back to one connection per client, which is exactly the problem the proxy was bought to solve. Keep sessions stateless where you can and check the AWS pinning guidance before relying on the pool.

How much does Amazon RDS Proxy cost?

For provisioned RDS and Aurora instances it's billed per vCPU-hour of the underlying database instance's size, on a minimum of 2 vCPUs per proxy — that floor is what makes a proxy in front of a small instance look disproportionately expensive. Aurora Serverless v2 is billed per ACU-hour of the proxied capacity instead. Billing is per second with a 10-minute minimum after a status change, and there's no separate charge for the pooled connections. Verify current rates on the official pricing page before estimating a real bill.

Can API Gateway or an ALB connect to RDS Proxy?

No. API Gateway and an ALB both speak HTTP, and RDS Proxy only speaks the SQL database wire protocol. Neither can hold a database connection. The Lambda or container tier behind them is what connects to the proxy, so Design Beaver flags those edges as invalid.