Most conversations about Kubernetes cost optimisation collapse three different things into one. People talk about "rightsizing" without specifying whether they mean the pods or the nodes. They talk about "saving money" without distinguishing between reducing demand and changing how demand is priced. The result is teams that work on cost optimisation for months, deliver real improvements at one layer, and don't see the bill move because the layer below or above absorbed all the savings.
The cost stack matters. Once you can see the three layers clearly, what each one costs, how each one wastes, who owns each one, and how the layers interact, the optimisation strategy almost designs itself. This piece is the framework. Worth understanding before any specific optimisation work.
The three layers, defined
Kubernetes cost lives in three distinct places. Each one is a different kind of decision, made by a different team, with a different waste pattern.
Three layers, three owners, three different waste patterns. The interactions between them are where optimisation gets interesting.
Layer one: pods
The pod layer is where engineers declare what their workloads need. Every pod manifest specifies resource requests (the minimum the cluster guarantees) and limits (the maximum before throttling kicks in). These numbers determine how Kubernetes places pods on nodes and ultimately how much capacity gets consumed.
The waste pattern at this layer is over-provisioning. Engineers writing pod specs usually don't have weeks of production data to size against. They estimate. And because under-sizing causes immediate visible problems (throttling, OOM kills, customer errors) while over-sizing causes invisible problems (a slightly higher bill at month-end), they consistently size high. Two times what's needed is normal. Three is common. Five times happens.
Pod-level waste is the largest single source of cost in most Kubernetes environments. It's also the most addressable, because it's the layer where engineers have direct control. The fix is rightsizing, adjusting requests to match actual workload behaviour. The challenge is doing it safely, at scale, and without breaking horizontal pod autoscaling.
We've written a longer piece on why over-provisioning persists at the pod layer and what fixes it.
Layer two: nodes
Below the pod layer sits the node layer. Nodes are the actual compute instances, EC2 instances, GCE VMs, Azure VMs, that the cluster autoscaler provisions to satisfy pod resource requests. Pods are scheduled onto nodes based on their declared requests, and nodes are added or removed based on how full the cluster is.
Three waste patterns live at the node layer. First, poor bin-packing: nodes that look "full" because pods are over-provisioned, but run at 30% real utilisation. The cluster autoscaler keeps spinning up new nodes because the scheduler operates on declared requests, not actual usage. Second, wrong instance types: workloads running on general-purpose instances when they'd be cheaper on memory-optimised or compute-optimised instances. Third, missed spot/preemptible opportunities: stateless or fault-tolerant workloads running on full-priced on-demand instances when they'd run fine on spot at 60-80% lower cost.
The node layer is owned by the platform team, the engineers running the cluster, configuring autoscalers, and making decisions about node pools and instance families. The fix here is bin-packing optimisation, instance type selection, and spot strategy. It's harder than pod-level rightsizing because the decisions are cluster-wide rather than workload-specific.
The interaction with layer one
Node-level optimisation is bottlenecked by pod-level over-provisioning. If pods request 2× what they need, the scheduler places them as if they need 2× the capacity, and bin-packing degrades accordingly. Even the most sophisticated bin-packing algorithm can't fix a problem that originates in the layer above. This is why the right sequence is pods first, nodes second. Optimising nodes on top of over-provisioned pods produces marginal improvements. Optimising nodes on top of right-sized pods produces structural improvements.
Layer three: cloud commitments
Below the node layer sits the commitment layer. Reserved Instances on AWS. Savings Plans on AWS. Committed Use Discounts on GCP. Reservations on Azure. These are pricing agreements where the customer commits to a level of compute usage for one or three years in exchange for a discount of 20-60% off on-demand pricing. Commitments don't change what the cluster does. They change what the underlying compute costs.
The waste pattern at the commitment layer is over-commitment. A finance team modelling cloud spend for next year takes the current cluster size, projects growth, adds a buffer, and commits to that capacity for a multi-year term. Then the engineering team optimises pods and nodes, actual capacity demand drops 30%, and the company is locked into commitments for capacity it no longer needs. The discount on the unused capacity doesn't help if you're paying for capacity you can't use.
The opposite pattern, under-commitment, also wastes money. If the workload is stable and the company isn't taking advantage of available commitment discounts, it's paying on-demand prices for capacity that could be discounted by 30-50%. The right commitment level is a moving target that depends on what the optimised cluster needs.
The interaction with layers one and two
Commitments depend on what the cluster needs, which depends on how nodes are sized, which depends on how pods are sized. Optimising commitments before the upstream layers are settled is locking in a commitment based on inflated demand. This is why the sequence matters: pods first, nodes second, commitments third. Get the order wrong and you'll spend years unwinding the commitment decision.
Why most teams optimise wrong
The three-layer model makes the most common optimisation mistakes obvious. Worth listing them, because every Kubernetes shop has fallen into at least one of these.
Mistake one: optimising commitments first. A finance team sees a big AWS bill, signs Reserved Instances or Savings Plans to get a discount, and locks in capacity sized for current (over-provisioned) demand. Six months later when engineering optimises pods and nodes, the company is paying for committed capacity it doesn't need. This is the most expensive mistake because commitments are hard to unwind.
Mistake two: optimising nodes without pods. A platform team installs a sophisticated cluster autoscaler, configures instance type recommendations, and tunes bin-packing, without addressing the over-provisioned pod requests that are driving the underlying capacity demand. Marginal improvements at the node layer are eaten up by the pod layer's continuing over-provisioning.
Mistake three: optimising pods without measuring impact at the node layer. Engineers right-size pods successfully, freeing up capacity at the node layer, but the cluster autoscaler doesn't immediately recognise the freed capacity, or the node pool configuration prevents consolidation. Pod-level savings exist on paper but don't translate to actual node reduction. The bill doesn't move.
Mistake four: optimising one layer at a time without considering interactions. The three layers compound. Optimising pods reduces actual demand by 30%. Optimising nodes on top of right-sized pods reduces capacity by another 20%. Optimising commitments on top of right-sized capacity captures another 25% via discount. The cumulative impact is meaningfully larger than any single layer. Most teams capture only one layer's worth of savings because they don't see the stack.
The right sequence
Bottom-up. Always.
Step 1, Right-size the pods
This is the layer with the largest waste, the most leverage on downstream layers, and the most direct ownership by engineering. Get a baseline of actual workload utilisation. Identify pods requesting significantly more than they use. Apply right-sizing recommendations through your normal CI/CD process, with engineering review of each change. Don't try to do this manually at scale, use a workload-aware tool that produces precise recommendations and integrates with deployment workflows.
The goal at the pod layer is to reduce declared resource requests to roughly 1.2-1.5× actual peak usage, with appropriate buffers for SLO-critical workloads. Most teams find 30-50% reduction in declared CPU and memory requests is achievable without compromising reliability.
Step 2, Optimise the nodes
Once pod demand is settled, the actual capacity requirement of the cluster becomes clear. Now node-level optimisation can produce real impact. Improve bin-packing so nodes carry more pods at higher utilisation. Choose instance types that match the workload mix (general-purpose, memory-optimised, or compute-optimised). Identify workloads suitable for spot or preemptible instances and migrate them.
The goal at the node layer is to push cluster utilisation from typical 30-40% up to 60-70% on the optimised cluster. Most teams find 15-25% additional savings here on top of the pod-level work.
Step 3, Right-size the commitments
With pods and nodes optimised, the actual baseline capacity requirement is now visible. Commitments can be sized correctly to that baseline rather than to the over-provisioned demand the cluster started with. For workloads with stable usage, commit to the baseline and capture the discount. For workloads with growth or seasonality, commit conservatively and use on-demand or spot for the variable portion.
The goal at the commitment layer is to capture 25-40% additional savings via discount on the optimised capacity baseline, without locking into commitments that exceed actual demand. Combined with the upstream layer savings, the total stack-level impact can reach 50-60% reduction in cloud spend.
Pod rightsizing reduces actual demand by ~30%. Node optimisation on top of that captures another ~20% via better bin-packing and instance selection. Commitment optimisation on the right-sized baseline captures another ~25% via discount. The compound effect is 0.7 × 0.8 × 0.75 = 0.42, a 58% reduction from the original spend. Optimising one layer at a time captures only one of these multipliers. Optimising in the wrong order captures less than that.
Where OptOps.ai fits
OptOps.ai produces recommendations across all three layers, sequenced correctly. Pod-level: workload-aware rightsizing recommendations that account for burst patterns, SLO tiers, and workload type. Node-level: bin-packing improvements, instance type recommendations, spot suitability analysis, applied once pod demand is settled. Commitment-level: visibility into the optimised capacity baseline so finance and procurement can make commitment decisions on right-sized demand rather than over-provisioned demand.
The architecture is read-only by default. Recommendations flow through engineering's existing CI/CD as code changes. The platform never takes write actions against production clusters. Engineers review and apply recommendations through their normal workflow, in the order that captures the compounding effects.
The deeper version of how this works in practice is on our OptOps.ai vs other Kubernetes optimization platforms page. The three-layer framework is also why advisory-first matters: each layer requires different review processes, and a tool that takes autonomous actions across all three layers is making decisions that should belong to different teams.