RDS Proxies pooling no connections for a month
What does ZopNight detect here?
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.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-170 |
| Category | idle |
| Severity | medium |
| Metric | none — pure configuration read |
| Source | rds_proxy_idle.go |
Where it applies
A proxy bills even when nothing connects through it
RDS Proxy is priced per vCPU-hour of the database instance behind it, 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, 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
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 MaximumRepeat 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.