GKE Cost Optimization: A Guide to Cutting Waste in 2026

GKE clusters average 6% GPU utilization. EKS clusters average 5%. AKS clusters average 2%. CPU utilization across GKE fleets sits at just 8%, down from 10% year over year. These numbers come from the Cast AI 2026 State of Kubernetes Optimization Report, and they point to a structural problem. GKE cost optimization is not primarily a purchasing problem. It is a provisioning problem. The hardware is running; the workloads are not using it.

This guide covers the four levers that move the needle: node provisioning choices between Autopilot and Standard, rightsizing pod resource requests, using Spot VMs with a reliable fallback, and applying committed discounts at the right time. A fifth lever, ARM instances, compounds the savings from each step before it.

The sequence matters as much as the tactics. Committing before rightsizing locks in waste for 1-3 years. Starting with Spot before configuring PodDisruptionBudgets turns an interruption into an outage. Follow the order.

Key Takeaways

• GKE clusters average just 8% CPU utilization – over-provisioning, not pricing, is the root cost driver.
• The five-step optimization sequence is: Measure → Rightsize → Spot → Commit → ARM. Each step compounds the previous one.
• Rightsizing pod resource requests is the highest-leverage action: 69% of GKE clusters over-provision CPU, 79% over-provision memory.
• GCP Spot VMs offer 60–91% savings with far more stable pricing than AWS (~0.35 repricing events/month vs ~197).
• Never apply Committed Use Discounts before rightsizing – you will lock in wasted resources for 1–3 years.
• ARM instances (T2A, C4A Axion, N4A) deliver up to 65% better price-performance for compatible stateless workloads.

Node Provisioning on GKE: Autopilot or Standard?

Both GKE modes charge $0.10 per hour for cluster management. The first cluster is free, providing a $74.40 monthly credit. Beyond that, the billing models diverge significantly. Choosing the wrong model for your workload profile costs money regardless of how well you optimize everything else.

GKE Autopilot: Your Request Is Your Bill

In Autopilot mode, Google manages the underlying nodes entirely. You declare pod resource requests; Google bills you for exactly what you request. Autopilot’s billing floor is 250m CPU and 512Mi memory per pod under standard workload scheduling. Multi-container pods are billed per-pod at the aggregate requested resources. Request more and you pay more, regardless of actual consumption.

This model eliminates node-level waste by design. However, it transfers the waste risk directly to pod resource requests. A pod requesting 4 CPUs and using 0.3 costs the same as one actually consuming 4. Thirty percent of new GKE clusters in 2024 chose Autopilot mode, according to the 2026 report. That share reflects genuine demand for managed node operations, not a misunderstanding of the billing model.

Autopilot has real constraints. It does not support privileged containers, host-path volume mounts, or kernel-level security agents. Additionally, DaemonSets that require host access are not viable in Autopilot. For the full trade-off breakdown, see Cast AI’s GKE Autopilot analysis.

Pick Autopilot when: utilization is low, teams cannot dedicate time to bin-packing, or the project is new and managed operations take priority over density optimization.

GKE Standard: Node VMs, Your Responsibility

In Standard mode, you pay for Compute Engine node VMs. Google runs the control plane. You own node utilization. Consequently, if nodes run at 8% CPU utilization, you absorb that waste directly.

Standard mode provides full control. Spot VM-heavy fleets, dense microservices with tight bin-packing requirements, privileged DaemonSets, and kernel-level security tooling all require Standard. In contrast to Autopilot, Standard supports any container workload that runs on Compute Engine.

Pick Standard when: you run Spot VM-heavy workloads, need kernel access for security tooling, operate dense microservices where bin-packing control matters, or require privileged containers.

Autoscaling on GKE Standard

The Cluster Autoscaler (CAS) on Standard mode polls the API server every 10 seconds. Scale-up typically takes 3-4 minutes from pod pending to node ready. Node Auto Provisioning (NAP) extends CAS by automatically creating node pools for workloads that need machine types not already available in existing pools.

Karpenter has no official GCP provider as of mid-2026. GKE stays on CAS. For a detailed comparison of CAS and Karpenter trade-offs, see Cast AI’s autoscaler comparison. For a broader autoscaling strategy across instance types and availability zones, the guide to Kubernetes autoscaling for cloud cost optimization covers the full picture.

Rightsizing: The Highest-Leverage Step in GKE Cost Optimization

The most expensive rightsizing mistake is not under-requesting. It is requesting too little, getting throttled, then panicking and doubling requests across the board. One team doing this can increase your cluster’s effective node count by 40% overnight. The Cast AI 2026 report found 69% of GKE clusters over-provision CPU, up from 40% year over year. Most of that increase is reactive over-provisioning after incidents, not poor initial estimates.

Also, 79% of GKE clusters over-provision memory. Rightsizing is the highest-leverage step because it addresses the root problem. On Autopilot, inflated requests directly inflate your bill. On Standard, inflated requests force unnecessary node provisioning, increasing node count and therefore node VM costs. Fixing requests fixes both modes simultaneously.

Establishing the Measurement Baseline

Start with PromQL. Query p95 CPU usage and p99 memory usage over a 7-14 day window. Use the longer window for production workloads with weekly traffic cycles, since a shorter window may miss weekend or end-of-month patterns.

# p95 CPU request sizing -- 14-day lookback
max by(namespace, container) (
  quantile_over_time(0.95,
    rate(container_cpu_usage_seconds_total{container!=""}[5m])[14d:5m]
  )
)

# p99 memory sizing -- 14-day lookback
max by(namespace, container) (
  quantile_over_time(0.99,
    container_memory_working_set_bytes{container!=""}[14d:5m]
  )
)

These queries use Prometheus subquery syntax, which requires Prometheus 2.7 or later. On large clusters with many containers, the 14-day subquery window can be expensive. Scope it to a specific namespace or set a step interval when running it for the first time: --start=$(date -d '14 days ago' +%s) --end=$(date +%s) --step=3600.

Group by (namespace, container) rather than (namespace, pod, container). Pod names are ephemeral across restarts and create fragmented time series over 14-day windows. Grouping at the container level gives you a stable, continuous signal for each workload type.

For CPU requests, set values at p95 actual usage. Set CPU limits 20-30% above requests. Do not set CPU limits on latency-sensitive services. CPU throttling at the limit creates unpredictable latency spikes that are harder to diagnose than cost overruns. Specifically, the kernel’s CFS scheduler enforces CPU limits in 100ms windows, which adds jitter that is invisible in most dashboards.

For memory, start with limits at 2x requests for stable workloads with predictable memory profiles. JVM applications should set memory limits based on -XX:MaxRAMPercentage rather than a fixed multiple. For batch jobs or workloads with variable peak load, set limits based on measured maximum actual usage over a representative period. Memory OOM kills are harder to recover from than CPU throttling, so the additional headroom is worth the cost at most utilization levels.

Kubernetes Native Rightsizing Tools

The Vertical Pod Autoscaler (VPA) runs in three modes. Off mode provides recommendations without applying them. Initial mode sets requests only at pod creation. Auto mode updates running pods, but requires pod restarts to apply new values.

The restart requirement in VPA Auto mode is a real production risk. For stateless services with multiple replicas, rolling restarts are manageable. For stateful services or low-replica deployments, however, restarts introduce availability risk that may not be acceptable.

VPA and HPA conflict: Do not enable VPA in Auto mode on deployments that already use HPA targeting CPU or memory. When both controllers target the same resources, they create resource oscillation: VPA adjusts requests, which changes HPA scaling targets, which changes pod count, which changes per-pod utilization, which triggers VPA again. Use VPA in Off mode (recommendations only) alongside HPA, or target HPA on custom metrics such as request rate or queue depth while letting VPA manage resource requests.

LimitRange objects enforce default requests and limits at the namespace level. ResourceQuota objects cap total CPU and memory consumption per namespace. Both are governance mechanisms rather than optimization tools. Use them to prevent runaway allocations while you address the underlying request values.

PlayPlay automates Spot VMs for 40% cloud cost reduction

Learn more

Rightsizing Without Pod Restarts

The 2026 State of Kubernetes Optimization Report shows that automated rightsizing cuts provisioned CPUs by roughly half while reducing OOM kills to near zero. Achieving that result requires applying new resource values without disrupting running workloads.

Cast AI’s Live Migration technology rightsizes pods without restarts. This directly addresses the VPA Auto mode limitation. In practice, continuous rightsizing applies to production workloads without cycling pods through their restart sequence. For clusters where VPA Auto mode is too disruptive, this difference is the deciding factor.

GKE Spot VMs: 60-91% Savings with the Right Fallback

Google confirms 60-91% savings on Spot VMs versus on-demand pricing. Spot-heavy GKE fleets average 77% savings. Mixed fleets average 59%. The variance depends on workload mix, region selection, and machine type availability. For most platform teams, Spot is the single fastest path to large cost reductions.

GCP Spot Stability vs. AWS

GCP Spot VMs reprice approximately 0.35 times per month. AWS Spot reprices approximately 197 times per month. In practice, GCP Spot pricing is far more stable for capacity planning. The best GCP regions for Spot availability are us-central1 and us-east1.

The standard interruption notice on GCP Spot is approximately 30 seconds, best-effort. This differs from AWS Spot, which provides a 2-minute notice. Your termination handling must be designed for the shorter window.

Additionally, Preemptible VMs are now legacy: they have a 24-hour maximum runtime and Google no longer recommends them. Always use Spot instead.

Workload Eligibility for Spot

Spot VMs are appropriate for stateless web services with multiple replicas, batch processing and data pipelines, CI/CD runners and build systems, and ML training jobs with checkpoint-and-resume logic.

Spot VMs are not appropriate for stateful databases, payment processors, and Kubernetes control-plane components. Furthermore, any workload that cannot tolerate a 30-second shutdown notice should run on on-demand nodes.

The Fallback Architecture

The most critical safety mechanism for Spot workloads is the PodDisruptionBudget (PDB). Set minAvailable to guarantee a minimum number of replicas remain running during eviction. Without a PDB, a Spot interruption can evict all replicas simultaneously, causing a full outage.

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: web-service-pdb
spec:
  minAvailable: 2  # Always keep at least 2 replicas
  selector:
    matchLabels:
      app: web-service

Safety note: Set minAvailable to at least one less than your replicaCount. A minAvailable: 2 on a two-replica Deployment blocks all voluntary disruptions, including cluster upgrades and node drains. For stateless services, maxUnavailable: 1 is often a better alternative: it allows rolling disruptions rather than requiring a minimum number of running replicas.

Taint your Spot node pool and add tolerations only to workloads eligible for Spot. This keeps eligible pods on Spot nodes and routes fallback traffic to on-demand nodes when Spot capacity disappears.

# Node pool taint (applied to Spot node pool)
gke-spot=true:NoSchedule

# Pod toleration (in deployment spec)
tolerations:
- key: "gke-spot"
  operator: "Equal"
  value: "true"
  effect: "NoSchedule"
nodeSelector:
  cloud.google.com/gke-spot: "true"

Set terminationGracePeriodSeconds to at least 30 seconds. Add preStop hooks to drain connections before the container terminates. These two settings together allow in-flight requests to complete before the pod shuts down.

Maintain a separate on-demand node pool as a fallback. When a Spot node is interrupted, pods without an available Spot node land on the on-demand pool instead of entering a pending state. For implementation details and configuration examples, see Cast AI’s guide to Kubernetes Spot instance cost optimization.

Cast AI’s prediction model analyzes GCP fleet capacity signals and historical preemption patterns to flag at-risk Spot nodes up to 3 hours before interruption, enabling proactive rebalancing rather than reactive restart. Automated on-demand fallback activates when Spot capacity is unavailable, without requiring manual intervention from the on-call team.

Commitments and ARM: Lock In Savings, Then Choose the Right Hardware

Sequence matters here more than anywhere else in this guide. Rightsize first. Commit second. Committing based on current over-provisioned requests locks in that waste for 1-3 years with no exit option. First fix your requests; then lock in the discount on the correct baseline.

GCP Discount Layers

Sustained Use Discounts (SUD) are automatic and require no commitment. SUD tiers increase as VMs run longer within a billing month: the first 25% of the month runs at base price, with progressively higher discounts applying across the 25-50%, 50-75%, and 75-100% usage windows. The maximum SUD discount for a full billing month is approximately 30% for N1 and compute-optimized (C2) machines, and approximately 20% for N2 machines. Always verify the SUD rate for your specific machine family before planning your discount strategy. SUDs apply only to Standard cluster node VMs. Autopilot pods and Spot VMs do not qualify.

Resource-based Committed Use Discounts (CUDs) require a 1-year or 3-year commitment to a specific amount of vCPU and memory. The discount reaches approximately 37% for 1-year commitments and approximately 55% for 3-year commitments on N2 standard machines. Memory-optimized and compute-optimized families offer higher rates. E2 machines follow a different discount schedule. Check the GCP pricing calculator for your specific machine type. These commitments cannot be cancelled. Size them against your rightsized stable baseline, not your peak consumption.

SUDs and CUDs do not stack. When you commit via a CUD, you no longer receive SUD on those committed resources. Apply CUDs only after rightsizing confirms your stable baseline. SUDs cover the rest automatically.

Flex CUDs take a spend-based approach. You commit to a minimum dollar spend per hour. A 1-year Flex CUD provides approximately 28% savings. A 3-year Flex CUD provides approximately 46%. Flex CUDs offer broader machine type coverage, which is useful when your instance mix changes over time.

The strategy: apply CUDs to stable baseline workloads. Use Spot for burst capacity. Never commit more than your steady-state consumption, because burst demand belongs on Spot, not on committed resources.

ARM Instances on GKE

ARM is no longer experimental in GKE. Currently, 9% of all CPUs in Kubernetes clusters are ARM, growing 3.5x faster than x86 since Q2 2024. Three ARM options are generally available on GKE.

T2A (Ampere Altra) provides approximately 30% better price-performance versus comparable x86 instances. It is generally available in us-central1, europe-west4, and asia-southeast1.

C4A (Google Axion, based on Neoverse V2) delivers up to 65% better price-performance for general-purpose workloads. It became generally available in October 2024 and represents Google’s current flagship ARM offering.

N4A (Axion-based, balanced) became generally available in January 2026. It targets workloads that need balanced compute and memory without the premium of the C4A series.

Multi-arch container builds are required before scheduling on ARM nodes. Your CI pipeline must produce both linux/arm64 and linux/amd64 images. Without multi-arch images, pods cannot schedule on ARM nodes and will remain pending or fall back to x86. Cast AI handles ARM instance selection automatically for T2A, C4A, and N4A, and manages Spot interruption across ARM instance families.

GKE Cost Optimization: Start with Waste, End with Automation

The five-step sequence is: Measure, Rightsize, Spot, Commit, ARM. Each step compounds the previous one. Rightsizing reduces the node count that Spot must cover. Spot reduces the on-demand baseline that CUDs must cover. CUDs then apply to a smaller, accurate baseline. ARM then delivers better price-performance on whatever that baseline consumes.

Skipping steps is expensive. Committing before rightsizing fixes over-provisioning at the committed price for 1-3 years. Running Spot without PodDisruptionBudgets turns the next interruption into a full service outage. Furthermore, evaluating ARM before fixing your image build pipeline results in scheduling failures. The sequence is not a suggestion; it is the prerequisite chain.

Note: If you already use HPA, start VPA in Off mode to collect recommendations first before enabling Auto mode. This prevents the resource oscillation described earlier and gives you a clean signal before any automated changes apply to running pods.

Cast AI connects to an existing GKE cluster in approximately 2 minutes. It applies rightsizing via Live Migration, manages Spot with proactive interruption prediction, and selects optimal instance types including ARM, without requiring changes to workload manifests. For a broader view of Kubernetes cost optimization across clouds and clusters, see Cast AI’s Kubernetes cost optimization hub.

Frequently Asked Questions