Idle RDS instances are different from over-provisioned RDS: over-provisioned findings apply to databases that are receiving connections but have more compute capacity than they need. Idle instances have near-zero database connections over the last 14 days — a signal the database may no longer be in use.
Before you delete or stop
- Confirm no applications, cron jobs, or reporting tools still connect to this database (including from other VPCs or via VPN).
- Check for read replicas, RDS Proxy endpoints, or EventBridge rules that reference this instance.
- Review automated backups and retention — deleting the instance removes automated backups; create a manual snapshot first if you need a recovery point.
- Remember that stopping an RDS instance still incurs storage charges; deleting with a final snapshot removes compute cost but snapshot storage is billed until you delete the snapshot.
Paid plans include remediation scripts that create a final snapshot and delete the instance. AWS does not support --dry-run for RDS delete — review commands carefully before running them.
What triggers this finding
An available RDS database instance older than 14 days with fewer than 0.5 average database connections over the last 14 days.
Typical fix
Create a final snapshot, then delete the instance if the database is no longer needed. Confirm applications and backups no longer depend on it.
Example savings
100% of instance compute charges — typically $15–$500+/month depending on instance class.
See also: Severity and savings estimates for how Parsivex calculates figures on your report.
What the instance-hour charge covers
RDS bills an instance class by the hour for as long as it is available, exactly as EC2 does, and with the same indifference to whether anyone is querying it. Parsivex prices the class from a table of us-east-1 on-demand rates over a 730-hour month — db.t3.medium at $52.56, db.m5.large at $138.70, db.r5.2xlarge at $700.80 — and reports the whole amount as the saving, since removing the instance removes all of it.
Multi-AZ doubles that figure, and the estimate doubles with it. The standby replica is billed at the same rate as the primary, so an idle Multi-AZ db.r5.xlarge is a $700.80 line item rather than $350.40. Idle databases configured for high availability are consistently the most expensive findings in this category.
What the estimate excludes matters just as much. Allocated storage, provisioned IOPS, and backup storage beyond the free allowance are billed separately and are not in the number. That gap is why stopping an idle database saves less than the finding suggests: stopping halts instance hours and nothing else. The storage bill continues in full.
Confirming the connection count
The finding fires when average DatabaseConnections over the last 14 days comes in below 0.5, the instance is available, and it is more than 14 days old. Parsivex reads the metric at a one-day period, so the figure is an average of daily averages.
aws cloudwatch get-metric-statistics --namespace AWS/RDS \
--metric-name DatabaseConnections \
--dimensions Name=DBInstanceIdentifier,Value=my-database \
--start-time 2026-07-29T00:00:00Z --end-time 2026-08-12T00:00:00Z \
--period 86400 --statistics Average Maximum
Half a connection sounds like a strange threshold until you read it as duty cycle. A database holding exactly one session for twelve hours a day averages 0.5 and sits precisely on the line. One holding a single connection continuously averages 1.0 and is never flagged, however little that session does.
Connections are a proxy, and an imperfect one
The metric counts open sessions, not work, and it fails in both directions.
It overstates activity wherever a connection pool is involved. An application server that opens ten connections at boot and keeps them alive reports ten connections forever, even if the database has served no query in a month. Those databases never appear in this finding at all — a genuine blind spot rather than a false positive, and the reason a pooled database deserves a look at CPUUtilization too.
It understates activity for work that is real but brief. A nightly batch job holding one connection for ten minutes averages well under 0.01 across a fortnight. So do quarterly reporting databases, disaster-recovery replicas kept warm and unqueried, staging instances used for a few hours before each release, and databases reached only through an occasional administrative session.
Two structural cases are worth checking before acting. A read replica's replication stream does not register as a client connection on the replica, so a replica serving no read traffic looks idle whether or not the primary depends on it. And databases fronted by a proxy report the proxy's pooled connections rather than the application's, which moves the number without describing the workload.
Stopping is temporary, deleting is not
RDS does not offer an indefinite stop. A stopped instance restarts itself automatically after 7 days, and billing resumes with it. That single fact shapes every decision here: stopping is a way to buy a week of investigation, not a way to save money. Making the saving durable means either deleting the instance or scripting a stop that runs again every week — and the second option keeps paying for storage regardless.
Deletion is the real fix, and it has a specific set of consequences worth being explicit about.
Automated backups are deleted with the instance. Point-in-time recovery goes with them. A final snapshot is the only thing that survives, it must be requested at deletion time, and its storage is billed until it is deleted in turn — at which point it becomes eligible for the orphaned manual snapshot finding rather than disappearing from the bill.
Restoring from a snapshot creates a new instance with a new endpoint hostname. Nothing that connects by DNS name will find its way back without a configuration change, and the restore itself takes time proportional to the data volume. Plan the recovery path before the deletion, not after.
If the database is quiet but not clearly dead, the reversible option is to downsize rather than delete. An instance receiving some traffic on an over-large class is a different finding — see over-provisioned RDS, which by construction never overlaps with this one.