Kubernetes Cost Tools Compared: OpenCost vs Kubecost, and Where AWS SCAD Fits

It always starts with the same question

If you run Kubernetes, you know the moment. The monthly cloud bill lands, you open it, and you pause: "Wait — why is it this high?" I'd pull up AWS Cost Explorer and get line items for EC2, EBS, load balancers. Nothing about what I actually wanted to know. Which namespace is driving the bill. Which pods are eating resources. How much of that spend is real usage versus capacity someone reserved and never touched.

That last one is the real Kubernetes trap. You pay for nodes, but pods get scheduled on requests. A team requests 4 CPUs "just in case," uses half of it, and nothing in the AWS bill says a word about that waste. The bill speaks in nodes. What happens inside a node is silence.

I saw the same shape running OpenAPI and payment platforms in finance. When the unit that reserves capacity and the unit that gets billed don't line up, somebody eventually shows up asking whether their team really consumed that much. If you can't answer with a number, the cost conversation turns into a fight about feelings.

So I went looking for a cost measurement tool. OpenCost was the first one I found.

OpenCost has a more solid foundation than I expected

OpenCost measures and allocates Kubernetes and cloud costs in real time. It's a CNCF incubating project under Apache 2.0, so it's free.

The origin story is the interesting part. It started as the cost allocation engine Kubecost built. When Kubecost open-sourced that engine, AWS, Google, Microsoft, and Adobe got involved, and what came out the other end was something closer to a spec for how Kubernetes cost should be calculated. A competitor's core engine becoming the seed of a standard — you don't see that often.

The stated goal is to be "the Prometheus of cost monitoring": a neutral data layer other tools can build on. It allocates cost by cluster, node, namespace, and pod — the units you actually think in — and it accounts for CPU, GPU, memory, and persistent volumes.

Installing it on EKS

Installation was simpler than I expected. In a good way.

Two things to know upfront. OpenCost installs via the official Helm chart only (the old standalone manifests were removed), and Prometheus is required. OpenCost doesn't collect metrics itself — it reads usage data out of Prometheus and computes cost from it. OpenCost is a calculator, not a store. That distinction bites later.

helm repo add opencost https://opencost.github.io/opencost-helm-chart
helm repo update
helm install opencost opencost/opencost --namespace opencost --create-namespace

The moment the pod came up I port-forwarded the UI and looked at my cluster through a cost lens for the first time. Cost per namespace, cost per pod, and an efficiency view comparing requested versus actual usage. Exactly the picture I wanted.

Then I left it running for a few days.

Where reality showed up

After a few days, data started disappearing from the OpenCost UI. It just stopped pulling up history.

I wasn't alone. Digging through community threads, the same complaint kept surfacing: I set up OpenCost, the data shows up fine, and after about a week I can't see anything historical.

People suggest fixes — tweak timeouts, run it locally, try this and that — but everyone who'd used it for a while landed in the same place.

"Export the data to Prometheus and use a Grafana dashboard. Much better than the built-in UI."

The thing is, this isn't a workaround. It's the intended architecture. The UI shipped with OpenCost is a viewer, not a data store. The actual cost history lives in Prometheus, and OpenCost itself only holds a short window in bounded memory.

I'd been trying to use the OpenCost UI as a dashboard, which was never the point. The design is: OpenCost feeds Prometheus, and you stand up your dashboard separately in Grafana.

That distinction matters more than it sounds. It's not "OpenCost doesn't work in production." It's "the OpenCost UI was never designed to be a production dashboard." Before blaming the tool, I had to admit I'd misread where its responsibility ended.

But it did make me step back. Is OpenCost + Prometheus + Grafana actually the right fit for my situation? Or is there a shorter path?

The real competitor: Kubecost

OpenCost's actual competitor is Kubecost. Both deploy into the cluster, both handle real-time cost allocation, and both use the same allocation engine. Same roots, so of course they do.

Kubecost is the commercial product built on top of that shared engine — and "commercial" doesn't mean "paid only." The free tier does considerably more than a default OpenCost setup.

Kubecost's free plan gives you unlimited nodes on a single cluster, a built-in UI that retains history, and savings recommendations. Multi-cluster, long-term retention, SSO/RBAC, and chargeback move to the paid plans (Business starts around $449/month).

There's a lesser-known perk if you're on EKS: the EKS-optimized Kubecost bundle. AWS and Kubecost built it together, and it includes some commercial features on top of the normal free tier at no extra cost. It's also exempt from the Kubecost v3 free tier's $100,000-per-30-days spend limit, so that ceiling isn't a concern for EKS users.

Installing on EKS

Unlike OpenCost, Kubecost bundles its own Prometheus, so you don't need an existing one. AWS documents two install paths: the EKS add-on, straight from the EKS console or AWS CLI, is the simplest; Helm is for when you want finer control over the configuration.

One important change: as of Kubecost v3, the Helm chart moved to an OCI registry on ECR.

helm upgrade -i kubecost \
  oci://public.ecr.aws/kubecost/cost-analyzer \
  --namespace kubecost --create-namespace \
  -f https://raw.githubusercontent.com/kubecost/cost-analyzer-helm-chart/develop/cost-analyzer/values-eks-cost-monitoring.yaml

One thing before you install. Kubecost needs persistent storage. On EKS that means the EBS CSI driver has to be present. If your pods are stuck in Pending, check the PersistentVolumeClaim first with kubectl get pvc -n kubecost. In my experience, half the places you get stuck installing a cost tool are storage.

AWS SCAD — a third option?

About here someone asks: do I really need to install a separate tool? Doesn't AWS just give me this? That's where AWS Split Cost Allocation Data (SCAD) for EKS comes in.

SCAD isn't a third contender alongside OpenCost and Kubecost. It's a different category of tool. OpenCost and Kubecost are cost monitoring tools — they run inside the cluster and hand engineers real-time efficiency analysis. SCAD is a billing data feature that enriches your AWS bill. SCAD answers finance's question, "how much was each namespace billed?" OpenCost and Kubecost answer the engineer's question, "where are we wasting money right now?"

Same costs, different seat. One seat is settling an invoice, the other is hunting waste. Try to cram both into one tool and you get something mediocre at each.

SCAD splits EC2 node costs down to the pod level and surfaces Kubernetes-related detail on top of AWS billing data. Since late 2025 you can pull in up to 50 custom Kubernetes pod labels as cost allocation tags, so you can slice cost by team or environment.

Setting up SCAD

One important thing before you go further. SCAD data does not appear in AWS Cost Explorer. That's spelled out in the AWS docs. Split cost allocation data is only available through the Cost and Usage Report (CUR) and CUR 2.0 data exports. Perfect trap for opening Cost Explorer and wondering where your SCAD data went.

Setup is a two-step opt-in, and only the management/payer account can do it.

1. Enable SCAD: AWS Billing and Cost Management console → Cost Management Preferences → General → select Amazon EKS under split cost allocation data

   Three allocation methods:

   • Resource requests: based on pod CPU/memory requests (simplest)
   • Amazon Managed Service for Prometheus: based on the higher of requests and actual usage (more accurate, but needs an AMP workspace)
   • Amazon CloudWatch Container Insights: the alternative if you're running the CloudWatch agent

2. Enable it in CUR: add split cost allocation data to a new Cost and Usage Report

Pod-level data starts showing up in the report within about 24 hours. From there you query CUR with Athena and visualize in QuickSight. Remember that this follows the billing cycle rather than being a real-time dashboard, and your expectations will stay calibrated.

So what do you actually pick

Let me straighten one thing out. This isn't a three-way race where you pick one. It's two separate decisions.

Decision one: OpenCost vs Kubecost

Go OpenCost if you need real-time efficiency and rightsizing, you're comfortable operating Prometheus/Grafana, and you care about full vendor neutrality and CNCF governance. Same answer if you want to attach your own dashboards or plugin ecosystem. Just know you'll be standing up Prometheus and Grafana alongside it, and don't mistake the built-in UI for a dashboard. That's the mine I stepped on.

Go Kubecost free tier if you want it running on a single cluster with minimum effort, and you need a UI that keeps history plus savings recommendations. For a small single-cluster setup, this is the practical choice.

Decision two: whether to use SCAD

SCAD doesn't replace either tool — it sits alongside them. If finance needs accurate, invoice-grade cost breakdowns, turn SCAD on. Plenty of teams run both: SCAD for financial chargeback, OpenCost or Kubecost for engineering efficiency.

One caveat. Both OpenCost and the Kubecost free service price things at on-demand list rates. If you're on Savings Plans, Reserved Instances, or Spot, the numbers these tools show won't match your actual bill. Fine for tracking efficiency trends, but don't treat them as your invoice.

Where I landed

My situation: one EKS cluster, a handful of nodes, and a preference for not standing up a whole Grafana stack just for this. So I went with Kubecost's free EKS bundle as the in-cluster tool, and I'll enable SCAD separately when finance needs accurate chargeback numbers.

I don't regret starting with OpenCost. Deploying it myself taught me things. That a cost engine and a cost dashboard are two different problems. That the word "free" carries several different meanings. That "built into AWS" and "Kubernetes-native cost tooling" are completely different domains even when they're describing the same dollars. None of that shows up in a comparison table — you learn it by leaving something running for a few days and watching the data vanish.

If you run Kubernetes and can't answer "what does this namespace cost, and how much of that is waste," that's not a small problem. The good news is the tools that produce that answer are mostly free. The real fork isn't whether you have a tool — it's which seat you're sitting in. Decide first whether you're solving engineering efficiency or financial chargeback, then pick the tool that fits that seat. Get the order backwards and you'll install a perfectly good tool and keep chasing the wrong thing.