GCP Right-Sizing Guide: How to Match Compute Engine VMs to Real Demand

Right-sizing matches VM resources to actual workload requirements, allowing teams to save potentially 20-40% on Compute Engine bills.

However, VM over-provisioning remains widespread. In one large-scale study of roughly 48,000 enterprise VMs, more than 80% used less than 70% of their provisioned CPU resources, with similar underutilization in memory.

This guide covers strategic approaches to GCP rightsizing — identification methods, machine type selection frameworks, implementation risk mitigation, and building sustainable rightsizing practices that prevent over-provisioning from recurring.

Part 1: What Is Right-Sizing in GCP?

GCP right-sizing is the process of matching a Compute Engine VM’s CPU, memory, and machine type to the workload’s actual resource needs. The goal is to reduce over-provisioned capacity and unnecessary spend while preserving enough headroom to maintain performance during normal traffic spikes and workload changes.

Over-provisioning vs under-provisioning: the cost of each

Over-provisioning costs money; under-provisioning costs reliability and can create additional operational costs as well.

Over-provisioning

• You pay for CPU and memory capacity that never gets used, every hour the VM runs.
• An oversized VM in dev, staging, and production multiplies the same mistake across environments.
• Committing against an inflated baseline can lock in waste along with the capacity you actually need.
• Oversized instances are easy to miss because nothing visibly breaks, so they can sit untouched for months.

Under-provisioning

• Too little capacity can cause CPU throttling, memory pressure, and slower response times under load.
• A workload that is marginal on a normal day may fail outright during a traffic spike or batch job.
• Teams can lose hours debugging apparent application problems that are really just resource ceilings.
• One constrained VM in a dependency chain can slow down or disrupt services downstream.

Why VMs drift out of alignment with their workloads

Workloads change. The API that needed 8 vCPUs at launch now caches aggressively and runs comfortably on 4. The batch job that processed 100K records per hour grew to 500K and needs more memory. Traffic patterns shift—what was peak load in Q1 is baseline by Q4.

However, VMs don't resize themselves. The instance you launched in January still runs the same machine type in December, even as the workload underneath evolved. Without continuous monitoring and adjustment, rightsizing is a one-time fix that decays within a quarter.

The other driver is infrastructure as code defaults. Terraform modules, deployment scripts, and quickstart guides default to machine types like n2-standard-4 or e2-medium. Those defaults propagate across dev, staging, and production without anyone revisiting the choice after the first deployment.

Part 2: How to Know What to Right-Size

At scale, the challenge is separating meaningful rightsizing opportunities from hundreds of low-value recommendations and ensuring recommendations are trustworthy enough not to break anything. Let’s talk specifics.

The metrics that matter (CPU utilization, memory, sustained vs peak, network and disk throughput)

CPU utilization is the first signal. Cloud Monitoring tracks CPU as a percentage of allocated vCPUs. If a 4-vCPU instance averages 40% CPU, the workload is using 1.6 vCPUs worth of compute. That's a rightsizing candidate.

Memory usage matters more than CPU for many workloads. A database with low CPU but 90% memory usage can't be downsized without causing OOM crashes. Install the Ops Agent to get memory metrics—Cloud Monitoring doesn't track memory by default on Compute Engine.

Sustained vs peak utilization is the critical distinction. A VM that averages 30% CPU but spikes to 95% twice a day needs that peak capacity. Rightsizing based on averages will create availability problems. Look at P95 and P99 utilization, not just P50.

Network throughput and disk I/O are hidden sizing constraints. Smaller machine types have lower network egress caps and disk throughput limits.

How long to observe before acting

The GCP Recommender bases machine type recommendations on the previous 8 days of metrics. That's enough for weekly patterns—weekday load vs weekend idle—but not enough for monthly cycles or seasonal spikes.

For workloads with monthly patterns (month-end batch jobs, quarterly reporting), observe for 30-60 days. For workloads with annual seasonality (retail holiday traffic, tax season workloads), you need year-over-year data or you'll rightsize during a trough and under-provision for the next peak.

The practical floor: 8 days catches obvious waste (VMs that never exceed 20% CPU). 30 days catches growth trends and monthly cycles. 365 days catches seasonal patterns most teams ignore until the peak breaks production.

Peak vs average - and why averages cause outages

A VM that averages 30% CPU sounds over-provisioned. But if that average includes 22 hours at 10% CPU and 2 hours at 95% CPU, the workload needs the full capacity during those 2 hours. Rightsizing based on the average will cause latency spikes or outages during peak periods.

The fix is to rightsize to P95 utilization, not average. If P95 is 60%, the workload needs at least 60% of current capacity. If P95 is 40%, you have real rightsizing headroom. Build in a 20-30% buffer above P95 for traffic spikes and you won't break production.

Identifying candidates across projects

Start by looking across projects rather than treating each one independently. The biggest opportunities often come from repeated patterns: oversized production fleets, development environments copied from production, or the same overly generous machine type embedded in a shared Terraform module.

Prioritize VMs based on a combination of:

• Focus first on instances and fleets with the largest absolute savings potential. A moderately over-provisioned group of expensive VMs can matter far more than dozens of tiny instances with extremely low utilization.
• Give more weight to resources that stay underused across weeks or months rather than workloads with irregular peaks.
• Look for sizing mistakes repeated across many instances. A small amount of waste multiplied across 50 or 100 VMs can become a major optimization opportunity.
• Start with lower-risk workloads such as dev, staging, stateless services, and redundant systems before moving to databases or latency-sensitive applications.
• Evaluate committed capacity alongside the underlying VMs so rightsizing does not create a mismatch between actual usage and the CUDs already covering it.

Part 3: Choosing the Right Machine Type

Choosing the right machine type means matching the workload’s actual CPU, memory, and performance needs to the GCP configuration that delivers them most efficiently.

Machine families compared - E2, N2, N2D, C3, and when each fits

Predefined vs custom machine types (custom types are the underused lever)

Predefined machine types come in fixed vCPU/memory combinations: 2/8GB, 4/16GB, 8/32GB. If your workload needs 6 vCPUs and 12GB RAM, the next predefined size (8 vCPUs, 32GB RAM) wastes 2 vCPUs and 20GB of memory.

Custom machine types let you specify vCPU and memory within limits that vary by machine series. For example, N2 supports 2–80 vCPUs and 0.5–8 GB of memory per vCPU, N2D supports 2–96 vCPUs and 0.5–8 GB per vCPU, and E2 supports 2–32 vCPUs and 0.5–8 GB per vCPU. You pay slightly more per GB and per vCPU (~5% premium), but you avoid the waste from oversized predefined types.

When to use custom types:

• Recommender suggests a downsize but the next-smaller predefined type is too small
• Your workload has unusual memory requirements (3GB per vCPU instead of 4GB)
• You're optimizing hundreds of VMs and the 5% custom-type premium is offset by the elimination of wasted resources

When to stick with predefined:

• A predefined type is close enough (within 10% of optimal)
• You're using spot or preemptible instances (custom types have lower availability in spot pools)
• The workload is temporary (testing, CI/CD) and the optimization effort exceeds the monthly savings

Memory-optimized and compute-optimized workloads

Memory-optimized workloads (databases, in-memory caches, analytics) are constrained by RAM, not CPU. A database with 8 vCPUs at 30% utilization but 80% memory usage can't be downsized by cutting vCPUs—it needs the memory. For these workloads, use M-series (memory-optimized) instances or custom machine types with high memory-to-vCPU ratios.

Compute-optimized workloads (video encoding, ML training, batch jobs) are CPU-bound. They max out vCPUs while memory sits idle. For these, use C-series (compute-optimized) instances with lower memory-to-vCPU ratios. You get more compute per dollar and avoid paying for memory the workload doesn't use.

A pitfall is to apply a generic rightsizing recommendation without checking the workload profile. A memory-bound database downsized based on low CPU will crash under load. A compute-bound batch job running on a memory-optimized instance wastes 60% of the instance cost on unused RAM.

Right-sizing persistent disks and disk types too, not just the VM

Persistent disks are billed separately from the VM. A rightsized VM still wastes money if it's attached to a 500GB SSD storing 50GB of data.

Disk sizing: Check actual disk usage (df -h on the VM). If usage is <70%, consider migrating the data to a smaller disk. GCP charges per GB provisioned, not per GB used, so a 500GB disk costs the same whether it holds 50GB or 450GB of data. Persistent Disk capacity cannot be reduced in place; you need to create a smaller disk, copy the data, and replace the original.

Disk type optimization: Most workloads default to SSD persistent disks (pd-ssd or pd-balanced) when standard persistent disks (pd-standard) would work fine. SSD costs 3-4x more per GB than standard. If your workload doesn't need sub-10ms disk latency (most don't), downgrade to pd-standard.

The exception is databases and I/O-intensive workloads. These need SSD performance. But dev/test VMs, logging aggregators, and file servers rarely do.

Part 4: Using GCP's Native Recommendations

GCP has several options for surfacing rightsizing recommendations.

Recommender and Active Assist machine type recommendations

GCP Recommender (part of Active Assist) generates machine type recommendations based on observed CPU and memory utilization for eligible Compute Engine VMs. Recommendations are not available for some instances, including VMs with GPUs or TPUs, memory-optimized VMs, and VMs created by services such as GKE and Dataflow.

Recommendations include:

• Current machine type
• Suggested machine type
• Estimated monthly savings (based on list prices)
• The operations required to apply the recommendations

How the recommendations are generated and what lookback they use

Recommender analyzes 8+ days of CPU utilization history. If you have the Ops Agent installed, it also analyzes memory usage. The algorithm looks for:

• Persistent under-utilization: CPU/memory consistently below 40% for the observation window
• Weekly patterns: Workloads with weekday/weekend cycles
• Growth trends: Workloads that are gradually increasing resource usage over time

Recommender works well for weekly patterns, gradual growth or decline, and persistent under- or over-utilization. Its bigger blind spots are infrequent spikes that fall outside the 8-day window and very short CPU spikes, since recommendations are based on average CPU utilization over 60-second intervals.

The gaps: per-project scope, conservative defaults, manual application, no continuous enforcement

GCP Recommender is useful for identifying rightsizing opportunities, but it has several limitations when you try to use it as an ongoing optimization system.

Part 5: Right-Sizing Without Breaking Things

Engineers won’t apply rightsizing recommendations if they can’t trust them. Useful strategies to ensure rightsizing won’t break anything include:

Setting an observation window

The observation window determines how much historical data you analyze before rightsizing. GCP Recommender uses 8 days minimum, but that's too short for workloads with monthly or seasonal patterns.

Recommended observation windows:

• 8-14 days: For VMs with stable, predictable traffic (always-on APIs, background jobs)
• 30 days: For workloads with monthly cycles (month-end reporting, billing runs)
• 60-90 days: For workloads with quarterly patterns (earnings processing, seasonal campaigns)
• 365 days: For workloads with annual seasonality (retail holiday traffic, tax season)

Leaving headroom for spikes and seasonality

Don't rightsize to average or even P95 utilization without buffer. Real-world traffic includes unexpected spikes—product launches, viral social posts, DDoS attacks, legitimate surges.

Recommended headroom:

• 20-30% buffer above P95: For most production workloads
• 40-50% buffer: For revenue-critical services or latency-sensitive workloads
• No buffer (rightsize to P95): For non-production environments (dev, staging, test)

The math: If P95 CPU utilization is 60%, target a machine type where 60% becomes 50-55% post-resize. That gives you 40-50% buffer above operating load before you hit resource constraints.

Staged rollout: dev, then staging, then production

Never rightsize production first. The safe sequence:

1. Dev/test environments: Rightsize aggressively. If something breaks, impact is contained. Validate that the workload still functions with reduced resources.

2. Staging: Rightsize to match the production target. Run load tests. Monitor for latency increases, memory pressure, or disk I/O bottlenecks. If performance stays within SLA, proceed.

3. Production: Rightsize during a low-traffic window. For stateless services behind a load balancer, resize 10-20% of instances at a time. For stateful services (databases), resize replicas first, then the primary.

The rollback plan: If production performance degrades post-resize, revert to the old machine type immediately. Don't wait for metrics—if users complain or latency spikes, rollback first and investigate later.

Monitoring after the change and how to roll back

After rightsizing, monitor for 7 days minimum:

• Application metrics: Request latency (P50, P95, P99), error rates, throughput
• System metrics: CPU utilization (should stay <70%), memory usage, disk I/O wait times, network saturation
• User experience: If you have RUM (real user monitoring), watch for latency increases or error rate spikes

Rollback procedure: Stop the VM, change the machine type back to the original size, restart. For Managed Instance Groups, update the instance template to the old machine type and roll out the change.

If utilization creeps above 80% or application latency increases by >10%, upsize before it becomes a customer-facing issue.

Workloads you should not right-size aggressively

Databases with active failover: Primary databases need headroom for failover scenarios. If the primary crashes and a replica promotes to primary, that replica needs capacity to handle 100% of traffic, not just its normal read load.

Latency-sensitive services: A 10ms increase in P99 latency from rightsizing may cost more in lost revenue than the VM savings. Financial services, gaming, real-time bidding—these workloads prioritize performance over cost.

Stateful services without redundancy: If losing the VM causes data loss or extended downtime, don't rightsize aggressively. The risk exceeds the monthly savings.

VMs already running on spot/preemptible instances: Spot instances are 60-91% cheaper than on-demand. The absolute dollar savings from rightsizing low-cost spot VMs are minimal compared to the testing effort required.

Part 6: Right-Sizing and Committed Use Discounts

Pricing is one of the biggest levers to pull when it comes to reduce your Google Cloud costs. Let’s talk about how it interacts with rightsizing.

Why right-sizing after committing can strand CUDs

GCP Committed Use Discounts lock you into specific machine families (N2, C2, E2) and regions for 1 or 3 years. If you commit to 100 N2 vCPUs and then rightsize your workload to E2 instances, those committed N2 vCPUs go unused. You still pay for the commitment.

The pitfall is that if you commit to a multi-year CUD for significant savings on current usage first, and then six months later, you rightsize and reduce your N2 usage by 40% — now you're paying for vCPUs you don't use. The CUD savings are partially offset by wasted commitment.

The correct sequence: right-size first, then commit to the new baseline

The safe sequence:

1. Rightsize everything: Downsize over-provisioned VMs, eliminate idle instances, optimize machine families

2. Observe the new baseline for 30-60 days: Ensure the rightsized footprint is stable

3. Commit to the floor: Buy CUDs for the minimum sustained usage, not the peak or average

If you commit before rightsizing, you lock in commitments based on inflated usage. If you rightsize after committing, you strand CUDs.

Consider committing to 60-70% of your steady-state usage post-rightsizing. Let the remaining 30-40% run on-demand or spot. This gives you flexibility to rightsize further without stranding commitments.

Keeping commitments aligned as workloads change

Workloads change. The instance mix that made sense in January may be wrong by June. CUDs don't adapt—they're fixed for 1-3 years.

Options for realignment:

1. Buy incremental CUDs: If usage grows, add more CUDs at the new baseline. Don't over-commit—buy only for the proven floor.

2. Let CUDs expire: If usage shrinks or shifts machine families, let existing CUDs run out. Don't renew.

3. Use flex (spend-based) CUDs: Flexible CUDs apply across eligible machine families and regions, so if you rightsize from N2 to E2, eligible usage can still receive the discount. The trade-off is flexibility versus a larger discount: flexible CUDs provide 28% savings for 1 year and 46% for 3 years, compared with up to 37% and 55% for resource-based commitments on most machine types.

The key: cloud commitment management requires continuous adjustment. Static CUDs and dynamic workloads create ongoing misalignment.

Tracking and Optimizing GCS Costs

Rightsizing can reduce today's over-provisioning, but workloads keep changing. nOps helps teams continuously identify optimization opportunities across GCP while keeping cost allocation and commitment strategy connected to the new baseline.

• Unified visibility: Get all of your spending from GCP, AWS, Azure, AI, and SaaS in one place, with cost allocation by application, customer, team, or business unit to understand what is driving spend and where optimization will have the greatest impact.
• Commitment Management: Automatically maximize discounts and minimize commitment risk across eligible cloud infrastructure supporting your GCP workloads. Customers typically save ~20% by switching to nOps — and with results-based pricing, you pay only when you get better results.

We’ve talked to companies that can save millions on their cloud bills by switching to nOps from competitors. Book a free savings analysis to quantify exactly how much more you could save across the infrastructure supporting GCP and the rest of your cloud environment.

nOps manages $5B+ in cloud spend and was recently rated #1 in G2’s Cloud Cost Management category.

Demo

AI-Powered Cost Management Platform

Discover how much you can save in just 10 minutes!

Book a Demo

FAQ