GCP Hyperdisk cost: pay for capacity, IOPS, and throughput separately
Hyperdisk is GCP's newer block storage that decouples capacity, IOPS, and throughput, so you provision and pay for each independently. This flexibility avoids over-buying, but over-provisioning any dimension wastes money. Here is the model.
Quick answer
Hyperdisk is Google Cloud's next-generation block storage that decouples capacity, IOPS, and throughput, so you provision and pay for each independently rather than getting performance bundled with size. This lets you buy exactly the performance you need without over-buying capacity (or vice versa), but over-provisioning any of the three dimensions wastes money, so right-sizing all three to real need is the lever.
Hyperdisk is GCP's newer block storage family, and its key difference from Persistent Disk is that it decouples the three dimensions of storage performance: capacity, IOPS, and throughput. Instead of performance scaling with size, you provision each independently. That flexibility is powerful for cost, because you no longer over-buy capacity just to get IOPS, but it also means three dimensions to size, each billed.
Three independent dimensions
| Dimension | Provision and pay for |
|---|---|
| Capacity | Per GB-month |
| IOPS | Per provisioned IOPS |
| Throughput | Per provisioned MB/s |
You set capacity, IOPS, and throughput independently (within the limits of the Hyperdisk type), and pay for each. So a workload needing high IOPS on modest capacity provisions high IOPS and low capacity, without paying for large unused space, which the old bundled model would have forced.
The flexibility cuts both ways
Decoupling avoids the classic waste of over-buying capacity to reach a performance level. But it also makes over-provisioning IOPS or throughput easy and expensive, since they are billed separately. The common mistake is provisioning generous IOPS and throughput a workload never uses. Right-size all three to real, measured need.
Hyperdisk vs Persistent Disk
Persistent Disk bundles performance with capacity (bigger disks get more IOPS), so you sometimes over-buy capacity for performance, as in the Persistent Disk types. Hyperdisk's decoupling lets you provision precisely, which can be cheaper for workloads whose performance and capacity needs are mismatched (high IOPS on small data, or large capacity with modest IOPS). For balanced needs, either works; Hyperdisk shines when the dimensions diverge.
Controlling Hyperdisk cost
Provision capacity, IOPS, and throughput each to real measured need, avoid generous defaults on the performance dimensions since they bill separately, use Hyperdisk where decoupling avoids over-buying capacity for performance, and monitor usage to right-size over time. The decoupled model rewards precise sizing, so measure and tune each dimension rather than over-provisioning to be safe.
FAQ
How is GCP Hyperdisk priced?
By provisioning capacity (per GB-month), IOPS (per provisioned IOPS), and throughput (per provisioned MB/s) independently, so you pay for each dimension separately rather than getting performance bundled with size. This lets you buy exactly the performance and capacity you need, but over-provisioning any dimension wastes money.
How is Hyperdisk different from Persistent Disk?
Persistent Disk bundles performance with capacity, so bigger disks get more IOPS and you sometimes over-buy capacity to reach a performance level. Hyperdisk decouples capacity, IOPS, and throughput, letting you provision each independently. This is cheaper for workloads whose performance and capacity needs are mismatched.
How do I reduce Hyperdisk cost?
Provision capacity, IOPS, and throughput each to real measured need, avoid generous defaults on the performance dimensions since they bill separately, use Hyperdisk where decoupling avoids over-buying capacity for performance, and monitor usage to right-size over time. Precise sizing of all three dimensions is the lever.
When is Hyperdisk cheaper than Persistent Disk?
When a workload's performance and capacity needs are mismatched: high IOPS on small data (where Persistent Disk would force buying large capacity for the IOPS) or large capacity with modest IOPS. Hyperdisk's decoupling lets you provision precisely for such workloads, avoiding the over-buying that bundled pricing causes.
What is the risk with Hyperdisk's decoupled pricing?
Over-provisioning the performance dimensions. Because IOPS and throughput are billed separately, provisioning generous amounts a workload never uses wastes money on each. The flexibility that avoids over-buying capacity also makes over-buying performance easy, so right-size all three dimensions to measured need.
Does C3X estimate Hyperdisk cost?
C3X prices Hyperdisk resources from your Terraform, including provisioned capacity, IOPS, and throughput, so the decoupled cost across all three dimensions appears before deploy, making over-provisioned performance visible.
What to do next
Right-size your block storage before you deploy. C3X reads your Terraform and prices your resources against a live catalog. Start with the quickstart.
Related posts
- GCP Filestore cost: you pay for provisioned capacity by tier
Filestore bills per GB-month of provisioned capacity by tier (Basic HDD, Basic SSD, Zonal, Enterprise), with tier minimums. You pay for the capacity you allocate, not what you use, so tier and size choice drive the bill. Here is how to pick.
- GCP Memorystore cost: you pay for provisioned capacity per hour
Memorystore for Redis bills per GB of provisioned capacity by the hour, by tier (Basic or Standard with a replica). Capacity, not usage, sets the bill, so right-sizing the instance and choosing the tier are the levers. Here is how it prices.
- EBS throughput vs IOPS cost: which one you are actually paying for
On gp3 you provision IOPS and throughput separately, and paying for the wrong one is a common waste. Here is how the two are priced, how to tell which your workload needs, and why a database and a log archive want opposite settings.
- GCP Cloud Run jobs cost: pay for the work, nothing when idle
Cloud Run jobs bill per vCPU-second and memory-GiB-second while the job runs, with no idle cost since jobs run to completion and stop. It suits batch and scheduled work. Here is how the model works and how it differs from Cloud Run services.
Share this post
Try C3X on your own Terraform
Free and open source. No API key required. One command to install, one command to estimate.