Why dead data accumulates
Every migration, experiment, and decommissioned service leaves data behind. The export bucket from a one off analysis. The BigQuery dataset behind a dashboard nobody opens anymore. Snapshots of disks attached to instances that no longer exist. None of it is large on its own, and none of it has an obvious moment to be deleted, so it sits on standard storage at full price indefinitely. Because storage cost is spread across many small objects with no single owner, no one ever sees a number big enough to act on.
Find unused data by signal, not by guess
The safe way to identify candidates is to use access signals the platform already records. In Cloud Storage, rank buckets and objects by last access time and size, and the large, untouched objects rise to the top. In BigQuery, look at last modified time and query history per table to find datasets with no reads over a meaningful window. Cross reference both against an owner label so every candidate has a team you can ask. Anything large, untouched, and unowned is your highest confidence target.
Decommission in stages, never in one delete
Outright deletion is what makes teams refuse to clean up. Stage it instead. Move candidates to a quarantine location or a cheaper storage class so cost drops immediately while the data is still recoverable. Notify owners with a deadline to object. After the window, delete what no one claimed, with a recovery period as a safety net. For anything under a retention obligation, archive rather than delete: Cloud Storage Archive and BigQuery long term storage keep the data at a fraction of standard pricing. Lifecycle rules then automate the same path for future data so the cleanup does not have to be repeated by hand.
A worked example
Indicative figures, verified against the client's billing data, anonymized. A European SaaS company had roughly 31 percent of its Cloud Storage and BigQuery spend on data with no access in over six months.
| Stage | What happened | Indicative monthly cost |
|---|---|---|
| Starting point | All data on standard classes | 74,000 USD |
| Quarantine and downclass | Cold data moved to Coldline and long term storage | 61,000 USD |
| Delete unclaimed | Orphaned buckets and stale snapshots removed | 52,000 USD |
| Lifecycle rules in place | Future data ages down automatically | 52,000 USD and holding |
The staged decommission cut roughly 30 percent off monthly data spend, with no production incident, because nothing was deleted until owners had a chance to object and a recovery window protected the rest. The lifecycle rules keep the gain from eroding.
Your next step
Rank your storage and BigQuery by last access, attach owners, and run the staged sequence on the largest untouched data first. For the wider method read the GCP cost optimization guide, and for neighbouring detail see the GCP data review playbook and snapshot and backup cost discipline on GCP. To run the decommission with us, our GCP cost optimization service turns the access analysis into verified savings, and you can request a free trial with zero provider commissions.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.