Persistent Disk

Persistent Disks are block storage volumes for Compute Engine, billed per provisioned GB per month whether attached or not. Unattached disks left behind after VM deletion keep billing indefinitely.

A meter that ignores the VM entirely

A persistent disk charges for its provisioned capacity by disk type (standard, balanced, SSD, or extreme) every month it exists. Written bytes are irrelevant: a 500 GB volume holding 20 GB pays for 500. So is the state of whatever it is attached to: the disk meter runs at full rate while its VM is stopped, and continues untouched after the VM is deleted unless the disk goes with it. Scheduling VMs off therefore trims compute spend but leaves the storage line exactly where it was.

How ZopNight maps attachment across the fleet

ZopDev inventories every disk via Cloud Asset Inventory, enriches attachment state, and flags unattached and over-provisioned disks through its recommendation rules. One subtlety it handles: disks provisioned by GKE through the Compute Engine PD CSI driver show an empty users list in the asset data, because the kubelet brokers the attachment and the GCE API never records a node reference. ZopNight resolves those through the cluster’s persistent volumes rather than misreporting in-use disks as orphans.

The forms persistent-disk waste takes

Orphans lead the list: volumes surviving their deleted VMs, billing quietly for months. Over-provisioning follows: disks sized generously up front can grow but never shrink, so early padding becomes a permanent charge. Third is type mismatch, where dev and test volumes sit on SSD or extreme tiers for workloads a standard disk would serve indistinguishably.

Auditing volumes from the console

Google Cloud console → Compute Engine → Disks lists every volume with its size, type, and the In use by column. Sorting so the blank In use by rows surface first gives an immediate orphan shortlist, with the caveat above that GKE CSI-managed disks need their cluster checked before deletion.