GCP cost optimization: CUDs, rightsizing, and idle workloads

GCP cost optimization is a four-axis pass, not a one-line rightsizing swap. The axes stack in a deliberate order — sustained-use discounts first (free, retroactively applied), then idle workload reclamation (no user-facing change, the highest signal-to-noise on any estate), then rightsizing against p95 trailing usage (the highest per-unit saving once idle is gone), then Committed Use Discounts (https://cloud.google.com/docs/cuds) (the highest absolute saving, but only after the post-rightsizing baseline is stable). This is the on-page runbook the Tallywyrm agent drives on a real GCP project; it composes the framework in the FinOps multi-cloud playbook (/blog/finops-multi-cloud-2025-playbook) and the audit shape in the multi-cloud waste-audit playbook (/blog/multi-cloud-waste-audit-playbook) into one provider-scoped guide. The GCP rightsizing-with-Terraform pillar (/blog/gcp-rightsizing-terraform-guide) is the closest cousin — read that one once you have chosen Terraform / Pulumi / Crossplane and want a resource-family-scoped diff; this one stays at the platform shape and the four-axis sequence above. Sustained-use discounts: free money first Sustained-use discounts (https://cloud.google.com/docs/sustained-use-discounts) apply automatically when a Compute Engine instance runs for more than 25% of a month. They compound throughout the month without any commitment — a workload running continuously ships at up to a 20% discount by the end of the month, with zero action from the team and zero upfront commitment. They are the always-on baseline, not a lever you have to engage. The audit shape here is "verify, do nothing" — the FinOps agent confirms the discount is being applied on each running instance, and the report surfaces the resulting month-end saving without any IaC change. A first-time GCP estate usually sees 8–15% of its Compute Engine bill drop into this bucket on the first audit run, with no commitment and no risk. Idle workload reclamation before sizing Idle workloads are the highest signal-to-noise pass on any GCP estate. The detection method is straightforward: pull the trailing 14-day CPU + network-in + network-out metrics at the instance level, and flag any instance where all three read below a configurable floor (a sensible default is 2% CPU and 1MB / day egress). The shift — stop, snapshot, delete, or schedule a nightly pause — is a one-line Terraform / Pulumi / Crossplane change, reversible without data loss because VM state is preserved through stop+start for the same instance family. The same idle hygiene sequence the waste-audit playbook describes (/blog/multi-cloud-waste-audit-playbook) applies on GCP (https://cloud.google.com/compute/docs/instances/stop-start-instance) as on any other provider: stop the workload, snapshot the boot disk if it carries ephemeral state, delete the instance, and record the row in the audit trail with the trailing-usage numbers. The blocker is usually a missing tag — a workload that should be idle was never tagged "non-prod" because nobody owned the tag taxonomy. Fix the taxonomy first; the pass becomes trivial. Rightsizing against p95, not average The single biggest mistake in a first-time GCP rightsizing pass is picking a target instance family off average CPU. p95 latency under peak is what your SLO actually depends on — average utilization on a load-balanced stateless service tells you almost nothing about whether your smallest machine type still fits the workload's tail-latency budget. Always size against trailing 14–30 day p95 CPU and p95 memory, with a safety margin that honours the workload's contract. The family-swap question — N2 vs N2D vs T2D — composes with the rightsizing pass. The cheapest shape for amd64 workloads is N2D (AMD EPYC); for burst-tolerant workloads the T2D family is the better target. The trade-off is the workload's existing image: an N1 fleet typically ships an x86 image that needs no rebuild; an N2D move usually requires no rebuild but the per-core pricing comparison is what determines whether it is cheaper; a T2D move is cheaper still but only fits if the workload's burst pattern does not exceed the T-series baseline. The rightsizing pass must always come paired with the family question in the PR description. The reviewer should push back on a rightsizing PR that handwaves the platform-specific implication — a one-line swap from n1-standard-8 to n2-standard-4 is the right answer if the workload is not memory-bound and the trailing p95 CPU is at 20%. Committed Use Discounts come last Layering a Committed Use Discount (https://cloud.google.com/docs/cuds) on a workload that is itself rightsizing-eligible is the worst first move. Anchor reservations against the post-rightsizing baseline, not the current shape. A 1-year CUD on a workload that should drop one machine type costs more than it saves — you have locked in a discount on capacity you no longer need. Run the rightsizing pass first, wait one quarter, then negotiate CUDs. The CUD shape that survives audit is resource-based CUDs anchored to specific machine families, not spend-based CUDs that cover any vCPU in any family. Resource-based CUDs read against the same audit trail the rightsizing pass already produces; spend-based CUDs surface as a single line on the invoice and the auditor cannot reconcile them to a specific change. The audit trail records the CUD commitment against the same six-field shape every other saving ships with — only the `changeArtifact` field differs (it carries the CUD purchase order rather than an IaC PR). The four-axis sequence in practice The sequence is what makes the four axes compose into a single pass. Running them out of order either loses saving (idle reclaimed after CUDs → paying for capacity the audit no longer needs to anchor) or produces audit risk (CUD commitments before the post-rightsizing baseline is known). The order is always: Sustained-use discounts. Verify they apply; record the realized month-end saving. Idle reclamation. Snapshot, stop, delete, or schedule-pause each flagged workload; record the per-row delta. Rightsizing. p95-driven target family + size, family-swap implication in the PR description, rollback path documented. CUD strategy. Anchor resource-based CUDs to the post-rightsizing baseline one quarter later; record the CUD purchase order against the audit trail. Each axis produces a row of the same audit trail the multi-cloud cluster already maintains. The audit aggregator reads one artifact, not four. The four-axis sequence is the deployment pattern the FinOps multi-cloud playbook (/blog/finops-multi-cloud-2025-playbook) describes, applied GCP-specifically. Verification: the bar for "verified" saving A saving is only counted when, a week after the change went live, the platform re-reads the workload and confirms the bill actually dropped the forecasted amount. The verification window is one week by default; the workload's trailing-usage signal at day 7 is read against the same signal at day 0, and the delta is recorded as either confirmed or regression. Confirmed savings flow through to the next invoice; regressions are removed. The same audit shape the compliance pillar (/blog/finops-compliance-guide) describes applies end to end: resource identity, change artifact (PR or CUD PO), deployment, verification, emissions delta where the workload is in scope, and invoice entry. The four Axis output rows share the same six-field shape, signed against the same secret, owned by the same people. From playbook to the agent loop The single highest-leverage next step is to instrument the four cost levers above as concrete Terraform / Pulumi / Crossplane modules your team can review. Once the modules exist — one per axis, callable from your existing repo — the agent has a stable surface to write changes against, and your team has a stable surface to review changes from. New GCP levers land as the platform evolves — start with the FAQ (/faq) and then talk to the team (mailto:tallywyrm@polsia.app) about a real audit on one of your own GCP projects.

GCP cost optimization: CUDs, rightsizing, and idle workloads

Send us your last month’s bill. We’ll show you what the agent finds.

GCP rightsizing with Terraform: a practical 2026 guide

FinOps for multi-cloud teams: a 2025 playbook

AWS rightsizing with Terraform: a practical 2026 guide

GCP cost optimization: CUDs, rightsizing, and idle workloads

Send us your last month’s bill. We’ll show you what the agent finds.

Related posts

GCP rightsizing with Terraform: a practical 2026 guide

FinOps for multi-cloud teams: a 2025 playbook

AWS rightsizing with Terraform: a practical 2026 guide