Prune old manual RDS snapshots

Every RDS manual snapshot you or a script creates is a line item in your S3-backed storage bill at roughly $0.095 per GB-month — and unlike automated snapshots, nothing in AWS will ever delete it automatically. That means every pre-migration safety net, every final snapshot taken at database decommission, and every ad-hoc copy sits on your bill in perpetuity until someone explicitly decides to remove it.

The unit economics are deceptively small: a single 100 GB snapshot costs about $9.50/month, just over $114 a year. But the pattern scales. An account with two years of migration activity typically accumulates dozens of these, often attached to databases that no longer exist. At $300–$1,500/month for a mid-size fleet, the line is real, it owns no budget, and it grows every time someone runs a pre-migration runbook without a paired cleanup step.

RDS-007 is the audit mechanism that surfaces this: flag every manual snapshot older than 90–180 days and demand a decision. The finance role here is to make that decision process systematic — a tiering judgment between delete (source database is gone, no retention requirement), archive (must keep for compliance but at 87% less cost), and keep standard (actively needed). The goal is zero unowned, unbudgeted snapshot storage, not zero snapshots.

Jordan is the FinOps analyst reviewing the monthly AWS bill. RDS storage is up $420 month-over-month with no corresponding infrastructure change in the sprint log. The spike isn't a new database — it's old backup data that crossed an accounting threshold nobody was watching.

She pulls the manual snapshot inventory grouped by source database, sorted by age and cost. The output is immediately legible as a chargeback problem: three engineering teams own the top fifteen snapshots by cost, totalling $1,140/month. Every snapshot is tagged to a project or database, so ownership is traceable. None of them have a budget line — they were created as one-time safety nets and never decommissioned.

Jordan takes the list to the next engineering leads review with a simple table: snapshot name, owner team, age, GB, and monthly cost. The ask is a decision per row within two weeks — delete, archive, or document a retention reason. Three of the snapshots turn out to have compliance requirements; those go to the Archive tier at $0.0125/GB-month, cutting their combined cost from $190 to $25. The rest are deleted. The $420 spike disappears from next month's bill and the process becomes part of the quarterly cloud cost review.

The billing mechanics make this a compounding problem. RDS snapshots bill at $0.095/GB-month on the allocated storage of the source instance, not the actual data on disk — so a 1 TB instance that was 20% full creates a 1 TB-allocated snapshot bill. Cross-region copies are billed independently in each region at the same rate, and cross-account shares that are accepted in another account create an additional billable copy there too. A single 400 GB snapshot replicated to one DR region is already paying for 800 GB.

The compounding part is time. A snapshot that cost $38/month when it was created costs the same amount 18 months later, even if the database it backed is long gone. There is no decay, no expiry, and no automatic signal — only the ever-growing cumulative line on the bill. Over two years of active migration work, a mid-size fleet routinely accumulates $500–$2,000/month in unowned snapshot storage because none of the individual snapshots ever crossed a threshold that warranted attention.

The finance intervention is to make the cost visible and owned. Put the monthly snapshot storage cost on the team-level chargeback report, broken down by source database tag and age bucket (30–90d, 90–365d, 365d+). The 365d+ bucket is almost always pure waste; the 90–365d bucket is where tiering decisions live. Requiring a retention reason and a named owner for every snapshot in the 90d+ bucket — on a quarterly cadence — is the recurring control that keeps the long tail from re-forming after a cleanup.

On the compliance side, untracked snapshots create audit exposure that has a dollar cost too. GDPR remediation findings, HIPAA audit observations, and PCI-DSS gap reports all generate consulting and remediation effort that dwarfs the storage cost they were triggered by. The cheapest version of compliance is a current, documented inventory — not a retroactive scramble.

Manual RDS snapshots are permanent by default — they accumulate every time an engineer takes a safety copy before a migration and never comes back to remove it. The result is a growing inventory of data at rest with no owner, no retirement policy, and a continuous storage charge. RDS-007 flags these when they age past a threshold because the organization has no recorded reason for their continued existence.

This is a governance failure as much as a cost one. GDPR, HIPAA, and PCI-DSS all require that personal or regulated data is deleted when its purpose expires. A snapshot taken before a data-deletion event still contains the deleted records. If no one knows the snapshot exists, the deletion was never actually complete — and that gap is the kind of finding that turns a routine audit into an incident.

The right organizational response is a policy, not a cleanup sprint: all backup creation must happen through a managed tool (AWS Backup) with defined retention, and manual snapshots require a paired deletion task in the runbook. That turns "we have a long tail" into a one-time remediation followed by a clean ongoing state. The leadership signal to track is not the count of old snapshots, but whether new ones are still being created outside the governed process.

At a scale-up, the VP of Engineering, Marcus, noticed that the AWS bill kept growing even in quarters where headcount and product scope were flat. The culprit turned out to be a five-year accumulation of manual RDS snapshots — pre-migration safety copies, final snapshots from decommissioned databases, and cross-region DR copies that had never been cleaned up. No one team owned them; no one had a mandate to review them.

The fix was not a cleanup sprint — it was a policy change. Marcus mandated two things: all new backup creation goes through the company's AWS Backup plan with a defined retention period, and every pre-migration runbook must include a paired decommission step to delete or archive the snapshot after the migration succeeds. The existing long tail was addressed in a single two-week triage, reducing RDS storage spend by $900/month.

The lasting organizational outcome was clarity of ownership. Backup data is now traceable to a project and a retention reason, and the monthly cost review includes a standing snapshot-age report. When regulators ask how long personal data persists in backups, Marcus has a documented answer with evidence — not a search through years of S3 keys. That's the difference between managing backup data and hoping no one looks.

The direct cost of old manual snapshots is real but bounded — a few hundred to a few thousand dollars a month depending on fleet size. The more consequential issue is what the accumulation signals: no one owns the data, no one knows when it expires, and no one has accountability for cleaning it up. That is a data governance failure with regulatory consequences.

GDPR Article 17, HIPAA's minimum necessary standard, and PCI-DSS Requirement 3 all impose obligations on how long you retain personal or cardholder data. A snapshot taken before a privacy-driven deletion event still contains the deleted records in full. If the snapshot is unknown to the data inventory, the deletion was never complete — and that gap can surface as a material finding in an audit. The cost of remediating a data-retention audit observation is orders of magnitude higher than the cost of the snapshot itself.

The executive signal to watch is not the snapshot count — it's whether new unmanaged snapshots are still being created. If the answer is yes, a cleanup sprint will just produce a clean slate that refills over the next 12 months. The durable fix is a policy: all backup creation through a governed tool with retention defined up front, and manual snapshots forbidden except through a documented exception process. When that policy is in place, the snapshot inventory becomes a trailing indicator of past practice, not an ongoing liability.