GCP FinOps: Committed Use Discounts, Rightsizing, and Budget Controls

A startup burned through $200k in a single month because a single engineer left a GPU instance running over the holidays. No alerts, no budgets, no commitments. That's the cost of ignoring FinOps. GCP FinOps isn't just about saving money—it's about building a culture where every dollar spent on cloud infrastructure is justified and optimized. This article covers the three pillars that actually move the needle: Committed Use Discounts (CUDs), rightsizing, and budget controls. If you're not doing all three, you're leaving money on the table.

Committed Use Discounts: The Foundation of Cost Optimization

Committed Use Discounts (CUDs) are the single most effective lever for reducing GCP costs, offering up to 70% discount on compute resources in exchange for a 1- or 3-year commitment. They apply to vCPU, memory, and GPUs across Compute Engine, GKE, and Cloud SQL. The key is to base commitments on stable, predictable workloads—not speculative growth. Start with a 1-year commitment for baseline usage, then layer 3-year commitments for truly stable services. Monitor your commitments monthly to avoid over-committing, which can lead to wasted spend. Use the CUD analysis report in the billing console to identify idle resources that should be covered by commitments.

#!/bin/bash
# Analyze CUD coverage using gcloud
PROJECT_ID="my-project"
gcloud compute commitments list --project=$PROJECT_ID --format="table(name, region, type, status, endTimestamp)"
# Check coverage
bq query --use_legacy_sql=false \
  'SELECT resource_name, SUM(cost) AS total_cost
   FROM `my-project.billing_dataset.gcp_billing_export_v1_*`
   WHERE service.description = "Compute Engine"
   AND usage_start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
   GROUP BY resource_name
   ORDER BY total_cost DESC
   LIMIT 10'

Rightsizing: Matching Resources to Workloads

Rightsizing is the process of adjusting machine types, disk sizes, and other resources to match actual workload requirements. Over-provisioning is the most common waste: teams pick large instances 'just in case' and end up paying for unused capacity. Use the Rightsizing Recommendations in the GCP console, which analyze CPU, memory, and network utilization over the past 6 weeks. For compute, consider custom machine types to fine-tune vCPU-to-memory ratios. For disks, switch from pd-standard to pd-balanced or pd-ssd only if IOPS demand justifies it. Automate rightsizing with the Recommender API to apply changes during maintenance windows.

from google.cloud import recommender_v1
from google.cloud.recommender_v1 import types

client = recommender_v1.RecommenderClient()
project = "projects/my-project"
location = "locations/us-central1"
recommender = "google.compute.instance.MachineTypeRecommender"
parent = f"{project}/{location}/{recommender}"

request = types.ListRecommendationsRequest(parent=parent)
response = client.list_recommendations(request=request)

for rec in response.recommendations:
    print(f"Instance: {rec.primary_resource.name}")
    print(f"Recommendation: {rec.description}")
    print(f"Cost savings: {rec.primary_resource.cost_projection.cost}")
    print("---")

Budget Controls: Setting and Enforcing Spend Limits

Budget controls are the safety net of FinOps. Without them, a single misconfiguration can lead to runaway costs. GCP budgets allow you to set a spend limit and receive alerts at thresholds (e.g., 50%, 90%, 100%). But alerts alone aren't enough—you need automated actions. Use Pub/Sub notifications to trigger Cloud Functions that can stop non-critical instances, disable billing for sandbox projects, or send Slack alerts. For hard enforcement, set up budget-based IAM roles that revoke permissions when a budget is exceeded. Always create budgets at the project and folder level, and include all SKUs (compute, storage, network).

resource "google_billing_budget" "budget" {
  billing_account = "012345-ABCDEF-012345"
  display_name    = "Monthly Budget - Production"

  budget_filter {
    projects = ["projects/my-project"]
    credit_types_treatment = "EXCLUDE_ALL_CREDITS"
  }

  amount {
    specified_amount {
      currency_code = "USD"
      units         = "50000"
    }
  }

  threshold_rules {
    threshold_percent = 0.5
    spend_basis       = "CURRENT_SPEND"
  }
  threshold_rules {
    threshold_percent = 0.9
    spend_basis       = "CURRENT_SPEND"
  }
  threshold_rules {
    threshold_percent = 1.0
    spend_basis       = "CURRENT_SPEND"
  }

  all_updates_rule {
    pubsub_topic = google_pubsub_topic.budget_alerts.id
    schema_version = "1.0"
  }
}

resource "google_pubsub_topic" "budget_alerts" {
  name = "budget-alerts"
}

Combining CUDs with Rightsizing for Maximum Savings

CUDs and rightsizing are complementary: rightsizing reduces the baseline, and CUDs discount that baseline. The optimal approach is to rightsize first, then purchase commitments based on the new, lower usage. This avoids committing to resources you'll later downsize. Use the Recommender API to get rightsizing recommendations, apply them, then run the CUD analysis report to determine the new baseline. For GKE, use node auto-provisioning with committed use discounts on the node pool. Monitor the effective savings rate (ESR) to ensure you're getting the expected discount.

from google.cloud import recommender_v1
from google.cloud.recommender_v1 import types

# Step 1: Get rightsizing recommendations
client = recommender_v1.RecommenderClient()
parent = "projects/my-project/locations/us-central1/recommenders/google.compute.instance.MachineTypeRecommender"
request = types.ListRecommendationsRequest(parent=parent)
response = client.list_recommendations(request=request)

rightsized_usage = {}
for rec in response.recommendations:
    instance = rec.primary_resource.name
    recommended_type = rec.primary_resource.machine_type
    rightsized_usage[instance] = recommended_type
    print(f"Rightsize {instance} to {recommended_type}")

# Step 2: Calculate new baseline for CUD
# (Simplified: assume rightsizing reduces vCPU count by 50%)
total_vcpus = sum(rec.primary_resource.vcpus for rec in response.recommendations)
new_baseline = total_vcpus * 0.5
print(f"New CUD baseline: {new_baseline} vCPUs")

Automating Budget Enforcement with Cloud Functions

Budget alerts via Pub/Sub are only useful if they trigger actions. Cloud Functions can listen to Pub/Sub messages and execute remediation: stop instances, disable billing, or send Slack messages. The function receives a JSON payload with budget details. Parse it to determine the threshold and take appropriate action. For example, at 100% threshold, stop all non-production Compute Engine instances. Use labels to distinguish production vs. non-production. Always log the action for auditability. Test the function with a sample budget alert before deploying.

import base64
import json
import os
from google.cloud import compute_v1

def stop_non_prod_instances(event, context):
    """Cloud Function triggered by Pub/Sub budget alert."""
    pubsub_message = base64.b64decode(event['data']).decode('utf-8')
    alert = json.loads(pubsub_message)
    
    budget_amount = alert['budgetAmount']
    cost_amount = alert['costAmount']
    threshold = cost_amount / budget_amount
    
    if threshold >= 1.0:
        project = os.environ.get('GCP_PROJECT')
        client = compute_v1.InstancesClient()
        request = compute_v1.AggregatedListInstancesRequest(project=project)
        for zone, instances in client.aggregated_list(request=request):
            for instance in instances:
                if 'prod' not in instance.labels.get('env', ''):
                    stop_request = compute_v1.StopInstanceRequest(
                        project=project,
                        zone=zone.split('/')[-1],
                        instance=instance.name
                    )
                    client.stop(universe_domain='googleapis.com', request=stop_request)
                    print(f"Stopped {instance.name}")
    return "OK"

Using the Recommender API for Proactive Cost Optimization

The Recommender API provides proactive recommendations for rightsizing, CUDs, and idle resources. It analyzes usage patterns and suggests actions with estimated savings. Integrate it into your CI/CD pipeline to get recommendations on every deployment. For example, after a new service is deployed, run a recommender check to see if the machine type is optimal. Use the insights to create tickets in your project management tool. The API also supports custom recommenders for your own optimization logic.

from google.cloud import recommender_v1
from google.cloud.recommender_v1 import types

client = recommender_v1.RecommenderClient()
project = "projects/my-project"
location = "locations/us-central1"
insight_type = "google.compute.instance.IdleResourceInsight"
parent = f"{project}/{location}/{insight_type}"

request = types.ListInsightsRequest(parent=parent)
response = client.list_insights(request=request)

for insight in response.insights:
    print(f"Insight: {insight.description}")
    print(f"Severity: {insight.severity}")
    print(f"Recommendation: {insight.associated_recommendations}")
    print("---")

Managing Costs Across Multiple Projects with Folders and Labels

In large organizations, costs span multiple projects. Use folders to group projects by environment (e.g., dev, staging, prod) and apply budgets at the folder level. Labels provide granular cost allocation—tag resources with cost center, team, and application. Use the billing export to BigQuery for custom reporting. Create dashboards in Looker Studio to visualize spend by label. Enforce label policies with Organization Policies to ensure every resource has required labels. Without this structure, you can't attribute costs to the right team.

-- Query billing export to get cost by cost_center label
SELECT
  labels.key AS label_key,
  labels.value AS label_value,
  SUM(cost) AS total_cost
FROM `my-project.billing_dataset.gcp_billing_export_v1_*`
CROSS JOIN UNNEST(labels) AS labels
WHERE labels.key = 'cost_center'
  AND usage_start_time >= '2026-06-01'
  AND usage_start_time < '2026-07-01'
GROUP BY label_key, label_value
ORDER BY total_cost DESC;

FinOps Culture: Engineering Accountability and Showback

FinOps isn't just tools—it's culture. Implement showback by sending cost reports to engineering teams weekly. Use the billing export to attribute costs to specific services or features. Set up a cost optimization scorecard that tracks metrics like CUD coverage, rightsizing adoption, and budget compliance. Make cost a part of the code review process: require a cost impact assessment for any infrastructure change. Celebrate wins by sharing savings in team standups. Without cultural buy-in, even the best tools fail.

import pandas as pd
from google.cloud import bigquery

client = bigquery.Client()
query = """
SELECT
  service.description AS service,
  labels.value AS team,
  SUM(cost) AS total_cost
FROM `my-project.billing_dataset.gcp_billing_export_v1_*`
CROSS JOIN UNNEST(labels) AS labels
WHERE labels.key = 'team'
  AND usage_start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
GROUP BY service, team
ORDER BY total_cost DESC
"""
df = client.query(query).to_dataframe()
print(df.to_string(index=False))

Monitoring and Alerting on Cost Anomalies

Cost anomalies can indicate misconfigurations, security breaches, or unexpected usage spikes. Use the Cloud Billing budget alerts for threshold-based alerts, but also set up anomaly detection using BigQuery and Cloud Monitoring. For example, query the billing export for day-over-day cost changes > 20% and alert via email or Slack. Use the Log Analytics to detect unusual patterns like a sudden increase in network egress. Create a custom dashboard that shows cost trends and highlights anomalies. Respond to anomalies within 24 hours to minimize financial impact.

-- Detect daily cost spikes > 20% compared to 7-day average
WITH daily_costs AS (
  SELECT
    DATE(usage_start_time) AS usage_date,
    SUM(cost) AS daily_cost
  FROM `my-project.billing_dataset.gcp_billing_export_v1_*`
  WHERE usage_start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 14 DAY)
  GROUP BY usage_date
),
average_costs AS (
  SELECT
    usage_date,
    daily_cost,
    AVG(daily_cost) OVER (ORDER BY usage_date ROWS BETWEEN 7 PRECEDING AND 1 PRECEDING) AS avg_7_day
  FROM daily_costs
)
SELECT
  usage_date,
  daily_cost,
  avg_7_day,
  ROUND((daily_cost - avg_7_day) / avg_7_day * 100, 2) AS pct_change
FROM average_costs
WHERE daily_cost > avg_7_day * 1.2
ORDER BY usage_date DESC;

Optimizing Storage Costs with Lifecycle Policies

Storage costs can sneak up if you don't manage data lifecycle. Use Object Lifecycle Management to automatically transition objects to colder storage classes (Nearline, Coldline, Archive) based on age. For example, move logs older than 30 days to Coldline, and delete them after 365 days. For persistent disks, use snapshots and delete old ones. Use the Storage Insights to identify buckets with high costs and apply lifecycle rules. Always test lifecycle policies on a small subset first to avoid accidental data loss.

{
  "lifecycle": {
    "rule": [
      {
        "action": {
          "type": "SetStorageClass",
          "storageClass": "COLDLINE"
        },
        "condition": {
          "age": 30,
          "matchesStorageClass": ["STANDARD", "NEARLINE"]
        }
      },
      {
        "action": {
          "type": "Delete"
        },
        "condition": {
          "age": 365
        }
      }
    ]
  }
}

Network Egress Costs: The Hidden Drain

Network egress costs are often overlooked but can be significant, especially for data-heavy applications. GCP charges for data transfer out to the internet, to other cloud providers, and between regions. Use the billing export to identify top egress sources. Optimize by using Cloud CDN for content delivery, compressing data, and choosing the same region for services that communicate frequently. For inter-region traffic, use Premium Tier networking only when necessary. Consider using VPC peering instead of VPN for inter-project communication to reduce costs.

-- Top egress destinations by cost
SELECT
  TO_JSON_STRING(location.region) AS region,
  SUM(cost) AS egress_cost
FROM `my-project.billing_dataset.gcp_billing_export_v1_*`
WHERE service.description = "Cloud Networking"
  AND sku.description LIKE "%Egress%"
  AND usage_start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 30 DAY)
GROUP BY region
ORDER BY egress_cost DESC;

Putting It All Together: A FinOps Implementation Roadmap

Implementing FinOps is a journey. Start with visibility: set up billing export to BigQuery and create a cost dashboard. Then move to control: implement budgets with automated enforcement. Next, optimize: rightsize and purchase CUDs. Finally, sustain: build a culture of cost awareness and continuous improvement. Use the following roadmap: Month 1: Visibility (billing export, dashboard). Month 2: Control (budgets, alerts, Cloud Function). Month 3: Optimization (rightsize, CUDs). Month 4+: Culture (showback, anomaly detection). Track progress with metrics like CUD coverage, rightsizing adoption rate, and cost per unit of business value.

import datetime

roadmap = [
    {"month": 1, "phase": "Visibility", "actions": ["Set up billing export to BigQuery", "Create Looker Studio dashboard"]},
    {"month": 2, "phase": "Control", "actions": ["Create budgets at folder level", "Deploy Cloud Function for automated enforcement"]},
    {"month": 3, "phase": "Optimization", "actions": ["Run rightsizing recommendations", "Purchase CUDs based on new baseline"]},
    {"month": 4, "phase": "Culture", "actions": ["Implement showback reports", "Set up anomaly detection", "Create cost optimization scorecard"]}
]

for step in roadmap:
    print(f"Month {step['month']}: {step['phase']}")
    for action in step['actions']:
        print(f"  - {action}")

The FinOps Hub: Unified Cost Optimization Dashboard

GCP's FinOps hub provides a centralized dashboard for monitoring and optimizing cloud costs. It summarizes active savings from CUDs, rightsizing, and idle resource removal, and surfaces new recommendations. Key metrics: CUD optimization rate (percentage of CUD-eligible usage covered by commitments), potential savings per month (estimated savings from applying all recommendations), and the FinOps score (how well you follow Google Cloud cost optimization best practices—including monitoring, labeling, rightsizing, CUDs, budgets, and automation). The FinOps score is actionable: each component shows specific improvements you can make. The hub integrates with Recommender APIs to display recommendations for idle resources, rightsizing, and CUD purchases. Use it as your team's weekly cost review starting point. In production, we project the FinOps hub on a TV dashboard in the engineering office—it drives accountability and visibility. The Recommendations page within the hub provides detailed breakdowns with estimated savings, so engineers can prioritize high-impact changes.

# Enable FinOps hub by setting up billing export to BigQuery
# (Required for FinOps hub to work)
BILLING_ACCOUNT="012345-ABCDEF-012345"

gcloud billing accounts describe $BILLING_ACCOUNT

# Set up BigQuery export (prerequisite)
# FinOps hub is accessed via Google Cloud Console > Billing > FinOps hub
echo "Access at: https://console.cloud.google.com/billing/BILLING_ACCT/finops"

Spend Caps: Hard Cost Boundaries for AI and Serverless

Spend Caps are Google Cloud's newest cost control tool (announced at Next '26), enabling automated budget enforcement at the project level for AI Studio, Vertex AI Agent Platform, Cloud Run, Cloud Functions, and Maps. Unlike traditional budget alerts that require custom Cloud Function remediation, Spend Caps natively pause API traffic when a configured budget is reached—no custom code needed. Resources remain intact; traffic resumes when the cap is suspended or increased. This is critical for AI workloads where a single runaway training job can drain a budget in hours. Spend Caps integrate with existing GCP Budgets: set a budget, enable the cap, and select which services to enforce. The cap pauses API requests (not writes to existing resources), preventing cost surprises while preserving data. In production, use Spend Caps for development and sandbox projects where cost overruns are unacceptable. For production, use budget alerts with monitoring instead of hard caps to avoid blocking customer traffic.

resource "google_billing_budget" "ai_budget_with_cap" {
  billing_account = "012345-ABCDEF-012345"
  display_name    = "AI Experiment Budget - Hard Cap"

  budget_filter {
    projects = ["projects/ai-experiment-project"]
    services = ["AI Platform", "Cloud Run"]
  }

  amount {
    specified_amount {
      currency_code = "USD"
      units         = "5000"
    }
  }

  threshold_rules {
    threshold_percent = 1.0
    spend_basis       = "CURRENT_SPEND"
  }

  all_updates_rule {
    pubsub_topic = google_pubsub_topic.budget_alerts.id
    schema_version = "1.0"
  }
}

# Note: Spend Cap toggle is set in the Google Cloud Console UI
# under Billing > Budgets & alerts > Edit budget > Enable Spend Cap

AI Cost Visibility with FinOps Explainability Agent

AI costs are notoriously hard to attribute because they span multiple services and models. Google Cloud's FinOps Explainability agent (powered by Gemini) autonomously analyzes AI spend and answers natural language questions like 'How much did I spend on Gemini 1.5 Pro vs Gemini 1.5 Flash?' or 'Break down my total spend by API key.' It ingests billing data and surfaces cost drivers by model type, API key, project, and token type (input vs output). This is critical for AI FinOps because AI costs behave differently: specialized hardware (TPU/GPU) can drain budgets quickly, and experimentation patterns are unpredictable. The agent works alongside the FinOps hub to provide granular AI cost breakdowns. In production, use the agent weekly to review AI spend trends and identify anomalously expensive model versions or API keys. Integrate with Slack to auto-post AI cost summaries to engineering teams.

# Access FinOps Explainability agent via Cloud Console
# Billing > FinOps hub > AI Cost Visibility > Explainability

# Example queries the agent can answer:
# - "Show me spend by model version for last 7 days"
# - "Which API key has the highest cost?"
# - "What is the input vs output token cost split?"
# - "Compare Gemini 2.0 Pro and Gemini 2.0 Flash costs"

# Query billing export directly
bq query --use_legacy_sql=false \
  'SELECT
    service.description,
    sku.description,
    SUM(cost) AS total_cost
  FROM `my-project.billing_dataset.gcp_billing_export_v1_*`
  WHERE service.description LIKE "%AI%"
    OR service.description LIKE "%Vertex%"
    OR service.description LIKE "%Gemini%"
  GROUP BY service.description, sku.description
  ORDER BY total_cost DESC
  LIMIT 20'

Spend-Based CUD Model Update: Direct Discount Pricing

In July 2025, Google Cloud updated spend-based CUDs from a credit-based system to a direct discounted price model. Previously, you paid on-demand rates and received credits for the discount. Now, you commit to a net discounted spend amount and are billed at the discounted rate directly—no credit math required. The new CUD Analysis tool provides hourly granularity (vs daily averages), revealing underutilization spikes that daily data hides. Coverage now includes Cloud Run, Cloud Run Functions, H3, and M-series VMs. Key improvements: unified CUD Analysis tool for auditing both old and new models, spend-based CUD metadata export for programmatic analysis, and scenario modeling with adjustable coverage thresholds and lookback windows up to 180 days. For FinOps teams, the practical impact is simpler math: net cost = committed amount × discounted rate, no credit reconciliation. Use the CUD Analysis tool to verify migration and compare pre/post savings. Always migrate old credit-based CUDs to the new model to simplify reporting.

# Analyze CUD coverage with hourly granularity (new model)
# Access via Billing > Committed Use Discounts > CUD Analysis

# Query via BigQuery billing export
bq query --use_legacy_sql=false \
  'SELECT
    TIMESTAMP_TRUNC(usage_start_time, HOUR) AS hour,
    SUM(cost) AS net_cost,
    SUM(IF(sku.description LIKE "%Commitment%", 0, cost)) AS on_demand_equivalent
  FROM `my-project.billing_dataset.gcp_billing_export_v1_*`
  WHERE service.description = "Compute Engine"
    AND usage_start_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  GROUP BY hour
  ORDER BY hour
  LIMIT 168'