Kubernetes Cost Optimization: 8 Steps, 23 Tools & Case Studies
Kubernetes clusters can look entirely healthy while the bill climbs. Autoscaling is configured, dashboards are green, and spend rises anyway. In a survey, 42 % of 455 platform engineers named cost as their number one Kubernetes challenge, while 88 % saw total cost of ownership rise year on year.1
We gathered 68 Kubernetes cost optimization case studies and mapped every use case mentioned to each vendor that published it:
Darker cells mean more mentions. Blank cells mean that tool has no published case for that use case.
Scroll on for 8-steps guide with real-life examples to cut cluster spend and the comparison of Kubernetes cost optimization tool.
1. Measure before changing anything
Every number in the rest of this guide is a delta, and a delta needs a starting point. Without a baseline captured before the first change, there is no way to tell whether step 1 worked, and no way to attribute step 3’s savings to consolidation rather than to the rightsizing that preceded it. This matters more here than in most engineering work, because all six actions reduce the same bill and their savings do not add. Freeing capacity in step 1 produces nothing on the invoice until step 3 removes the nodes.
Measure four things:
- Requested versus used CPU and memory, per workload. The gap is your step 1 backlog, sorted by size.
- Cost per namespace and per workload. This is what makes step 2 quotas a negotiation rather than an imposition.
- Bin-packing efficiency, allocatable versus requested per node. Step 3’s target.
- Idle cost by hour of day and day of week in non-production. Sizes step 5 before you build it.
Measure across at least one full business cycle. Seven days is the minimum and thirty is better. The window is not procedural caution. Step 1 sets memory requests at the observed maximum, and an observed maximum is only as good as the window that observed it. A maximum taken over 48 hours misses a weekly batch job and produces an OOMKill the following Sunday.
Tooling
- Cost allocation: OpenCost, the CNCF project behind the allocation model, is the gratuit floor. Kubecost’s gratuit tier wraps the same engine in a UI up to 250 cores.
- Utilisation: Prometheus with kube-state-metrics is the substrate. Robusta KRR reads it directly without installing anything in-cluster.
- Wider spend: Where Kubernetes is one part of a bill that finance also has to explain, CloudZero, Vantage and Finout sit above this layer rather than replacing it.
Both cost tools attribute by label, so labelling comes first. Unlabelled spend is the most common reason a baseline turns out to be useless three weeks later.
Each action below states the recommendation, the method, the configuration, and a company that took that step. Every case study and every statistic carries a source link.
2. Set namespace quotas as guardrails
Savings decay as teams deploy new workloads with no requests specified. A LimitRange supplies default requests to containers that omit them, and a ResourceQuota caps what a namespace can consume in aggregate.
Deploy the LimitRange before the ResourceQuota. Once a quota constrains a resource, any pod without a request for that resource is rejected at admission, so the reverse order breaks deployments.2
Each load balancer is billed separately by the cloud provider, and orphaned volumes continue to bill after their pods are gone.
2. Rightsize CPU and memory requests
Requests determine node count, and node count determines the bill. Most clusters run far below the capacity they pay for, because requests were guessed once and never revisited. One analysis of 23 000 production clusters across AWS, Azure and Google Cloud found average CPU utilisation at 8 %, memory at 20 % and GPU at 5 %. 3
Set CPU requests near the 95 percentile of observed usage. Set memory requests at the observed maximum rather than a percentile, and set the memory limit equal to the request. A percentile leaves the container short during the remaining traffic, and because the limit matches the request, that shortfall arrives as an OOMKill rather than a slowdown.
Omit the CPU limit. CPU throttling degrades latency without killing the pod, and the request already reserves what the workload needs.
The Vertical Pod Autoscaler in recommendation-only mode produces these figures at no production risk.
Read the recommendations with kubectl describe vpa payments-api and compare the target value against the current request.
Real-life case study: Tryg Insurance
Tryg Insurance is the largest general insurer in the Nordic region and runs Kubernetes on Oracle Cloud Infrastructure. Its engineering team combined the Horizontal Pod Autoscaler and the Vertical Pod Autoscaler to right-size workloads dynamically while holding service levels, and reduced Kubernetes cloud costs by 50 % using open-source autoscalers alone, with no commercial optimisation platform.4
4. Consolidate nodes with Karpenter, and scale idle workloads to zero
Rightsizing frees capacity, but that capacity sits on nodes that keep running until something removes them. Karpenter provisions instances just in time and repacks workloads onto fewer nodes. KEDA scales queue-driven workloads down to zero replicas, which a standard Horizontal Pod Autoscaler cannot do.
Set the consolidation policy to WhenEmptyOrUnderutilized. The alternative, WhenEmpty, restricts disruption to nodes holding no workload pods at all, and those rarely occur without intervention. 5
A narrow instance list defeats this, because Karpenter cannot find cheap outliers and your spot resilience drops. You should let it choose across whole instance families.
Real-life case study: Adidas
Adidas runs multiple Kubernetes clusters on AWS EKS. Their platform engineering team adopted Karpenter for node provisioning, added KEDA for event-driven scaling, auto-created Vertical Pod Autoscaler objects through Kyverno policies, and used kube-downscaler for idle environments. They reduced the cost of running their Kubernetes clusters on AWS by up to 50 %, using an entirely open-source stack.6
5. Prepare properly before moving workloads to spot
Spot instances offer the largest discount available and the narrowest applicability. Nothing should move to spot until PodDisruptionBudgets, instance diversification, topology spread and termination handling are all in place.
A PodDisruptionBudget that leaves no headroom blocks all voluntary disruption, including Karpenter consolidation, so the values need slack. 7
Real-life case study: Delivery Hero
Delivery Hero operates 390 applications across 43 countries, with roughly 90 % of workloads running on AWS EKS. Their team migrated to Spot Instances over approximately six months, building termination handling and a descheduler into the process rather than switching capacity types directly.
- Infrastructure costs fell by around 70 %
- Spot discounts reached up to 90 % against on-demand pricing
- The platform absorbs traffic spikes of 4 to 5 times normal volume.8
6. Shut down non-production on a schedule
Development and staging environments carry little or no load overnight and at weekends. Scheduled shutdown is technically simple and politically uncontested, which makes it the quickest saving to deliver and a useful first action where harder changes will need support later.
Apply the schedule by default across non-production namespaces and require teams to opt out explicitly. A policy that requires action to join reaches fewer teams than one that requires action to leave.
The saving only reaches the invoice if node consolidation is already running, since scaled-down deployments leave empty nodes behind.
Real-life case study: Bud Financial
Bud Financial enriches financial transaction data for the financial services sector and runs roughly 25 clusters on Google Kubernetes Engine. Their team used scheduled pause and resume to shrink cluster nodes overnight and at weekends, alongside daily rebalancing.
- Costs fell by 47 % from the scheduling change alone
- The schedule removed 80 hours of cluster operation per week
- Resource utilisation rose above 90 %.9
7. Migrate compatible workloads to ARM
ARM-based instances change unit price rather than competing for the same idle capacity as the actions above, so these savings genuinely stack with the rest. The blockers will be dependencies without ARM64 builds.
Users should scope this per workload rather than across the estate, and build multi-architecture images before scheduling anything.
Real-life case study: Pinterest
Pinterest migrated its web API workload to AWS Graviton instances running on ARM64, motivated by both cost and carbon reduction.
- Costs fell by 47 %
- Compute consumption fell by 38 %
- Carbon emissions fell by 62 %.10
8. When tuning runs out, change the architecture
The six actions above tune workloads inside existing clusters. Once they are exhausted, further gains require architectural change rather than further tuning.
Two published results mark the practical limit. InCred Finance cut spend by 30 % on clusters its team already considered well optimised, and Yotpo achieved 30–40 % while already running 80 % of workloads on spot instances. Beyond that range, the remaining waste no longer sits inside the clusters. It sits in the number of clusters. Each one carries a control plane charge and forms a scheduling island that bin-packing cannot cross.
Multi-tenancy removes both costs. Instead of dedicating a cluster to each customer, team or environment, virtual clusters run on shared physical infrastructure. Each tenant receives its own API server and virtual control plane while nodes are pooled. This eliminates the per-cluster control plane charge and allows bin-packing across the shared node pool rather than within isolated estates.
yaml
bash
Two mechanisms are available. Namespaces are always cheaper, so the choice is made on the separation tenants require, not on cost.
- Namespaces partition a single cluster and add no control plane of their own. They are sufficient when tenants trust each other and can share one API server and one set of CRDs.
- Virtual clusters give each tenant its own API server, running as a workload on the host. That cost is justified in two cases: tenants that need their own cluster-scoped resources, and isolation requirements that a shared API server cannot meet.
Real-life case study: Atlan
Atlan is a data catalogue company that hosts the platform for roughly 95 % of its customers, many in healthcare and finance where data isolation is contractual. It ran one full EKS cluster per customer and passed 100 clusters, an estate that was expensive to run around the clock and hard to maintain. From Q1 2022 it evaluated multi-tenancy options and rebuilt on vCluster, giving each customer a virtual cluster rather than a physical one.
- Physical EKS clusters fell from more than 100 to 20, still serving 100+ customers
- Kubernetes spend fell by $600 000.12
Ajouter comme source préféréeOrder of execution
Commitments sit last despite being the easiest action. Buying them before rightsizing locks in one to three years of the waste rightsizing was about to remove. It is the most expensive sequencing error available, and it is common because it needs a purchase rather than engineering work.
Action 7 is a branch, not a step. Take it only once the first six are complete and the result is still short, since it changes how many clusters run rather than how efficiently each one runs.
Kubernetes cost optimization tools
We plotted tools with three or more published case studies covering 47 of the 68 case studies in the dataset:
- Horizontal: how many case studies each tool has, counted once each.
- Vertical: how many distinct use-case categories those cases span, out of ten. A tool counts once per category no matter how often it appears there, so CAST IA’s 12 separate rightsizing mentions contribute 1 toward its score of 10.
- Bubble size: how many of the eight strategy stages the tool appears in.
Open-source frameworks
Open-source frameworks can be deployed for stages from 0 to 6. Users own the upgrades, the version churn, the Prometheus retention bill, and the judgement calls that a commercial recommender would make for them.
Each of these owns a different field, which is why several run at once.
- Robusta KRR or VPA in
updateMode: "Off"produces the step 1 backlog. Writes nothing. - Karpenter owns nodes: provisioning, consolidation, instance selection, spot diversification, architecture. Carries steps 3, 4 and 6.
- KEDA owns replica counts, including scale to zero, which HPA alone cannot do.
- py-kube-downscaler or kube-green owns the non-production schedule. Cheapest saving on the list.
- OpenCost measures throughout and participates in nothing.
Commercial platforms
Every commercial tool takes one of three positions on the node layer. That is the decision, and it matters more than price or feature count, because step 3’s NodePool manifest either survives or it does not.
- Leave it alone: StormForge, PerfectScale, Sedai and Kubex rightsize workloads only. They need Karpenter or Cluster Autoscaler underneath and never touch it. The safest addition to an existing setup.
- Work with it: ScaleOps adds bin packing on top of Karpenter. nOps tunes an existing Cluster Autoscaler or Karpenter rather than substituting its own. More coverage, provisioner still yours.
- Replace it: CAST IA and Spot Ocean install their own provisioner and discard the manifest. Broadest coverage, least control.
- Visibility tools sit outside: OpenCost, Kubecost, CloudZero, Vantage and Finout only read, so they conflict with nothing and stack freely. Run one regardless of what else is adopted.
How to combine these tools
The invoice is based on nodes running, not on requests declared. Rightsizing lowers requests, which frees space on existing nodes but does not remove any of them, so the bill is unchanged until a node tool consolidates that space away. Node tools alone fail for the mirror reason: they pack whatever requests they are given, so over-padded requests simply get packed more tightly.
Two ways to cover both layers:
- Two tools: VPA, StormForge or PerfectScale for requests, plus Karpenter for nodes. Cheaper, and the node layer stays under direct control.
- One platform: CAST IA, Zesty or Spot Ocean do both in a single product. More expensive, and their provisioner replaces Karpenter.
Five tool combinations that break things:
- Two mutating rightsizers on one deployment: VPA in
Autoalongside StormForge, ScaleOps, PerfectScale or Zesty means two controllers writing different numbers to the same field. One mutating admission controller per workload. - Karpenter and Cluster Autoscaler on one node group: Both provision against the same unschedulable pods, so the cluster ends up with roughly double the nodes it needs.
- VPA and HPA on the same metric: Usage rises, VPA raises the request, measured utilisation falls because it is usage over request, HPA removes replicas, load per pod rises, repeat. Safe when HPA scales on something VPA does not touch, such as queue depth via KEDA.
- Two commitment tools on one payer account: Both buy against the same uncovered spend, locking in over-commitment for one to three years.
- Two full platforms: CAST IA, Zesty and Spot Ocean each install their own provisioner and each expect to own it.
Further reading
Citer cette recherche
Choisissez le format qui correspond à votre lieu de publication. Coller la version avec lien dans votre CMS préserve le lien retour.
@misc{simsek2026,
author = {Şimşek, Hazal},
title = {{Kubernetes Cost Optimization: 8 Steps, 23 Tools & Case Studies}},
year = {2026},
month = sep,
howpublished = {\url{https://aimultiple.com/kubernetes-cost-optimization}},
note = {AIMultiple. Consulté le 14 Septembre 2026}
}Liens de référence
Soyez le premier à commenter
Votre adresse courriel ne sera pas publiée. Tous les champs sont obligatoires. Les commentaires sont laissés dans leur langue d'origine.