Optimizing Google Cloud Costs with FinOps

Observability costs are the charges for ingesting, storing, and querying telemetry from traces, metrics, and logs while keeping enough visibility to troubleshoot. In Google Cloud, Cloud Trace (opens in a new tab) spans, Google Cloud Managed Service for Prometheus samples, and Cloud Logging bucket storage drive most of the spend. Cloud Billing dashboards, exports, and alerts connect that technical usage to teams, budgets, and chargeback. Cost control therefore happens first in the telemetry pipeline, and cost accountability happens second in billing data.

1.1Control Trace Sampling and Metric Ingestion Volume

Cloud Trace sampling configuration determines which requests produce spans that flow from instrumented applications to the Trace backend for storage and analysis. Cloud Trace costs scale directly with ingested span volume, so the sampling rate is the primary cost control. Lowering the rate reduces ingested spans and cost, while raising it preserves more distributed traces for performance analysis. Keep higher sampling for critical or high-latency paths and lower sampling for high-volume healthy traffic to balance coverage against budget.

Metric collection cost grows with scrape frequency, cardinality, and retention as data flows from scrape targets to an ingestion pipeline and then to a global datastore. Google Cloud Managed Service for Prometheus charges per sample ingested, so total cost equals the number of time series multiplied by samples per series. Every sample sent to the global datastore incurs cost, and very frequent scraping can also degrade workload performance. Sampling and aggregation retain representative signals for troubleshooting without storing excessive raw telemetry.

Cost is controlled with three levers that act before samples reach the global datastore:

• Sampling period: changing the scrape period from 15 seconds to 60 seconds can save 75% without sacrificing cardinality, configured per job, per target, or globally.
• Filtering: use filtering and metric-relabeling configs to drop metrics at ingestion time based on label matchers, so unwanted samples never reach the global datastore.
• Keep high-cardinality, low-value data local: run standard Prometheus alongside the managed service with the same scrape configs and keep exploratory data locally.

Predictability comes from what is not counted as a billable sample. Sparse histograms count only the first non-zero value and then only when the value in bucket n is greater than bucket n-1; values 10 10 13 14 14 14 count as three samples, which typically means 20% to 40% fewer billed samples than raw bucket counts. Ephemeral containers created by Horizontal Pod Autoscaler (HPA) or GKE Autopilot bill only while running, rather than charging a full month each time a container starts. All user queries, including queries issued by Prometheus recording rules, are charged separately through Cloud Monitoring API calls.

1.2Manage Logging Storage with Exclusions and Routing

Cloud Logging storage costs apply only to log data stored in log buckets, so routing and exclusion decisions determine the bill. Log entries flow from sources to log sinks, where exclusion filters decide whether entries are streamed to log buckets or dropped. A sink can exclude all entries matching a filter or only a percentage of matching entries, and excluded entries do not count against storage allotment. Exclusion filtering is therefore the direct way to remove low-value, high-volume logs while preserving audit and troubleshooting signals.

Admin Activity audit logs cannot be excluded, configured, or disabled, and they are still generated even if the Cloud Logging API is disabled. Data Access audit logs are optional and very large, so they are the main candidate for exclusion, especially in development projects. Because filtering happens before storage, a precise filter on resource type, log name, or severity directly reduces ingestion overhead without losing required compliance coverage. Log sinks can also route entries away from log buckets to BigQuery, Cloud Storage, or Pub/Sub for cheaper long-term storage, extended analysis, or streaming.

System and custom buckets divide responsibility by compliance value and retention need. The _Required bucket holds compliance logs for 400 days with no changes allowed, the _Default bucket holds other logs for 30 days by default with changeable retention, and user-defined buckets allow 1 day to 3650 days with full control over location, access, and locking. Neither system bucket can be deleted, and after creation a custom bucket region cannot be changed. Choose custom buckets to isolate workloads with different compliance, access, and cost needs.

1.3Govern Observability Spend with Billing and Chargeback

Cloud Billing provides the usage and cost data that makes observability spend visible across projects and workloads. Billing data flows from Cloud Billing to built-in reports and, when deeper analysis is needed, through export to BigQuery for analysis and to Looker Studio for visualization. Automated notifications send cost anomalies, budget thresholds, and optimization opportunities directly to owners who can act. Exporting detailed billing data to BigQuery and joining it with Monitoring logs lets teams extract patterns such as rising log bytes, metric samples, or trace spans per workload.

Chargeback and showback models assign every observability cost to the team, product, environment, or cost center that caused it. The Google Cloud project hierarchy is the natural starting point because permissions, policies, and costs are attributed to projects and folders visible in billing exports. Tags and labels add granularity below the project level for application, environment, team, and region. A centralized FinOps team enforces mandatory tagging, budget reviews, and commitment aggregation, while product teams own day-to-day optimization with autoscaling, rightsizing insights, and cost-allocation metrics.

Spot VMs (opens in a new tab) are excess Compute Engine capacity sold at discounts of up to 91% off on-demand price with no availability guarantee. Compute Engine can reclaim that capacity at any time to run standard VMs, at which point a Spot VM is either stopped or deleted. Spot VMs therefore fit only fault-tolerant work that can lose and replace capacity without corrupting results.

2.1Understand Spot Pricing and Preemption Risk

Spot pricing reflects spare Compute Engine capacity rather than a fixed bid, so both price and availability shift with overall platform usage. Spot prices cover many machine types, GPUs, TPUs, and Local SSD disks, and prices can change up to once every day at midnight Pacific Time. Current prices are published on the Spot VMs pricing page and through the Cloud Billing Catalog API, while historical trends are available through the preemption and pricing history view. Comparing Spot price history against on-demand price shows potential savings, while comparing preemption histories shows which machine type and zone combinations have been more stable.

Billing follows the VM lifecycle state rather than preemption alone. If a preempted VM was stopped, the VM enters a TERMINATED state and accrues no VM-hour charges while it remains TERMINATED, but attached persistent disks still incur storage charges until deleted. If Compute Engine preempts a Spot VM less than one minute after creation, there is no charge for that VM use, and the same first-minute waiver applies to attached GPUs and Local SSDs. Premium operating systems are the exception because Spot VMs do not reduce premium OS cost, minimum-usage charges still apply, and OS charges continue even when preemption occurs in the first minute.

Preemption probability is generally low but varies by day, zone, machine family, and resource, similar to resource-availability errors. Only Spot VMs in a RUNNING state are considered for preemption, while Spot VMs in a TERMINATED state are not. Stopping then restarting a Spot VM resets preemption exposure because the VM passes through TERMINATED, while resetting or rebooting keeps it RUNNING and does not reset exposure. Spot capacity is finite, so Spot VMs might not be available at creation time, carry no Service Level Agreement, and are excluded from the Compute Engine SLA.

2.2Follow the Preemption Sequence to Termination

The preemption process is the ordered sequence Compute Engine follows to reclaim a Spot VM while giving the workload a brief chance to react. The workload detects preemption by monitoring instance metadata, handles it during a short shutdown window, and then the VM moves to its configured final state. The sequence runs in this order:

1. Metadata notice: Compute Engine sets the preempted value in VM default metadata to TRUE, after a notice duration of 120 seconds in Preview or 0 seconds by default.
2. ACPI G2 Soft Off and shutdown period: Compute Engine sends an ACPI G2 Soft Off signal, which triggers any configured shutdown script and starts a best-effort shutdown period of up to 30 seconds.
3. ACPI G3 Mechanical Off: If the Spot VM has not stopped after the shutdown period, Compute Engine sends an ACPI G3 Mechanical Off signal to the operating system.
4. Termination action: Compute Engine applies the per-VM termination action to place the VM in its final state.

The final state depends on the termination action configured for each Spot VM:

2.3Build Resilient Fleets with Templates and Managed Groups

A Managed Instance Group (MIG) is the control plane for a Spot VM fleet because the MIG continuously attempts to maintain its target size from an instance template. When Compute Engine preempts Spot VMs in the group, the MIG repeatedly tries to recreate those VMs from the same template, and replacements return to RUNNING only when capacity becomes available again. If Spot capacity remains limited in a zone, the MIG cannot resize or autoscale out until capacity returns. Fleet design must therefore add flexibility through regional placement and multiple machine types rather than relying on a single type in a single zone.

A Terraform configuration provides the repeatable way to provision Spot VMs because the same scheduling block defines the economic model and preemption behavior. The resource google_compute_instance depends on a boot disk image, machine type, zone, and network interface, with provisioning_model = "SPOT", preemptible = true, automatic_restart = false, and instance_termination_action set to STOP or DELETE. STOP leaves a stopped VM that can be restarted manually when capacity exists, while DELETE relies on the MIG to recreate it. The same fields appear in gcloud and API calls, so a CI/CD pipeline can promote one tested template from development to production and apply updates with automatic or selective rollout.

Resilient applications treat Spot VMs as ephemeral compute, keep state outside the VM, save progress continuously, and spread replicas. Stateless services, batch jobs, and checkpointed parallel work fit because a lost VM only slows the job, while authoritative data on the VM disk or Local SSD is unsafe because it is deleted on preemption. The common pattern is a shutdown script that gracefully stops the program and copies a checkpoint file to a Cloud Storage bucket, plus polling of metadata preempted or a hanging ?wait_for_change=true request for in-workload handling. The documented fallback is to retry Spot creation once or twice after preemption, then fall back to standard VMs in a mixed cluster so baseline throughput continues.

Optimizing resource usage for cost and efficiency means matching infrastructure size and pricing to actual demand while maintaining reliability. Compute Engine (opens in a new tab) right-sizing adjusts instance shape from observed utilization, storage lifecycle moves cooling data to cheaper classes, and autoscaling aligns container supply with real-time demand. Together these practices remove idle waste without creating bottlenecks.

3.1Right-Size Compute and Apply Cost-Saving Purchase Models

Right-sizing Compute Engine instances is the continuous practice of monitoring actual demand and adjusting allocation to avoid over-provisioning, which wastes money, and under-provisioning, which causes slowdowns. Utilization data flows from workloads to Cloud Monitoring for real-time visibility, then from Cloud Monitoring to Recommender for analysis, and Recommender returns machine type recommendations and idle VM findings. This loop lets teams base decisions on observed patterns rather than initial guesses, with regular review because pricing and instance features change over time.

Effective analysis tracks several dimensions of demand, not CPU alone:

• CPU utilization to detect idle or saturated cores
• Memory usage to detect pressure or overallocation
• Network traffic to detect throughput constraints
• Disk I/O to detect storage performance limits
• Application response times and custom metrics such as queue depth or request latency to link infrastructure signals to user experience

Compute Engine custom machine types refine the choice when demand is stable but falls between standard sizes, because CPU and memory are selected independently. After resources are right-sized, purchase models lower the billing rate. Committed use discounts (CUDs) cover stable baseline for one or three years, sustained use discounts reward consistent use within a billing cycle with no commitment, and Spot VMs use spare capacity at a steep discount with preemption risk. Choose resource-based CUDs for stable regional baseline, spend-based CUDs for predictable but distributed spend, and Spot VMs only when interruption is acceptable.

3.2Manage Storage Lifecycle and BigQuery Processing Cost

Cloud Storage classes separate actively used data from cold data by access frequency and retention need. Actively used datasets stay in Standard for low-latency access, while colder data moves to cheaper classes that trade retrieval cost for lower at-rest cost. Choosing Standard and then automatically downgrading avoids paying Standard rates for data that cools, while placing stable long-term retention directly in Archive avoids repeated transition churn.

Cloud Storage Object Lifecycle Management (OLM) automatically downgrades or deletes objects when age and other conditions are met, while Cloud Storage Autoclass transitions each object based on its observed access pattern. Use OLM when retention rules are known in advance, such as downgrade after 30 or 90 days, and use Autoclass when objects in the same bucket cool at unpredictable rates. Define aggressive time to live policies for logs, temporary model artifacts, and regenerable intermediate results. Governance depends on tags for owner, purpose, and retention period, enforced by Organization Policy Service constraints so lifecycle automation and billing exports can trust them.

BigQuery analysis cost is driven by bytes processed and slot pricing model. BigQuery on-demand pricing charges per bytes scanned for sporadic queries, while BigQuery editions use committed and autoscaling slots for sustained volume. Reduce processing by storing inputs in Parquet or Avro instead of JSON or CSV, retaining only aggregates long term, and running jobs in the same region as source buckets and datasets. Co-locate heavy processing with data, replicate across regions only for mandatory disaster recovery or high availability, and use Storage Transfer Service or Requester Pays buckets instead of mass dumps when data must move.

3.3Align Container Resources with GKE Autoscaling Layers

Container requests and limits control how efficiently Pods pack onto nodes in Google Kubernetes Engine (GKE). A request is the guaranteed CPU and memory the scheduler uses to place a Pod, so accurate requests let the scheduler pack more Pods per node. A limit is the maximum a container can consume, which prevents one container from starving others. When requests are set far above actual use, nodes appear full while CPUs sit idle, which drives over-provisioning. Cloud Monitoring exposes the gap between allocation and use, while Recommender suggests right-sized requests and limits.

The chain runs in order: VPA rightsizes container requests, HPA changes replicas based on those rightsized Pods, Cluster Autoscaler adds or removes nodes for schedulable Pods, and Node Auto-Provisioning creates new pool shapes when Pods fit no existing pool. For complex workloads, multidimensional Pod autoscaling configures HPA and VPA simultaneously to minimize footprint for required performance. Combine reactive scaling for unpredictable spikes with proactive scaling for predictable business hours or sales events, and scale asynchronous work on queue depth or latency rather than CPU alone to prevent flapping.

Infrastructure cost planning trades commitment, placement, and network path for lower rates without harming performance. Committed use discounts (CUDs) (opens in a new tab) lower hourly price for a one-year or three-year promise, sustained use discounts reward continuous use with no purchase, and Network Service Tiers select the traffic path between the internet and Google Cloud. The strategy is to cover stable baseline with CUDs, leave variable peaks to on-demand plus sustained discounts, and use Standard Tier where backbone performance is not required.

4.1Compare Commitment-Based Discount Models

Resource-based committed use discounts (resource-based CUDs) provide a discount for committing to a minimum quantity of Compute Engine resources in a specific region for 1 or 3 years. Each commitment is linked to the region and project where it was purchased and covers only matching machine configurations in that region. Eligible resources include vCPUs and memory for a specific machine series, GPUs and local SSDs, sole-tenant nodes, and premium OS licenses purchased separately. Hardware commitments earn up to 70% off for memory-optimized series and up to 55% off for other series, with separate software discounts for SLES and RHEL.

Spend-based committed use discounts (spend-based CUDs) provide a discount for committing to spend a minimum hourly amount on a product for 1 or 3 years. The commitment is purchased at the Cloud Billing account level and applies to eligible usage in any linked project, regionally or globally depending on the product. Compute flexible CUDs are the spend-based form for Compute Engine, Google Kubernetes Engine (GKE), and Cloud Run, where one hourly spend commitment covers eligible spend across all three services. Choose spend-based when total spend is predictable but regions, projects, or machine types vary.

Sustained use discounts (SUDs) are automatic credits for consistent Compute Engine and GKE usage that require no commitment purchase. The discount is earned when the same resources run continuously beyond duration thresholds within the billing period, so longer continuous use produces a larger credit. SUDs apply only to overage usage not already covered by a CUD and require no administrator action. Choose SUDs for variable but long-running usage where a fixed quantity or spend commitment would create underutilization risk.

4.2Purchase Commitments and Reconcile Coverage Hourly

Purchasing a spend-based commitment requires the Billing Account Administrator role, and the commitment cannot be cancelled or moved to a different billing account after purchase. The discount start time depends on purchase time: a purchase at :49 or earlier starts at the beginning of the next hour, while a purchase at :50 or later skips an hour. For most accounts, resource-based CUD sharing is enabled so one regional commitment covers matching usage across all projects under the same billing account. Spend-based commitments are inherently billing-account level.

Each hour, Google Cloud reconciles commitments against actual use in a fixed order:

1. Apply resource-based commitments first: Google Cloud utilizes resource-based commitments and applies credits to eligible hourly usage for that region and machine configuration.
2. Apply compute flexible commitments second: Google Cloud utilizes compute flexible commitments to cover remaining eligible Compute Engine, GKE, and Cloud Run usage.
3. Bill overage at on-demand rates: Google Cloud charges additional hourly usage at on-demand rates, which may then qualify for SUDs.

If hourly usage exceeds the commitment, the overage is charged at on-demand rates. If hourly usage falls below the commitment, the unused portion is still billed as a commitment fee and savings are lost. Size commitments below the observed baseline rather than at the peak, using CUD recommendations with coverage thresholds, term selection, and insights such as historical days above recommended spend and break-even days.

4.3Optimize Network Cost with Service Tier Selection

Network Service Tiers select the path traffic takes between the internet and Google Cloud instances. Premium Tier routes traffic on Google's premium backbone for performance, while Standard Tier routes traffic over peering, ISP, or transit networks for cost savings. Outbound data transfer pricing differs by tier, so the tier choice directly changes both latency and egress cost for internet-facing architectures.

External IP type and resource type determine whether Standard Tier can be selected. Global external IPv4 and IPv6 addresses are anycast and supported only in Premium Tier, regional external IPv4 addresses are supported in both tiers with eligible resources, and regional external IPv6 addresses are supported only in Premium Tier. Global external Application Load Balancer and global external proxy Network Load Balancer require global IPs and are not supported in Standard Tier, while regional load balancers, VM instances including GKE nodes, and Cloud NAT gateways require regional IPs in both tiers. A regional external IP can still be contacted from anywhere; regional means resources must be in a single region.

Tier selection for storage and caching follows special rules. Access to Cloud Storage buckets is Premium Tier by default, with Standard Tier available only when a bucket is a backend for an external Application Load Balancer. Cloud CDN is always Premium Tier and cannot be moved to Standard Tier. Traffic between VM instances stays on Google's network regardless of tier, so tier selection controls the internet ingress and egress path rather than the internal VM-to-VM path.

Recommender (opens in a new tab) insights are machine-generated findings about resource usage, and recommendations are the suggested actions that follow. In Google Cloud, Active Assist surfaces both through the Recommender API across cost, security, performance, manageability, and reliability domains. An insight explains the observed pattern, such as low CPU utilization or trending-out-of-disk, while the recommendation proposes the fix, such as rightsizing, enabling autogrow, or removing an idle resource. Prioritization weighs business impact against technical feasibility.

5.1Prioritize High-Impact Cost Recommendations

High-impact cost recommenders identify idle resources that can be removed and overprovisioned resources that can be downsized with low operational risk. The finding flows from the monitored resource to the recommender, which returns a recommendation entity that names the target in its resource field as //API_NAME/RESOURCE_PATH. The operator then applies the change with the service-specific tool, because Recommender itself does not mutate the resource. The ordered FinOps workflow is first remove idle waste, then rightsize what remains, and only then commit stable usage to discounted pricing.

Idle-cluster, idle-instance, and unattended-project findings usually represent the highest impact because the entire cost is waste. Overprovisioned VM, GKE, and Cloud SQL findings come next because rightsizing preserves function while lowering spend, but each requires checking peak load and latency goals. The Cloud SQL overprovisioned recommender analyzes primary instances older than 30 days using 30-day CPU and memory peaks, excludes read replicas and high-availability instances, refreshes every 24 hours, and fires only when estimated monthly savings are at least $10. The idle recommender emits LOW_ACTIVITY with SHUTDOWN_INSTANCE, where stopping suspends instance charges while storage and IP charges continue.

5.2Apply Recommendations Through a Controlled Lifecycle

The controlled lifecycle enforces review, explicit state transitions, and rollback readiness before production change. Human review must assess performance, reliability, and permission impacts first, and any automated application without review requires a prebuilt rollback process. Only recommendations first retrieved through the API or BigQuery Export can be transitioned through the API, and applying the change requires the recommender-specific apply role plus target-service permission. Enabling the Recommender API requires serviceusage.services.enable, typically via Owner or Service Usage Admin.

The lifecycle preserves order from finding to verified result:

1. List: List recommendations for the target project, location, and recommender ID with gcloud recommender recommendations list or GET on the recommendations resource.
2. Claim or dismiss: Mark a recommendation the team intends to apply as claimed, or mark one it will not apply as dismissed, so ownership and intent are recorded before mutation.
3. Apply: Apply the change manually with the resource-specific console action, gcloud command, or REST call identified by the resource field, or automatically through Active Assist.
4. Confirm outcome: Mark the recommendation as succeeded or failed only after verifying resource state and spend effect, preserving the audit trail.

Validation confirms that an applied change actually lowers the bill and does not merely shift utilization. Cost validation flows from the changed resource to billing telemetry and back to FinOps review through console cost reports, Cloud Monitoring and billing alerts, and export of recommendations to BigQuery for analysis in Looker Studio. For Cloud SQL, CpuUsageInsight and MemoryUsageInsight map LOW_CPU_UTILIZATION or LOW_MEMORY_UTILIZATION to CHANGE_INSTANCE_SIZE. When steady-state usage remains after cleanup, Committed Use Discounts (CUDs) lock in lower pricing for predictable consumption.

5.3Integrate Recommenders into Automated Workflows

Programmatic ingestion is the process where a scheduled job or pipeline calls the recommender interfaces to collect findings for a project, folder, or organization. The pipeline depends on the Recommender API being enabled and on an automation identity with viewer roles, and it scopes every call by project and location. Data flows from the recommender service to the pipeline, then to ticketing, policy checks, or remediation jobs. Because ingestion is pull-based, pipelines must handle pagination with pageSize and pageToken and filter by recommenderSubtype or insightSubtype.

Governance decides which findings a pipeline may fix directly and which require human approval based on risk. The decision uses primaryImpact.category such as SECURITY, priority such as P1, recommenderSubtype, and the concrete operations that would execute. Low-risk reversible changes are candidates for automation, while changes that alter memory, enforce organization policy, or touch production databases require review. To avoid races, mark a recommendation as CLAIMED with its current etag before applying it, execute the operationGroups.operations exactly as described, then verify and allow the recommender to clear the finding. Dismissed recommendations appear dimmed but remain restorable from History.

Reliability and performance insights identify underprovisioned resources that need more capacity, so they improve health rather than reduce spend. Cloud Monitoring, Cloud Logging, Cloud Trace, and Cloud Profiler provide the latency and saturation evidence to confirm real user impact. Because these actions may increase cost, the FinOps Recommendations dashboard excludes VM findings with negative savings, GKE CLUSTER_UNDERPROVISIONED or WORKLOAD_UNDERPROVISIONED, and Cloud SQL underprovisioned findings, while the Utilization insights dashboard retains them for engineering review. Database Center can further validate Cloud SQL for PostgreSQL changes by cloning the instance, benchmarking baseline versus recommended configurations, and comparing latency and throughput.

Optimizing individual workload costs means matching traffic patterns, resource use, and execution duration to the lowest-cost compute service. Google Kubernetes Engine (GKE) (opens in a new tab), Cloud Run, and Compute Engine have different pricing models, scaling behavior, and operational overhead, so the same workload can cost very different amounts on each platform. The goal is to avoid paying for idle capacity while keeping performance stable during bursts and low-use periods.

6.1Select the Service from Workload Characteristics

Traffic patterns and execution duration describe how demand arrives and how long compute must stay allocated. Cloud Run runs code without managing infrastructure and adjusts instances automatically as traffic rises and falls, which reduces cost when traffic is variable, bursty, or idle for long periods. Compute Engine with managed instance groups (MIGs) maintains a defined minimum and maximum number of VMs and adds VMs on high CPU and removes them on low CPU, which fits steady demand that benefits from always-available capacity. GKE dynamically adjusts cluster resources through complementary autoscalers, which fits containerized workloads where both Pod count and node capacity must change together.

Resource consumption and application state further narrow the choice. Stateful applications store client or transaction data such as shopping-cart contents, while stateless applications close the session after serving the request and scale more freely. Assessment includes whether metadata must survive reboot, whether VMs need mixed machine types or images, whether all VMs can share one zone and VPC subnet, and whether low-latency proximity to a database is required. Operational overhead also matters: Cloud Run removes node management, MIGs preserve full VM control but leave images and rollouts with the operator, and GKE improves bin-packing of multi-tenant clusters but requires tuning of requests, autoscalers, and regions.

GKE provides signals for matching requests to actual consumption. A workload is underprovisioned when CPU or memory utilization exceeds 150% for at least 10% of the time over the last 15 days, and the recommendation is to scale up. A workload is overprovisioned when utilization is below 50% for at least 90% of the time over the last 15 days, and the recommendation is to scale down. GKE does not generate a recommendation for the Horizontal Pod Autoscaler target metric or when Vertical Pod Autoscaler already manages requests, and may wait up to three days for new workloads.

6.2Manage Lifecycle with Autoscaling and Spot Placement

Compute Engine managed instance groups (MIGs) are groups of VMs managed and scaled as a single entity. An autoscaling policy defines minimum and maximum VM counts and trigger conditions, such as adding VMs on high CPU and removing them on low CPU. Traffic flows from the load balancer to VMs in the group, and the autoscaler adds or removes VMs based on load signals within policy bounds. Choose MIG autoscaling when the workload runs directly on VMs and needs horizontal scaling with explicit bounds.

GKE coordinates scaling across Pods and nodes in a fixed dependency order:

1. Horizontal Pod Autoscaler: Changes the number of Pod replicas based on CPU, memory, or custom metrics when concurrency changes.
2. Vertical Pod Autoscaler: Fine-tunes Pod resource requests and limits based on usage patterns when Pods are sized incorrectly.
3. Cluster Autoscaler: Adds or removes nodes based on unschedulable Pod demands or idle nodes when replicas cannot fit.
4. Node Auto-Provisioning: Automatically creates optimized node pools when existing pools do not match required shape.

Cloud Run provides built-in autoscaling based on incoming traffic, scaling container instances up on load and down to reduce cost, including scale to zero by default when there is no traffic. Choose Cloud Run for intermittent or event-driven services where idle servers would be waste, including GPU workloads that should consume GPUs only during use. Spot VMs provide unused capacity at more than 80% lower cost for fault-tolerant batch and background work, with on-demand VMs as fallback when Spot capacity is reclaimed. Combine reactive scaling for real-time spikes with proactive schedules for business hours and sales events, and store session state externally such as in Memorystore for Redis so any instance can handle any request.

6.3Tune Sizing and Discounts for Each Compute Option

Right-sizing is the continuous practice where utilization data flows from workloads to observability tools to a resizing or discount decision. Cloud Monitoring provides real-time visibility into CPU and memory, Recommender produces machine-type and idle-resource findings, and alerts notify administrators when thresholds are met. Batch workloads may intentionally sustain high utilization, so a highly utilized batch workload does not need scale-up if allocation already meets the job. Java Virtual Machine workloads on GKE need extra scrutiny because visibility into memory inside the JVM is limited.

Tuning in Compute Engine centers on machine shape and idle cleanup through custom machine types and decommissioning of unused instances and disks. Tuning in GKE centers on Pod requests and limits, where underprovisioned workloads need higher requests and overprovisioned workloads need lower requests followed by cluster resizing through Cluster Autoscaler and Node Auto-Provisioning. Tuning in Cloud Run centers on instance and CPU allocation, where default CPU allocates only during request processing and always-allocated CPUs support predictable traffic at a fraction of the price for that pattern. Labels by project, department, or cost center then let billing break down spending and trigger budgets and alerts when thresholds are exceeded.

Discounts lower the rate after resources are right-sized. Committed use discounts (CUDs) suit predictable steady usage for one or three years and can stack on enterprise discounts with auto-renewal to avoid gaps. Sustained use discounts apply automatically after continuous use with no commitment. A central FinOps team maximizes commitments by aggregating requirements across the organization, while product teams manage optimization and region selection with attention to price, latency, compliance, and sustainability tradeoffs.

Key Facts

• Google Cloud Managed Service for Prometheus bills per sample ingested, and changing a scrape period from 15 seconds to 60 seconds can save 75% without sacrificing cardinality.
• Cloud Logging _Required buckets retain logs for 400 days and cannot be changed or deleted, while _Default buckets retain logs for 30 days by default and custom buckets allow 1 to 3650 days.
• Spot VMs are excess Compute Engine capacity with discounts up to 91% and no availability guarantee, and only Spot VMs in a RUNNING state can be preempted.
• Google Cloud reconciles commitments each hour in fixed order: resource-based CUDs apply first, compute flexible CUDs apply second, and remaining usage is billed at on-demand rates that may earn sustained use discounts.
• Premium Tier routes traffic within the Google Cloud network with a 99.99% SLA, while Standard Tier routes over peering or ISP networks with a 99.9% SLA and lower egress cost.