Why this matters
Block storage on Google Cloud bills by provisioned size, not by bytes written. A 1 TB Persistent Disk holding 40 GB of files costs the same as one holding 900 GB. That explains most oversized disks in a typical project: someone picked a round number for headroom three years ago and nothing has revisited it since.
Snapshots bill differently. You pay for the compressed stored bytes of each incremental, so a daily schedule on a quiet boot disk barely moves while one on a busy database grows steadily. The real problem is deletion. Schedules keep firing, retention is often unset, and the snapshot line item climbs until it is your second largest storage cost.
Add the debris: disks left behind when a VM was deleted, images from a migration that finished last spring, regional disks kept for redundancy that nothing needs. Each one bills every hour. None of this needs a redesign. It needs an inventory, a handful of settings, and a rule that stops it coming back.
Before you start
Get read access first. Compute Viewer on each project lets you list disks, snapshots and images. Billing Account Viewer, or a BigQuery billing export you can query, shows what those resources cost. The first pass should change nothing at all.
Turn on the detailed Cloud Billing export to BigQuery if it is not already running. It gives you SKU level rows, which is what you need to separate Persistent Disk Capacity from Persistent Disk Snapshot from the Hyperdisk charges. The export only covers days after you enable it, so switch it on early even if the cleanup happens later.
The Compute API knows how big a disk is, not how full it is. For real usage, run the Ops Agent and read disk utilization from Cloud Monitoring, or run df inside each instance. Write down what each volume is and who owns it. Guessing wrong on a database disk is how a cleanup turns into an incident.
How to do it
Work from safest to riskiest. Deleting unattached disks and stale images carries almost no risk. Changing disk types shifts load onto performance, so it comes after you have usage numbers. Snapshot location affects future restores, so decide it once, deliberately, with the recovery plan open.
On zonal Persistent Disk, pd-standard is the HDD backed tier and the cheapest per GB, pd-balanced sits in the middle and scales IOPS with size, and pd-ssd costs the most. Hyperdisk Balanced, Throughput and Extreme separate capacity from performance, so you can keep a small fast disk instead of buying capacity you do not need just to reach an IOPS target. That decoupling is the biggest structural saving for performance sensitive workloads.
Snapshot storage location is a project level setting under Compute Engine, then Settings, then Snapshots. The default places new snapshots in a multi-region bucket priced above a single region. If restores always happen in one place, pin the location there. Existing snapshots keep their original location, so pair the change with a retention policy or the old ones stay forever.
- Export storage cost by SKU. Turn on detailed Cloud Billing export to BigQuery and filter rows where the service is Compute Engine and the SKU name contains Persistent Disk or Hyperdisk. Group by project and label so you can see which team owns the bytes.
- Sweep for unattached disks. Run gcloud compute disks list --filter='-users:*' in every project. Each result is billing for nothing. Snapshot anything whose data might matter, then delete it.
- Measure real usage. Read disk utilization from Cloud Monitoring through the Ops Agent, or run df -h on each instance. Flag every volume sitting well under its provisioned size.
- Rightsize the big offenders. Plan capacity at current usage plus a stated growth buffer, not at a round number. Since disks cannot shrink, schedule the snapshot, copy and swap for the few volumes where the waste is large.
- Move cold volumes to cheaper media. Backup targets, log volumes and build caches belong on pd-standard. Keep databases on pd-balanced or higher, and use Hyperdisk Throughput where you need speed without the capacity.
- Drop regional disks where one zone is fine. A regional disk bills for two replicas, so a single zone workload does not need one. Recreate it zonal, or delete the standby if another layer already covers that failure mode.
- Pin snapshot storage to one region. In Compute Engine, open Settings then Snapshots and choose a region close to where you would restore. Existing snapshots stay where they are, so plan to let them age out.
- Add retention to every schedule. Edit each snapshot schedule resource policy and set max retention days, or recreate it with --max-retention-days. Ten to fourteen days covers most operational mistakes, and longer weekly copies should exist only where an owner asks.
- Clear out old images. List custom images and machine images, then delete the ones nobody has used since the last migration. They bill at snapshot rates and rarely get reviewed.
How to check it worked
Compare the same SKU rows in BigQuery a full month apart. Storage is charged per GiB hour, so a mid month cleanup shows up as a partial month drop. Watch the trend, not a single day.
For snapshots, run gcloud compute snapshots list and look at storageBytes rather than diskSizeGb. That field is what you actually pay for, and it is usually a fraction of the disk size. A snapshot far larger than its neighbors is normally a full copy taken after a disk swap, not a routine incremental.
Rerun the unattached disk query after a month. It should be empty, or every entry should carry an owner and a label. Test one restore into a throwaway disk in the region you chose. A cheap snapshot location that takes hours to restore from is a bet, not a saving.
Mistakes to avoid
You cannot shrink a Persistent Disk. Downsizing means snapshot, create a smaller disk, copy the data, verify, swap, delete. Do that for the volumes where the waste is large, and leave the marginal ones alone.
Moving a write heavy volume from pd-ssd to pd-standard to save money backfires, because pd-standard gives far fewer write IOPS per GB and queues build under load. Read IOPS and throughput from Cloud Monitoring before the switch, and move one non critical disk first.
Do not delete snapshots to hit a target without confirming where else the data lives. And fix the defaults in your instance templates and Terraform modules. Otherwise the next autoscaled VM arrives with a 500 GB pd-ssd boot disk and the problem returns within a week.
If the inventory turns out bigger than one person can work through, or finance wants a ranked number before approving changes, the Cloud cost audit from Cloudverg is a two-week read-only review at $4,500 fixed price covering storage tiers, idle resources and commitments. It is one option among several, and the steps above still apply whether or not you use it.
Frequently asked questions
How does Google Cloud bill for snapshots?
Snapshots are incremental and compressed, and you pay for the stored bytes of each one, not for the size of the source disk. Deleting a snapshot only frees the blocks no later snapshot depends on, so removing the newest often saves more than removing the oldest.
Can I make a Persistent Disk smaller?
No. Capacity is fixed at creation, so shrinking means creating a smaller disk, copying the data across and swapping it in. Check the filesystem too, since XFS cannot be shrunk at all and ext4 shrinking is an offline operation with real risk.
Do I still pay for disks after deleting a VM?
Yes, unless the boot disk had auto-delete turned on. Attached non boot disks and boot disks with auto-delete disabled keep billing after the instance is gone. Confirm the leftovers with gcloud compute disks list --filter='-users:*'.