The bill went up. Nobody knows why.

The application is healthy. Traffic is roughly where you expected it to be. Nobody remembers launching a giant new environment. Then the monthly cloud number lands in a meeting and it is 28% higher than last month.

Finance asks engineering what changed. Engineering opens Cloud Billing. Somebody sorts by service. Somebody else checks Compute Engine. A third person says, “Maybe it is BigQuery.” Twenty minutes later, everyone has more screenshots and almost nobody has an answer.

To explain the increase, connect each charge to a resource, a workload, and an owner. Then compare the cost with the work that resource performed. That is the starting point for the FinOps process in this guide.

Cost visibility comes before cost optimization

The first FinOps question is rarely “What should we resize?” It is “What are we actually paying for?”

Google Cloud gives you several layers of visibility. Billing Reports are useful for fast investigation. FinOps Hub brings savings, recommendations and utilization insights together. Billing export to BigQuery becomes valuable when you want your own allocation model, trend analysis or unit-cost reporting.

A useful allocation model starts simple

• Project: which application or platform owns the resource?
• Environment: production, QA, development or sandbox?
• Team: who is expected to act when spend moves?
• Cost centre / product: where should the spend ultimately be attributed?
• Workload: what customer or internal capability is the resource supporting?

Labels and resource hierarchy help, but they only work when teams treat them as operational data rather than decoration. “unlabeled” is not a useful business owner.

SELECT
  service.description AS service,
  ROUND(SUM(cost), 2) AS gross_cost
FROM `billing-project.billing_dataset.gcp_billing_export_v1_XXXXXX_XXXXXX_XXXXXX`
WHERE usage_start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY service
ORDER BY gross_cost DESC;

That query is intentionally basic. It is useful for investigation, not invoice reconciliation; real chargeback or showback usually needs credits, discounts, labels, hierarchy and the detailed export handled properly.

A big bill does not tell you whether you are efficient

Imagine two teams. Team A spends $100,000 a month and supports ten million dollars of revenue. Team B spends $50,000 and supports a product generating half a million. Which one is better optimized?

You cannot answer from cloud spend alone. The more useful question is what each unit of business value costs.

Once you have a unit metric, growth stops looking automatically bad. If cloud spend rises 20% while completed orders rise 45%, the economics may actually be improving. FinOps gives you a language for that conversation.

Find the waste nobody owns

Every cloud estate accumulates resources that made sense when they were created and became invisible afterwards. A temporary VM outlives the incident. A development database quietly becomes permanent. A disk remains after its VM is gone. A logging configuration that was useful for troubleshooting stays verbose for six months.

• idle or underused virtual machines
• unattached or oversized persistent disks
• overprovisioned Cloud SQL instances
• GKE workloads with inflated CPU or memory requests
• forgotten development and test environments
• load balancers, IPs or snapshots with no clear owner
• excessive logging, retention or data-processing patterns
• resources created outside the normal ownership and labeling model

FinOps Hub currently consolidates optimization recommendations around areas such as idle resources, rightsizing, configuration changes and committed use discounts. Its utilization insights can also surface potential wasted usage across services including Compute Engine, GKE, Cloud Run and Cloud SQL.

Rightsizing is not “make everything smaller”

A VM averaging 20% CPU is not automatically 80% too large. Maybe it is memory-bound. Maybe it absorbs a sharp morning peak. Maybe the application starts slowly and that headroom is intentional. Or maybe it really is five times bigger than it needs to be.

Utilization
   +
Peak behaviour
   +
Availability requirement
   +
Application characteristics
   =
Rightsizing decision

Use utilization alongside latency, memory pressure, traffic peaks, and reliability targets before changing resource sizes.

Compare GKE Resource Requests With Usage

Kubernetes introduces a second version of reality: what the container uses, and what the scheduler believes it needs.

resources:
  requests:
    cpu: "4"
    memory: "8Gi"
  limits:
    cpu: "6"
    memory: "10Gi"

Observed during representative load
CPU:    ~450m average, ~900m peak
Memory: ~1.6 GiB average, ~2.3 GiB peak

Those numbers do not tell you to immediately cut the request to 500m and 2Gi. They tell you there is a conversation worth having. Requests affect scheduling and therefore cluster capacity. If every team adds “just in case” headroom, the cluster autoscaler may be provisioning nodes for capacity that applications rarely use.

• compare requests with observed CPU and memory over representative windows
• look at peak behaviour, not only averages
• understand HPA signals before changing requests
• separate workload rightsizing from node-pool rightsizing
• verify disruption and availability requirements before shrinking capacity
• measure the result after the change

The useful FinOps question is not “How do I make this pod cheaper?” It is “What capacity does this workload genuinely need to meet its SLO?”

Review Cloud Run Billing and Scaling Settings

Serverless removes much of the node-management discussion, but it does not remove economics. The knobs simply change.

• CPU and memory allocation
• request-based versus instance-based billing
• minimum and maximum instances
• concurrency
• region and network traffic
• startup characteristics and execution duration

Google currently recommends choosing billing mode and resource settings based on the traffic pattern rather than assuming one configuration is universally cheaper. Higher concurrency can let fewer instances handle the same load, but the application must actually tolerate parallel work efficiently. Maximum instances can also act as a useful cost-safety baseline.

Match Committed Use Discounts to Predictable Usage

Commitments are powerful because stable demand is valuable to a cloud provider. They are dangerous for exactly the same reason: you are making a prediction about future consumption.

On-demand baseline          $100k / month
Discounted committed spend  $70k / month

Looks great — if the committed usage is actually consumed.

A discount applied to unused capacity is still waste. Mature FinOps separates rate optimization from usage optimization. First understand the steady baseline. Then decide how much of that baseline deserves a commitment.

Google completed changes to its spend-based CUD model in 2026, including a direct discounted-price model for covered usage and expanded coverage. That makes the reporting easier to reason about, but it does not remove the forecasting problem.

Choose Budget Alerts and Spending Controls

Traditional budget alerts are visibility tools. A threshold is crossed, an email arrives, and then a human has to decide whether anything should happen.

Budget threshold
      ↓
Alert
      ↓
Investigation
      ↓
Owner decision
      ↓
Action

That is still useful—especially when the owner and escalation path are clear. But the 2026 Google Cloud Billing controls go further in selected areas. Google introduced early anomaly detection for AI services and spend-cap budgets for eligible services, where enforcement can pause supported service usage when the cap is reached.

That does not mean every workload should have a hard cap. Stopping a production service can be more expensive than the cloud spend you avoided. FinOps needs risk context as much as it needs thresholds.

Cost anomalies: find the problem before the invoice does

A monthly invoice is a terrible monitoring system. By the time it tells you something went wrong, the expensive behaviour may have been running for weeks.

Normal daily spend
$1,820
$1,910
$1,875
$1,930

Tuesday
$7,420

An anomaly might be legitimate growth. It might also be a runaway job, accidental scale-out, unexpected network egress, a logging explosion, a forgotten performance test, compromised credentials, or an AI loop making far more calls than designed.

Cloud Billing now surfaces anomalies against historical spending patterns, and Google is increasingly connecting those signals with AI-assisted investigation. The value is not that a model magically understands your business; it is that the time from “something changed” to “here is where to look” becomes shorter.

AI makes FinOps harder—and more important

A traditional web request often has a fairly visible resource path. An agentic request can fan out.

User request
   ↓
Agent
   ├─ model call
   ├─ tool invocation
   ├─ retrieval
   ├─ another model call
   ├─ downstream agent
   └─ final response

That is why “cost per request” can become almost meaningless for AI. A better measure may be cost per resolved support case, cost per generated document, cost per successful agent task, or cost per approved transaction.

Google Cloud Billing now includes AI-specific cost analysis capabilities, including an AI Cost Summary Agent for Google Cloud AI services and AI-driven forecasts. In 2026 Google also introduced more proactive AI-spend controls. The tooling is moving in the right direction, but the engineering model still has to define what a successful unit of AI work actually is.

Gemini Cloud Assist can shorten the investigation loop

There is a practical difference between asking AI to “reduce my cloud bill” and using it to help navigate a complicated cost dataset.

In current Cloud Billing, Gemini Cloud Assist can help summarize cost reports, highlight cost drivers, surface FinOps Hub optimization and utilization insights, and help teams investigate where wasted usage is concentrated. Google also exposes natural-language cost and utilization questions through Cloud Assist experiences.

That is useful because FinOps investigation is often a search problem: which service moved, which project caused it, which resource is inefficient, and what changed around the same time? AI can make that search faster. It should not silently become the approval authority for deleting production resources.

FinOps automation should grow in layers

A lot of teams jump from spreadsheets straight to “autonomous optimization.” That skips the hard part: agreeing on what safe optimization means.

Level 1  Visibility
         Reports + billing export

Level 2  Accountability
         owners + budgets + alerts

Level 3  Optimization
         rightsizing + commitments + waste removal

Level 4  Guardrails
         policies + approved automated actions

Level 5  Continuous FinOps
         measure → optimize → verify → learn

• automatically stop known non-production environments outside working windows
• flag unlabeled or unowned resources
• route anomalies to the owning team
• create tickets from approved recommendation classes
• enforce budget or quota guardrails where service risk allows
• automate remediation only when rollback and ownership are clear

Automate repetitive checks while keeping people responsible for exceptions, production changes, and cost-versus-reliability decisions.

The FinOps operating loop

FinOps works best when it is treated as a recurring engineering loop rather than a quarterly cleanup event.

INFORM
Understand spend and ownership
      ↓
OPERATE
Budgets, allocation, accountability
      ↓
OPTIMIZE
Rightsize, remove waste, improve rates
      ↓
MEASURE VALUE
Unit economics and outcomes
      ↓
REPEAT

A one-time optimization project almost always regresses because the platform keeps changing. New services arrive. Traffic patterns shift. Teams launch experiments. Pricing models evolve. FinOps has to move at roughly the same speed as engineering.

Who owns cloud cost?

Finance, platform engineers, and application teams share responsibility for cloud cost.

• Finance understands budgets, forecasts, commitments and financial accountability.
• Engineering understands what the resource is doing and what breaks if it changes.
• Platform / Cloud teams build the allocation model, guardrails and optimization tooling.
• Product understands whether the spend is creating customer or business value.
• Leadership decides which trade-offs are worth making.

FinOps is the operating model that lets those perspectives meet around the same data. When cloud cost lives only in a finance spreadsheet, engineers see it too late. When it lives only in an engineering dashboard, nobody connects it to business outcomes.

A practical 30-day FinOps playbook

If you are starting from “we have a bill and some dashboards,” do not attempt to implement every FinOps practice in the first week.

Week 1 — Make the spend explainable

• confirm billing-account and project hierarchy
• enable the billing exports you need
• define the minimum labeling / ownership standard
• identify the top services, projects and cost changes

Week 2 — Find obvious waste

• review FinOps Hub recommendations and utilization insights
• identify idle resources and stale environments
• compare major GKE requests with observed use
• review Cloud Run scaling, memory, CPU and concurrency for expensive services

Week 3 — Put owners around the numbers

• assign budgets and anomaly-routing paths
• define which team owns each major cost area
• agree on a small set of unit-cost metrics
• separate one-time growth from recurring waste

Week 4 — Optimize safely

• rightsize the highest-confidence opportunities
• review commitment coverage only after rightsizing
• automate low-risk non-production savings
• measure performance and cost after every meaningful change

Keep Cost Decisions Traceable

The goal of FinOps is not to make your Google Cloud bill as small as possible.

Some workloads should become smaller. Some should disappear. Some should move to a different pricing model. And some should cost more next month because they are serving twice as many customers or doing something genuinely valuable.

Good FinOps gives engineering enough visibility to know the difference. It replaces “Why is this bill so high?” with better questions: Who owns the change? What unit of value increased? Is the capacity intentional? What can we optimize without damaging reliability?

Review cost changes regularly with workload owners. Record the reasons for capacity decisions and check whether each optimization delivered the expected savings without reducing reliability.

Official Google Cloud references

Google Cloud billing and FinOps capabilities evolve quickly. These are the current references used while reviewing this article:

• FinOps Hub — savings, recommendations, CUD metrics and utilization insights.
• Cloud Billing export to BigQuery — standard, detailed, pricing and CUD metadata exports.
• AI-powered Cloud Billing features — AI cost summaries, forecasts and Gemini-assisted FinOps insights.
• Cloud Run cost optimization — billing mode, scaling, concurrency and resource sizing guidance.
• Updated spend-based CUD model — 2026 guidance for FinOps teams.
• Early anomalies and spend caps — newer cost controls for supported AI services and eligible workloads.