Cost Optimization

Cloud cost is not a technical problem; it is an operational discipline. The same workload can cost a factor of ten more or less depending on which services it runs on, how those services are configured, and how their consumption is monitored. The eleven previous chapters introduced fifty-one services; almost every one of them has a pricing dimension that can dominate the bill if ignored. This topic is about the practices that keep cost under control as an ongoing engineering activity, not as an end-of-quarter panic.

The single most important principle: cost engineering is continuous, not episodic. Teams that "do a cost optimization sprint" once a year save 30% temporarily, then watch the bill creep back up over the next twelve months. Teams that wire cost visibility into normal operations — the bill is on the dashboard, the budget alerts are wired to the on-call rotation, the per-environment tags are required — save 30% permanently and never need the panic sprint.

Pricing Models

GCP services fall into a small set of pricing shapes. Knowing which shape applies to which service is half the battle. Compute services usually price by time and size: Compute Engine charges per second for the machine type; Cloud Run charges per request and per vCPU-second of execution time when the container is active. Managed databases price by storage plus compute: Cloud SQL bills the instance hour and the storage GB; Spanner bills processing units and storage; BigQuery bills storage at one rate, queries either by scanned bytes (on-demand) or by slot-hour (capacity-based).

Cloud Storage has three dimensions: storage by GB-month at a rate that varies by class (Standard, Nearline, Coldline, Archive), operations by count (Class A for writes/lists, Class B for reads), and egress when bytes leave the bucket. Pub/Sub bills by bytes published and delivered. Cloud Load Balancing charges for forwarding rules and processed bytes. The bill is the sum of these dimensions across every resource you own.

Three pricing levers cut spend dramatically without changing the architecture: committed use discounts (CUDs) for steady-state compute, where a 1- or 3-year commitment saves 25–55% on Compute Engine, Cloud Run, GKE, Cloud SQL, and Spanner; sustained use discounts applied automatically to Compute Engine instances that run a large fraction of the month; and Spot VMs for fault-tolerant workloads, which cost 60–91% less than on-demand at the price of preemption. The right mix usually has CUDs covering the baseline and on-demand or Spot absorbing the peaks.

Right-Sizing and Auto-Scaling

A right-sized resource is one whose capacity matches the actual demand, not the demand someone imagined at provisioning time. The default failure mode is over-provisioning — picking a four-vCPU VM because it might be needed, watching it run at 8% utilization, paying for the other 92% forever. The Active Assist recommender in Cloud Console surfaces oversized Compute Engine instances and idle resources continuously; the fix is usually a single command.

Auto-scaling does right-sizing automatically for workloads that fit it. Cloud Run scales from zero to thousands of containers in seconds; you pay only for the requests served. GKE Autopilot scales nodes against pod resource requests; idle namespaces cost nothing because no nodes are running for them. The discipline is to set the right resource requests, not just limits — requests drive scheduling and node count, limits only prevent runaway containers.

Schedule non-production environments. A staging environment that runs at full capacity overnight and over the weekend costs the same as production while delivering zero value during those hours. Cloud Scheduler triggering Cloud Functions that scale down GKE node pools or shut down Compute Engine instances during off hours typically cuts non-prod spend by 60–70%.

Storage Tiering

Cloud Storage's four classes have dramatically different costs per GB-month: Standard is the baseline; Nearline is roughly half; Coldline is roughly a quarter; Archive is roughly an eighth. The cost of retrieval climbs in the opposite direction — pulling from Archive costs more than pulling from Standard, and Archive has a minimum 365-day storage duration with early-deletion fees. The right placement is the one where the cumulative storage savings outweigh the retrieval cost over the data's expected lifetime.

Object Lifecycle Management automates the tiering. A rule like "transition objects older than 30 days to Nearline, older than 90 days to Coldline, older than 365 days to Archive, delete after 7 years" runs continuously without any per-object code. The same mechanism deletes old object versions in a versioned bucket, which prevents the silent accumulation of cost from soft-deleted data.

For block storage, the equivalent discipline is to delete snapshots and unattached Persistent Disks. Orphan disks from deleted VMs are one of the most common sources of slow-growing waste; a weekly Cloud Asset Inventory query surfaces them. Filestore has minimum capacity floors per tier — the Basic tier starts at 1 TB; allocating 2 TB "to be safe" doubles a fixed cost that does not auto-scale down.

Egress and Network Costs

Network egress is the most overlooked cost dimension. Intra-zone traffic is free; cross-zone traffic in the same region is cheap; cross-region within GCP costs more; egress to the public internet costs the most; egress to specific destinations through certain peering arrangements can cost differently again. A workload that hits a cross-region pattern not by design but by accident — a Cloud Run service in europe-west1 calling Spanner in us-central1 — can pay 10x more than the intra-region equivalent.

Co-locate services that talk to each other. The Cloud Run service, its database, its Cloud Storage bucket, and its Pub/Sub topic should normally all live in the same region. Multi-region or dual-region deployments are appropriate for global services but should be a deliberate choice, not a default. Cloud CDN in front of static assets cuts egress dramatically by serving cached responses from the edge; the cache hit rate on a well-tuned CDN is the single biggest egress lever for content-heavy sites.

Private connectivity to managed services — Private Google Access, Private Service Connect — keeps traffic inside Google's network and avoids any internet egress. This is a security best practice and a cost best practice at the same time.

BigQuery Cost Patterns

BigQuery deserves its own treatment because its pricing dimensions are unusual. On-demand pricing bills by bytes scanned per query; a careless SELECT * FROM big_table can cost tens of dollars in seconds. Capacity-based pricing reserves slots for predictable spend; the right choice depends on workload variability — capacity is cheaper for steady analytics, on-demand is cheaper for sporadic queries.

The practices that cut BigQuery spend without rewriting queries: partition large tables by date so a WHERE date = '...' filter scans only the relevant partitions; cluster on the columns that filter most queries so BigQuery prunes blocks within a partition; materialize repeatedly computed aggregates as scheduled materialized views; cap query bytes with the --maximum-bytes-billed flag or per-project query quotas to prevent runaway scans.

Avoid SELECT * in production code; name the columns. BigQuery's columnar storage means each named column is a separate cost, and unnecessary columns multiply the bill. A team that switches a daily reporting query from SELECT * to SELECT col1, col2, col3 often cuts cost by 70% or more in one commit.

FinOps Practices

FinOps is the discipline of running cloud cost as an engineering practice with shared accountability across engineering, finance, and product. Three practices form the spine.

First, label everything. Every resource gets labels for cost center, team, environment, and service. Without labels, the bill is one giant unstructured number; with labels, the bill is a sliceable dataset that answers questions like "which team consumed 80% of the BigQuery spend last month?". Enforce labels with organization policies so untagged resources cannot be created in production projects.

Second, export the billing data to BigQuery and build a small analytics layer over it. The Cloud Console billing reports are useful for at-a-glance views; serious analysis happens in BigQuery against the exported data. Data Studio dashboards on top of the export give product and finance teams self-serve visibility without engineer intervention.

Third, budget alerts and anomaly detection. Set budgets at the project or label level; configure Cloud Billing budget alerts to fire at 50%, 90%, 100% of spend; wire the alerts to the same channels as production alerts so engineering sees them. Recommender's anomaly detection surfaces sudden spend changes — a misbehaving job that scanned a terabyte instead of a gigabyte shows up the day it happens, not at the end of the month.

Continuous Cost Engineering

The teams that keep cost under control treat it as an ongoing measurement, similar to how SRE treats reliability. A monthly cost review covers: top spending services, biggest month-over-month changes, recommender findings (idle resources, oversized instances, CUD opportunities), egress trend, BigQuery scan trend, unattached disks, and the labels coverage report. The output is action items with owners and due dates, tracked like any other engineering work.

Pair cost engineering with reliability engineering — the error budget and the cost budget answer the same question for different axes. "Can we afford a more reliable architecture?" and "can we afford a less efficient implementation?" are the same conversation, and the right answer comes from the data, not from anyone's intuition.

Cost Anti-Patterns

Recurring shapes of wasted spend on GCP: