Storage bills rarely spike. They drift. A few more snapshots here, a copy for a migration that finished last year there, and eventually the line item is large enough that someone asks why. The good news is that storage waste is usually concentrated in a handful of predictable places. This checklist is meant for a review session of an hour or two, run by whoever owns the data platform, with someone from finance or engineering management present to confirm what can go.

Before You Delete Anything

Cost reviews go wrong when they turn into cleanup sprees. Before touching data, agree on three rules.

1. Find an owner first. Anything without a known owner gets tagged and announced, not deleted.
2. Prefer reversible steps. Moving data to a cheaper class or enabling versioned deletion is safer than permanent removal.
3. Check retention obligations. Some data must be kept for legal, contractual or audit reasons, and requirements vary by jurisdiction and industry. Confirm with the right people before shortening any retention.

Where Storage Waste Usually Hides

Forgotten copies

Test exports, one-off analyses and migration staging areas tend to outlive their purpose. Search for buckets and folders with names like “tmp”, “backup”, “old” or “test”, then look at when they were last read, not just written.

Snapshots and backups without an expiry

Automated snapshots are valuable, but a schedule that never expires old ones grows forever. Check that each backup policy has a retention period that matches a real recovery need.

Versioning on high-churn data

Object versioning protects against accidental overwrites, but on data that is rewritten daily, old versions accumulate quietly. Pair versioning with a rule that removes noncurrent versions after a sensible window.

Incomplete uploads

Interrupted multipart uploads can leave fragments behind that count toward your bill while serving no purpose. Most providers let you add a rule to clean these up automatically; check current documentation for the exact setting.

Tiny files

Millions of very small objects can inflate request costs and slow queries. Compacting them into larger files often helps on both counts.

Over-provisioned volumes

Block and file storage are often paid for by provisioned size rather than used size. A volume sized for a peak that never arrived is a common finding.

The Review Checklist

Check	What to look for	Safe first action
Unowned buckets	No tag or contact	Tag, announce, set a review date
Old snapshots	No expiry rule	Add retention, then expire gradually
Noncurrent versions	Growth with no cleanup	Lifecycle rule for old versions
Incomplete uploads	Leftover fragments	Abort-incomplete rule
Cold data in hot tiers	No reads for a long period	Move to a cooler class
Small-file sprawl	Huge object counts	Plan a compaction job
Oversized volumes	Low utilization	Resize in a maintenance window
Cross-region copies	Duplicates with no stated reason	Confirm purpose, then decide

Look at Access, Not Just Size

The largest bucket is not necessarily the best target. A modest dataset read heavily from another region may cost more in transfer than a huge archive costs to sit. Use your provider’s cost and usage reporting to break spend down by capacity, requests and data transfer, and use storage access logs or analytics to see what is actually read. This tells you whether to change a tier, a location or a data layout.

Use Tags to Make This Repeatable

A review is far easier when resources carry consistent tags for team, project and environment. Without them, you spend the session guessing who owns what. Decide on a small set of required tags, enforce them at creation where your tooling allows, and report cost by tag each month. Visibility changes behavior: teams who can see their own storage spend tend to tidy it up without being asked.

Do Not Trade Cost for Recoverability Blindly

Cutting backup retention or dropping a replica saves money and also reduces your safety net. Write down the recovery point and recovery time you actually need for each important dataset, then size backups to meet them. If nobody can state the need, that is a finding in itself and worth resolving with the business owner.

A Realistic Example

Imagine a hypothetical data team that runs their first review. They find a staging bucket from a finished migration, daily snapshots with no expiry, and a versioned bucket where a nightly job rewrites the same files. They tag the staging bucket and give owners a short window to object, add an expiry to the snapshot policy, and set a lifecycle rule for old versions. Nothing is deleted on day one. A few weeks later, with no objections, the staging data is removed. The team puts a recurring review on the calendar and adds the checklist to their onboarding notes so the work does not depend on one person’s memory.

Frequently Asked Questions

How often should we run a storage cost review? A quarterly rhythm suits many teams, with lighter monthly checks of cost reports. Fast-growing platforms may want to review more often.

Is moving data to an archive tier always cheaper? Not always. Archive classes usually have lower holding costs but can add retrieval charges, delays and minimum retention periods. They suit data that is rarely read, so check the provider’s current terms.

Should we delete old data or keep it just in case? Decide by policy rather than instinct. Define retention per dataset based on business, legal and recovery needs, then automate it. Keeping everything indefinitely has a cost, and so does deleting something you later need.

What is the quickest win in most reviews? Lifecycle rules for expiring temporary data, old snapshots, noncurrent versions and incomplete uploads. They are low risk and keep working after the review ends.

Do cost tools replace manual review? They help by surfacing candidates, but a person who knows the business context still has to decide what is safe to change.

Next Step

Schedule a one-hour review this week. Export your storage spend by service, pick the top three line items, and run the checklist against each. Record every finding with an owner and a date, and start with the reversible actions.