Kubernetes rightsizing, fixed at the source

Most Kubernetes clusters are oversized, and yours probably is too.

Engineers set CPU and memory requests from estimates and nobody estimates low. Multiply that across a few hundred workloads and you’re paying for a lot of capacity that sits idle. The scheduler reserves whatever was requested, used or not. On the bill it shows up as one node pool line item, and if your workloads aren’t labelled you can’t even tell which team it belongs to, let alone fix it. Every new pull request can compound the problem, and nobody reviewing the YAML sees a price.

Infracost now rightsizes Kubernetes workloads using your cloud bill and Datadog utilization. Each fix goes wherever your team will act on it: Slack, a ticket, your coding agent or a pull request. Rightsizing clears out the waste you already have, but any new pull request can add it right back. So on every pull request going forward, Infracost estimates the cost of Kubernetes changes and enforces your organization’s labels, so costs are attributed correctly from the source and anyone reviewing the YAML can see what it costs.

Rightsize: find the waste you’re already paying for

You can’t rightsize from a manifest. You have to watch the workload run, and you have to know what it costs you.

So Infracost connects to two things:

• Your cloud billing data. Savings are priced at your real rates, discounts included.

• Your observability platform. Datadog to start, for container-level CPU and memory utilization over time.

Infracost then finds workloads running well below their requests and suggests a new size. By default it sizes to P95 utilization, the level a workload stays under 95% of the time, which leaves headroom for traffic spikes. Sizing to the average looks great on paper, right up until someone gets paged at 2am.

Remediate: fix it in code

Rightsizing recommendations go wherever your team already works:

• Slack. Send it to the team that owns the workload, with the savings and the exact change.

• A ticket. Create a ticket in your issue tracker for the owning team, with the savings and the exact change attached, so the fix gets planned into their backlog.

• Your coding agent. Hand it to Claude, Cursor or whatever your engineers use, and it makes the change with the cost context attached.

• A pull request. Infracost opens a PR against the workload definition. Your team reviews and merges it like any other change.

Putting the fix in code is important. Plenty of rightsizing tools patch the running cluster directly. The cluster shrinks but the definition in your repo still has the old numbers, so the next deploy puts them straight back. You end up with a repo and a cluster that disagree.

With Infracost the new request lives in the workload definition. It goes through code review and survives every deploy after that. Your repo stays the source of truth.

Prevent: keep the waste from coming back

Rightsizing clears out the waste you already have, but any pull request can add it back.

Twelve lines of YAML:

 spec:
-  replicas: 2
+  replicas: 6
   template:
     spec:
       containers:
         - name: db
           resources:
             requests:
-              cpu: "1"
-              memory: 4Gi
+              cpu: "4"
+              memory: 16Gi
   volumeClaimTemplates:
     - spec:
         resources:
           requests:
-            storage: 100Gi
+            storage

 spec:
-  replicas: 2
+  replicas: 6
   template:
     spec:
       containers:
         - name: db
           resources:
             requests:
-              cpu: "1"
-              memory: 4Gi
+              cpu: "4"
+              memory: 16Gi
   volumeClaimTemplates:
     - spec:
         resources:
           requests:
-            storage: 100Gi
+            storage

 spec:
-  replicas: 2
+  replicas: 6
   template:
     spec:
       containers:
         - name: db
           resources:
             requests:
-              cpu: "1"
-              memory: 4Gi
+              cpu: "4"
+              memory: 16Gi
   volumeClaimTemplates:
     - spec:
         resources:
           requests:
-            storage: 100Gi
+            storage

Replicas go from 2 to 6. The database container’s requests go from 1 vCPU and 4Gi to 4 vCPU and 16Gi. The volume claim template goes from 100Gi to 500Gi. Every line is defensible. It gets approved in forty seconds.

That change costs about $1,110 a month. You won’t spot it by reading the diff. Kubernetes cost is requests × replicas × storage class, and in a Helm repo those values are often spread across different files. Nowhere in the manifest is there a dollar figure.

Infracost puts one there.

Point it at the repo that holds your manifests, Helm charts or Kustomize overlays. It reads them statically, prices what each workload reserves, and shows the number where the decision gets made:

• In the pull request. A cost comment tied to the commit, visible to reviewers and platform owners, and able to sit behind a policy gate that blocks the merge.

• In the editor. The engineer changing memory: 4Gi to 16Gi sees the cost while they type, including on branches CI never sees.

• Inside the agent loop. Coding agents run the same check, price their own changes, and correct the sizing before they open a PR.

It covers Deployments, StatefulSets (including per-replica volume claim templates), DaemonSets, Jobs and CronJobs, standalone PersistentVolumeClaims, LoadBalancer Services, and vendored Helm subcharts. There’s no cluster connection, no agent to install, and nothing for security to review.

The pricing model is deliberately simple. It uses two flat reference rates for vCPU and memory, taken from OpenCost’s published defaults. Any engineer can check the arithmetic in their head, and the same manifest always gives the same figure.

That’s a different choice from rightsizing, on purpose. Rightsizing measures money you’re already spending, so it uses your bill. A pull request estimate has to stay stable and easy to check, so it uses reference rates.

Labels, enforced at author time. Infracost treats Kubernetes labels as tags, so the tagging policies you already run on Terraform now cover workloads, volumes and load balancers too. Policies evaluate after Helm templating and Kustomize transforms, so labels from _helpers.tpl or commonLabels count. That matters because labels can’t be backfilled. Once a workload ships unlabelled, its spend can’t be allocated to anyone.

How it fits together

Put together, Infracost now covers a Kubernetes workload for its whole life:

1. While it runs, rightsizing compares requests against real usage, priced against your real bill.

2. When it’s oversized, the recommendation goes to Slack, your coding agent or a pull request, and the fix lands in code.

3. Before the next change merges, cost estimates and label policies catch the expensive change and the unlabelled workload.

And because every fix is a code change, it goes through the same check. The rightsized workload gets priced and policy-checked in its own pull request, like everything else.

Get started

Connect your cloud billing data and Datadog in Infracost Cloud, and rightsizing recommendations start arriving wherever you’ve pointed them.

To stop new waste at the same time, point Infracost at your repo and Kubernetes cost estimates and label policies show up in your pull requests. No cluster access required.

If you run something other than Datadog, tell us what it is. Demand decides which integration we build next.

Want to see what it finds in your clusters? Book a demo or try Infracost for free.