Overview and What You Will Learn
In this lab, you will create both a zonal and a regional Persistent Disk, attach each to a VM, and understand exactly what each option protects against - so the choice reflects the actual downtime tolerance for the specific data on that disk, not a default habit.
Why This Matters in Production
A team runs their production database on a zonal Persistent Disk because it was the default option shown during setup, without asking whether a single zone outage taking that database offline for an extended period is actually acceptable to the business. A regional Persistent Disk, replicating synchronously across two zones, would have kept that same database available through exactly that kind of failure.
Core Principles
A Persistent Disk is the block storage attached to a Compute Engine VM, equivalent to an AWS EBS volume or an Azure Managed Disk - and like both of those, GCP offers a choice in how broadly that data is replicated.
+------------------------------------------+| Zonal Persistent Disk || Data replicated within a single zone || Lower cost || Unavailable if that zone fails, until it || recovers |+------------------------------------------+| Regional Persistent Disk || Data synchronously replicated across two || zones in the same region || Higher cost || Survives a single zone failure, can attach || to a VM in either zone |+------------------------------------------+Detailed Step-by-Step Practical Lab
- Create a project and enable Compute Engine:
gcloud projects create gcp-disk-lab-2026 --name="Persistent Disk Lab"gcloud config set project gcp-disk-lab-2026gcloud services enable compute.googleapis.com- Create a zonal Persistent Disk:
gcloud compute disks create disk-zonal-app-data \ --zone=asia-south1-a \ --size=50GB \ --type=pd-ssd- Create a regional Persistent Disk, specifying two replica zones within the same region:
gcloud compute disks create disk-regional-app-data \ --region=asia-south1 \ --replica-zones=asia-south1-a,asia-south1-b \ --size=50GB \ --type=pd-ssd- Compare the two disks' configuration directly:
gcloud compute disks describe disk-zonal-app-data \ --zone=asia-south1-a --format="value(type,zone)" gcloud compute disks describe disk-regional-app-data \ --region=asia-south1 --format="value(type,region,replicaZones)"- Create a VM and attach the zonal disk to it:
gcloud compute instances create vm-zonal-test \ --zone=asia-south1-a \ --machine-type=e2-medium \ --image-family=debian-12 \ --image-project=debian-cloud \ --disk=name=disk-zonal-app-data,mode=rw- Attach the regional disk to a VM in one of its two replica zones:
gcloud compute instances create vm-regional-test \ --zone=asia-south1-a \ --machine-type=e2-medium \ --image-family=debian-12 \ --image-project=debian-cloud \ --disk=name=disk-regional-app-data,mode=rwNoteA regional Persistent Disk can be attached to a VM in either of its two replica zones, which is exactly what makes it useful for failover scenarios - if the VM in
asia-south1-abecomes unavailable, a replacement VM inasia-south1-bcan attach to the same regional disk and continue with the same data.
- Clean up:
gcloud compute instances delete vm-zonal-test vm-regional-test \ --zone=asia-south1-a --quietgcloud compute disks delete disk-zonal-app-data --zone=asia-south1-a --quietgcloud compute disks delete disk-regional-app-data --region=asia-south1 --quietgcloud projects delete gcp-disk-lab-2026 --quietProduction Best Practices & Common Pitfalls
Common MistakeDefaulting to zonal Persistent Disks for every workload without asking whether that specific data's downtime tolerance actually permits waiting for a zone to recover. A stateless application server's boot disk is usually fine as zonal, since the VM can simply be recreated elsewhere - a database holding data that cannot be easily recreated is a stronger candidate for regional.
TipRegional Persistent Disks matter most specifically for genuinely stateful workloads. Combine a regional disk with a Managed Instance Group spanning both replica zones for a database or similar stateful service that needs to survive a zone failure with minimal manual intervention.
- Regional Persistent Disks cost meaningfully more than zonal disks of the same size and type, since they maintain synchronous replication across two zones continuously - this cost should be weighed against the actual downtime cost of a zone failure for that specific workload.
- Snapshots work identically for both disk types and remain a separate, complementary backup mechanism - regional replication protects against a zone failure happening right now, while snapshots protect against data corruption or accidental deletion regardless of which zone is involved.
Quick Reference & Troubleshooting Commands
| Command | Description |
|---|---|
gcloud compute disks create --type=pd-ssd |
Create a zonal Persistent Disk |
gcloud compute disks create --replica-zones= |
Create a regional Persistent Disk |
gcloud compute disks describe |
View a disk's configuration and replication details |
gcloud compute instances create --disk=name= |
Attach an existing disk to a new VM |