Persistent Disk Types: SSD, Balanced, Standard

Persistent Disk (PD) is Google Cloud's block storage service for Compute Engine instances. It is durable, network-attached storage that persists independently of VM lifecycles. Google offers three main types of PD: SSD Persistent Disk (pd-ssd), Balanced Persistent Disk (pd-balanced), and Standard Persistent Disk (pd-standard). Each type has distinct performance characteristics, pricing, and use cases. The ACE exam expects you to know the differences and apply them to scenario-based questions.

Different workloads have different IOPS (input/output operations per second) and throughput requirements. Using SSD PD for a low-traffic file server is wasteful and expensive; using Standard PD for a high-transaction database will cause severe performance degradation. Google designed these tiers to allow cost optimization: you pay for the performance you need. Balanced PD was introduced as a mid-tier option, offering better performance than Standard but at a lower cost than SSD.

Each PD type has baseline IOPS and throughput limits that depend on disk size, as well as burst capabilities. The key metrics are:

#### SSD Persistent Disk (pd-ssd) - Max IOPS per instance: 100,000 (with larger disks, up to 1 TB per disk). - Max throughput per instance: 2,000 MB/s (with larger disks). - Baseline IOPS: 30 IOPS per GB, up to 100,000. - Baseline throughput: 0.48 MB/s per GB, up to 2,000 MB/s. - Use cases: High-performance databases (e.g., MySQL, PostgreSQL, MongoDB), latency-sensitive applications, boot disks for performance-critical VMs.

#### Balanced Persistent Disk (pd-balanced) - Max IOPS per instance: 80,000. - Max throughput per instance: 1,200 MB/s. - Baseline IOPS: 6 IOPS per GB, up to 80,000. - Baseline throughput: 0.28 MB/s per GB, up to 1,200 MB/s. - Use cases: Most general-purpose workloads, such as web servers, small to medium databases, dev/test environments.

#### Standard Persistent Disk (pd-standard) - Max IOPS per instance: 3,000. - Max throughput per instance: 120 MB/s. - Baseline IOPS: 0.75 IOPS per GB, up to 3,000. - Baseline throughput: 0.12 MB/s per GB, up to 120 MB/s. - Use cases: Large data processing workloads that are throughput-oriented (e.g., log processing, data warehousing), boot disks for non-critical VMs, file servers with sequential access patterns.

All PD types have performance that scales linearly with disk size until you hit the per-instance maximum. For example, a 100 GB SSD PD provides 3,000 baseline IOPS (30 IOPS/GB * 100 GB) and 48 MB/s throughput. A 1 TB SSD PD provides 30,000 IOPS and 480 MB/s. Beyond the per-instance limits, adding more disks or using a larger machine type with higher aggregate limits can increase performance, but the per-disk limits still apply.

PD types support bursting for short periods. SSD PD can burst to 100,000 IOPS for up to 30 minutes per day, depending on disk size. Balanced PD can burst to 80,000 IOPS for up to 30 minutes. Standard PD does not support bursting. The burst credits are replenished daily. This is important for workloads with periodic spikes.

The maximum IOPS and throughput available to a disk are also limited by the VM's machine type. For example, a n1-standard-1 VM has a maximum of 10,000 IOPS and 180 MB/s throughput across all attached PDs. So even if you attach a 10 TB SSD PD capable of 100,000 IOPS, the VM will only deliver up to 10,000 IOPS. The exam tests this: you must choose a machine type that can fully utilize the disk's performance.

You create disks with specific types using the gcloud compute disks create command. For example:

gcloud compute disks create my-disk --size=100GB --type=pd-ssd --zone=us-central1-a

To attach a disk to a VM:

gcloud compute instances attach-disk my-vm --disk=my-disk --zone=us-central1-a

To change a disk's type, you cannot directly modify it. Instead, you must create a snapshot, create a new disk with the desired type from the snapshot, and detach/reattach. For example:

gcloud compute disks snapshot my-disk --snapshot-names=my-snapshot --zone=us-central1-a
gcloud compute disks create my-new-disk --source-snapshot=my-snapshot --type=pd-balanced --zone=us-central1-a
gcloud compute instances detach-disk my-vm --disk=my-disk --zone=us-central1-a
gcloud compute instances attach-disk my-vm --disk=my-new-disk --zone=us-central1-a

You can monitor disk performance using Cloud Monitoring metrics like compute.googleapis.com/instance/disk/read_ops_count and write_ops_count. The exam might ask you to identify performance bottlenecks by looking at IOPS utilization vs. limits.

All three types are available as regional PD (replicated across two zones) for higher durability. Regional PD has the same performance characteristics but costs 2x the standard zonal PD. The exam may ask about regional PD for disaster recovery or high availability.

Pricing is per GB-month and varies by type and region. As of the current exam, approximate US prices:

Snapshot storage is charged separately at $0.026/GB-month. The exam may ask you to calculate costs for a given scenario.

Persistent Disk types are a fundamental choice in GCE. The ACE exam tests your ability to select the right type based on workload requirements, cost, and performance. Memorize the key numbers and understand the relationships between disk size, IOPS, throughput, and VM limits.

A financial services company runs a MySQL database on-premises and wants to migrate to GCE. The database requires 50,000 IOPS and low latency for transaction processing. The cloud architect selects SSD PD (pd-ssd) with a 2 TB disk, which provides 60,000 baseline IOPS (30 * 2000) — exceeding the requirement. They choose an n1-standard-32 machine type, which supports up to 100,000 IOPS, ensuring no VM bottleneck. The migration is performed using a snapshot of the on-premises database restored to the PD. Performance testing shows consistent sub-millisecond latency. A common misconfiguration would be using Balanced PD, which would only provide 12,000 IOPS (6 * 2000), causing severe performance degradation. The architect also enables regional PD for disaster recovery, doubling the cost but ensuring data survives a zone failure.

A SaaS company hosts thousands of low-traffic WordPress sites. Each site requires a boot disk and a small data disk. The workload is mostly reads with occasional writes. Using SSD PD would be cost-prohibitive; Standard PD is too slow for page loads. The architect chooses Balanced PD (pd-balanced) for both boot and data disks, sized at 10 GB each. Balanced PD provides 60 IOPS per disk (6 * 10), which is sufficient for the low traffic. They also use regional PD for the data disks to ensure high availability. The total cost is about $0.10/GB-month per disk, significantly lower than SSD. The architect monitors Cloud Monitoring metrics and sees average IOPS utilization below 50%. A mistake would be using Standard PD for boot disks, which could cause slow boot times and poor page load performance due to higher latency.

A media company processes large video files (hundreds of GB each) using a Spark cluster. The workload is sequential read/write with high throughput requirements but low IOPS. They choose Standard PD (pd-standard) for the data disks, as it offers 0.12 MB/s per GB throughput, which is cost-effective for large volumes. They attach 10 TB of Standard PD to each worker node, providing 1,200 MB/s throughput (0.12 * 10000), well within the per-instance limit of 120 MB/s? Wait — the per-instance limit for Standard PD is 120 MB/s, so the baseline throughput of 1,200 MB/s is capped at 120 MB/s. Actually, the scaling formula gives baseline throughput, but the per-instance maximum is 120 MB/s. So for a 10 TB disk, the baseline throughput is 1,200 MB/s, but the actual maximum throughput is 120 MB/s due to the per-instance cap. Therefore, the architect must either use multiple disks or a larger machine type? No — the per-instance limit is per disk? Actually, the per-instance maximum is per disk for Standard PD: 120 MB/s. So a single 10 TB Standard PD can only achieve 120 MB/s. To get higher throughput, they need to stripe across multiple Standard PDs. This is a common exam trap: knowing that scaling is linear but capped by per-disk limits. The architect should use multiple 1 TB disks striped with RAID0 to achieve higher aggregate throughput.