Google Compute Engine: Machine Families, Disks, and Optimization

You’ve provisioned a VM, picked a machine type, attached a disk, and watched your monthly bill balloon by 40% because you chose the wrong combination. That’s the reality of GCE: the flexibility of machine families, disk types, and optimization knobs is a double-edged sword. Get it right, and you save thousands. Get it wrong, and you’re paying for idle vCPUs and IOPS you never use. This article walks through the concrete decisions—standard vs. preemptible, HDD vs. SSD, regional vs. zonal—and the production patterns that separate a well-tuned deployment from a cost disaster. No fluff, just the math and the gotchas.

Machine Families Overview

GCE offers four machine families: General-purpose (N4, N4D, N4A, N2, N2D, N1, E2, Tau T2D/T2A), Compute-optimized (C4, C4D, C4A, C3, C3D, C2, C2D), Memory-optimized (X4, M4, M4N, M3, M2, M1), and Accelerator-optimized (A4X, A4, A3, A2, G4, G2). Each family targets specific workload profiles. The latest 4th-generation families (C4, N4, C4D, N4D, N4A) are powered by Intel Emerald Rapids, AMD EPYC Turin, and Google Axion processors respectively, with Titanium offload silicon for improved performance. General-purpose is your default for web servers, small databases, and dev environments. Compute-optimized is for CPU-bound tasks like batch processing or high-performance web serving. Memory-optimized handles in-memory databases and large caches. Accelerator-optimized includes GPUs for ML training and HPC. Choosing the wrong family is the #1 cause of overspend: don't run a memory-intensive Redis instance on a compute-optimized C2—you'll pay for vCPUs you don't need.

gcloud compute machine-types list --filter="zone:us-central1-a" --format="table(name,zone,guestCpus,memoryMb)"

General-Purpose: E2, N2, N2D, N1

General-purpose machines are the workhorses. E2 is the budget king: shared-core, no sustained use discounts, but cheap. N2 offers a balance of price and performance with up to 128 vCPUs and 864 GB RAM. N2D uses AMD EPYC processors, often 10-15% cheaper than N2 for the same vCPU count. N1 is legacy—avoid unless you need specific GPU compatibility. Key decision: E2 for burstable, N2 for steady-state, N2D for cost-sensitive compute. Always check if your workload benefits from custom machine types (e.g., 6 vCPUs instead of 4 or 8) to avoid paying for unused resources.

gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --custom-cpu=6 \
  --custom-memory=26GB \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud

4th-Generation Families: C4, N4, C4D, N4D, N4A

The 4th-generation machine series bring significant performance and efficiency improvements. C4 (Intel Emerald Rapids) delivers up to 25% better price-performance over C3, with up to 192 vCPUs, 1.5 TB DDR5 memory, and 200 Gbps networking via Titanium. N4 (Intel Emerald Rapids) offers up to 18% better price-performance over N2, with custom shapes up to 80 vCPUs and 640 GB DDR5. N4D (AMD EPYC Turin) provides up to 96 vCPUs and 768 GB DDR5, often 10-15% cheaper than N4. N4A (Google Axion Arm-based) offers up to 64 vCPUs and 512 GB DDR5, ideal for scale-out Arm workloads. C4D (AMD EPYC Turin) delivers 30% performance boost over C3D with up to 384 vCPUs and 3 TB DDR5. Key decision: N4/N4D for cost-efficient general-purpose, C4/C4D for demanding compute workloads, N4A for Arm-native applications. All benefit from Titanium offload for networking, storage, and security. Use the Recommender to identify which workloads benefit from upgrading older N2/C2 instances to these newer series.

gcloud compute instances create n4-bench \
  --zone=us-central1-a \
  --machine-type=n4-standard-8 \
  --image-family=ubuntu-2404-lts \
  --image-project=ubuntu-os-cloud

# List available 4th-gen types
gcloud compute machine-types list \
  --filter="name~'^(c4|n4|n4d|n4a|c4d).*'" \
  --format="table(name,guestCpus,memoryMb)"

Compute-Optimized: C2, C2D, C3

Compute-optimized machines deliver the highest performance per core for CPU-bound workloads. C2 is based on Intel Cascade Lake, C2D on AMD EPYC, and C3 on Intel Sapphire Rapids with DDR5. These are ideal for gaming servers, HPC, and video transcoding. C3 offers up to 30% better performance than C2 for the same vCPU count. However, they are expensive—typically 2x the cost of E2 per vCPU. Only use them when your workload is CPU-bound and latency-sensitive. For batch jobs that can tolerate preemption, pair with preemptible instances to cut costs by 60-80%.

gcloud compute instances create c3-bench \
  --zone=us-central1-a \
  --machine-type=c3-standard-4 \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud

Memory-Optimized: M1, M2, M3

Memory-optimized machines are designed for workloads that need massive amounts of RAM, such as SAP HANA, large in-memory databases, and real-time analytics. M1 offers up to 4 TB RAM, M2 up to 12 TB, and M3 up to 8 TB with Intel Xeon Scalable processors. These are expensive—M2 can cost over $100/hour. Use them only when your dataset fits in memory and you need low latency. For smaller memory needs, consider N2 with custom memory up to 864 GB. A common mistake is using M2 for a 500 GB Redis cluster when N2 with 624 GB would be 40% cheaper.

gcloud compute instances create m3-mem \
  --zone=us-central1-a \
  --machine-type=m3-megamem-64 \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud

Accelerator-Optimized: A2, G2

Accelerator-optimized machines include GPUs for ML training, inference, and HPC. A2 features NVIDIA A100 GPUs, G2 features L4 GPUs. A2 is for heavy training (e.g., GPT models), G2 for inference and cost-sensitive GPU workloads. GPUs are expensive and often idle. Use preemptible GPUs for training jobs that can checkpoint. Attach GPUs only when needed—don't leave them running overnight. Also, GPUs require specific machine types: A2-highgpu-1g has 1 A100, 12 vCPUs, 85 GB RAM. You cannot attach a GPU to an arbitrary machine type.

gcloud compute instances create g2-inference \
  --zone=us-central1-a \
  --machine-type=g2-standard-4 \
  --accelerator=type=nvidia-l4,count=1 \
  --maintenance-policy=TERMINATE \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud

Persistent Disks: Types and Performance

GCE offers persistent disks: Standard (pd-standard), Balanced (pd-balanced), SSD (pd-ssd), and Extreme (pd-extreme). Standard is HDD-backed, cheap, but low IOPS (0.75 IOPS/GB). Balanced is SSD-backed, good for most workloads (6 IOPS/GB). SSD is high-performance (30 IOPS/GB). Extreme lets you provision IOPS independently of size (up to 500K IOPS). Choosing the wrong disk type is a common performance bottleneck. For boot disks, use Balanced or SSD—Standard makes boot slow. For data disks, match IOPS requirements: databases need SSD or Extreme, logs can use Standard.

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

Hyperdisk: Next-Generation Block Storage

Hyperdisk is Google's next-generation block storage, offering higher performance and flexibility than persistent disks. Hyperdisk Balanced provides up to 160K IOPS and 4 GB/s throughput (vs 80K for pd-balanced). Hyperdisk Extreme delivers up to 500K IOPS and 10 GB/s throughput (vs 100K for pd-ssd). The key difference: Hyperdisk lets you provision IOPS and throughput independently of capacity, so you can get high performance without over-provisioning gigabytes. Hyperdisk Throughput is optimized for large sequential workloads like data warehouses, offering up to 2 GB/s per core. Hyperdisk is available on C3, C4, N4, and other 4th-gen machine series. It requires the gVNIC driver and Titanium support. In production, use Hyperdisk Balanced for general-purpose databases and Hyperdisk Extreme for latency-sensitive workloads like OLTP databases. Cost-wise, Hyperdisk Balanced is comparable to pd-ssd but offers more flexibility. Always benchmark before migrating—Hyperdisk performance depends on VM type and driver version.

# Create Hyperdisk Balanced volume
PROVISIONED_IOPS=50000
PROVISIONED_THROUGHPUT=800  # MB/s

gcloud compute disks create hyperdisk-data \
  --zone=us-central1-a \
  --size=500GB \
  --type=hyperdisk-balanced \
  --provisioned-iops=$PROVISIONED_IOPS \
  --provisioned-throughput=$PROVISIONED_THROUGHPUT

# Attach to a C4 VM
gcloud compute instances attach-disk c4-vm \
  --disk=hyperdisk-data \
  --zone=us-central1-a

Local SSDs: When to Use and Avoid

Local SSDs are physically attached to the host machine, offering ultra-low latency and high throughput (up to 1M IOPS per device). However, they are ephemeral: data is lost on VM stop/terminate. Use them for temporary data like caches, scratch space, or high-performance databases that replicate elsewhere. Never use local SSDs as the sole storage for persistent data. They also cannot be live migrated—VM must be terminated on host maintenance. Each local SSD is 375 GB, and you can attach up to 24 (9 TB).

gcloud compute instances create local-ssd-vm \
  --zone=us-central1-a \
  --machine-type=n2-standard-4 \
  --local-ssd=interface=nvme,size=375 \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud

Disk Snapshots and Images

Snapshots are incremental backups of persistent disks. They are global resources, so you can restore to any zone. Use snapshots for disaster recovery and migration. Images are bootable snapshots for creating instance templates. Key optimization: schedule snapshots during low-usage windows to avoid IOPS contention. Also, snapshots only capture data written to disk—unallocated space is not backed up. For large disks, snapshot time can be significant; test with a 1 TB disk to estimate.

gcloud compute disks snapshot data-disk \
  --zone=us-central1-a \
  --snapshot-names=data-disk-snapshot-$(date +%Y%m%d)

Optimization: Right-Sizing and Committed Use

Right-sizing means matching machine type to actual resource usage. Use the Recommender (gcloud recommender) to get recommendations. Committed Use Discounts (CUDs) offer up to 57% off for 1-year or 3-year commitments. However, CUDs are per-region and per-machine family. If you commit to N2 in us-central1 but later need C2, you're stuck. Start with on-demand, then commit after 30 days of stable usage. Also consider sustained use discounts (automatic for >25% usage in a month).

gcloud recommender recommendations list \
  --project=my-project \
  --location=us-central1-a \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --format="json"

Preemptible and Spot VMs

Preemptible VMs are short-lived (max 24 hours) and can be terminated at any time with 30 seconds notice. They cost 60-80% less than on-demand. Spot VMs are the same but without the 24-hour limit. Use them for batch jobs, fault-tolerant workloads, and stateless processing. Never use them for stateful services like databases. Design for preemption: checkpoint frequently, use managed instance groups with autohealing, and distribute across zones.

gcloud compute instances create preemptible-vm \
  --zone=us-central1-a \
  --machine-type=n2-standard-4 \
  --preemptible \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud

Instance Templates and Managed Instance Groups

Instance templates define VM configuration (machine type, disk, network) for creating instances. Managed Instance Groups (MIGs) use templates to manage a fleet of VMs with autohealing, autoscaling, and rolling updates. Use MIGs for stateless applications. Key optimization: set autoscaling based on CPU or load balancer utilization. Also, use canary deployments with rolling updates to minimize downtime. MIGs support regional deployment for high availability.

gcloud compute instance-templates create web-template \
  --machine-type=e2-medium \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud \
  --tags=http-server

gcloud compute instance-groups managed create web-mig \
  --zone=us-central1-a \
  --template=web-template \
  --size=3 \
  --target-cpu-utilization=0.6

Network Optimization: Tier 1 vs Tier 2

GCE offers two network tiers: Premium Tier (default) uses Google's global network for low latency, and Standard Tier uses ISP networks for lower cost. For latency-sensitive apps, use Premium. For cost-sensitive, Standard can save 20-30% on egress. Also, use internal IPs for inter-instance communication to avoid egress costs. For high-throughput workloads, enable Virtual Private Cloud (VPC) Flow Logs for monitoring, but beware of costs—logs can be expensive.

gcloud compute instances create standard-tier-vm \
  --zone=us-central1-a \
  --machine-type=e2-micro \
  --network-tier=STANDARD \
  --image-family=ubuntu-2204-lts \
  --image-project=ubuntu-os-cloud