Aurora clusters with no connections for 30 days
What does ZopNight detect here?
ZopNight flags an Aurora cluster when DatabaseConnections stays at zero and CPU stays under 5% across a 30-day window. Both axes are required: a cluster with no client connections can still be burning CPU on replication or backups, and that is not safely idle.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-190 |
| Category | idle |
| Severity | high |
| Metric | none — pure configuration read |
| Source | aurora_idle.go |
Where it applies
Two axes, because connections alone are not enough
DatabaseConnections at zero is the primary signal, read from the CloudWatch series Aurora publishes for each cluster. On its own it is not sufficient, because an Aurora
cluster with no clients attached can still be doing real work: replicating to a reader, running
a backup window, or processing background maintenance.
So CPU is required as well, below a 5% average over the same 30 days. A cluster that is quiet on both axes for a month is genuinely unused.
Severity is high here, unlike most idle findings. Aurora charges by the instance-hour on top of storage and I/O, and an idle
cluster is one of the largest single recoverable line items the rules surface.
Reading DatabaseConnections at Maximum
aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name DatabaseConnections --dimensions Name=DBClusterIdentifier,Value=my-cluster --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 MaximumUse Maximum rather than Average. A single connection during a nightly job averages to
almost nothing across a day and would look like zero.
The option before deletion
Aurora Serverless v2 scales to a minimum ACU rather than to zero, so “idle” still bills. If the cluster is genuinely unused, deleting it recovers the full cost. If it is used rarely rather than never, moving to Serverless v2 with a low minimum capacity usually beats a schedule, because the cluster stays available for the occasional query.
Take a final snapshot before deleting. Snapshots bill for storage but are a fraction of a running cluster, and they make the decision reversible.
Reader instances are counted separately
An Aurora cluster’s cost is the sum of its instances, and readers are frequently the forgotten part. A cluster showing no connections often has a reader provisioned for a failover story that was never exercised, or for an analytics workload that moved elsewhere. Check the instance list before deciding the cluster is the unit to remove: dropping an unused reader is a smaller, lower-risk change that recovers most of the cost.