Aurora DB clusters with zero connections and under 5% CPU for 30 days

An Aurora cluster bills for instances and storage whether or not anyone connects

Each Aurora cluster pays for its DB instances by the hour plus cluster storage and backups. The stop and start guide shows how much of that is instance time: while a cluster is stopped, you are charged only for cluster storage, manual snapshots and automated backup storage within the retention window. But a cluster can only stay stopped for up to seven days before Aurora starts it again, so stopping is a pause, not a fix for a database nobody uses.

Finding clusters with no clients

aws rds describe-db-clusters \
  --query 'DBClusters[?Status==`available`].[DBClusterIdentifier,Engine,EngineMode]'

aws cloudwatch get-metric-statistics --namespace AWS/RDS --metric-name DatabaseConnections \
  --dimensions Name=DBClusterIdentifier,Value=orders-aurora \
  --start-time 2026-08-26T00:00:00Z --end-time 2026-09-25T00:00:00Z \
  --period 86400 --statistics Maximum

A daily maximum of zero for a month, with CPU flat near the floor, is the pattern this rule looks for.

Every guard the cluster passes

1. Its status is available; a stopped or modifying cluster is left alone.
2. DatabaseConnections is present, has at least 7 days of peak data in the 30-day window, and is zero on both average and maximum.
3. CPUUtilization for the same cluster is present and below 5% on both average and maximum. A cluster with no clients but real CPU, from replication, maintenance or a batch process running inside it, is not idle.
4. It has no known recurring schedule. A cluster parked on a schedule looks quiet because it is already being managed.
5. ZopNight has a positive monthly cost for it.

Clusters that are not reported

Missing CPU data is enough to stop the finding: a zero-connection signal alone is not treated as proof. Clusters with any connection at peak are skipped. Development clusters that are used by day are better served by Dev/Test Aurora Off-Hours Scheduling Opportunity.

Pricing the finding on deletion

saving = monthly cost ZopNight holds for the cluster itself
cost after deletion = 0

For a provisioned cluster, the member DB instances are priced on their own and flagged separately when idle, so deleting the cluster with its instances recovers both.

ZopNight does not offer an automated stop for this finding. A stop would return within seven days and keep the storage charge, so it could not deliver the saving shown.

Retiring or shrinking the cluster

1. Confirm no application, job or reporting tool uses the cluster endpoints.
2. Delete with a final snapshot: aws rds delete-db-cluster --db-cluster-identifier orders-aurora --final-db-snapshot-identifier orders-aurora-final after deleting its DB instances.
3. If it must stay reachable for rare use, consider Aurora Serverless v2 with a minimum capacity of 0 ACUs, which pauses automatically after a period with no user connections and is not charged for instance capacity while paused.