Topic 3 of 11
Disks and managed instance groups
Two items in the exam guide: choosing the right storage for Compute Engine (zonal or regional Persistent Disk and Google Cloud Hyperdisk) and creating an autoscaled managed instance group from an instance template. Together they are the foundation of any scalable VM deployment.
Contents
Block storage: temporary or durable
Temporary: Local SSD
The fastest, physically attached to the server. Data is lost if the VM stops, suspends, restarts, or fails. Only for scratch data and caches. It can't be a boot disk.
Durable: Hyperdisk and Persistent Disk
Network disks that keep data when you stop or delete the VM. You can attach them to a running VM, detach them, and move them. Encrypted at rest and in transit by default.
You pay for provisioned capacity from when the disk is created until it is deleted, even if it is attached to a stopped VM or to none. For Hyperdisk and PD Extreme you also pay for provisioned performance.
How to choose a disk
Do you need durable or temporary storage?: The boot disk must always be durable.
Temporary: Local SSD, if your machine series supports it.
Durable: Hyperdisk, if your series supports it. Google recommends it for performance and features.
If your series doesn't support Hyperdisk: Persistent Disk. The latest series don't support PD.
The key difference
With Hyperdisk, performance (IOPS or throughput) is configured independently of size and can change while the disk is in use. With Persistent Disk, performance depends on capacity: to get more, you make the disk bigger.
Google Cloud Hyperdisk
Compute Engine's fastest durable disk, built on Titanium technology. It supports sharing a volume between VMs, Storage Pools to buy capacity and performance in bulk, torn write protection, and Asynchronous Replication to another region.
| Type | What for | Max per volume |
|---|---|---|
| Hyperdisk Balanced | Most workloads: enterprise apps, boot disks, PostgreSQL, MySQL. Read-write from up to 8 instances | 160,000 IOPS, 2,400 MiB/s |
| Hyperdisk Balanced High Availability | Critical apps with RPO 0: synchronous replication across two zones | 100,000 IOPS, 2,400 MiB/s |
| Hyperdisk Extreme | SAP HANA, high-end SQL Server and Oracle. The highest IOPS | 350,000 IOPS, 5,000 MiB/s |
| Hyperdisk ML | AI and HPC: one read-only volume attached to up to 2,500 instances | The highest read throughput |
| Hyperdisk Throughput | Scale-out analytics (Hadoop, Spark, Kafka) and cheap cold disks | 9,600 IOPS, 2,400 MiB/s |
Zonal Persistent Disk
A network disk whose data is distributed across several physical disks. Use it when your series doesn't support Hyperdisk.
| Type | Media | What for |
|---|---|---|
Balanced (pd-balanced) | SSD | Balance of cost and performance; most general-purpose apps |
SSD (pd-ssd) | SSD | Enterprise apps and databases that need low latency and more IOPS |
Standard (pd-standard) | HDD | Data processing with sequential I/O |
Extreme (pd-extreme) | SSD | High-end databases; lets you set target IOPS. Few series |
Default type
In the console the default type is pd-balanced; with gcloud or the API it is pd-standard.
Regional Persistent Disk and high availability
Regional Persistent Disk and Hyperdisk Balanced High Availability replicate data synchronously across two zones in the same region and survive one zone failure. If the primary zone fails, you force attach the disk to a standby VM in the other zone, in seconds.
| HA option | Data loss | Recovery | Cost |
|---|---|---|---|
| Zonal snapshots | Whatever came after the last snapshot | Minutes | $ |
| Synchronous application replication | None | Seconds | $$ (two VMs) |
| Regional disks | None | Seconds (force attach) | 1.5x to $$; the disk costs twice as much per byte |
- The application, file system, and OS must tolerate abrupt crashes.
- You save by starting the secondary VM only when failover is needed.
- Durability: regional PD has twice as many replicas as zonal. Neither regional disks nor snapshots alone protect against application data corruption.
Local SSD
- Each Local SSD disk provides 375 GiB on the series that use that size.
- It isn't replicated: data may be lost if the VM stops or terminates for any reason.
- Data is kept in certain cases: VMs that restart in place on the same host after maintenance, or if you choose to preserve it when stopping or suspending the VM (preview).
- After a host error, Compute Engine tries to recover the data for the configured time; if it can't, the data is lost.
- To keep the data, copy it to a Persistent Disk or Hyperdisk.
- With Spot VMs, Local SSDs also get Spot pricing.
Instance templates
They save a VM's configuration: machine type, boot disk image, labels, startup script, and other properties. You use them to create individual VMs, reservations, and, necessarily, managed instance groups.
Regional (recommended)
Usable only in its region. Isolates hardware errors and helps with data residency.
Global
Reusable in any region. Use it only if you need it in several.
- They can't be modified after creation: you create a new one from a VM or from another template.
- If they include a zonal resource (for example, a read-only disk in
us-central1-a), they only work in that zone. - Deterministic templates pin specific versions of the software the startup script installs so every VM is identical.
gcloud compute instance-templates create web-tpl-v1 \ --instance-template-region=us-central1 --machine-type=e2-medium \ --image-family=debian-13 --image-project=debian-cloud \ --metadata-from-file=startup-script=startup.sh
Managed instance groups
A MIG runs several identical VMs created from a template, with autoscaling, autohealing, multi-zone deployment, and automatic updates. Unmanaged instance groups only load balance across VMs you manage yourself; they don't support autoscaling.
Zonal MIG
All VMs in one zone. Up to 1,000 VMs by default.
Regional MIG
VMs spread across several zones: protects against a zone outage. Up to 2,000 VMs by default.
- If a VM stops, crashes, is preempted (Spot), or is deleted by something other than the MIG, the MIG recreates it with the same name and template.
- Stateful MIGs keep each VM's name, disks, and metadata when recreating it: useful for databases or legacy applications.
- They integrate with load balancers as backends.
gcloud compute instance-groups managed create web-mig \ --region=us-central1 --size=3 --template=web-tpl-v1 \ --health-check=web-hc --initial-delay=120
Autoscaling
The autoscaler adds VMs when load goes up and removes them when it goes down, following the group's policy. It uses the Compute Engine Service Agent, created when the API is enabled. It only works with MIGs.
| Signal | Details |
|---|---|
| Average CPU utilization | The default signal when you turn on autoscaling. Example: 75% target |
| HTTP load balancing serving capacity | Based on the capacity defined on the backend |
| Cloud Monitoring metrics | Per-instance or group metrics, such as pending messages in a queue |
| Schedules | Minimum capacity on a schedule (once, daily, weekly, or monthly). Up to 128 per group |
- With several signals, the group takes the largest recommended size.
- With CPU, load balancer capacity, or per-instance metrics it can't scale in to zero. With other metrics or schedules it can, if the minimum is 0.
- Initialization period (formerly cool down): 60 s by default; during that time the new VM's data isn't used for scale-out decisions.
- Stabilization period: 10 minutes by default (0 to 3,600 s); it prevents removing VMs too soon after a peak.
- Predictive autoscaling: forecasts load from history and scales out ahead of time. Useful if the app takes more than 2 minutes to start and load follows daily or weekly cycles.
- Scale-in controls: limit how many VMs can be removed within a time window.
gcloud compute instance-groups managed set-autoscaling web-mig \ --region=us-central1 --min-num-replicas=2 --max-num-replicas=20 \ --target-cpu-utilization=0.60 --cool-down-period=90 --stabilization-period=240
Autohealing and health checks
Application-based autohealing uses a health check that verifies the app responds on each VM; if it doesn't, the MIG recreates the VM. It is more precise than just checking that the VM is running.
Load balancer health check
Moves traffic away from unresponsive VMs; it doesn't recreate them. Should be more aggressive.
Autohealing health check
Deletes and recreates UNHEALTHY VMs. Should be more conservative. Google recommends using separate health checks.
- The initial delay is the time a new VM takes to boot and run its startup script; during it, the MIG ignores failed health checks.
- The firewall must allow health check traffic from
130.211.0.0/22and35.191.0.0/16.
Updating a MIG
Automatic (proactive)
The MIG applies the new template to all VMs or a subset, with a disruption budget. Supports canary: a second template for part of the VMs.
Selective (opportunistic)
The new configuration is applied only to the VMs you target, manually or all at once.
Exam scenarios
| Situation | Answer | Why |
|---|---|---|
| Boot disk for a new VM on a current machine series | Hyperdisk Balanced | Recommended for most workloads, boot included. |
| A database that can't lose data if a zone fails (RPO 0) | Hyperdisk Balanced High Availability or regional PD | Synchronous replication across two zones. |
| The fastest possible scratch cache or tempdb | Local SSD | The fastest, but ephemeral. |
| Increase a Persistent Disk's performance without changing type | Increase its size | PD performance depends on capacity. |
| Change an instance template's configuration | Create a new template | Templates can't be modified. |
| A stateless website that survives a zone outage and scales | Regional MIG with autoscaling | Spreads VMs across zones. |
| Predictable traffic every Monday at 9:00 | Schedule-based or predictive autoscaling | Adds capacity before the peak. |
| Test the new version on 10% of the VMs | Proactive update with a canary | A second template applied to a subset. |
Common exam traps
❓ Can Local SSD be a boot disk?
No. Boot requires durable storage: Hyperdisk or Persistent Disk.
❓ How do I increase a Persistent Disk's performance?
By increasing its size, because its performance depends on capacity. With Hyperdisk, performance is set separately.
❓ Can I edit an existing instance template?
No. You create a new one and apply it to the MIG.
❓ Can a CPU-scaled MIG scale in to zero VMs?
No. With CPU, load balancer capacity, or per-instance metrics the effective minimum is one VM.
❓ What is the default PD type with gcloud?
pd-standard. In the console it is pd-balanced.
❓ Does a regional disk replicate across three zones?
No. It replicates synchronously across two zones in the same region.
❓ Do unmanaged instance groups support autoscaling?
No. Only MIGs do.
Did you get this topic?
Test what you just learned
A stateless web application must keep running if a zone fails and adjust to load on its own. The VMs take 3 minutes to boot, and the MIG keeps recreating healthy VMs that haven't finished starting. What should you do?
Ready to test "Disks and managed instance groups"?
Original questions, each with a full explanation.
Start a mock exam