Your Kubernetes Cluster Can Run for 40% Less. Here Is How to Find the Savings.

Many Kubernetes clusters use about a fifth of the capacity they pay for. The good news is that most of that gap can be closed without changing application code or lowering availability. This guide gives you a two-minute check and the four steps we use. It is based on a real engagement where the monthly bill fell from $18,000 to about $10,800.

Two-minute self-check

Answer these honestly:

1. What is the average CPU and memory utilisation of your nodes over the last 60 days?
2. Can you name the cost of each team or service, per month?
3. Are pod requests based on measured usage, or on a guess made at launch?
4. Does the cluster add and remove nodes by itself when traffic changes?
5. What share of your baseline capacity is covered by reserved or savings-plan pricing?

If you can answer four or more, you are in good shape. Each answer you cannot give is a place where savings are waiting.

Where the savings usually are

• Requests set at launch and never revisited: pods ask for far more than they use, so nodes look full while they are mostly idle.
• Node pools left from services that no longer exist.
• No autoscaling, so the cluster is sized for the busiest hour all month.
• Everything on on-demand pricing, including steady baseline load and fault-tolerant jobs.

The plan, in four steps

1. See the cost per workload. Collect 60 days of metrics and map every pod to the instance cost behind it. Label by team and namespace so each owner sees their own number.
2. Rightsize. Set requests and limits from observed usage, remove unused node pools and choose smaller instance types for non-critical workloads. The same workload then fits on fewer nodes.
3. Autoscale. Enable the Cluster Autoscaler with sensible node templates, add an application autoscaler such as KEDA for traffic peaks, and set pod disruption budgets so scale-down is graceful.
4. Buy capacity the smart way. Cover the steady baseline with reserved capacity, run fault-tolerant workloads on diversified spot instances and keep an on-demand fallback.

What it looked like in practice

On an e-commerce cluster, nodes ran at about 20% utilisation. The node pool went from 20 to 14 nodes for the same workload, and the monthly cost went from $18,000 to about $10,800, which is $86,400 a year. Throughput stayed the same, deployments got faster and every team can now see its own cost. Details: the case study.

Next step

Run the self-check today. If it shows gaps, book a call and we will look at your cluster together.