# Idle RDS Proxy -- No Connections

> RDS Proxy bills per vCPU-hour of its target database even with no traffic. ZopNight flags a proxy for deletion when every present connection series, DatabaseConnections and ClientConnections, stays below 1.0 on average and peak with 30 full days of coverage, and abstains when both series are absent.

Source: https://zop.dev/integrations/aws/recommendations/idle-rds-proxy-no-connections
Updated: 2026-08-19

---

## A proxy bills even when nothing connects through it

RDS Proxy is [priced per vCPU-hour of the database instance behind it](https://aws.amazon.com/rds/proxy/pricing/), a standing charge that
accrues whether or not a single client resolves the proxy endpoint. That makes an abandoned
proxy a clean deletion target: removing it recovers 100% of its charge, because a proxy nobody
connects through provides no pooling benefit to trade off.

Proxies get orphaned in a specific way. The pooling layer is added for a Lambda-heavy workload,
the workload is later rearchitected or pointed straight at the database, and the proxy keeps
billing in front of a database that no longer needs it.

## Two connection axes and a floor of 1.0

The proxy has two distinct connection populations. `ClientConnections`, [one of the proxy-scoped series under AWS/RDS](https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/monitoring-cloudwatch.html), counts applications
attached to the proxy endpoint; `DatabaseConnections` counts the pooled connections the proxy
holds open to its target. Traffic on either one proves the proxy is working, so every series
that is present must sit below the floor, on average **and** at peak.

The floor is 1.0 rather than exactly zero because health-check probes and stray pings leave a
trace signal on proxies that are functionally dead. And each present series must carry 30 full
days of coverage (a stricter bar than the platform's usual 7) because the recommendation is
deletion, and a partial week cannot prove a month of silence. When both series are absent the
rule abstains outright.

## How the proxy's metrics get matched up

CloudWatch dimensions proxy metrics by the customer-assigned proxy name, while the platform
identifies each proxy by the opaque `prx-...` id from its ARN. Discovery records the real name
and the metrics pipeline queries CloudWatch with it, keeping the results keyed to the id. If
that link ever breaks for a proxy, its series simply come back absent, and absence triggers
the abstain path, never an idle verdict.

## Reproduce the proxy check with the CLI

```bash
aws cloudwatch get-metric-statistics \
  --namespace AWS/RDS --metric-name ClientConnections \
  --dimensions Name=ProxyName,Value=my-proxy \
  --start-time "$(date -u -v-30d +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --period 86400 --statistics Average Maximum
```

Repeat with `--metric-name DatabaseConnections`. Both should show nothing reaching 1.0.

## Rewiring applications before the delete

Search Lambda environment variables and ECS task definitions for the proxy endpoint. Those
are the two places proxy references usually hide. Anything still pointing at it should be moved
to the database endpoint directly. The deletion itself is the one write ZopNight performs here,
via `rds:DeleteDBProxy`; if the priced cost is missing the rule stays silent instead of
reporting a $0 saving.