GCP Cost Optimization Guide: 2026 Best Practices

Google Cloud waste has a shape, and it is the project. Every team, environment, experiment, and migration gets its own GCP project, which is the platform's great organizing virtue and its quiet cost problem: projects outlive their purpose, their resources keep billing, and because each one sits in its own billing scope, nobody sees the estate as a whole. The proof-of-concept project from last spring, the migration project whose source system was decommissioned, the per-developer sandboxes, the BigQuery dataset a dashboard still scans hourly: each is small, each has an owner who moved on, and together they are the first month's savings in almost every GCP optimization program.

This guide covers how Google Cloud pricing works in 2026, including the three discounts that stack and the January change to committed-use discounts, why allocation by project and label comes first, and ten best practices across compute, GKE, BigQuery, storage, and network, with worked US figures. It ends with how Opslyft runs the whole loop and what it found for Purplle in its first month on GCP. For the Kubernetes-specific half, our GKE cloud cost management best practices go deeper; this guide covers the estate around the clusters.

Key Takeaways

• GCP's project hierarchy is the best allocation structure of any cloud and the reason waste accumulates: projects outlive their owners and keep billing.
• Three discounts stack: automatic sustained-use (up to ~30 percent, eligible machine types only), committed-use (resource-based ~37/57 percent; Flexible ~28/46 percent, now the default model), and Spot (60 to 91 percent).
• BigQuery on-demand at $6.25 per TiB scanned is the service-specific trap; capacity pricing wins above roughly 100 TB a month.
• Idle resources in unowned projects are the first month's saving: Purplle found more than $200,000 of them on GCP within minutes of connecting.
• Allocation comes first, because every other practice only recurs when a team sees its own number.

How Google Cloud Pricing Works

GCP bills per second for compute, per GB-month for storage, per TiB scanned or per slot for BigQuery, and per GB for network egress, with every rate varying by region. What distinguishes it from AWS and Azure is the discount structure: one discount applies with no action, two require commitment, and all three stack.

Start With Allocation: Projects, Folders, Labels

GCP gives you an allocation structure that AWS and Azure make you build: the project is a hard billing and permission boundary, folders group projects into business units, and labels add product, environment, and cost center. Used deliberately, that hierarchy answers who owns this spend for most of the bill before a single label is applied. Used accidentally, with projects created ad hoc and never mapped to anything, it produces the sprawl described above. The practice is to map every project to a team or product in the folder hierarchy, enforce a short label set at creation through Organization Policy, export billing to BigQuery so the whole estate is queryable, and attribute the remainder, shared platform projects and unlabelled resources, by rule rather than leaving it in a bucket. Our engineering guide to cloud cost allocation covers the general method; on GCP the project hierarchy does half the work.

Ten GCP Cost Optimization Best Practices

1. Find and remove idle resources across every project

Recommender surfaces idle VMs, unattached persistent disks, idle Cloud SQL instances, and unused IP addresses per project; the gap is that it works per project and most organizations have hundreds. An estate-wide pass across all projects, especially the ones with no recent activity, is the first month's saving. Unattached disks are the classic case: billed at about $0.04 to $0.17 per GB-month depending on type, persisting after the VM they served was deleted, invisible unless someone lists them.

2. Right-size VMs with more than eight days of data

Recommender's rightsizing uses the last eight days of CPU and memory, which misses month-end and seasonal peaks. Measure over four to eight weeks, include memory and disk I/O, step down one size at a time, and use custom machine types to match the shape exactly rather than rounding up to the next standard size, which is a GCP advantage AWS does not offer.

3. Choose machine types for price-performance, and know the SUD trap

E2 types are the cheapest general-purpose option and do not receive sustained-use discounts; N2 and N1 cost more at list but discount automatically. For a steady workload the two often land close; for bursty or scheduled workloads E2 wins outright. Tau T2A (Arm) and C3 offer better price-performance for suitable workloads. Check the net rate after SUDs, not the list rate.

4. Schedule non-production down

Instance schedules stop and start VMs on a timetable; a development project running eight hours on weekdays costs about a quarter of one running all month. Apply the same to GKE Standard node pools with autoscaling to zero and to Cloud SQL instances that serve only working hours.

5. Commit the stable baseline, Flexible first

After right-sizing, cover the always-on baseline with committed-use discounts. Flexible CUDs, now the default model, discount about 28 and 46 percent and follow workloads across families and regions, which suits estates that change; resource-based CUDs discount deeper, about 37 and 57 percent, and suit workloads provably fixed in one family and region. Size commitments to the trough of sustained usage, not the average, and remember SUDs already reduced the baseline.

6. Run interruptible work on Spot VMs

Spot VMs are 60 to 91 percent off and suit batch, CI, data processing, and fault-tolerant GKE node pools. Diversify across zones and machine types and keep a floor of on-demand or committed capacity for what cannot be interrupted.

7. Fix GKE at the request level

GKE's $0.10 per cluster-hour fee is the small part; the bill is the nodes, and the nodes are sized by pod requests. Right-size requests to measured usage, choose Autopilot or Standard per workload, enable cluster autoscaling with scale-to-zero on non-production, and turn on GKE cost allocation so the billing export carries namespace and label. The full sequence is in our GKE cost management best practices.

8. Stop BigQuery from scanning what it does not need

On-demand BigQuery bills $6.25 per TiB scanned, with the first TiB a month free, and it bills for the bytes a query reads, not the rows it returns. Partition tables by date, cluster by the columns queries filter on, set per-user and per-project byte limits, and move heavy, steady consumers to capacity pricing, which typically beats on-demand above about 100 TB scanned a month. The BigQuery pricing page lists both models; the trap is a dashboard that rescans a large unpartitioned table every hour and quietly bills four figures a month.

9. Tier Cloud Storage and set lifecycle rules

Standard storage costs about $0.020 per GB-month in US regions; Nearline about $0.010, Coldline about $0.004, and Archive about $0.0012, each with a minimum duration and retrieval fee. Lifecycle rules that move objects down the tiers by age, and Autoclass for buckets with unpredictable access, cut storage cost by half or more on data that is rarely read. Our comparison of cloud storage pricing across S3, Blob, and GCS covers the classes side by side.

10. Reduce egress and pay for the right network tier

Premium tier egress at $0.12 per GB for the first terabyte makes GCP's network the most expensive of the three for internet-facing traffic. Put Cloud CDN in front of public content, use Private Google Access and Private Service Connect for traffic to Google services, keep chatty components in one region, and evaluate Standard tier networking for workloads that do not need Google's global backbone.

A Worked Example

A US company spends about $420,000 a month on GCP across 140 projects: a production platform on GKE and N2 VMs, BigQuery analytics, Cloud Storage, and a long tail of team and experiment projects. Labels cover about 55 percent of spend; 30 projects have had no deployment in six months.

Allocation first: mapping projects to teams through folders and inferring ownership from project naming takes attribution to 93 percent in three weeks, and the 30 inactive projects turn out to hold $31,000 a month of idle VMs, unattached disks, and a GKE cluster serving nothing. Removing them is the first saving. Right-sizing N2 VMs over six weeks of data and switching the bursty tier to E2 saves $44,000. Scheduling development projects down saves $18,000. Flexible CUDs on the remaining stable baseline, sized to the trough after SUDs, save $52,000. Moving the two heaviest BigQuery consumers from on-demand to capacity and partitioning the three largest tables cuts analytics by $27,000. Lifecycle rules on Cloud Storage save $9,000, and Cloud CDN in front of the public assets cuts egress by $12,000. Monthly spend falls by about $193,000, 46 percent, over two quarters, with $31,000 of it in the first week from projects nobody owned.

How Opslyft Does This

The GCP problem is the estate-wide view that no console provides: 140 projects, each with its own Recommender, its own billing scope, and its own absent owner. Opslyft ingests GCP billing alongside AWS, Azure, OCI, Kubernetes, and Snowflake, and Explorer shows GCP spend as one estate, broken down by project, folder, team, product, or customer, with GKE cost by pod, service, or namespace in the same view, tracked over time so a project's growth is visible before the invoice. Canvas puts the view each team needs on one screen, finance and engineering from the same numbers.

Atlas keeps a live inventory of every GCP resource across every project with an owner and a cost on each, tracking ownership so no project runs without one, and surfaces the idle VMs, unattached persistent disks, and unused clusters that Recommender shows only one project at a time, with recommendations that weigh each workload's purpose and criticality and draw on memory, storage, and query-time metrics rather than CPU alone. Its change history traces a cost movement to the change that caused it. Dimension Studio maps projects and folders to the business once and attributes shared platform projects and unlabelled spend by rule, fixed, proportional, or usage-based, which is how allocation coverage typically rises from around 60 percent to 95 percent or higher within 30 days without a labelling project.

Monitor detects anomalies per project or team with a root-cause explanation, a BigQuery dashboard rescanning a table hourly, a GKE node pool that doubled, a Cloud SQL instance resized up and left there, and routes them to the owner's Slack channel, with budgets at project, folder, or organization level holding the result. Tickets turns each finding into an assigned item in Jira, ServiceNow, or Asana tracked to a measured saving, and Iris answers which projects grew fastest this month and why in plain English.

Proof: Purplle, more than $200,000 saved on GCP in one month

Purplle, India's largest online beauty and wellness store serving 4 million customers, moved its GCP operations from reactive firefighting to automated cost governance with Opslyft. Within minutes of integration, idle and underutilized resources across its projects were surfaced with their cost impact: unattached disks, low-CPU VMs, and unused compute clusters. More than $200,000 was saved in a single month with zero engineering bandwidth spent finding the waste. Read the full story: Purplle saves $200K on GCP in one month

On the allocation side, a leading fintech with a $40 million GCP estate cut unattributed cloud cost by 75 percent with the same project-structure inference, giving finance statements it could close on.

The Bottom Line

Google Cloud is well priced and generously discounted, and its project model is both the cleanest allocation structure in the cloud and the reason waste collects in corners nobody checks. Map every project to an owner, clear the idle resources that mapping exposes, right-size with real data, let sustained-use discounts do their automatic work and commit the baseline that remains, run interruptible work on Spot, and fix the service leaks in GKE requests, BigQuery scans, storage tiers, and egress. Done in that order the first month is usually the largest, which is what Purplle found. The general practice behind it is in our cloud cost optimization guide and our complete guide to cloud cost management; on GCP, the lever that makes it recur is a project with a name next to it.