Reserved Instances, Savings Plans, and CUDs for Kubernetes

Key takeaways

• Three commitment flavors exist: instance-locked RIs, spend-based Savings Plans and Flexible CUDs, and resource-locked CUDs. Each carries a different discount ceiling and flexibility trade-off.
• Kubernetes autoscalers change instance types constantly. Spend-based instruments, specifically AWS Compute Savings Plans, the Azure Savings Plan for Compute, and GCP Compute Flexible CUDs, survive those changes where instance-locked instruments do not.
• Commit only after rightsizing. Cast AI’s 2026 analysis of 23,000+ clusters found average CPU request utilization at 8%. Committing at that utilization means buying discounts on compute you never actually need.
• A stable 60-90 day post-rightsizing baseline is the minimum data window before sizing any commitment purchase.
• The practical split is 60-70% of the stable baseline on committed rates, with the remaining 30-40% covered by Spot or on-demand for variable load.
• Savings accumulate in phases, not on day one. The full compound effect of committed baseline plus Spot typically takes 3-6 months to materialize.

The three commitment types by cloud

Every major cloud provider offers a way to trade flexibility for a lower per-hour compute price. The instruments differ in what you commit to, how long the term runs, and how much discount you get. For Kubernetes specifically, the flexibility dimension matters more than on traditional VM workloads, because autoscalers continuously change node types in ways that can break instance-locked commitments.

AWS: three instruments with different flexibility levels

AWS offers three instruments. Standard Reserved Instances lock to a specific instance type, region, and OS for 1 or 3 years. Discounts reach up to 72% vs on-demand. You can sell unused Standard RIs on the AWS Marketplace, but you cannot change the instance type. Convertible RIs allow instance type changes, though the discount drops to roughly 54%.

EC2 Instance Savings Plans commit to an instance family in a specific region, for example m5 in us-east-1, across any size within that family. The discount is about 72%. This works well when your node size varies but the instance family stays stable over time.

Compute Savings Plans commit only to a $/hour spend rate. No instance family, region, or OS restriction applies. The discount is up to 66%. This is the best fit for Kubernetes clusters running Karpenter or Cluster Autoscaler, because those tools pick instance types dynamically. When your autoscaler selects an m5.2xlarge today and a c5.xlarge tomorrow, a Compute Savings Plan still applies. For deeper EKS-specific guidance, the EKS cost optimization guide covers how Karpenter interacts with commitment coverage in practice.

GCP: resource-based and Flexible CUDs

GCP’s committed use discounts come in two forms. Resource-based CUDs lock in specific vCPU and memory amounts for 1 or 3 years. The 1-year discount is 37%; the 3-year discount is 55%, rising to 70% for memory-optimized workloads. Resource-based CUDs cannot be canceled and apply automatically across projects in the same billing account.

Compute Flexible CUDs are spend-based and instance-family-agnostic. The 1-year discount is 28% and the 3-year discount is 46%. The lower discount is the direct trade-off for flexibility. For GKE clusters using Node Auto Provisioning or Cluster Autoscaler, Compute Flexible CUDs are the safer choice because they survive instance type changes. Note that GKE Autopilot CUDs are no longer available for new purchases as of 2025.

The GKE cost optimization guide covers GKE Standard vs Autopilot commitment trade-offs, including how resource-based CUDs behave when Node Auto Provisioning changes machine types mid-term.

Azure: Reserved VM Instances and the Azure Savings Plan

Azure Reserved VM Instances commit to a specific VM size and region. Discounts reach up to 72% off pay-as-you-go rates for 1 or 3 years. These work well for stable node pools with a fixed VM size, but break down once AKS autoscaling shifts workloads to a different VM family.

The Azure Savings Plan for Compute commits to a $/hour spend rate with no instance family or region restriction. The 3-year discount is up to 65%. For AKS clusters with autoscaled node pools, the Azure Savings Plan is the right instrument. Node pools that scale across VM sizes benefit from the flexibility that Reserved VM Instances cannot provide. The AKS cost optimization guide walks through how to size Azure Savings Plans against AKS node pool utilization data.

Commitment comparison table

Term length: 1 year vs. 3 years

All three clouds offer 1-year and 3-year terms. The deeper discount from 3-year terms is real: AWS 3-year pricing runs 20-30% below 1-year pricing; GCP resource-based CUDs jump from 37% to 55% (and from 37% to 70% for memory-optimized workloads); Azure 3-year Reserved VM Instances add roughly 15% over 1-year rates. The tradeoff is lock-in. Kubernetes workloads change instance families and cluster topologies with each major Kubernetes version upgrade or significant workload evolution. A 3-year commitment to an instance family that a future Karpenter NodePool upgrade replaces becomes locked-in waste, not locked-in savings.

Start with 1-year terms for most Kubernetes use cases. Reserve 3-year commitments for the most stable, unchanging workload categories, for example, persistent database nodes that have run the same instance family for years with no anticipated change. On payment options: all-upfront provides the maximum discount; no-upfront commits usage without requiring capital outlay. Both no-upfront and partial-upfront are typically available for 1-year and 3-year terms across all three clouds.

When to commit

Commitment timing is where most teams go wrong. The math looks attractive from day one: 66% off on-demand sounds like immediate, large savings. In practice, committing before you understand your actual compute baseline locks in waste rather than eliminating it.

Cast AI’s 2026 analysis of 23,000+ clusters found average CPU request utilization sitting at 8%. A team running at that utilization who commits to their current node count is buying a discount on compute they never needed in the first place. The discount percentage is real. The dollar savings are not.

Building a stable baseline before you commit

The stable baseline is the minimum node count your cluster maintains week-over-week without dropping further. To find it, collect 60-90 days of post-rightsizing node count data. Look for the floor: the number of nodes that stays consistent even during off-peak hours and lighter traffic periods.

Rightsizing must come before this observation window. Bin-packing pods tightly means node count reflects actual workload demand, not oversized pod requests. Without that step, the floor you observe includes the headroom from overprovisioned requests that bin-packing would have eliminated. Committing against an unrightsized baseline buys discounts on phantom compute.

Once you have 60-90 days of post-rightsizing data, identify the consistent floor. That number is your candidate baseline for commitment sizing.

Signals that indicate readiness to commit

Three signals together indicate a cluster is ready for commitment sizing. CPU request utilization stays consistently above 60% across the stable node pools. The node count floor has held for 8 or more consecutive weeks without a significant drop. No major workload migrations or architecture changes are planned within the next 6 months.

When all three conditions hold, the cluster has a predictable enough baseline to size against. The practical target is 60-70% of that stable floor. The remaining 30-40% stays on Spot or on-demand to absorb variable load spikes.

For workloads with strong seasonal patterns (Black Friday spikes, quarterly batch processing, end-of-month reporting), reduce the commit target to 40-50% of the rightsized baseline. Commit to the inter-seasonal floor, not the seasonal average. The variable layer above the floor runs on Spot or on-demand.

Savings accumulate in phases, not as a one-time unlock. The first phase covers the stable baseline at discounted rates. The second phase arrives when Spot handles the variable layer at spot prices. The compound effect of both strategies typically takes 3-6 months to fully appear in billing reports. Plan for this timeline so that short-term billing comparisons don’t create false signals.

Overcommitment risk and remediation

When a workload shrinks after you commit, the unused reservation cost continues. The exit options differ by cloud. The AWS Standard RI Marketplace lets you sell unused Standard Reserved Instances; Convertible RIs cannot be sold but can be exchanged for a different instance type. GCP CUDs cannot be cancelled or sold; unused discount applies to any eligible usage in the billing account, but you pay for committed vCPU and memory regardless. Azure Reserved Instances can be exchanged for a different VM size or region; the Azure Savings Plan has a small refund window (within 7 days of purchase).

The primary mitigation is commitment sizing discipline: commit to the minimum stable baseline, not the average. Use the floor, which is the minimum node count over 90 days, as the commitment target rather than the mean. A 60-70% commit ratio against your rightsized baseline already provides buffer; the uncommitted 30-40% absorbs workload variation without stranding reserved capacity.

Combining with spot and rightsizing

Commitment instruments cover the predictable floor. Spot covers the variable layer. The two strategies are complementary, not competing, and the layered model is the standard approach for cost-conscious Kubernetes operations.

The three tiers in the model: a committed baseline at discounted rates for stable node pools, a Spot tier for variable and batch workloads, and an on-demand fallback for capacity when Spot is unavailable. Each tier has a different cost profile and interruption risk. Sizing each tier correctly is the execution challenge.

Per-cloud implementation

On AWS EKS, Compute Savings Plans cover the baseline node pools. Karpenter provisions Spot instances for bursty workloads and batch jobs, selecting across instance families to find available capacity. When Spot interruption happens, Karpenter falls back to on-demand until new Spot capacity opens. The Compute Savings Plan coverage persists across this autoscaling activity because it is not instance-locked.

On GCP GKE, Compute Flexible CUDs cover the stable node pool. Spot VMs handle preemptible batch and ML training workloads. The Spot tier on GCP suits workloads that checkpoint regularly, because GCP provides a 25-second preemption warning before reclaiming the VM. Resource-based CUDs fit teams with stable, predictable vCPU and memory requirements that don’t shift across machine families.

On Azure AKS, the Azure Savings Plan covers steady-state node pools. Spot node pools handle variable and batch workloads. Azure’s Spot eviction policies give clusters time to drain pods before eviction, which matters for graceful workload handling. The Azure Savings Plan applies regardless of which VM family the steady-state nodes run on, making it resilient to future node pool configuration changes.

Estimating your commitment savings

Before sizing any commitment, run this math:

monthly savings = stable_nodes x on_demand_hourly_rate x hours_per_month x commitment_discount_pct.

As a concrete example:
20 stable m5.2xlarge nodes at $0.384/hr on-demand, covered by a 1-year no-upfront Compute Savings Plan, gives 20 x $0.384 x 730 x 0.21 = approximately $1,177/month saved on those nodes.

Expressed as a percentage of on-demand baseline: a 21% discount on 20 nodes at $5,606/month on-demand = $1,177/month saved, or approximately 21% of total node cost recaptured. (The 21% reflects the 1-year no-upfront Compute Savings Plan rate for m5.2xlarge in us-east-1; the 3-year no-upfront rate is approximately 54%, which produces materially higher savings if your workload warrants the lock-in. Check your specific instance’s rates in the AWS Pricing Calculator or your cloud provider console before committing.) The GCP equivalent is: committed_vCPUs x $vCPU_on_demand_hourly x 730 x CUD_discount_pct. The point is to run this math before committing, not after reviewing a billing report six months later.

How automation changes the commitment calculus

Running commitments manually means re-evaluating your baseline every 60-90 days as workloads change. Cast AI’s rightsizing engine tracks your stable baseline continuously, flags when committed utilization drifts below 70% (a signal of over-commitment), and adjusts Spot and on-demand node selection to match. When it’s time to renew, you commit against a verified, current baseline rather than a stale estimate.

Conclusion

Commitment instruments reduce the unit price of compute you know you will use. The discount ceiling is meaningful: up to 72% on AWS and Azure, up to 70% on GCP for memory-optimized workloads. That ceiling only translates to actual savings when you commit against compute demand you have verified rather than assumed.

The sequence that makes commitments work for Kubernetes: rightsize pod requests, bin-pack to reduce node count, observe the new stable floor for 60-90 days, commit 60-70% of that floor (or 40-50% for workloads with strong seasonal patterns), and route variable load to Spot. The commitment instrument you choose depends primarily on whether your cluster’s autoscaler changes instance types frequently. If it does, spend-based instruments, specifically Compute Savings Plans on AWS, the Azure Savings Plan, and Compute Flexible CUDs on GCP, are the right fit. Instance-locked instruments work for the minority of node pools where the instance type is fixed by design.

The Kubernetes cost optimization guide covers rightsizing, bin-packing, and autoscaling together as the foundation that commitment strategies build on.

See how Cast AI identifies your stable baseline, sizes commitments automatically, and monitors utilization to prevent over-committing across EKS, GKE, and AKS clusters.

Frequently Asked Questions