Kubernetes commitments map onto the nodes that back the cluster, not onto the pods scheduled on them. AWS Savings Plans, Azure Reservations and the Azure Savings Plan, and GCP Committed Use Discounts all discount the underlying compute, so the question is how much node capacity your cluster reliably uses and which instrument keeps covering it as the cluster scales and shifts instance types. Flexible instruments win here, because a Reserved Instance pinned to one instance type strands its discount the moment the autoscaler picks something else. Cover the steady floor, leave the peak variable, and the discount follows the cluster instead of fighting it.
Here is how each provider's instruments line up against a moving cluster, and how to set coverage that does not strand discount.
Why commitments attach to nodes, not pods
Billing happens at the infrastructure layer. The cloud charges for the virtual machines that form your node pools, and the Kubernetes scheduler then packs pods onto those nodes. A commitment is a promise about compute spend or capacity, so it discounts the nodes regardless of which pods land where. This is liberating: you do not need to forecast pods, only the node capacity the cluster holds over time.
It also explains the classic failure mode. Teams overprovision pod requests, the cluster scales out more nodes than the real workload needs, and a commitment then locks in that inflated baseline. Right size requests and bin pack first, then commit to the leaner floor that remains.
How does each provider's instrument map?
- AWS. Compute Savings Plans are the natural fit because they apply across instance families, sizes, and regions, so they keep covering nodes as the autoscaler changes shape. Reserved Instances offer a deeper rate but pin to a specific type, which strands discount on a cluster that moves. Graviton nodes layer a standing price advantage underneath either.
- Azure. The Azure Savings Plan for compute behaves like the flexible option and suits AKS node pools that change, while Reservations give a deeper discount for stable pools and can be exchanged if the shape shifts. Dev Test pricing and Hybrid Benefit can change the per node math underneath.
- GCP. Spend based Committed Use Discounts fit GKE well because they commit to an hourly spend rather than a specific machine, so they ride through autoscaling. Resource based CUDs discount more but tie to a machine type and region. Sustained use discounts already apply automatically to steady nodes.
How much of the cluster should you commit?
Coverage follows the floor, not the peak. Plot node usage over a representative period and find the baseline the cluster never drops below, including quiet nights and weekends. Commit to that floor and leave the variable layer on demand or on the most flexible instrument. Committing to the peak guarantees you pay for idle reserved capacity every time the cluster scales in.
For multi tenant clusters, set the floor against the combined steady demand, not the sum of each team's peak. Shared clusters smooth demand, which is one of their cost advantages, and the commitment should capture that smoothing rather than undo it.
A worked example
A European SaaS company ran a GKE estate on entirely on demand nodes, nervous that committing would clash with aggressive autoscaling. Pod requests were inflated, so the cluster floor looked higher than the real workload. Right sizing requests and bin packing dropped the steady node count, and a spend based Committed Use Discount then covered the new floor while the autoscaler handled peaks on demand. Because the commitment was spend based, it kept applying as machine types changed. The blended rate fell across the cluster without a single capacity surprise. Figures are verified against billing data and anonymised.
Frequently asked questions
Do cloud commitments apply to Kubernetes pods?
Which commitment fits an autoscaling cluster?
How much of a cluster should be committed?
Map your cluster commitments with us
We size Kubernetes commitments to the real cluster floor across AWS, Azure, GCP, and OCI, so the discount follows the workload instead of stranding. Our guarantee: we reduce your cloud spend or we reimburse our service fee, on either a Fixed Fee or a no risk Gainshare basis. Practical mechanics like this land regularly in The Cloud Spend Navigator.
Put a defensible number on your cloud spend.
No provider in the room, no published price list. Tell us your footprint and we will scope the savings against your billing data — we reduce your cloud spend or we reimburse our service fee.
The Cloud Spend Navigator: what changed in cloud pricing, commitments, and FinOps — no vendor spin.