Idle RDS databases
A database at near-zero CPU costs what a production one costs — and databases are the priciest hourly resources in a typical account.
What this problem is
RDS bills the instance class continuously, and databases are among the most expensive hourly items in an AWS account. An idle database is not a small line: it is frequently the single largest item in a waste report.
Idle databases appear where the lifecycle of an environment and of its database came apart. The staging environment that was replaced but whose database stayed; the replica created for a migration that finished; the database of a decommissioned service, kept "until we're sure" nobody queries it. Because the database keeps accepting connections and looking healthy, nothing signals that it is surplus.
The way out depends on whether the data still matters. If it does, a final snapshot preserves everything for a fraction of the instance price, and the database can be restored from it if anyone needs it. If it does not, terminating settles it. What rarely justifies itself is keeping a database running, idle, on indefinite precaution.
How we detect it
We list database instances with DescribeDBInstances and read the average CPU utilization RDS publishes to CloudWatch, via GetMetricStatistics, across a multi-week window.
- Idle RDS databases
What it costs
A db.t3.medium runs about $50 a month, a db.m5.large about $125, a db.r5.large about $170 (us-east-1, single instance, on demand). A snapshot of the same data costs a fraction of that.
Public AWS list prices, us-east-1, subject to change. The figure in your report is computed against your resources in your regions.
How it appears in the report
An illustrative example, with invented resources and figures. In the report each finding carries the real resource, its region, and the fix command where a safe one exists.
Does your account have this?
The scan is read-only and shows you what it found before you pay for anything.
Run a free scan