Compute Engine rightsizing means matching each instance to the CPU and memory its workload actually uses, and the reason it so often fails to stick is behavioural, not technical. Someone rightsizes a fleet, the bill drops, and over the next two quarters new instances launch from an oversized template, engineers pad memory because a single out of memory event once scared them, and the fleet quietly inflates back. The durable version does three things at once: it sizes from observed utilization rather than the requested shape, it uses custom machine types so you stop rounding up to the next fixed size, and it builds in a review cadence and default that keep new instances honest. Because sustained use discounts apply automatically to running instances, a smaller rightsized instance keeps its automatic discount, so rightsizing and the discount compound rather than fight.
This sits in the GCP compute cluster with persistent disk rightsizing and spot VMs and preemptible economics on GCP. Read those to rightsize the storage attached to these VMs and to move tolerant workloads onto cheaper spot capacity.
How do you size from real utilization, not the request?
The request is what a team asked for; utilization is what the workload uses. Compute Engine rightsizing recommendations read actual CPU and memory over a trailing window and propose a smaller machine type when the instance is consistently underused. The key is the window and the percentile. Size to a high percentile of real usage, not the average, so you keep headroom for genuine peaks while cutting the fat between them. An instance averaging low CPU with brief spikes does not need a machine sized for its average doubled for fear; it needs one sized for its observed peak plus a measured margin.
Why custom machine types change the math
Predefined machine families come in fixed ratios of vCPU to memory, so a workload that needs a lot of memory but little CPU forces you up to a large, expensive shape just to get the memory, paying for vCPUs you never touch. Custom machine types let you set vCPU and memory independently, so you provision the four vCPUs and the larger memory the workload actually needs rather than the eight vCPUs a predefined shape would bundle. For memory heavy or CPU heavy workloads this alone removes a structural overpay that no amount of picking a predefined size can fix. The E2 and Tau families and custom types together give you precise shapes for most general purpose work.
Why does rightsizing drift back, and how do you stop it?
Drift has three sources, and each has a control. New instances launch oversized because the template or the infrastructure as code module defaults to a large shape, so fix the default to a sensible baseline and require a reason to exceed it. Engineers pad memory after a scare, so give them a fast, low friction path to resize up when monitoring genuinely shows pressure, which removes the incentive to overprovision defensively. And the fleet ages without review, so put a recurring rightsizing pass on the calendar, monthly or quarterly, that reads current recommendations and acts. Without the cadence, entropy wins and you rightsize the same fleet every year.
Where does rightsizing sit relative to commitments?
Always before. Committed use discounts reward a steady baseline, but if you commit against an oversized fleet you lock in a discount on capacity you did not need, which is worse than paying on demand for the right size. Rightsize first, let the leaner fleet run long enough to establish its true steady state, and only then size committed use discounts to that floor. The sequence matters as much as the actions: lean, then commit, never commit, then discover the bloat.
A worked example
An indicative European SaaS company rightsized its Compute Engine fleet once and saw the bill climb back within two quarters. The recurrence had three causes: a Terraform module defaulting to an oversized machine type, several teams padding memory after one out of memory incident, and no review cadence. They set the module default to a custom machine type baseline, gave teams a quick resize path backed by monitoring, and added a monthly rightsizing review against current recommendations. The second cut held because the behaviours that had reinflated the fleet were now controlled, and the leaner fleet still earned its automatic sustained use discounts. Figures are verified against billing data and anonymised.
Frequently asked questions
How do I rightsize Compute Engine correctly?
Do custom machine types save money?
Should I rightsize before buying committed use discounts?
Where this fits the cost review
Rightsizing is the move that should happen before any commitment, and keeping it from drifting back is what separates a one time cut from a durable one. We run that review as an independent buyer side advisory across AWS, Azure, GCP, and OCI, with zero provider commissions and a guarantee: we reduce your cloud spend or we reimburse our service fee.
For monthly buyer side analysis delivered to your inbox, subscribe to The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.