Persistent disk and storage cleanup on GCP is the least glamorous and most reliable saving on the platform, because it is pure waste removal with no performance trade-off. Persistent disks are billed for their full provisioned size as long as they exist, independent of any VM. Snapshots accumulate incrementally but never expire unless you make them. Custom images sit in storage indefinitely. None of this shows up as a problem until you look, and on most estates the orphaned-disk and stale-snapshot line is larger than anyone expects. The good news: deleting genuinely unused storage carries no risk to running workloads.
This article is part of our Google Cloud cluster. For where waste cleanup sits among the wider levers, start with our complete guide to Google Cloud cost optimization, the pillar this piece links up to.
The four kinds of silent storage spend
Four resource types generate cost long after anyone remembers creating them.
| Resource | How it becomes waste | Cleanup action |
|---|---|---|
| Orphaned persistent disk | VM deleted but boot or data disk kept | Snapshot if needed, then delete |
| Unattached disk | Disk detached and never reattached | Delete after confirming with owner |
| Old snapshots | Manual snapshots that never expire | Apply a snapshot retention policy |
| Stale custom images | Build images kept past their usefulness | Delete superseded versions |
Orphaned disks are the biggest single contributor, usually created when a VM is deleted without the disk, because the default behavior depends on how the disk was configured. The idle-disk recommendation in Active Assist flags many of these automatically; see GCP Active Assist and Recommender for cost savings.
Finding orphaned disks
The reliable way to find unattached disks is to list every persistent disk and filter for those with no users field, meaning no VM is attached. You can do this in the console, with the gcloud command line, or at scale by querying asset inventory. Cross-check against the idle persistent disk recommendation, which Recommender generates from usage. Once you have the list, sort by size, because a few large unattached SSDs often dwarf dozens of small ones. Before deleting, confirm with the owning team, because a detached data disk occasionally holds the only copy of something that matters.
Snapshots: the slow accumulator
Snapshots are incremental, so each one stores only the blocks changed since the last, which makes them feel cheap. The cost creeps in when manual snapshots pile up with no retention policy and are never deleted. The fix is a snapshot schedule with a retention period, so snapshots roll off automatically after, say, 30 or 90 days, matching your actual recovery needs. Replace ad hoc manual snapshots with scheduled ones that expire. Be careful deleting old snapshots in a chain; modern snapshots are managed so deleting one does not corrupt others, but always keep the retention you genuinely need for disaster recovery.
Want the silent storage waste cleaned out?
Our Google Cloud cost audit inventories every disk, snapshot, and image across the estate, ranks the waste by dollars, and cleans it up with the right safety checks and retention policies in place. On the performance model you pay only from realized savings. No savings, no fee.
Book a GCP cost audit →Rightsize the disks you keep
Cleanup is not only deletion. Disks that are still in use are often the wrong type or size. Many workloads run on SSD persistent disks when a balanced or standard disk would serve fine at lower cost, and many disks are over-provisioned far beyond what the workload uses. Match the disk type to the performance the workload actually needs, and provision capacity to real usage rather than a round number chosen at creation. This pairs with VM rightsizing; see how to rightsize Compute Engine VMs with Recommender.
Make cleanup continuous, not a one-off
The reason this waste recurs is that nothing stops it returning. A one-time sweep helps once; a standing process keeps the saving. Set a snapshot retention policy so snapshots expire automatically. Configure VM deletion so boot disks are removed with their VMs unless explicitly retained. Run a monthly orphaned-disk report and assign the cleanup. Label disks so you can tell who owns each one; see labels and folders for cost allocation on Google Cloud. The goal is that orphaned storage is caught within a month, not discovered a year later.
Disk types, snapshot mechanics and deletion behavior above reflect Google Cloud as of May 2026. Verify current behavior in Google Cloud documentation before acting, as the platform changes.
The Google Cloud Cost Optimization Field Guide includes our orphaned-disk inventory queries and the snapshot retention templates we deploy. It is the downloadable companion to this article.
The short version
Persistent disks, snapshots, and images keep billing long after the VM is gone, and on most estates orphaned disks are the single largest piece of silent waste. Find unattached disks by filtering for no attached VM, sort by size, confirm with owners, and delete. Replace ad hoc snapshots with a retention schedule, prune stale images, and rightsize the disks you keep. Then make it continuous so the waste never rebuilds. When you want this swept and kept clean across the estate, that is exactly what our Google Cloud cost optimization service delivers.