Explanation
Why the waste happens and who it affects.
Those charges apply to what is provisioned, not what the workload uses. Values are commonly set high for a migration or load test, copied from a template sized for the largest database, or left at defaults, and then never revisited.
Defaults matter here. When IOPS and throughput are not specified, Hyperdisk Balanced sets them from the volume size (6 IOPS per GiB plus 3,000, and 1.5 MiB/s per GiB plus 140, up to limits), so large volumes created with defaults are billed for performance above the free baseline even if the application barely does I/O. Provisioned performance above what the VM can deliver is also wasted, because Hyperdisk performance is capped at the VM-level limit.
Billing model
The pricing dimensions that drive this cost.
Rates vary by Hyperdisk type and region.
- Provisioned capacity
- Billed per GiB-month of provisioned size until the volume is deleted
- Hyperdisk Balanced performance
- The first 3,000 IOPS and 140 MiB/s per volume are free; provisioned IOPS and throughput above that are billed monthly, so 5,000 provisioned IOPS bills 2,000
- Hyperdisk Extreme and Throughput
- Extreme bills provisioned IOPS and Throughput bills provisioned throughput, whether used or not
- High Availability variant
- Hyperdisk Balanced High Availability bills capacity, IOPS and throughput at roughly double the zonal rates
How to detect
4 checks to find it in your estate.
- For each Hyperdisk volume, compare provisioned IOPS and throughput (gcloud compute disks describe, provisionedIops and provisionedThroughput) with observed peaks from compute.googleapis.com/instance/disk read and write ops and bytes metrics over a full business cycle
- Apply Google's guidance: if peak IOPS is consistently lower than provisioned IOPS, provisioned IOPS can be lowered to reduce the cost of the disk; do the same for throughput
- Flag large Hyperdisk Balanced volumes created with default performance values, which bill above the 3,000 IOPS and 140 MiB/s baseline by construction
- Check whether the total provisioned throughput across a VM's Hyperdisk volumes exceeds the VM's own Hyperdisk performance limit; anything above it cannot be used
How to fix
4 ways to remove the waste.
- Lower provisioned IOPS and throughput to observed peak plus headroom with gcloud compute disks update --provisioned-iops and --provisioned-throughput; performance can be changed at most once every 4 hours, so step down gradually
- Set explicit IOPS and throughput in templates and Terraform instead of relying on size-based defaults
- Consider Hyperdisk Storage Pools with Advanced performance for fleets of many volumes with uneven load, so performance is pooled instead of provisioned per volume for peak
- Keep performance headroom where latency SLOs require it, and monitor queue length and latency after each reduction
Documentation
Vendor references for pricing and configuration.