Persistent Disk on GCP is charged on the capacity you provision, not the capacity you fill, and the rate depends on the disk type you pick. That makes rightsizing a three part exercise: choose the cheapest disk type that meets the access pattern, provision capacity close to real need rather than to a round number, and find and delete the disks that are detached or idle but still billing. Because Persistent Disk cannot be shrunk in place, the route to a smaller disk is to create a right sized one, migrate the data, and delete the old volume, which is the single move that releases the most cost. None of this requires touching the compute, so it is some of the lowest risk saving available on a GCP estate.
Storage is rarely the headline number, but it accumulates quietly across hundreds of instances and snapshots. Here is how to bring it under control.
Which disk type should each workload use?
Disk type is the largest single lever, because the price per provisioned gigabyte differs sharply between types. GCP offers a spread from hard disk backed volumes to high performance SSD, and most estates default everything to one type without checking the access pattern.
| Disk type | Relative cost | Best fit |
|---|---|---|
| Standard Persistent Disk | Lowest | Throughput oriented, sequential, cold, and archival workloads |
| Balanced Persistent Disk | Moderate | The sensible default for most general purpose SSD workloads |
| SSD Persistent Disk | Highest | Latency sensitive, high IOPS databases that genuinely need it |
The common waste is SSD Persistent Disk applied to workloads that never approach its IOPS ceiling, when Balanced Persistent Disk would serve the same access pattern at a lower rate. Moving a workload from the SSD type to the Balanced type where the metrics support it cuts the storage rate without the application noticing. For genuinely cold data sitting on SSD, the Standard type is cheaper still. Hyperdisk, the newer family that decouples capacity from provisioned IOPS and throughput, is worth evaluating for large databases where you want to pay for performance separately from size.
How much capacity should you provision?
Because you pay for provisioned size, a 500 gigabyte disk holding 80 gigabytes of data is paying for 420 gigabytes of air. Capacity creep happens for reasonable sounding reasons: a disk was provisioned generously at launch, growth never materialised, or a round number felt safer than a measured one. The fix is to measure real utilisation across the fleet, identify disks running well below their provisioned size, and rebuild them at an appropriate capacity with headroom for genuine growth.
Persistent Disk can be grown in place but never shrunk in place, which shapes the workflow. To reduce a disk you create a smaller right sized disk, migrate the data with a snapshot or a copy, repoint the instance, and delete the oversized original. It is more work than resizing up, so the practical discipline is to provision closer to need at creation time and to review the fleet periodically rather than letting every disk drift large.
What about detached and idle disks?
A Persistent Disk that is detached from any instance still bills for its full provisioned capacity every hour. When an instance is deleted without its data disks, or a migration leaves the old volume behind, those orphaned disks keep charging silently. The same is true of disks attached to instances that have been stopped for weeks but never decommissioned. Run a regular sweep for unattached disks, disks attached to long stopped instances, and old snapshots whose source is gone, and reclaim them after a short retention check. The reclaim discipline pairs well with snapshot hygiene, which is covered in snapshot and backup cost discipline on GCP.
A European SaaS company found a third of its Persistent Disk capacity sitting on the SSD type for workloads that never exceeded modest IOPS, plus a tail of disks detached from instances deleted months earlier. Moving the eligible volumes to the Balanced type, rebuilding the most over provisioned disks at measured capacity, and deleting the orphans cut the monthly Persistent Disk line by a clear double digit percentage with no measured performance change. Figures are verified against billing data and anonymised.
Where disk rightsizing fits the wider GCP picture
Disk rightsizing is the storage companion to compute rightsizing and commitment coverage. Once the disks are typed and sized correctly, the steady compute underneath them is the candidate for Committed Use Discounts, and the utilisation of those commitments deserves its own watch, which is the subject of CUD utilization monitoring. The full estate picture, including network and BigQuery, lives in the GCP cost optimization guide, and the cross cloud view sits in the cross cloud cost optimization guide.
Frequently asked questions
Does shrinking a Persistent Disk reduce cost?
What is the difference between the Balanced, SSD, and Standard Persistent Disk types?
Do unattached Persistent Disks still cost money?
Reclaim your Persistent Disk spend
We help enterprises type, size, and reclaim Persistent Disk across the fleet without risking the workloads that depend on it. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk. We take zero provider commissions and answer only to you.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.