Costanalyst
BUYER GUIDE

Kubernetes Rightsizing Tools: Pod Rightsizing Software and Container Rightsizing Platforms Compared

Ten tools that resize Kubernetes workloads, sorted by the question that decides whether you can actually run one in production: what does it have to do to your pods to apply a change? Some only print a number. Some evict and recreate the pod. A newer group changes CPU on a running container without restarting it, which only became a supported Kubernetes primitive very recently. We build a cost platform that deliberately sits in the first group, and we say so on our row.

Last updated August 2026

Spend Console
Sample data
Connected AWS GCP Azure SaaS
Find savings in
Identified

projected this month if unattended

Spend by team

Budget forecast

Projected EoQ $124k
With savings
Read-only · Sample data

The short answer

Kubernetes rightsizing tools fall into three groups and the difference is how they apply a change, not how clever the recommendation is. Recommenders such as Goldilocks, Kubecost, and the Vertical Pod Autoscaler in Off mode produce target CPU and memory requests and leave the change to you. Restart-based actuators apply the new requests by evicting the pod so the scheduler recreates it, which is how nearly every automated rightsizer worked until recently. In-place actuators change CPU on a running container without a restart, which is possible because the InPlacePodVerticalScaling feature reached stable in Kubernetes v1.35. ScaleOps, StormForge by CloudBolt, CAST AI, PerfectScale by DoiT, Kubex, Zesty, and Sedai all automate the change in production; PerfectScale is free up to 200 vCPU per month and StormForge offers a 30-day full trial on one cluster, while the rest quote. Pick a recommender if pods cannot be disrupted and nobody has approved write access yet, and pick an actuator once you accept that rightsizing only saves money when something actually applies it.

Costanalyst is on this list and it belongs in the recommendation and attribution group, not the automation group. We connect cloud accounts, Kubernetes, and SaaS subscriptions read-only, report what is being wasted in dollars, and attribute it to a team. We do not resize pods, evict workloads, or hold write access to your clusters, so if what you need is something that makes the change by itself, one of the actuators on this list is the right purchase and we say which. Product facts, pricing, and platform behavior were checked against vendor primary pages and Kubernetes documentation on 22 August 2026. Where a row says a vendor does not publish a price, that is exactly what it means, and we will not repeat a figure from a competitor blog.

// CRITERIA

How we compared

Five things that actually separate these tools

What it has to do to your pods to apply a change

This is the first question and it eliminates most shortlists in one pass. A pod resource request is part of the pod spec, and for most of Kubernetes history changing it meant replacing the pod. That is why so many teams turn automated rightsizing off after a week: the savings are real, but every adjustment shows up as a rolling restart on workloads that do not enjoy being restarted. Kubernetes now documents a different path. In-place pod resize, gated behind InPlacePodVerticalScaling, reached stable in Kubernetes v1.35 and allows changing the CPU and memory allocation of containers in a running pod while potentially avoiding application disruption. Ask any vendor directly whether their controller uses it, on which resources, and what it falls back to when it cannot.

The limits of in-place resize, because it is not universal

Vendors are starting to advertise in-place resizing as though it removes restarts entirely. It does not, and the Kubernetes documentation is unusually blunt about why. Memory commonly still needs restartPolicy RestartContainer because many applications and runtimes cannot adjust their memory allocation dynamically, so a memory change restarts the container even on a cluster that fully supports the feature. If both CPU and memory change at once and memory is set to RestartContainer, the container restarts. The pod QoS class is fixed at creation and a resize cannot change it. Windows pods do not support in-place resize. Non-restartable init containers and ephemeral containers cannot be resized, though sidecars can. Pods managed by static CPU or memory manager policies are excluded. And when decreasing a memory limit, the kubelet makes only a best-effort attempt to prevent OOM kills, and skips the resize entirely if current usage already exceeds the new limit. Read that list against your own workloads before you believe a zero-restart claim.

Whether it also fixes the node bill, or only the requests

The most common disappointment in this category is a team that cuts requests by forty percent and watches the invoice stay flat. Requests are a scheduling claim, not a charge. You pay for nodes. If you shrink every pod and nothing consolidates the workloads onto fewer machines, all you have done is convert allocated capacity into idle capacity that still bills at full rate. So a rightsizer is only half a product unless it also drives node consolidation, either by bin-packing pods itself or by working correctly with Cluster Autoscaler or Karpenter so that emptied nodes are actually removed. Ask how the tool behaves alongside your node autoscaler rather than assuming they cooperate, and treat node count and cost per core as the metric that proves the project worked, not the reduction in requested CPU.

Write access, blast radius, and what you can scope it to

Everything that saves money here does so by changing production. That makes the security review the longest part of most evaluations, and the sensible move is to shorten it by shrinking the blast radius rather than by arguing about principle. Useful questions: does the controller run entirely inside your cluster or does it call an external control plane, what RBAC does it require, can you scope automation to one namespace or one set of labels while everything else stays in recommendation mode, is there an approval step, and what is the rollback path when a recommendation is wrong. Several vendors now ship an explicit human-in-the-loop mode for exactly this reason, and starting there costs you a few weeks of savings and buys you the approval you need to keep the tool.

How it is priced, and what the price scales with

Four models compete and they are not equally easy to approve. Free and native costs nothing and does the least. Per vCPU subscription, which is how PerfectScale prices, is predictable and grows with the cluster you are trying to shrink, which is a mild but real misalignment. Savings share, which is Zesty position, means you pay against realized savings so the vendor carries the burden of proof. Quote-only enterprise pricing, which covers CAST AI, ScaleOps, Sedai, and Kubex, tells you nothing until you take the call. With any savings-share arrangement the term worth negotiating is the baseline: what counts as a saving, measured against which reference period, and how long the vendor keeps being paid for a reduction that happened once.

// COMPARISON

At a glance

10 Kubernetes rightsizing tools compared

← Scroll to see all columns →

Tool Best for Scope How it applies a change Pricing
Kubernetes native (VPA, in-place resize, Goldilocks) Every cluster, before any tool is purchased Kubernetes Recommend, restart, or in-place (alpha) Free, open source
ScaleOps Continuous automated rightsizing that stays inside your cluster Kubernetes, GPU Automated, continuous Quote from sales
StormForge by CloudBolt Teams that want to tune the HPA and the requests together Kubernetes Automated, ML-driven Free 30-day trial on 1 cluster, then quote
CAST AI Aggressive automation across rightsizing, bin-packing, and spot Kubernetes, GPU, databases Automated, full autopilot available Quote from sales
PerfectScale by DoiT Starting free and scaling by vCPU with a published entry tier Kubernetes, GPU Recommend or automate Free up to 200 vCPU/month, then per vCPU
Kubex (formerly Densify) Policy-controlled automation with a human in the loop by default Kubernetes, cloud VMs HITL or fully automated Free trial, otherwise quote
Zesty Buyers who want the price tied to realized savings Kubernetes, storage, cloud commitments Automated, continuous Usage and savings based, no published figures
Sedai Autonomous optimization beyond Kubernetes, including serverless Kubernetes, VMs, serverless, storage Copilot approval or full autopilot Quote from sales
IBM Kubecost Seeing the waste per namespace before automating anything Kubernetes Recommendations only Free tier, then quote
Costanalyst Finance owners who need the Kubernetes saving in the wider budget Kubernetes, AWS, Azure, GCP, SaaS Read-only, never changes a resource Public, self-serve, from $99/month

Product facts checked July 2026. Vendors change pricing and packaging often, so confirm before you buy.

// DETAIL

Tool by tool

What each tool is genuinely best at

01

Kubernetes native (VPA, in-place resize, Goldilocks)

Best for: Every cluster, before any tool is purchased

The honest first answer, and it moved a long way in the last two releases. The Vertical Pod Autoscaler produces CPU and memory request recommendations from observed usage and can apply them for you. Its update modes matter more than its recommendations: Off produces numbers and changes nothing, Recreate evicts pods to apply them, Auto was deprecated in VPA 1.4.0 and is now an alias for Recreate, and InPlaceOrRecreate attempts an in-place update first and falls back to eviction when it cannot complete one in time. InPlaceOrRecreate is an alpha feature gate that defaults to disabled and has to be enabled on both the updater and the admission controller. Underneath it sits InPlacePodVerticalScaling, which reached stable in Kubernetes v1.35. Goldilocks from Fairwinds wraps VPA in a dashboard so you can read recommendations per namespace without adopting automation at all. Start here for a fortnight. You will learn how much waste you actually have, and the number usually justifies whatever you buy next.

02

ScaleOps

Best for: Continuous automated rightsizing that stays inside your cluster

Positioned as autonomous rather than advisory: it continuously right-sizes CPU, memory, and nodes across VPA, HPA, and Karpenter, then adds smart pod placement and replica optimization so the freed capacity turns into fewer nodes instead of more idle. That combination is the reason it belongs near the top of a shortlist, because rightsizing without consolidation does not move the invoice. It installs with a single helm command and is available self-hosted, as ScaleOps Cloud, or air-gapped, which matters for security reviews that will not accept an external control plane reading production telemetry. A separate GPU platform covers fractional GPU sharing, GPU replica optimization, and batch inference optimization. Pricing is not published. Vendor savings claims run to eighty percent, with named case studies at sixty-two percent CPU and forty percent memory, so treat the headline as marketing and the case studies as directional.

03

StormForge by CloudBolt

Best for: Teams that want to tune the HPA and the requests together

Now sold as StormForge by CloudBolt following CloudBolt acquisition of StormForge, announced 31 March 2025 with terms undisclosed. The distinguishing idea is bi-dimensional autoscaling: instead of treating vertical rightsizing and horizontal pod autoscaling as separate problems, it adjusts resource requests and limits alongside the HPA target utilization so the two do not fight each other. That is a real gap in most tooling, where an aggressive rightsizer lowers requests, the HPA sees higher utilization, and replicas climb until the savings evaporate. Machine learning drives the recommendations, and the vendor describes the patents as patent-pending. The trial is unusually concrete for this category: full optimization on one cluster for thirty days, which is enough to produce an honest before-and-after on real workloads. Headline savings claims of up to eighty percent are vendor claims.

04

CAST AI

Best for: Aggressive automation across rightsizing, bin-packing, and spot

The widest automation surface here. Alongside workload rightsizing it runs cluster optimization, Karpenter cluster optimization, spot instance handling with automated fallback, a GPU product, and separate database and storage optimization. If your goal is the largest possible reduction and you are prepared to let software make production changes without a human in the loop, this is the category benchmark and has been for several years. Two things to plan for. First, that automation needs meaningful write access, which is the longest conversation in most security reviews. Second, CAST AI no longer publishes pricing: the pricing page now states that the model depends on factors specific to your environment and that they need to get in touch to give accurate pricing. Any per-CPU figure you find in an older comparison is stale, including ones still circulating in competitor blog posts.

05

PerfectScale by DoiT

Best for: Starting free and scaling by vCPU with a published entry tier

The most transparent entry point in the automated group and now part of DoiT International. Pricing is based on monthly vCPU consumption with a genuinely usable free tier up to 200 vCPU per month, then Advanced and Expert tiers quoted per vCPU. It covers cost optimization and waste detection alongside performance and resilience issues, which is a useful framing because the fastest way to lose a rightsizing program is one OOM kill in production that nobody predicted. It works with Karpenter, Cluster Autoscaler, and Node Auto Provisioning, and is described as agnostic to all Kubernetes distributions and cloud environments including private data centers, with a self-hosted option. Worth noting that the per vCPU model scales with the cluster you are trying to shrink, so model the cost at your current size and at your target size before signing.

06

Kubex (formerly Densify)

Best for: Policy-controlled automation with a human in the loop by default

Densify has rebranded: densify.com now redirects to kubex.ai, and the product line is split into an Automated Pod Scaler for right-sized pod requests, a Container Sizer for new containers with no usage history, an HPA Optimizer for autoscaling specs, and a Node Optimizer that recommends instance types and CPU-to-memory ratios. A Kubex Automation Controller executes changes within policy. The reason it earns a place on a shortlist is the explicit human-in-the-loop or fully automated choice, which lets you pass the security review in advisory mode and turn automation on per namespace once the recommendations have proven themselves. Densify heritage also means unusually strong node-shape analysis, which is the half of the problem most Kubernetes-only tools ignore. No published pricing; a free trial is offered. The savings figures on the site, including a twenty to sixty percent range, are vendor claims.

07

Zesty

Best for: Buyers who want the price tied to realized savings

Zesty covers multi-dimensional autoscaling, adaptive pod placement to raise node utilization, persistent volume autoscaling to cut storage cost, and compute cost visibility, which makes it broader than a pure pod rightsizer. Persistent volume autoscaling is genuinely differentiated: over-provisioned PVCs are a quiet, permanent line item that almost no rightsizing tool touches, partly because shrinking a PVC is not a thing Kubernetes lets you do casually. Commercially it takes the savings-share position, stating that pricing is based on actual usage and realized savings and that it will never be more than the value delivered, with a claimed minimum 1:3 ROI across the customer base. No tiers, numbers, or free tier are published, and any engagement starts with an analysis of your Cost and Usage Report. If your finance team prefers a variable cost that only appears when savings do, this is the model to ask about.

08

Sedai

Best for: Autonomous optimization beyond Kubernetes, including serverless

The broadest scope on this list and the clearest position on autonomy. Sedai uses reinforcement learning to find configurations for containers on EKS, AKS, and GKE, but also for VMs, serverless functions, storage, and data and streaming workloads, so it suits an organization where Kubernetes is one of several places money leaks rather than the only one. It ships two explicit modes: Copilot, where a human approves each optimization with a click, and Autopilot, where it executes without manual approval. That progression is the right shape for a nervous platform team, and the vendor leans on it, citing eight United States patents on autonomous action in cloud environments and a claim of zero incidents caused by its autonomous actions. No pricing is published. Named customer results include fifty percent savings and a forty-six percent Kubernetes reduction, which are vendor-published case studies rather than independent measurements.

09

IBM Kubecost

Best for: Seeing the waste per namespace before automating anything

Kubecost is a cost allocation and visibility product with request-sizing recommendations attached, not an actuator, and it is worth being precise about that because it appears on almost every rightsizing shortlist. Built on the open-source OpenCost project and acquired by IBM in September 2024, it allocates container spend by namespace, deployment, and label, and surfaces where requests exceed observed usage. The free Foundations tier covers unlimited clusters up to 250 cores with 15-day metric retention, which is enough to quantify the opportunity across a real estate of clusters at zero cost. Use it to build the business case and to keep score afterwards, then pair it with one of the actuators above when someone approves the change. Treating it as a rightsizing tool on its own is how teams end up with a beautiful dashboard and an unchanged bill.

IBM Kubecost compared to Costanalyst
10

Costanalyst

Best for: Finance owners who need the Kubernetes saving in the wider budget

We are on this list for completeness and we are firmly in the recommendation group. Costanalyst connects clouds, Kubernetes, and SaaS subscriptions read-only, reports waste in dollars with the underlying line items, attributes it to a team or cost center, and raises anomaly alerts before the invoice lands. It never holds write access, never resizes a pod, and never moves money, which makes the security review short and the automation column empty. Use it when the question in the room is whether the Kubernetes saving is material next to everything else in the technology budget, or when the platform team has produced a rightsizing number and finance wants it in the same view as the cloud commitments and the SaaS renewals. If the clusters need something to actually apply the change, buy ScaleOps, StormForge, CAST AI, or PerfectScale for that job and keep us for the reporting.

See how Costanalyst works
// DECISION

How to choose

Pick by the problem you actually have

Nothing is allowed to change yet, you just need the numbers

Run VPA in Off mode, or Goldilocks on top of it, and read the recommendations per namespace for two weeks. This costs nothing, requires no vendor, and produces the only artifact that matters at this stage: the gap between requested CPU and memory and what the workloads actually use. Kubecost free Foundations covers unlimited clusters up to 250 cores with 15-day retention if you want the same picture in dollars rather than cores. Almost every team that does this discovers the number is larger than expected, and that number is what wins approval for whatever you buy next. Skipping this step is how rightsizing projects get funded on a vendor estimate and then quietly fail to reproduce it.

Your pods genuinely cannot be restarted

This is the case where the in-place question stops being academic. Long-running training jobs, stateful services with expensive warm caches, and anything with a slow start-up all make eviction-based rightsizing unusable in practice, which is why so many teams turn it off. In-place pod resize is stable as of Kubernetes v1.35, so ask each vendor whether their controller uses it, on which resources, and what happens when it cannot. Then read the exclusions honestly: memory changes usually still restart the container because many runtimes cannot adjust memory allocation dynamically, Windows pods are not supported, and pods under static CPU or memory manager policies are excluded. For many of these workloads the correct answer remains recommendation plus a planned change window rather than continuous automation.

You cut requests and the bill did not move

You have an allocation problem, not a rightsizing problem, and buying a second rightsizer will not fix it. Requests are a scheduling claim; nodes are the charge. If nothing consolidated the workloads onto fewer machines, you converted allocated capacity into idle capacity at the same price. Check node count and cost per core before and after, not requested CPU. Then either configure Cluster Autoscaler or Karpenter so emptied nodes actually terminate, or pick a tool that does bin-packing itself. ScaleOps and CAST AI both drive consolidation directly; Kubex adds node-shape analysis from its Densify heritage. This is the single most common reason a rightsizing project reports success and finance disagrees.

GPU nodes are where the money actually is

CPU rightsizing on a fleet that is mostly GPU is optimizing the wrong axis. Ask specifically about fractional GPU sharing, GPU replica optimization, and inference or batch workload handling, because a general pod rightsizer will happily tune the sidecar and leave an idle accelerator burning. ScaleOps ships a dedicated GPU platform, CAST AI has a GPU product, and PerfectScale covers GPU optimization. Do the arithmetic before the demo: work out what proportion of your cluster cost is accelerator hours, because if it is most of it, the CPU savings figures in every vendor deck are close to irrelevant to your invoice.

Security will not approve write access to production clusters

Say this on the first call rather than discovering it in month two of procurement, because it eliminates most of this market. What remains is the recommendation group, plus the vendors that ship an explicit human-in-the-loop mode you can leave switched on: Kubex offers HITL or fully automated, and Sedai has a Copilot mode where a person approves each optimization with a click. Also ask where the controller runs, since a tool that operates entirely inside your cluster is a materially easier review than one that streams production telemetry to an external control plane. ScaleOps offers self-hosted and air-gapped deployments and PerfectScale offers a self-hosted option, both of which shorten that conversation considerably.

You need to know which team the savings belong to

Rightsizing tools optimize workloads; they are generally poor at telling a CFO whose budget just improved. If the goal is chargeback or showback rather than pure reduction, pair an actuator with an allocation layer. Kubecost allocates container spend by namespace, deployment, and label, and Costanalyst puts the Kubernetes number in the same view as cloud commitments and SaaS renewals so the saving lands in the technology budget rather than in a platform-team dashboard nobody else reads. Decide up front which number you are reporting, because reduced requested CPU and reduced invoice are different figures and presenting the first as the second is how these projects lose credibility.

One cluster, small budget, you want to prove it works first

Two options give you a real before-and-after without a purchase order. PerfectScale is free up to 200 vCPU per month, which covers a genuinely useful cluster and is the only published free tier in the automated group. StormForge by CloudBolt offers full optimization on one cluster for thirty days. Run either against a non-critical namespace, and measure node count and cost, not requested cores. Keep the native VPA recommendations running alongside as a control, so you can see whether the vendor recommendation is materially better than the free one. Sometimes it is, by a lot. Sometimes it is not, and that is worth knowing before you sign an annual contract.

// FAQ

Questions buyers ask

Kubernetes rightsizing tools, answered

What are the best Kubernetes rightsizing tools?

It depends on whether you want a recommendation or an action. For automated rightsizing in production, ScaleOps, CAST AI, StormForge by CloudBolt, PerfectScale by DoiT, Kubex, Zesty, and Sedai all apply changes for you, and they differ mainly in scope, autonomy, and pricing model. For recommendations only, the Vertical Pod Autoscaler in Off mode, Goldilocks, and Kubecost tell you what the requests should be and change nothing. Start with the free options for two weeks to size the opportunity, then buy an actuator once you know the number is worth a contract.

What is pod rightsizing in Kubernetes?

Pod rightsizing means setting each container CPU and memory requests and limits close to what the workload actually uses, instead of the number a developer guessed when the manifest was written. Requests are what the scheduler reserves, so an over-provisioned request permanently occupies capacity nobody consumes, and you pay for the node holding it. Rightsizing closes that gap. It is the largest single source of waste in most clusters because the safe default for an engineer under deadline pressure is always to ask for more than they need.

Can you resize a pod without restarting it?

Yes, with limits. In-place pod resize lets you change the CPU and memory allocation of containers in a running pod while potentially avoiding disruption, and it reached stable in Kubernetes v1.35 behind the InPlacePodVerticalScaling feature gate. In practice CPU resizes in place cleanly, while memory usually needs restartPolicy RestartContainer because many applications and runtimes cannot adjust memory allocation dynamically. Windows pods are not supported, QoS class cannot change, non-restartable init and ephemeral containers cannot be resized, and pods under static CPU or memory manager policies are excluded.

How much do Kubernetes rightsizing tools cost?

Most do not publish a figure. PerfectScale by DoiT is the exception with a free tier up to 200 vCPU per month and per vCPU pricing above it, quoted for the Advanced and Expert plans. StormForge by CloudBolt offers a free 30-day trial covering full optimization on one cluster. Zesty prices on actual usage and realized savings and publishes no numbers. CAST AI, ScaleOps, Sedai, and Kubex all quote from sales. The Vertical Pod Autoscaler, Goldilocks, and OpenCost are free and open source, and Kubecost has a free tier for unlimited clusters up to 250 cores.

Does CAST AI publish pricing?

Not any more. The CAST AI pricing page now states that the pricing model depends on factors specific to your environment and that they need to get in touch to give accurate pricing information, with a form asking for cluster count, GPU usage, and which products you want. Any per-CPU or per-plan figure for CAST AI in an older comparison article is stale, and several such figures are still circulating in competitor blog posts. If you see a number quoted for CAST AI without a link to their own page, do not plan a budget around it.

Is StormForge still an independent company?

No. CloudBolt acquired StormForge in an acquisition announced on 31 March 2025, with terms not disclosed, and the product is now sold as StormForge by CloudBolt. The technology is described as machine-learning-powered Kubernetes resource optimization that automatically adjusts resource requests and limits along with the target utilization of the HPA to match real-time demand. If you are reading a comparison written before spring 2025 it will describe StormForge as a standalone vendor, and stormforge.io now redirects into the CloudBolt site.

What happened to Densify?

Densify has rebranded as Kubex. The densify.com domain now redirects to kubex.ai, and the product line is presented as an Automated Pod Scaler, a Container Sizer for new containers with no usage history, an HPA Optimizer, a Node Optimizer for instance types and CPU-to-memory ratios, and a Kubex Automation Controller that executes changes within policy. It offers a choice of human-in-the-loop or fully automated operation. The GitHub organization is still densify-dev, which is the clearest confirmation of the lineage on the site itself.

Why did rightsizing not reduce my Kubernetes bill?

Almost certainly because nothing consolidated the workloads afterwards. Requests are a scheduling reservation, not a charge; you are billed for nodes. If you halve every request and the same number of nodes keeps running, you have turned allocated capacity into idle capacity at identical cost. Fix it by making sure Cluster Autoscaler or Karpenter can actually drain and terminate the emptied nodes, or by using a tool that bin-packs pods onto fewer machines itself. Measure node count and cost per core, not requested CPU, or the report will say success while the invoice disagrees.

What is the difference between VPA and a commercial rightsizing tool?

The Vertical Pod Autoscaler produces sound recommendations and is free, but its default way of applying them is to evict the pod, and its in-place path, InPlaceOrRecreate, is an alpha feature gate that is disabled by default and needs enabling on both the updater and the admission controller. Commercial tools compete on three things VPA does not do well: applying changes continuously without disruption, driving node consolidation so the savings reach the invoice, and coordinating with the HPA so vertical and horizontal scaling do not work against each other. Run VPA first anyway. It tells you whether the gap justifies a purchase.

Do Kubernetes rightsizing tools need write access to my cluster?

Any tool that applies a change does, and that is the honest trade in this category. Recommendation tools such as Goldilocks, Kubecost, and VPA in Off mode need only read access. Actuators need permission to modify workload resources, and often to influence scheduling and node lifecycle as well. The practical way through a security review is to reduce the blast radius rather than argue the principle: scope automation to one namespace, use a human-in-the-loop mode where the vendor offers one, and prefer deployments that run inside your cluster. ScaleOps offers self-hosted and air-gapped options and PerfectScale offers self-hosted.

How do you rightsize Kubernetes workloads safely?

Work in this order. Measure first with VPA or Goldilocks for at least two weeks so seasonal and weekly peaks are in the data, because a recommendation built on a quiet afternoon will cause an incident on Monday. Start in recommendation mode and compare the tool numbers against the free VPA baseline. Enable automation on one low-risk namespace, watch for OOM kills and latency, then widen by label rather than all at once. Keep limits and requests decisions separate, since memory limits are the ones that kill pods. And confirm your node autoscaler removes the capacity you freed, otherwise nothing you did reaches the bill.

See your savings in dollars

Connect your cloud and SaaS spend read-only and get a prioritized savings plan. Money never moves. No card to start.