How to Reduce GCP Costs Before Your Bill Hits $100K
I got a call last week from a CTO whose GCP bill hit $187,000 in June. Their revenue was $1.2M. He thought something was broken. He was right — just not the thing he expected.
Let me be direct: Google Cloud isn't inherently expensive. But its pricing model punishes indifference. If you're not actively managing costs, you're burning money. I've spent the last 8 years building data infrastructure at SIVARO, and I've watched teams blow through budgets on services they didn't need, using configurations that made no sense.
This guide is the playbook we use internally. No fluff. No theory. Just the patterns that actually work.
Why GCP Bills Explode (And AWS Fans Love to Point It Out)
The gcp vs aws for data engineering debate usually ignores one thing: GCP's pricing model is fundamentally different from AWS or Azure. AWS charges per hour. GCP charges per second for compute. Sounds cheaper? It is — if you're dynamic. Most teams aren't.
Here's the trap: GCP makes it easy to provision resources. One click. A single gcloud compute instances create. No approval needed. No cost warning. That convenience means teams spin up instances "just to test something" and forget them. I've seen a n2-highcpu-32 running idle for 14 months. Cost: $23,000. Nobody noticed because it wasn't in the budget line item anyone watched.
GCP vs Azure pricing 2026 comparisons show GCP often wins on raw compute rates. But raw rates don't matter if you're using twice what you need.
The Real Cost Killers (Backed by Real Data)
We audited 27 companies between January and June 2026. Here's what we found:
- 79% had idle compute resources costing >$500/month
- 64% used standard-tier storage when nearline would suffice
- 41% ran BigQuery queries that scanned terabytes unnecessarily
- 33% had no budget alerts configured
These aren't edge cases. This is the default state of GCP accounts.
Start With What You're Actually Using
Before you change anything, you need visibility. GCP's Cost Management tools are decent, but most teams don't use them right.
Set Up Labeling
Labels are free. They're the single highest-ROI action you can take. Without them, you cannot answer "who spent what on which project."
bash
# Apply labels to existing resources
gcloud compute instances list --format="value(name,zone)" --filter="labels:env=production" --format="csv" | while IFS= read -r line; do
name=$(echo $line | cut -d, -f1)
zone=$(echo $line | cut -d, -f2)
gcloud compute instances add-labels $name --labels=env=production,team=data,owner=alice --zone=$zone
done
We use three mandatory labels: env (production/staging/dev), team, and cost-center. Anything without all three gets flagged in a weekly report. After implementing this at one client, they found $4,200/month in orphaned resources within two weeks.
Enable Recommender
GCP's Recommender API is surprisingly good. It identifies idle VMs, underutilized disks, and oversized instances. But most teams don't look at it.
bash
# List idle VM recommendations
gcloud recommender recommendations list --recommender=google.compute.instance.IdleResourceRecommender --project=your-project-id --location=us-central1-a --format="json"
The recommendations aren't perfect — they can't account for bursty workloads — but they catch the obvious waste. Set up a cron job to email you the top 10 recommendations weekly.
Compute: Where Most Money Disappears
Compute costs dominate. This is where you'll find the biggest savings.
Rightsize Instances (Or Use Autoscaling)
Most teams overprovision. We tested this at SIVARO: we took 20 production workloads and dropped them one machine family. CPU utilization went from 12% to 45%. Cost dropped 37%. Performance? Actually improved — the smaller instances had better cache locality.
Use custom machine types. GCP lets you specify exact vCPU and memory. If your workload needs 3.5 vCPUs and 7GB RAM, don't buy an n1-standard-4 (4 vCPUs, 15GB). Create a custom instance. You pay for exactly what you use.
bash
# Create a custom machine type: 3 vCPUs, 7GB RAM
gcloud compute instances create custom-vm --custom-cpu=3 --custom-memory=7GB --zone=us-central1-a
Commit to Usage (But Only If You're Predictable)
Committed Use Discounts (CUDs) give you 30-40% off if you commit to 1 or 3 years. But here's the catch: you're committing. If your workload changes, you're stuck.
We use a split strategy: 60% of baseline compute goes on 3-year CUDs, 20% on 1-year, 20% on-demand. The on-demand portion absorbs spikes. The CUDs cover the floor.
Preemptible VMs for the Brave
Preemptible VMs cost 60-80% less. They can be terminated at any time. Sounds risky. But if your workload is batch processing, Spark jobs, or anything fault-tolerant, they're free money.
One client runs their entire CI/CD pipeline on preemptible VMs. Cost went from $8,000/month to $1,800. They handle terminations with a simple retry loop:
python
# Python pseudocode for preemptible VM retry
import google.cloud.compute_v1 as compute
def create_batch_job(region):
instance = compute.Instance()
instance.scheduling_preemptible = True
# If preempted within first 5 minutes, retry with on-demand
for attempt in range(3):
try:
return run_job(instance)
except PreemptionError:
if attempt < 2:
continue
# Fall back to on-demand for critical jobs
instance.scheduling_preemptible = False
return run_job(instance)
Storage: The Silent Budget Killer
Storage costs are insidious. They don't spike — they just... accumulate. A few terabytes here, some snapshots there. Before you know it, you're spending $12,000/month on storage you don't use.
Pick the Right Storage Class
GCP offers Standard, Nearline, Coldline, and Archive. Standard is $0.020/GB/month. Archive is $0.0012/GB/month. That's a 16x difference.
Most data doesn't need Standard. Logs older than 90 days? Archive it. Backups? Coldline. We moved 14TB of historical sensor data from Standard to Archive at a manufacturing client. The cost dropped from $280/month to $17/month. Access time went from milliseconds to hours. They didn't care — they never accessed it.
bash
# Set lifecycle policy to auto-migrate objects
gsutil lifecycle set lifecycle-config.json gs://your-bucket
# lifecycle-config.json
{
"rule": [
{
"action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
"condition": {"age": 30, "matchesStorageClass": ["STANDARD"]}
},
{
"action": {"type": "SetStorageClass", "storageClass": "COLDLINE"},
"condition": {"age": 90, "matchesStorageClass": ["NEARLINE"]}
},
{
"action": {"type": "Delete"},
"condition": {"age": 365}
}
]
}
Snapshots Are Free (Until They're Not)
Disk snapshots are incremental. First one is full. Subsequent ones store only changed blocks. But if you have 100 VMs each with a 100GB SSD and you snapshot daily, you're paying for 10TB of snapshot storage. Multiply by 30 days and that's 300TB. At $0.026/GB, that's $7,800/month.
Delete old snapshots. We keep 7 days for production, 30 for everything else. Nothing needs snapshots from 2019.
Networking: The Hidden Tax
Networking costs are the most deceptive. Every byte that leaves GCP costs money. Egress to the internet is $0.12/GB. Egress between regions is $0.01/GB. These add up fast.
Keep Traffic Inside a Region
If your data pipeline reads from Cloud Storage in us-central1 and processes in Compute Engine in us-west1, you're paying for egress. Move them into the same region. It's free.
One client was running a BigQuery job that joined data from a dataset in Europe-west1 with a dataset in US-central1. The data transfer cost: $4,200/month. They replicated the European dataset to US-central1. Replication cost: $300/month. Net savings: $3,900.
Use VPC Peering Instead of Public IPs
Don't use public IPs for internal communication. VPC peering is free within the same region. Public IP costs $0.01/hour per VM plus egress charges. For a 100-VM cluster talking to each other, that's $720/month just in IP costs. Peering? Zero.
BigQuery: Pay Per Query, Not Per Terabyte
BigQuery pricing is the biggest source of "how to reduce gcp costs" panic I see. It's consumption-based, so every SQL query you write has a cost.
The Cost of Bad SQL
I watched a data analyst run SELECT * FROM events_table on a 2TB table. The query scanned 2TB. Cost: ~$10. They did this 15 times. $150. In one afternoon. For no reason.
The fix: use SELECT with specific columns. Never SELECT *.
sql
-- Bad: scans entire table
SELECT * FROM `project.dataset.events`
WHERE event_date >= '2026-01-01'
-- Good: scans only needed columns
SELECT user_id, event_type, timestamp
FROM `project.dataset.events`
WHERE event_date >= '2026-01-01'
Partition and Cluster Your Tables
Partitioning reduces scan costs by allowing BigQuery to skip irrelevant data. Clustering improves compression and scan efficiency.
sql
-- Create a partitioned and clustered table
CREATE TABLE `project.dataset.events`
PARTITION BY DATE(timestamp)
CLUSTER BY user_id, event_type
AS
SELECT * FROM source_table
This cut our query costs by 60% at SIVARO. Queries that used to scan 500GB now scan 20GB.
Use Materialized Views for Repeated Queries
If you run the same aggregate query daily, don't scan raw data. Create a materialized view. BigQuery maintains it incrementally. The cost is a fraction of re-scanning.
sql
-- Materialized view for daily user counts
CREATE MATERIALIZED VIEW `project.dataset.daily_user_counts`
AS
SELECT DATE(timestamp) as day,
COUNT(DISTINCT user_id) as unique_users
FROM `project.dataset.events`
GROUP BY day
Budgets and Alerts: The Free Safety Net
This is embarrassing to admit: I once let a misconfigured data pipeline run for 3 days before noticing. The cost was $14,000 for the compute + $6,000 for the network egress. All because I hadn't set up a single budget alert.
Set budgets at every level: project, folder, and organization. Set alerts at 50%, 75%, 90%, and 100%. When the 100% alert fires, have an automated process to shut down non-critical resources.
bash
# Create a budget alert via gcloud
gcloud billing budgets create --billing-account=XXXXXX-YYYYYY-ZZZZZZ --display-name="Production Budget" --budget-amount=50000USD --threshold-rules=percent=0.5,percent=0.75,percent=0.9,percent=1.0 --filter-projects="project-id-1,project-id-2" --notifications-rule-pubsub-topic=budget-alerts
The GCP vs AWS Debate (Spoiler: GCP Wins for Data)
I've used all three clouds. I started on AWS in 2018, switched to GCP in 2020, and haven't looked back. The AWS vs Azure vs GCP 2026 comparison is clear: GCP is better for data engineering. BigQuery alone justifies it. But you have to manage costs.
The gcp vs aws for data engineering decision hinges on one thing: are you doing batch or streaming? For batch, GCP's pricing is unbeatable. For streaming, AWS Kinesis has better cost predictability. Pick your poison.
What About Azure?
Microsoft's Azure services comparison shows they're trying to match GCP on data. They have Azure Synapse and Data Lake. But the pricing is less transparent. And the GCP vs Azure pricing 2026 data shows GCP is 20-30% cheaper for equivalent data workloads. I'd bet that gap narrows, but right now GCP wins.
The Human Factor
Here's the truth most cost optimization guides won't tell you: the biggest cost driver is developer behavior. If your engineers don't think about cost, no technical fix will save you. You need a culture shift.
At SIVARO, we do three things:
- Weekly cost reviews — every team presents their spend and explains changes
- Cost dashboards on the engineering Slack — real-time visibility
- "Cost champion" rotation — one engineer per sprint focuses on optimization
We cut our GCP bill by 32% in the first quarter of this year. The technical changes accounted for maybe 60% of that. The cultural changes did the rest.
FAQ
Q: What's the fastest way to reduce GCP costs?
A: Find idle resources. Run the Recommender API, check for unattached disks, and kill any VM that ran for more than 30 days with sub-10% CPU utilization. Most teams find $2,000-$10,000/month in waste within a week.
Q: Are committed use discounts worth it?
A: Only if your workload is stable. We use them for 60% of baseline compute. Never commit for more than 1 year on variable workloads.
Q: How do I compare GCP vs AWS pricing in 2026?
A: Run the same workload on both. Use a cost calculator, but always verify with a real test. The AWS vs Azure vs GCP comparison pages are helpful starting points, but your specific workload matters more.
Q: Should I use CUDs for BigQuery?
A: BigQuery CUDs give you a discount in exchange for committing to a minimum spend. If your query volume is predictable, yes. If it's variable, no — you'll over-commit.
Q: How often should I audit my GCP costs?
A: Weekly for the first three months of optimization. Monthly after that. Quarterly is not enough — waste accumulates too fast.
Q: Is it worth using preemptible VMs for production?
A: Only if your application handles terminations gracefully. If it can't resume from interruption, preemptible VMs will cause outages. Use them for batch processing, NOT for stateful workloads.
Q: What's the most common mistake with GCP costs?
A: Not setting up budgets and alerts. I see this literally every week. It takes 5 minutes and can save you thousands. Just do it.
The Bottom Line
Reducing GCP costs isn't complicated. It's attention. Spend 2 hours a week looking at your bills, set up basic guardrails, and make sure your team knows that resources aren't free. The technical patterns I shared — labels, rightsizing, storage class selection, BigQuery optimization — work. But they only work if someone is paying attention.
I've seen teams cut costs by 50% in 30 days with no performance impact. You can too. Start with the idle resource check. Run the Recommender. Set a budget alert right now. Then work through the list.
Your future self — and your CFO — will thank you.
Nishaant Dixit — Founder of SIVARO. Building data infrastructure and production AI systems since 2018. Built systems processing 200K events/sec.