GCP Cost Optimisation Strategy: 5 Steps to Reduce Google Cloud Spend

Simple explanation

A cost optimisation strategy is a plan for spending less on cloud infrastructure without reducing the value it delivers. It is not the same as a one-time cleanup. A cleanup fixes the waste you can see today. A strategy creates a process that finds and fixes waste continuously, month after month.

There are three levers for reducing cloud costs, and they work best in order:

• Reduce waste: stop paying for resources nobody uses. Lowest risk, fastest payback.
• Reduce unit cost: pay less per resource through discounts, scheduling, and right-sizing. Moderate effort, predictable savings.
• Redesign architecture: change how workloads run so they need fewer resources. Highest potential savings, but requires engineering time and carries migration risk.

A strategy sequences all three levers so you capture the easy wins first and avoid locking in commitments on infrastructure you are about to change.

Who this is for

• Small team with a growing bill: You launched on GCP, things are working, but the invoice is climbing and nobody is sure why. You need a structured starting point.
• Startup scaling on GCP: Traffic and infrastructure are growing fast. You want to keep costs proportional to revenue, not runaway ahead of it.
• Mature team building a FinOps practice: You have done ad-hoc cleanups before. Now you want a repeatable framework with clear ownership and ongoing governance.

When to use this

• Bills are growing but nobody can explain why or who owns which costs
• Leadership wants predictable savings without risky migrations or service disruptions
• Previous cost-cutting efforts saved money temporarily but waste returned within a few months
• You need a repeatable framework to hand to teams, not a list of random cleanup tasks

How cost optimisation works in GCP

GCP cost optimisation follows a simple operating model. Each stage builds on the one before it:

1. Visibility: know what you spend, where it goes, and how it trends. Without this, every other step is guesswork. Start with cost breakdown reports and billing budgets and alerts.
2. Ownership: assign costs to teams, projects, or applications so the people who create spend can see and manage it.
3. Waste removal: delete or stop resources that deliver no value (idle VMs, unattached disks, unused IPs, old snapshots).
4. Pricing optimisation: reduce the per-unit cost of resources you actually need through committed use discounts, Spot VMs, and storage class alignment.
5. Architectural optimisation: change how workloads run so they consume fewer resources for the same output.
6. Governance: embed cost review into routine engineering practice so savings persist and waste does not re-accumulate.

The five-step framework below maps directly to this model. Steps 1 and 5 cover visibility, ownership, and governance. Steps 2-4 cover the three categories of technical optimisation, sequenced from lowest to highest effort.

The 5-step framework

Step 1: Establish a cost baseline

What this step is: Before changing anything, understand what you currently spend and where the money goes.

Why it matters: Without a baseline, you cannot measure whether optimisations worked, and you cannot spot regression when costs creep back up. Every team that skips this step ends up guessing.

What to do:

• Enable the BigQuery billing export (Billing → Billing export → BigQuery export in the GCP Console). Choose the detailed export for per-resource visibility.
• Use cost breakdown reports to see spend by service, project, and label.
• Set up billing budgets and alerts at 80% and 100% of your expected monthly spend.
• Calculate estimated costs for any new infrastructure before provisioning it.

Your baseline should answer these five questions:

• What is the total monthly cloud spend?
• Which five services cost the most?
• What is the month-over-month growth rate?
• What is the cost per team or application (if labels exist)?
• What is the cost per unit of value (cost per user, cost per request)?

A quick SQL query against your billing export can give you a monthly spend summary:

-- Monthly spend by service for the last 3 months
SELECT
  FORMAT_DATE('%Y-%m', DATE(usage_start_time)) AS month,
  service.description AS service,
  ROUND(SUM(cost), 2) AS total_cost
FROM `PROJECT.DATASET.gcp_billing_export_v1_BILLING_ACCOUNT_ID`
WHERE DATE(usage_start_time) >= DATE_SUB(CURRENT_DATE(), INTERVAL 90 DAY)
GROUP BY month, service
ORDER BY month DESC, total_cost DESC;

What not to do: Do not skip straight to buying discounts or changing architecture. Every action in Steps 2-4 depends on data from this baseline.

Step 2: Remove waste and capture quick wins

What this step is: Delete, stop, or schedule resources that cost money but deliver no value. This is the highest-ROI, lowest-risk work you can do.

Why it matters: Waste elimination typically reduces costs by 20-40% for teams that have never done a systematic review. The effort is small (often a few days of engineering time) and the risk is near zero because you are removing things nobody uses.

What to do:

• Use resource identification to find your highest-cost items and focus there first.
• Follow the cleaning up unused resources guide to delete unattached disks, release unused static IPs, remove old snapshots, and terminate stopped VMs with attached disks.
• Schedule dev and test VMs to stop outside business hours. A weekday-only schedule (08:00-18:00) cuts those VM costs by roughly 76%.
• Pause dev Cloud SQL instances when not in use by setting their activation policy to NEVER.
• Review storage buckets containing backups, logs, or archived files. Moving them from Standard to Nearline or Coldline with a lifecycle policy cuts storage cost by 50-80%. See storage cost optimisation for configuration details.
• Check Active Assist recommendations in the console for per-resource savings estimates.

# Schedule dev VMs to stop outside business hours
gcloud compute resource-policies create instance-schedule dev-schedule \
  --region=us-central1 \
  --vm-start-schedule="0 8 * * MON-FRI" \
  --vm-stop-schedule="0 18 * * MON-FRI" \
  --timezone="Europe/London"

What not to do: Do not spend weeks building dashboards or approval workflows before cleaning up obvious waste. If a disk has been unattached for 90 days, delete it. Governance comes in Step 5.

Step 3: Rightsize and optimise rates

What this step is: Reduce the per-unit cost of resources you actually need. This includes rightsizing VMs to match actual utilisation and purchasing committed use discounts (CUDs) for stable workloads.

Why it matters: After waste is gone, your remaining infrastructure is genuinely needed. Paying less per unit for that infrastructure is the next safest way to reduce costs. CUDs save 37-55% compared to on-demand pricing for eligible compute.

What to do:

1. Complete waste elimination first. Do not commit to resources you are about to delete.
2. Rightsize VMs using Active Assist recommendations. If a VM averages 15% CPU, it is over-provisioned.
3. Gather at least 90 days of utilisation data before purchasing CUDs.
4. Start with 1-year commitments. Only consider 3-year after you are confident the workload pattern is stable.
5. Evaluate Spot VMs for batch workloads, ML training, and CI/CD pipelines. Spot offers 60-91% savings for workloads that can tolerate interruption.
6. Review GCP pricing models to understand how on-demand, sustained use discounts, CUDs, and Spot pricing interact.

Step 4: Make higher-ROI architecture changes

What this step is: Change how workloads run so they consume fewer resources for the same output. These changes have the highest potential savings but require engineering investment.

Why it matters: Some cost problems cannot be solved by deleting waste or buying discounts. A service that runs at 20% CPU utilisation on an always-on VM wastes 80% of its compute budget even after rightsizing. Moving it to Cloud Run, which scales to zero between requests, eliminates idle cost entirely.

What to do:

• Evaluate VM-to-serverless migration: Variable-traffic services often cost less on Cloud Run or Cloud Functions. Use the Cloud Run vs Compute Engine comparison to decide which workloads are good candidates.
• Optimise BigQuery costs: Add partition filters to queries on large tables. Without filters, a query on a 10 TB table scans everything at $6.25/TB. With partition filters, the same query may scan a fraction of that. See BigQuery cost optimisation for details.
• Add caching layers: Memorystore or Cloud CDN for frequently accessed data reduces compute and database load. Each cache hit is a backend query that did not need to run.
• Shift batch processing: Move non-urgent work from real-time VMs to overnight batch jobs on Spot VMs. This combines the Spot discount with the elimination of idle daytime compute.
• Review network egress: Cross-region and internet egress adds up. See network egress costs for strategies to reduce transfer charges.

What not to do: Do not start here. Architectural changes take weeks or months and carry migration risk. If you have not done Steps 1-3, you are spending engineering time on hard problems while easy money sits on the table.

Step 5: Build ongoing governance

What this step is: Embed cost management into routine engineering practice so savings persist and waste does not re-accumulate.

Why it matters: Without governance, a cleanup in Q1 will have significant new waste by Q3 as teams provision new infrastructure. The difference between a one-time project and a sustainable strategy is this step.

What to do:

• Cost review in architecture documents: Every new service proposal includes a cost estimate and a cost-per-unit calculation before approval.
• Monthly cost review meetings: Review spend trends, discuss anomalies, and assign optimisation actions to specific owners.
• Per-team budget alerts: Each team has a monthly budget with alerts at 80% and 100%. See billing budgets and alerts for setup.
• Quarterly cleanup reviews: Run the cleanup checklist and review Active Assist recommendations as a standing team ritual.
• Annual CUD review: As infrastructure plans change, review expiring commitments and adjust based on current workload patterns.
• Adopt FinOps principles: Build shared cost ownership across engineering and finance using the practices described in FinOps principles.

Quick wins vs deeper optimisation

The pattern is consistent: lower effort and lower risk produce faster results. Always exhaust one category before investing heavily in the next. Teams that jump straight to architectural changes often overlook thousands of dollars of waste sitting in idle resources.

Cost optimisation strategy vs one-time cleanup vs FinOps program

These three concepts overlap but are not the same thing:

• One-time cleanup: A single pass through your infrastructure to delete waste and fix obvious over-provisioning. Effective in the short term, but savings erode as new resources are created without cost review.
• Cost optimisation strategy: A sequenced, repeatable process (this page) that covers waste removal, rate optimisation, and architecture changes, plus the governance to sustain them. It is the technical backbone of ongoing cost management.
• FinOps program: The full organisational framework that includes a cost optimisation strategy plus cultural practices like shared cost ownership, team-level accountability, cost-aware architecture reviews, and cross-functional collaboration between engineering and finance. See FinOps principles for the broader picture.