Finding and cutting unused and idle RDS databases

The databases nobody is using anymore

On almost every non-trivial AWS account I look at, some RDS databases are running that nobody uses. They were spun up for a migration that finished, a service that got decommissioned, or a test that became permanent. They still run 24/7, still carry storage, and still show up on the bill every month.

The problem is not that these are hard to fix. Deleting an unused database or dropping an instance a size is a few minutes of work. The problem is finding them. On an account with dozens of databases spread across several regions, the waste is spread thin, and no single database is obviously wrong to an engineer who does not stare at RDS metrics all day.

What idle actually looks like in the metrics

I do not trust a database is unused because someone thinks it is. I look at the data.

For each database I pull a few dozen CloudWatch metrics over the last 30 days: CPU and memory utilization, IOPS, database connections, and the engine-level SQL metrics. Combined with the instance type specs and the AWS pricing data, that is enough to sort every database into a clear action.

A database with zero connections for 30 days is a deletion candidate, full stop. One running at a few percent CPU with memory usage well under what the instance provides is a rightsizing candidate. Others are candidates for a storage change, an engine version update, or query optimization.

On one recent engagement I ran this across a client with 50+ databases spread over five AWS regions. It produced a single spreadsheet, roughly 50 columns wide, with the current cost and a few alternative configurations costed out for every database. We spent about 45 minutes on a call going through it with one of their engineers. Many of those databases had zero connections and could be safely deleted. Others were clear rightsizing, storage, or Aurora conversion candidates, and a few still needed to move to MySQL 8.x to avoid the Extended Support fees. The total came to over $50,000 per month in savings potential from that one account, all visible on a single view. Their engineer was surprised by most of it.

Delete first, then rightsize

The order matters. There is no point rightsizing a database you should be deleting, so I clear out the unused ones first.

On the first hands-on day of another engagement, in about two hours of work, we shut down an unused m5.xlarge database that was costing $371 a month including its storage, and rightsized two more from m5.large and m6g.xlarge down to t4g.large for another $214 a month. That is $585 a month, about $7,000 a year, from two hours of looking at the right metrics on the right instances.

None of this is rocket science. It is boring waste removal: unused and unneeded resources, plus a few suboptimal configurations. But it adds up. On a larger account, working through waste like this took a client’s spend from about $125,000 a month down to $85,000, a third of the bill, before touching a single reserved instance.

Why this rarely gets done in-house

The engineers who own these databases are usually capable and already doing a lot of things well. What they do not have is the bandwidth to go database by database across every region, pull the metrics, cost out the alternatives, and confirm each one is safe to change. It always loses to higher-priority product work, so it sits there for years.

That is the part we automate. The analysis that used to take me multiple days by hand for a handful of databases now runs in seconds across an entire account, and then we go through the results together and roll out the changes through your own review process.

If you run a meaningful RDS footprint and suspect there is idle capacity hiding in it, book a discovery call or reach out on LinkedIn.

-Cristian