AWSAmazon RDSDatabase

`aws_db_proxy` cost estimation

A managed connection pool in front of RDS or Aurora. Priced per vCPU-hour of the proxied database instances, billed continuously.

An aws_db_proxy sits between your application and an RDS or Aurora database, pooling and multiplexing connections so bursty or serverless workloads (especially Lambda) don't exhaust the database's connection limit. Its cost is tied to the size of the database it fronts, not to traffic.

RDS Proxy bills per vCPU-hour of the underlying database instance, at roughly $0.015/vCPU-hour. So a proxy in front of a 4-vCPU db.r6g.xlarge runs about 4 x $0.015 x 730 = ~$43.80/month, billed continuously whether or not connections flow. For Aurora, it's based on the instance vCPUs as well. There is a documented minimum charge equivalent to a small number of vCPUs even for tiny instances.

c3x prices the proxy from the vCPU count of the target instance class at 730 hours/month. Because the charge is always-on and proportional to instance size, the proxy is worth its cost when it actually solves a connection-exhaustion or failover problem; for a low-connection workload it's pure overhead. The database itself (aws_db_instance / aws_rds_cluster) bills separately.

Terraform example

A minimal but realistic configuration that C3X can estimate.

resource "aws_db_proxy" "app" {
  name                   = "app-proxy"
  engine_family          = "POSTGRESQL"
  role_arn               = aws_iam_role.proxy.arn
  vpc_subnet_ids         = aws_subnet.db[*].id
  require_tls            = true

  auth {
    auth_scheme = "SECRETS"
    secret_arn  = aws_secretsmanager_secret.db.arn
    iam_auth    = "DISABLED"
  }
}

Pricing dimensions

What you actually pay for when you provision aws_db_proxy.

Dimension	Unit	What's being charged
Proxy vCPU hours	per vCPU-hour	Billed per vCPU of the proxied database instance, continuously. c3x prices the target instance's vCPU count at 730 hours/month, subject to a small per-instance minimum. $0.015/vCPU-hour

Sample C3X output

Example output from c3x estimate (proxy for a 4-vCPU instance):

aws_db_proxy.app
└─ Proxy vCPU-hours (4 vCPU)   2,920  vCPU-hours    $43.80

OVERALL TOTAL                                       $43.80
(database instance billed separately)

Optimization tips

Common ways to reduce aws_db_proxy cost without changing the workload.

Add a proxy only when connections are the bottleneck

Whole proxy if unneeded

RDS Proxy earns its always-on cost by solving connection exhaustion (Lambda fan-out) or speeding failover. For steady, low-connection apps it adds cost without benefit. Confirm the problem first.

Right-size the database, which sizes the proxy

Proportional to instance vCPUs

Proxy cost is proportional to the target instance's vCPUs. Right-sizing the database down also reduces the proxy charge, a double saving.

Share one proxy across functions hitting the same DB

Per avoided proxy

Many Lambda functions or services can share a single proxy to one database. Don't provision a proxy per consumer when one pool serves them all.

FAQ

How does c3x estimate RDS Proxy cost?

It prices per vCPU-hour of the proxied database instance at 730 hours/month, using the target instance class's vCPU count. The charge is continuous and independent of connection volume.

Why does the proxy cost depend on the database size?

RDS Proxy bills per vCPU of the database it fronts, not per request. A proxy for a 4-vCPU instance costs twice one for a 2-vCPU instance, regardless of traffic.

Does the proxy charge stop when there's no traffic?

No. The per-vCPU-hour charge is continuous while the proxy exists. It's an always-on cost, so only deploy a proxy where it solves a real connection or failover problem.

Is the database instance included?

No. The aws_db_instance or aws_rds_cluster behind the proxy bills separately for its compute and storage. c3x estimates it as its own resource.

When is RDS Proxy worth it?

For serverless or bursty workloads that open many short-lived connections (Lambda), where the database would otherwise hit connection limits, and for faster, more transparent failover. For steady connection pools managed in-app, it's often unnecessary.