Rightsizing Virtual Machines in GCP: How to Cut Compute Costs Safely

Simple explanation

Most VMs are created with a generous size estimate and never revisited. A team picks an n2-standard-8 because they are not sure what the workload needs, the application runs fine, and nobody goes back to check whether an n2-standard-4 would have been enough.

Rightsizing means closing that gap. It can take three forms:

• Downsizing: moving to a smaller machine type in the same family (n2-standard-8 to n2-standard-4).
• Changing machine family: switching to a family with a better price-performance fit (N2 to E2 for variable workloads, or N2 to C3 for compute-heavy ones).
• Custom machine types: specifying exact vCPU and memory when no predefined size matches the workload shape.

How GCP rightsizing recommendations work

Google Cloud generates rightsizing recommendations through the Recommender service (also called Active Assist). The service continuously monitors CPU utilisation and, when the Ops Agent is installed, memory utilisation for every Compute Engine instance in your project. When it detects sustained over-provisioning, it suggests a specific target machine type and an estimated monthly saving.

Recommendations are based on recent historical data, typically the last eight days of observed utilisation. This means they reflect what the workload did recently, not what it might do during a seasonal peak, a monthly batch run, or a one-off traffic event.

When recommendations may be unavailable or less useful

• VMs that have been running for fewer than a few days may not have enough data for a recommendation.
• VMs with highly variable or bursty workloads may receive recommendations that underestimate peak needs.
• Custom metric workloads (such as GPU-bound or I/O-bound tasks) are not well-captured by CPU and memory signals alone.
• VMs covered by sole-tenant nodes or with specific licensing constraints may not have applicable recommendations.

Treat every recommendation as a starting point. Cross-reference it with your own monitoring data before acting.

When to use rightsizing

Rightsizing delivers the most value in these situations:

• Long-running VMs with low sustained utilisation. The classic case. If a VM has been running for months at 10–15% average CPU, it is almost certainly over-provisioned.
• Conservatively provisioned workloads that were never revisited. Common after initial deployments where the team chose a large size “just in case.”
• Post-optimisation applications. After developers improve caching, query performance, or concurrency, the same workload may need significantly less CPU and memory.
• Fleets where small per-VM savings add up. Saving $30/month per VM across 200 VMs is $72,000/year.

When not to rightsize yet

• Before a known traffic peak. Do not downsize the week before a product launch, seasonal event, or end-of-quarter processing.
• When memory is already tight. If the VM is swapping or the application is under memory pressure, downsizing memory will cause failures.
• When monthly or batch spikes are easy to miss. A VM that runs at 5% CPU most of the month but hits 90% during a three-hour batch job on the 28th needs that headroom.
• When the bigger problem is architecture, not VM size. If the workload would be better served by Cloud Run, GKE, or a serverless option, rightsizing the VM is optimising the wrong layer.

What to check before resizing

Run through this checklist before resizing any VM. Skipping items here is how resize operations cause outages.

• CPU average and peaks. Check both over at least two weeks. A low average with high peaks means the VM needs that headroom.
• Memory usage and pressure. If the Ops Agent is installed, check memory utilisation alongside CPU. Without it, SSH in and check with free -m or top during peak hours.
• Observation window. Make sure the window is long enough to capture weekly patterns. Four weeks is a good default.
• Batch jobs, backups, and cron spikes. Check for scheduled processes that spike utilisation on specific days or times.
• Disk throughput and disk count. Some machine types have different maximum persistent disk throughput or maximum number of attached disks. Verify the target type supports your disk configuration.
• Network bandwidth. Per-VM egress bandwidth scales with vCPU count on most machine families. If the workload is network-heavy, confirm the smaller type still meets throughput needs.
• Maintenance window and redundancy. Standalone VMs require a stop/start. Plan for the outage or ensure redundancy is in place.
• Reservations, commitments, and discounts. If the VM is covered by a committed use discount, check that downsizing does not waste committed resources. Ideally, rightsize first, then commit.

None of these items have universal pass/fail thresholds. A VM at 30% average CPU might be fine to downsize if peaks stay below 60%, or it might be too tight if the workload is latency-sensitive and needs burst headroom. Use the data as input, not as a decision.

Finding rightsizing candidates

You can find candidates in two ways: manually through Cloud Monitoring, or through the Recommender service. Use both because they catch different things. Start by identifying your most expensive resources so you know where downsizing will have the biggest impact.

Manual analysis with Cloud Monitoring

Query CPU utilisation over a 30-day window for a specific VM. Check both the average (to find steady-state waste) and the maximum (to confirm you have headroom to downsize).

# Average CPU utilisation for a VM over the last 30 days
gcloud monitoring time-series list \
  --project=PROJECT_ID \
  --filter='metric.type="compute.googleapis.com/instance/cpu/utilization"
            AND resource.labels.instance_id="INSTANCE_ID"' \
  --aggregation-align-period=86400s \
  --aggregation-per-series-aligner=ALIGN_MEAN \
  --interval-start-time=$(date -d "30 days ago" +%Y-%m-%dT00:00:00Z) \
  --interval-end-time=$(date +%Y-%m-%dT00:00:00Z)

# Peak CPU utilisation over the same period
gcloud monitoring time-series list \
  --project=PROJECT_ID \
  --filter='metric.type="compute.googleapis.com/instance/cpu/utilization"
            AND resource.labels.instance_id="INSTANCE_ID"' \
  --aggregation-align-period=86400s \
  --aggregation-per-series-aligner=ALIGN_MAX \
  --interval-start-time=$(date -d "30 days ago" +%Y-%m-%dT00:00:00Z) \
  --interval-end-time=$(date +%Y-%m-%dT00:00:00Z)

As a rough heuristic: VMs with average CPU below 20% and peak CPU below 60% are strong candidates. VMs between 20–40% average with peaks below 80% are worth investigating. These are guidelines, not rules. Always consider the workload context.

Recommender-based analysis

The Recommender service scans your project automatically and flags VMs it considers over-provisioned. Each recommendation includes the suggested target machine type and an estimated monthly cost reduction.

# 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,
                   primaryImpact.costProjection.cost.nanos)"

# Get full details for a specific recommendation
gcloud recommender recommendations describe RECOMMENDATION_ID \
  --project=PROJECT_ID \
  --location=us-central1-a \
  --recommender=google.compute.instance.MachineTypeRecommender

# Mark a recommendation as accepted after acting on it
gcloud recommender recommendations mark-accepted RECOMMENDATION_ID \
  --project=PROJECT_ID \
  --location=us-central1-a \
  --recommender=google.compute.instance.MachineTypeRecommender

Review recommendations regularly. Monthly is a good cadence. For larger fleets, sort by estimated savings and work through the highest-impact VMs first.

Safe standalone VM resize

Resizing a standalone VM requires stopping it, changing the machine type, and starting it again. The VM keeps all its persistent disks, data, IP addresses (if static), and configuration. Only the vCPU and memory allocation changes. Expect one to three minutes of downtime.

Before you resize

• Consider taking a snapshot of attached disks if the workload is critical and you want a rollback point.
• For VMs behind a load balancer, drain traffic first using gcloud compute backend-services get-health to confirm the VM is out of rotation.
• Schedule the resize during a maintenance window if the VM has no redundancy.
• Note the current machine type so you can revert quickly if the new size causes problems.

# Step 1: Record the current machine type
gcloud compute instances describe my-vm \
  --zone=us-central1-a \
  --format="value(machineType)"

# Step 2: Stop the VM
gcloud compute instances stop my-vm --zone=us-central1-a

# Step 3: Change the machine type
gcloud compute instances set-machine-type my-vm \
  --zone=us-central1-a \
  --machine-type=n2-standard-2

# Step 4: Start the VM
gcloud compute instances start my-vm --zone=us-central1-a

# Step 5: Verify the application is healthy
gcloud compute ssh my-vm --zone=us-central1-a \
  --command="systemctl status my-app"

After the resize

• Verify that the application started correctly and is serving traffic.
• Monitor CPU and memory utilisation for at least 24–48 hours to confirm the new size handles real load.
• Check application logs for out-of-memory errors, performance degradation, or timeout increases.
• If the resize causes problems, stop the VM, change back to the previous machine type, and restart.

Safe MIG resize

For VMs in a Managed Instance Group, you do not resize individual instances. Instead, you create a new instance template with the target machine type and trigger a rolling update. The MIG replaces instances one at a time, so the service stays available throughout.

Rolling updates reduce risk because only a fraction of instances are being replaced at any moment. If the new machine type causes problems, you can stop the rollout and roll back to the previous template.

# Create a new instance template with the smaller machine type
gcloud compute instance-templates create my-template-v2 \
  --source-instance-template=my-template-v1 \
  --machine-type=n2-standard-2

# Update the MIG to use the new template
gcloud compute instance-groups managed set-instance-template my-mig \
  --template=my-template-v2 \
  --zone=us-central1-a

# Start a rolling update (replace one VM at a time)
gcloud compute instance-groups managed rolling-action start-update my-mig \
  --version=template=my-template-v2 \
  --max-unavailable=1 \
  --zone=us-central1-a

# Watch the rollout progress
gcloud compute instance-groups managed list-instances my-mig \
  --zone=us-central1-a

Rollout safety

• Make sure health checks are configured on the MIG so that unhealthy new instances are detected automatically.
• Set —max-unavailable=1 to limit blast radius so only one instance transitions at a time.
• Monitor error rates and latency during the rollout. If metrics degrade, pause or cancel the update.
• Keep the old instance template available. If you need to roll back, update the MIG to point back to it and trigger another rolling action.

If you use autoscaling on the MIG, the autoscaler will continue to work with the new template. After the rollout completes, the autoscaler creates any new instances using the updated machine type.

Custom machine types

Predefined machine types come in fixed vCPU-to-memory ratios. If your workload needs a combination that does not match any standard size (say 4 vCPUs with 12 GB of RAM instead of the standard 16 GB), a custom machine type avoids paying for the unused 4 GB.

Custom machine types use family-prefixed syntax: FAMILY-custom-VCPU-MEMORYMB.

# Create a VM with 4 vCPUs and 16 GB RAM on the N2 family
gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --machine-type=n2-custom-4-16384

# Create a VM with 2 vCPUs and 8 GB RAM on the E2 family
gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --machine-type=e2-custom-2-8192

# Extended memory: add more than standard ratio allows
gcloud compute instances create my-vm \
  --zone=us-central1-a \
  --machine-type=n2-custom-4-32768 \
  --custom-extensions

When custom types make sense

• The workload’s CPU-to-memory ratio does not fit any predefined machine type well, and the waste from the nearest standard type is significant.
• You have profiled the workload carefully and know the exact resource envelope it needs.
• Extended memory is required. Some applications need much more RAM per vCPU than standard types offer.

When to use a predefined type instead

• If the nearest predefined type wastes less than 10–15% of resources, the simplicity of standard types usually outweighs the small saving from custom sizing.
• Custom types cost slightly more per vCPU-hour and per GB-hour than equivalent standard types. The total bill is lower only if you eliminate enough waste to offset the per-unit premium.
• Custom types still need validation against real workload behaviour. Do not guess the sizing. Profile first, then configure.

Rightsizing vs autoscaling vs Spot VMs vs committed use discounts

Rightsizing is one of several strategies for reducing compute costs. Each solves a different problem. Understanding when to apply each one, and in what order, matters more than picking a favourite.

The recommended order: rightsize first, then evaluate autoscaling for variable workloads, then commit to discounts once you know the correct baseline size. Committing to a discount before rightsizing locks in waste. Read more about sequencing in building a cost optimisation strategy.