Google Cloud Cost Optimization for Organizations

Mid market organizations on Google Cloud routinely waste 20 to 40 percent of their monthly bill. The waste is not from reckless decisions. It accumulates from compute instances that outlive their projects, BigQuery queries that scan full tables when they should scan partitions, and Cloud Storage sitting in the wrong class because no one set a lifecycle policy.

None of these show up as obvious line items. They grow quietly until someone pulls a cost report and wonders what happened.

This article covers where that waste lives for organizations spending under five million dollars annually on Google Cloud, how to use the billing tools Google provides to find it, and what a structured quarterly review looks like without a dedicated FinOps team.

The 5 Places Mid Market Organizations Lose Money on Google Cloud

Idle and over provisioned Compute Engine instances.

Development and test environments are the most common source of compute waste. Teams spin up VMs for a project, finish the work, and the instances keep running. The same pattern appears post-launch: servers sized for a traffic peak that never materialized, running at five percent utilization for months with no review scheduled.

BigQuery on demand query costs from full table scans.

BigQuery charges by the volume of data each query processes, not by how long the query runs. A query against an unpartitioned table with 500 GB of data charges for all 500 GB every time it executes, even if the analysis covers only one week of records. When queries like that run on a schedule, the costs compound fast.

Cloud Storage accumulation with no lifecycle policies.

Data that was once active does not automatically move to a cheaper storage class. Standard class costs roughly six cents per GB per month. Nearline drops to about one cent, Coldline to four tenths of a cent, and Archive to one tenth. Organizations that have never set a lifecycle policy pay Standard rates for data that has not been accessed in over a year.

Orphaned Dataflow pipelines and Pub/Sub subscriptions still running on schedule.

Pipelines built for a specific workload and then forgotten continue consuming resources. Pub/Sub subscriptions with no active consumers accumulate undelivered messages and keep charging. They do not fail loudly. They just run indefinitely.

Missing or inconsistent resource labels that prevent cost attribution.

Without labels, the billing dashboard cannot tell you which team, product, or workload generated a given cost. You can see total spend by service, but you cannot allocate it by owner. That makes it nearly impossible to hold teams accountable or make informed decisions about rightsizing.

How to Read the Google Cloud Billing Dashboard and Find What Matters

The billing console has three main views, and most organizations only use one of them.

The Billing Overview gives a summary of current and projected spend. It is useful for a quick check but does not reveal what is driving costs.

The Cost Table view is where analysis starts. It breaks spend down by project, service, and SKU. Sort by amount to see the top cost drivers, and filter by date range to compare billing periods.

If spend increased month over month, the Cost Table identifies which service changed and by how much.

The Cost Breakdown view adds a visual layer and is useful for spotting anomalies in spending patterns, but the Cost Table does more analytical work per minute spent on it.

The Reports section surfaces top spending services over time and shows month over month changes. Set the grouping to Service and look for anything that grew by more than 15 percent without a corresponding change in usage or project scope.

Budget Alerts are underused by most teams. Set a budget for each project with alert thresholds at 50, 90, and 100 percent of expected monthly spend. Alerts route to email and Pub/Sub, so they can trigger automated responses if needed. Without alerts, cost overruns are discovered after the billing cycle closes.

Billing Export to BigQuery gives analytical control over spend data. Once enabled, every billing event flows into a BigQuery dataset where you can write SQL queries, build Looker dashboards, and join cost data with operational metrics.

For organizations spending more than $50,000 per month on Google Cloud, the setup time pays back quickly in visibility and attribution accuracy.

BigQuery Cost Patterns That Quietly Drain Budget

BigQuery on demand pricing charges five dollars per terabyte scanned. That number looks manageable until a team writes a query that runs every hour against a 500 GB table with no partition filter.

At five dollars per terabyte, that query costs $2.50 per run and over $1,800 per month in scan charges, regardless of whether the output changes between runs.

Partition pruning is the mechanism that controls this. When a table is partitioned by date or another column, a query that includes a filter on that column only scans the relevant partitions.

A query against a date partitioned table with a filter set to seven days scans seven days of data, not the entire table. Without a matching partition column in the WHERE clause, BigQuery scans everything, every time.

Teams that have not reviewed their BigQuery usage often find that a small number of queries account for most of their monthly scan costs. The fix is usually adding a partition filter, not rewriting the query from scratch.

On demand pricing is the right model when query volume is low or unpredictable. When a team runs consistent, high volume analytics workloads, switching to capacity based pricing through slot reservations reduces cost and makes the bill predictable.

Slots are purchased as a block of processing capacity instead of paying per byte scanned. As a rough guide: if your on demand BigQuery bill consistently exceeds $5,000 per month, run the math on a slot reservation before your next billing cycle.

Before executing any large query, use the Query Validator built into the BigQuery console. It displays the estimated bytes processed before the query runs. The Dry Run API does the same thing programmatically. Both prevent cost surprises during ad hoc analysis.

When Committed Use Discounts Actually Pay Off

Google Cloud Committed Use Discounts reduce the cost of Compute Engine and Cloud SQL by 37 to 57 percent in exchange for a one year or three year commitment.

The one year discount lands around 37 percent; the three year discount approaches 57 percent. Both apply to a specific machine type and region. If the workload runs as committed, the savings are real. If it does not, the commitment still charges.

The right way to size a commitment is to pull 90 days of billing data and identify the compute baseline, meaning the resource level that runs consistently regardless of traffic variation. Commit to that baseline.

Use on demand pricing for everything above it. Committing before you understand your baseline is its own form of waste.

Committed Use Discounts are different from Sustained Use Discounts. Sustained Use Discounts are automatic: Google applies them when a VM runs for more than 25 percent of a billing month, with no action required and no contract.

Committed Use Discounts require a contract but deliver a deeper discount. Both can stack on the same workload.

Three categories of teams should not commit yet. Teams still in a period of active scaling, where instance types and counts are changing month over month, should wait until the architecture stabilizes.

Teams with workloads that spike unpredictably should rely on Sustained Use Discounts and on demand pricing for the variable portion. And teams running compute jobs that spin up and down within a billing cycle will not benefit from a commitment that assumes continuous usage.

How to Run a Quarterly Google Cloud Cost Review

A quarterly cost review does not require a FinOps specialist. It requires a cloud engineer or architect and a budget owner, typically the CTO, VP Engineering, or whoever owns the infrastructure line item. Two focused hours per quarter is enough with a consistent structure.

Four questions should anchor every review.

What changed?

Compare this quarter's spend to last quarter by service and by project. Any service that grew by more than 20 percent needs an explanation tied to a specific business change, not a shrug.

What is idle or orphaned?

Pull the list of Compute Engine instances, Dataflow pipelines, Pub/Sub subscriptions, and Cloud Storage buckets. Flag anything with no meaningful activity in the past 30 days.

Are labels complete?

Run a cost report grouped by label. Any spend showing as unlabeled represents cost that cannot be attributed to a team or workload. Fix the labeling gaps before the next review.

Are instance types and storage classes still matched to current usage?

An instance sized for peak load from six months ago may be over provisioned today. A Cloud Storage bucket that once held active pipeline output may now qualify for Coldline or Archive.

Google Cloud Recommender and Active Assist automate part of this work. Recommender surfaces idle VM recommendations, rightsizing suggestions, and unattached persistent disks.

Active Assist extends this to broader optimization opportunities across the project. Neither tool replaces the quarterly review, but both reduce the manual investigation time required to run it.

The right cadence: review billing alerts monthly to catch acute overruns, and run the full structural review quarterly.

The goal is not to cut spending for its own sake. It is to make sure every dollar on the invoice corresponds to something intentional.

If this review is overdue at your organization, or the team lacks the bandwidth to run it, Thessia's Cloud Cost and Performance Review Sprint delivers a full findings report and a prioritized action plan as a fixed fee engagement. You leave with a specific list of changes and the cost impact of each. Learn more at thessia.ai

Frequently asked questions

1. Where are we most likely wasting money on Google Cloud?

For mid-market organizations, Google Cloud waste usually hides in a few predictable places: idle or oversized Compute Engine instances, BigQuery queries that scan full tables, Cloud Storage buckets without lifecycle policies, orphaned Dataflow or Pub/Sub workloads, and missing resource labels that make spend hard to attribute. Thessia helps teams find these hidden cost drivers and turn them into a prioritized action plan instead of a vague “reduce cloud spend” initiative.

2. Do we need a dedicated FinOps team to control Google Cloud costs?

Not necessarily. Organizations spending under $5M annually on Google Cloud can often make meaningful progress with a structured quarterly review led by a cloud engineer or architect and a budget owner. Thessia’s approach focuses on practical cost governance: reviewing what changed, identifying idle resources, fixing labeling gaps, checking rightsizing opportunities, and making sure every major cost has a clear owner.

3. How can we reduce BigQuery costs without slowing down analytics?

BigQuery cost optimization often starts with query behavior, not platform replacement. Teams can reduce waste by using partition filters, checking estimated bytes processed before running large queries, reviewing scheduled queries that scan full tables, and evaluating slot reservations when on-demand query costs become predictable and consistently high. Thessia helps teams distinguish between useful analytics spend and avoidable query waste.

4. When do Google Cloud committed use discounts actually make sense?

Committed use discounts make sense when you have a stable compute baseline that is unlikely to change over the commitment period. Thessia recommends reviewing roughly 90 days of billing data before committing, then reserving only the predictable baseline while leaving variable or spiky workloads on demand. This prevents teams from locking into commitments that look like savings but become another form of waste.

5. How can Thessia help us lower Google Cloud spend without hurting performance?

Thessia’s Cloud Cost and Performance Review Sprint is designed to identify practical savings opportunities while protecting the systems the business depends on. The goal is not to cut cloud spend blindly. It is to find idle infrastructure, inefficient queries, wrong storage classes, missing labels, and misaligned commitments, then produce a prioritized list of changes with the expected cost impact of each.

Google Cloud Cost Optimization for Organizations Under $5M Annual Spend