---
cuppy_hub: gcp
cuppy_path: reference/storage/persistent-disk-and-hyperdisk.md
cuppy_section: docs
cuppy_doc: WGFX-1ZR0
cuppy_doc_uuid: dbd3135a-79e9-4458-afb7-02ea419c5cc4
cuppy_permalink: https://cuppy.io/gcp/d/WGFX-1ZR0
cuppy_version: 1
cuppy_updated: 2026-10-23T16:16:52.575Z
cuppy_canonical: https://cuppy.io/gcp/docs/reference/storage/persistent-disk-and-hyperdisk
cuppy_mcp: https://cuppy.io/mcp
cuppy_body_sha256: 14fba8d2bac68db6e86692e82ef27e876ff09d39f132e660e871c924878558c9
# cuppy_body_sha256 is over the document body ALONE, excluding both generated blocks.
---


# Block storage on Compute Engine

## 1. Three families, and what actually separates them

| Family | Types the page names | The distinguishing property |
|---|---|---|
| **Hyperdisk** | Balanced, Balanced High Availability, Extreme, ML, Throughput | performance is configured **independently** of size |
| **Persistent Disk** | Standard, Extreme, Regional | performance **scales with capacity** |
| **Local SSD** | — | "physically attached to the server that hosts your instance", and **ephemeral** |

**That middle column is the whole decision.** On Persistent Disk, buying more IOPS means buying more
gigabytes; on Hyperdisk it does not. A migration sizing exercise that was done against a per-capacity
performance model and lands on Hyperdisk will over-provision capacity, sometimes by a lot. That is a saving
worth finding, and it is the single most common Google Cloud block-storage estimate error.

## 2. Local SSD — the one to be explicit about

Data on Local SSD is **lost if the VM stops, crashes or fails.** Not "at risk": lost. It is a cache, a scratch
area or a shard of something reconstructible, and nothing else. A lift-and-shift that maps an on-premises
local disk to Local SSD because the name matches has moved a durable disk onto ephemeral media.

## 3. Zonal and regional

- a zonal disk is a **zonal resource**, and, verbatim: *"To attach a zonal persistent disk to an instance,
  both resources must be in the same zone."*
- **Regional Persistent Disk** gives "cross-zonal synchronous disk replication";
- **Hyperdisk Balanced High Availability** is the Hyperdisk family's regional-replication option.

So there are two regional block-storage answers, one per family, and they are not the same product. Pick the
one that matches the family you chose in §1 rather than reaching for Regional PD by habit.

## 4. What can change after creation

The page names **"Modify Hyperdisk size and performance"** and **"Change the disk type"** as capabilities. So
a type change is supported — but read the specific type pair's own page before planning one, because this
overview does not state which pairs are allowed, nor whether the change is online.

**What cannot change is the zone.** A zonal disk does not move zones; it is copied
(`reference/overview/regions-zones-and-locations.md` §3). In Terraform that shows up as a **replace**, which
means a destroy of the data unless a snapshot stands behind it — see `guides/iac/terraform-first-apply.md`
step 6.

## 5. An absence, recorded

**The page does not address attaching a disk to multiple instances.** Multi-writer attachment is a real
feature on some Google Cloud disk types, and this document does not say which, because the page read here does
not. Establish it from the specific disk type's page before designing a shared-disk cluster.

Next: `reference/storage/filestore.md` for the shared-filesystem answer, which is usually the right one when a
shared block device was the question.


---
<!-- cuppy -->
You are reading one file. The same content is free over MCP at https://cuppy.io/mcp with no signup: ranked search across all 91 documents in this hub, the merged view when you work in a layer, known workarounds matched to the error you hit, and depth control so you spend tokens on what you need. Start with the `_hello` tool. How to connect: https://cuppy.io/gcp/ Something wrong in this document? Report it with the `session feedback` tool on the same endpoint.
<!-- /cuppy -->