A Kubernetes cost review is a repeatable five step pass: attribute the bill to workloads, close the gap between pod requests and real usage, rightsize the nodes the scheduler packs onto, remove idle and weekend capacity, and decide where commitments and spot fit. Kubernetes obscures cost because shared clusters and overprovisioned requests turn many teams into one opaque node bill, so the review starts with allocation, not tuning. The largest single saving in most clusters is closing the distance between what pods request and what they use, because the scheduler reserves the request whether or not the workload needs it. Done monthly, this playbook keeps a cluster honest as teams ship.
The steps work the same on EKS, AKS, GKE, and OKE, with the cloud specific levers layered on at the end. Here is the playbook.
Step one: attribute the bill to workloads
You cannot cut what you cannot see. The cloud bill reports node and add on cost, not the cost of a team or a service, so the first job is mapping spend to namespaces, workloads, and owners using pod resource requests and actual usage. Until every dollar has an owner, the review is guesswork and no team feels accountable. Allocation is the foundation everything else stands on.
Step two: close the request to usage gap
This is where the money is. Teams set CPU and memory requests well above real consumption to avoid throttling or eviction, the scheduler reserves that capacity, and nodes fill with reservations instead of work. Compare requested resources to observed usage at the workload level, then bring requests down toward real demand with enough headroom for safe operation. Vertical autoscaling can drive this continuously, but a one time pass on the worst offenders usually recovers the bulk of it. This single step is typically the largest line in the review.
Step three: rightsize the nodes
Once requests reflect reality, the node pool is usually wrong for the new shape of demand. Pick instance sizes that bin pack pods efficiently rather than leaving large fragments of every node unused, and match the node family to the workload, including using cost efficient processor families where the software supports them. Good bin packing turns the same workload into fewer, better filled nodes, and fewer nodes is a direct saving.
Step four: remove idle and out of hours waste
Clusters rarely need to run development and test environments nights and weekends, yet most do by default. Scale non production clusters down or off out of hours, find idle clusters that no longer serve anything, and check that autoscaling actually scales in after a spike rather than leaving the high water mark running. Persistent volumes and orphaned load balancers from deleted workloads belong on the same sweep.
| Review step | What you check | Typical saving lever |
|---|---|---|
| Attribute | Cost mapped to namespace and owner | Accountability, not waste yet |
| Requests | Requested versus used CPU and memory | Largest single line |
| Nodes | Bin packing and instance family | Fewer, better filled nodes |
| Idle | Out of hours and orphaned resources | Quick, low risk wins |
| Commit and spot | Stable baseline versus interruptible work | Rate reduction on what remains |
Table: the five steps of the review and the lever each one pulls.
Step five: apply commitments and spot to what remains
Only after the cluster is sized correctly does the rate decision make sense, because committing to oversized capacity locks in the waste. Map the stable baseline of node demand to commitments such as Savings Plans, Reservations, Committed Use Discounts, or Universal Credits depending on the cloud, and move fault tolerant, interruptible workloads onto spot or preemptible capacity for a deeper rate. Commit to the floor of a defensible forecast, never the current run rate of an unoptimised cluster.
A Fortune 500 retailer ran a shared GKE estate where the cloud bill was a single large number no team owned. Attributing cost to namespaces exposed that requested CPU was more than double observed usage across the busiest services. Bringing requests in line, repacking onto right sized nodes, and switching non production clusters off out of hours removed a large block of node hours, and only then were commitments sized to the new, lower baseline. The same disciplined pass of rightsizing and waste removal left the container estate materially lighter. Figures are verified against billing data and anonymised.
Where the review connects
This playbook is the operating cadence on top of the structural work covered in the pillar. For the mechanics of requests and limits, see pod requests, limits, and real cost, and for the node layer see node rightsizing for Kubernetes. The full container picture, including the cloud specific differences across EKS, AKS, GKE, and OKE, lives in the Kubernetes cost guide, which links up to the cross cloud cost optimization guide.
Frequently asked questions
Why are Kubernetes bills so hard to read?
What is the single biggest source of Kubernetes waste?
How often should a Kubernetes cost review run?
Run the playbook with us
We run this review across your EKS, AKS, GKE, and OKE estate and leave your platform team able to repeat it, with zero provider commissions. Our guarantee: we reduce your cloud spend or we reimburse our service fee. Pricing is either a Fixed Fee scoped up front or Gainshare, a share of verified savings with no retainer and no risk.
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.