# Spot-only GKE capacity without standard fallback Canonical: https://www.pointfive.co/efficiency-hub/inefficiencies/spot-only-gke-capacity-without-standard-fallback Workloads are constrained to run only on Spot-based capacity with no viable path to standard nodes when Spot capacity is reclaimed or unavailable. By: Hierony Manurung [Cloud Efficiency Hub](https://www.pointfive.co/efficiency-hub) # Spot-Only GKE Capacity Without Standard Fallback The short version Workloads are constrained to run only on Spot-based capacity with no viable path to standard nodes when Spot capacity is reclaimed or unavailable. [Hierony Manurung](https://www.linkedin.com/in/hierony-manurung-53598168) Cloud FinOps @ Dkatalis GCP service [GCP GKE](https://www.pointfive.co/efficiency-hub/cloud-services/gcp-gke) Category [Compute](https://www.pointfive.co/efficiency-hub/service-category/compute) Reference CER-0287 Type Inefficient Architecture ## Explanation Why the waste happens and who it affects. While Spot reduces unit cost, rigid dependence can create hidden costs by requiring standby standard capacity elsewhere, delaying deployments, or increasing operational intervention to keep environments usable. GKE explicitly recommends mixing Spot and standard node pools for continuity when Spot is unavailable. ## Billing model The pricing dimensions that drive this cost. Spot VMs are discounted but have no availability guarantees; relying on Spot-only capacity can force compensating spend (extra standard capacity, retries, and operational overhead) to maintain reliability. ## How to detect 3 checks to find it in your estate. - Review whether critical or time-sensitive workloads rely exclusively on Spot-based capacity - Assess whether the environment can continue operating acceptably during Spot interruptions - Identify patterns where teams maintain separate standard capacity "just in case" due to Spot uncertainty ## How to fix 2 ways to remove the waste. - Treat Spot as preferred (where appropriate), not exclusive, capacity - Maintain sufficient standard capacity to keep essential workloads running when Spot capacity is reclaimed or temporarily unavailable ## Documentation Vendor references for pricing and configuration. - [https://docs.cloud.google.com/kubernetes-engine/docs/concepts/spot-vms docs.cloud.google.com](https://docs.cloud.google.com/kubernetes-engine/docs/concepts/spot-vms) - [https://docs.cloud.google.com/kubernetes-engine/docs/how-to/spot-vms docs.cloud.google.com](https://docs.cloud.google.com/kubernetes-engine/docs/how-to/spot-vms) ## Related inefficiencies [Browse the library](https://www.pointfive.co/efficiency-hub) - GCP GKE CER-0193 ### [Orphaned and Overprovisioned Resources in GKE Clusters](https://www.pointfive.co/efficiency-hub/inefficiencies/orphaned-and-overprovisioned-resources-in-gke-clusters) As environments scale, GKE clusters tend to accumulate artifacts from ephemeral workloads, dev environments, or incomplete job execution. PVCs can continue to retain Persistent Disks, Services may continue to expose public IPs and... Compute - GCP GKE CER-0270 ### [Orphaned Kubernetes Resources in GKE](https://www.pointfive.co/efficiency-hub/inefficiencies/orphaned-kubernetes-resources) In GKE environments, it is common for unused Kubernetes resources to accumulate over time. Examples include Persistent Volume Claims (PVCs) that retain provisioned Persistent Disks, or Services of type LoadBalancer that continue to front... Compute - GCP GKE CER-0498 ### [Balanced Cluster Autoscaler Profile on Cost-Sensitive GKE Clusters](https://www.pointfive.co/efficiency-hub/inefficiencies/balanced-cluster-autoscaler-profile-on-cost-sensitive-gke-clusters) The GKE cluster autoscaler has autoscaling profiles that decide how eagerly it removes nodes. Standard clusters default to the balanced profile, which Google describes as prioritizing keeping more resources readily available for incoming... Compute --- Source: the public page above. Product screenshots and illustrative interfaces are examples, not live customer data.