GCP Compute Engine Cost Optimisation: CUDs, Spot VMs & Rightsizing

Simple explanation

Think of Compute Engine cost optimisation like managing a fleet of rental cars. You are paying for every car by the hour, whether anyone is driving it or not. The goal is to return the cars you do not need, downsize to smaller models where a sedan works as well as an SUV, and negotiate a bulk rate for the ones you keep long-term.

Most savings come from five actions:

• Use smaller or better-fit machine types. Many VMs are provisioned larger than they need to be.
• Run VMs fewer hours. Dev and test machines do not need to run overnight or on weekends.
• Use discounts for steady usage. Committed use discounts reward predictable, long-running workloads.
• Use Spot VMs for interruptible work. Batch jobs, CI/CD pipelines, and rendering tasks can run at up to 91% off.
• Remove wasted disk and snapshot spend. Unattached disks and old snapshots add up silently.

None of these require re-architecting your application. They are configuration changes, scheduling policies, and purchasing decisions. For a broader look at how GCP pricing works across all services, see Understanding GCP Pricing Models.

How it works

Your Compute Engine bill is driven by a few variables. Understanding them helps you target the right cost lever:

• Machine family and type: determines the per-hour rate. An E2-standard-4 costs less than an N2-standard-4, which costs less than a C2-standard-4, even though all three have 4 vCPUs and 16 GB memory.
• vCPU and memory footprint: bigger VMs cost more per hour. Halving vCPU count roughly halves the compute portion of the bill.
• Hours running: a VM that runs 24/7 costs roughly 4.4 times more per month than one that runs 8 hours on weekdays only.
• Persistent disks and snapshots: billed by provisioned size, not actual usage, and they keep billing whether the VM is running or not.
• Discount model: on-demand is the default. Sustained use discounts (SUDs) apply automatically. Committed use discounts (CUDs) require a 1- or 3-year purchase. Spot VMs offer the steepest discount but can be reclaimed at any time.

Quick wins: what to do first

Start at the top of this list. Scheduling and disk cleanup are nearly risk-free. Rightsizing gives the best return for the effort. CUDs and Spot VMs deliver the largest percentage savings but need more planning. For a structured approach to prioritising these actions, see Building a Cost Optimisation Strategy.

Best ways to reduce Compute Engine costs

Rightsizing over-provisioned VMs

Rightsizing means swapping a VM to a smaller machine type that still handles its actual workload. Picture it this way: if you booked a 12-seat minibus to carry two passengers, switching to a 4-seat car gets the same people to the same destination at a fraction of the cost.

Many VMs are provisioned generously at launch and never re-evaluated. A VM running at 10-15% average CPU is paying for capacity that sits idle.

GCP Active Assist analyses CPU and memory utilisation and generates specific recommendations showing which VMs to downsize, what machine type to move to, and how much you will save per month. This is the fastest way to find candidates across a large fleet.

# List rightsizing recommendations for a zone
gcloud recommender recommendations list \
  --project=PROJECT_ID \
  --location=us-central1-a \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --format="table(name,description,primaryImpact.costProjection.cost.units)"

# Resize a VM (requires stopping it first)
gcloud compute instances stop my-vm --zone=us-central1-a

gcloud compute instances set-machine-type my-vm \
  --zone=us-central1-a \
  --machine-type=n2-standard-2

gcloud compute instances start my-vm --zone=us-central1-a

For VMs in a managed instance group, update the instance template with the new machine type and perform a rolling update to resize instances one at a time without overall service downtime.

For the full resizing procedure including MIG rolling updates and safety checks, see Rightsizing Virtual Machines.

Scheduling non-production VMs

This is the “turn off the lights when you leave the room” optimisation. Dev, test, and internal VMs rarely need to run around the clock. A VM running only during business hours (8 hours per day, Monday to Friday) runs for roughly 174 hours per month instead of 730. That is a 76% reduction in compute cost for those instances.

# Create an instance schedule
gcloud compute resource-policies create instance-schedule dev-vm-schedule \
  --region=us-central1 \
  --vm-start-schedule="0 8 * * MON-FRI" \
  --vm-stop-schedule="0 18 * * MON-FRI" \
  --timezone="Europe/London"

# Attach the schedule to a VM
gcloud compute instances add-resource-policies my-dev-vm \
  --zone=us-central1-a \
  --resource-policies=dev-vm-schedule

Scheduling is not suitable for production systems that must stay available. For those workloads, look at rightsizing and CUDs instead.

Choosing the right machine family

Machine family choice has a big effect on cost for the same vCPU and memory configuration. For a deep dive into every machine family, see Machine Types Explained.

# Compare machine types in a region
gcloud compute machine-types list \
  --filter="zone:us-central1-a AND name~'^(e2|n2|n2d)-standard-4$'" \
  --format="table(name,guestCpus,memoryMb)"

Committed use discounts for steady workloads

CUDs work like signing an annual lease instead of paying nightly hotel rates. You commit to a certain amount of vCPU and memory for 1 or 3 years, and GCP gives you a significant discount in return. Resource-based CUDs commit to a pool of resources, not specific instances, so you can resize VMs or change machine types and still benefit from the discount.

Approximate discount levels (exact rates vary by region and machine family):

• 1-year resource CUD: roughly 37% off on-demand
• 3-year resource CUD: roughly 55% off on-demand

For context: an N2-standard-4 at approximately $138/month on-demand drops to roughly $87/month on a 1-year CUD and roughly $62/month on a 3-year CUD. At 10 such VMs, the 3-year CUD saves around $760/month compared to on-demand. Actual pricing depends on your region. Check the Estimating Cloud Costs page for how to model this.

# Purchase a 1-year committed use discount
gcloud compute commitments create my-commitment \
  --plan=12-month \
  --region=us-central1 \
  --resources=vcpu=8,memory=32GB

# List existing commitments
gcloud compute commitments list --regions=us-central1

# Check utilisation of a commitment
gcloud compute commitments describe my-commitment \
  --region=us-central1

For a broader view of when CUDs, SUDs, and Spot pricing each apply, see GCP Pricing Models.

Spot VMs for interruptible workloads

Spot VMs are like standby airline tickets. You get a massive discount (up to 91% off the equivalent on-demand price), but GCP can reclaim your seat at any time with only a 30-second warning. If your workload can handle being bumped and rebooked, the savings are enormous.

Best-fit workloads:

• Batch data processing and ETL pipelines
• ML model training with checkpointing
• CI/CD build and test runners
• Video rendering and transcoding
• Genomics and scientific computing

# Create a Spot VM
gcloud compute instances create batch-worker \
  --zone=us-central1-a \
  --machine-type=n2-standard-4 \
  --provisioning-model=SPOT \
  --instance-termination-action=STOP

Spot VMs complement CUDs and rightsizing well. Use CUDs for your stable, always-on baseline. Use Spot VMs for work that can tolerate interruption. Together, they cover both ends of the cost spectrum.

For preemption handling strategies, checkpointing patterns, and managed instance group configurations with Spot VMs, see Spot VMs for Cost Savings.

Reducing disk and snapshot waste

Persistent disks bill by provisioned size regardless of how much data is stored, and they continue billing after a VM is stopped or deleted (if the disk was not deleted with the VM). SSD persistent disks cost roughly $0.17/GB/month. That means a 500 GB unattached SSD is $85/month doing nothing.

# Find unattached disks (no VM using them)
gcloud compute disks list \
  --filter="users.len()=0" \
  --format="table(name,zone,sizeGb,type,lastDetachTimestamp)"

# Snapshot an unattached disk before deleting (safety net)
gcloud compute snapshots create backup-my-disk \
  --source-disk=my-disk \
  --source-disk-zone=us-central1-a

# Delete the unattached disk
gcloud compute disks delete my-disk --zone=us-central1-a

Snapshots also accumulate over time. Old snapshots from VMs that no longer exist still cost storage. Review snapshots periodically and delete those that are no longer needed for recovery:

# List snapshots sorted by creation date
gcloud compute snapshots list \
  --sort-by=creationTimestamp \
  --format="table(name,diskSizeGb,creationTimestamp,storageBytes)"

# Delete an old snapshot
gcloud compute snapshots delete old-snapshot-name

For a broader cleanup checklist covering disks, snapshots, IP addresses, and other orphaned resources, see Cleaning Up Unused Resources.

CUDs vs Spot VMs vs rightsizing vs scheduling

These options are not mutually exclusive. A typical cost-optimised setup combines several: rightsize all VMs first, schedule dev machines, buy CUDs for the stable production baseline, and run batch jobs on Spot VMs.

When to use this

Different workloads benefit from different tactics:

• Dev and test VMs: Schedule shutdowns outside business hours. Switch to E2 if not already. Delete VMs you no longer need.
• Steady production web apps: Rightsize based on Active Assist data. Purchase CUDs for the stable baseline. Use N2 or N2D for consistent performance.
• Batch processing: Run on Spot VMs with checkpointing. Use autoscaling instance groups to scale down when idle.
• Fault-tolerant workers: Spot VMs in a managed instance group with automatic recreation on preemption.
• Databases and memory-heavy workloads: Rightsize carefully using memory utilisation data from Cloud Monitoring. Consider M-series only if you genuinely need high memory ratios. Purchase CUDs for the committed baseline.
• Managed instance groups: Update instance templates with the right machine type, enable autoscaling to match demand, and consider mixing on-demand and Spot VMs in the group.