💡 Originally published on devtocash.com — where this guide stays updated. I write hands-on DevOps/SRE deep-dives there weekly.
The short answer
OpenCost is the free, vendor-neutral CNCF cost-allocation engine: it computes per-namespace/per-workload cost from your existing Prometheus and exposes it as an API and metrics — you build the dashboards, alerts, and reports yourself. Kubecost is the commercial product built on that same engine: a full UI, savings recommendations, budgets and alerts, cloud-bill reconciliation, and (paid) unified multi-cluster views with SSO/RBAC. If you already run Prometheus + Grafana and want cost data, start with OpenCost. If you want cost answers out of the box — "which team overspent, and what should we rightsize?" — Kubecost gets you there faster, and you'll pay once you outgrow the free tier.
Both answer the question your cloud bill can't: AWS tells you what the EC2 fleet cost, not which namespace burned it. Allocation tooling is step one of any real Kubernetes cost optimization effort — you can't cut what you can't attribute.
Same engine, different product
The relationship confuses people, so let's fix that first. Kubecost (the company, acquired by IBM in late 2024) donated its core allocation engine to the CNCF in 2022 as OpenCost, which also carries a vendor-neutral specification for how Kubernetes cost should be computed: take each container's CPU/memory/GPU/storage allocation over time, multiply by the node's per-resource hourly rate, and attribute shared and idle capacity by policy.
So this is not Prometheus-vs-Datadog style rivalry. It's an open core and a product wrapped around it:
- OpenCost = allocation engine + Prometheus metrics + HTTP API + a minimal UI. Apache-2.0, no license gates.
- Kubecost = OpenCost's math plus ETL storage for long retention, a real frontend, savings insights, alerts, cloud integrations, and enterprise features behind a paid tier.
That means the numbers agree when configured the same way. You're choosing how much product you want on top of the math, not whose math to trust.
Installing OpenCost (and actually querying it)
OpenCost assumes you already have Prometheus scraping your cluster — if you don't, set that up first with the Prometheus + Grafana production setup guide. Then:
helm repo add opencost-charts https://opencost.github.io/opencost-helm-chart
helm install opencost opencost-charts/opencost \
--namespace opencost --create-namespace \
--set opencost.prometheus.internal.enabled=false \
--set opencost.prometheus.external.enabled=true \
--set opencost.prometheus.external.url="http://prometheus-server.monitoring.svc:80"
Point it at your Prometheus URL — the default assumes prometheus-server in a prometheus-system namespace and silently computes garbage if that's wrong (check the opencost pod logs for scrape errors before trusting any number).
The allocation API is the payoff. Per-namespace cost for the last 7 days:
kubectl port-forward -n opencost svc/opencost 9003:9003
curl -sG http://localhost:9003/allocation/compute \
--data-urlencode "window=7d" \
--data-urlencode "aggregate=namespace" \
--data-urlencode "accumulate=true" | jq '
.data[0] | to_entries[]
| {ns: .key, totalCost: .value.totalCost, cpuEff: .value.cpuEfficiency}'
You get cpuCost, ramCost, pvCost, totalCost, and — critically — cpuEfficiency (usage ÷ requests). Efficiency under ~0.4 is your rightsizing hit list; that same API is what I wired an autonomous FinOps agent to in an earlier post.
OpenCost also exports cost as Prometheus metrics (node_cpu_hourly_cost, node_ram_hourly_cost, container_cpu_allocation, pv_hourly_cost), so cost becomes just another PromQL dimension. Rough monthly CPU cost per namespace, straight in Grafana:
sum by (namespace) (
container_cpu_allocation * on(node) group_left() node_cpu_hourly_cost
) * 730
That composability is OpenCost's real strength: cost lives next to your latency and saturation panels, alertable with the same Alertmanager rules ("namespace X grew 40% week-over-week"). The weakness is symmetric — nothing exists until you build it. The bundled UI is a basic allocation view, not a FinOps console, and there's no built-in idea of budgets, reports, or recommendations.
Installing Kubecost (and what you get for the extra weight)
helm repo add kubecost https://kubecost.github.io/cost-analyzer/
helm install kubecost kubecost/cost-analyzer \
--namespace kubecost --create-namespace
kubectl port-forward -n kubecost deployment/kubecost-cost-analyzer 9090
By default it ships its own bundled Prometheus (you can point it at an existing one, but check version compatibility notes first — this is the most common install friction). Open http://localhost:9090 and you immediately get what OpenCost makes you build:
- Allocation views by namespace, deployment, label, team, with idle cost attribution policies you toggle in the UI.
- Savings insights: rightsizing recommendations with concrete request values, abandoned workloads, unclaimed PVs and unattached disks, underutilized nodes.
- Budgets and alerts: "alert Slack when team-payments exceeds $2,000/month" is a form, not a PromQL project.
- Network cost monitoring via an optional daemonset that attributes egress/cross-AZ traffic — a line item OpenCost largely leaves dark, and often 10–20% of a real bill.
- Cloud billing reconciliation: hook up the AWS CUR (or GCP/Azure billing export) and Kubecost adjusts its list-price estimates to what you actually pay — reserved instances, savings plans, negotiated discounts, spot realized prices.
That last one matters more than it sounds. Every allocation tool starts from list-ish pricing; if 60% of your fleet is spot or covered by savings plans (as it should be after working through the AWS cost optimization playbook), unreconciled numbers can be off by 2×. OpenCost has cloud-cost ingestion too, but Kubecost's reconciliation is the mature, supported path.
The catch is the tiering. The free tier is genuinely useful for a single cluster but caps metric retention (~15 days) and gives you per-cluster views only. Unified multi-cluster aggregation, long retention, SSO/RBAC, and support live in the paid tiers — and that's exactly the point where platform teams either pay up or fall back to OpenCost + Thanos and build the aggregation themselves.
Feature by feature
| Dimension | OpenCost | Kubecost |
|---|---|---|
| License / cost | Apache-2.0, free | Free tier; paid for enterprise features |
| Allocation math | The reference engine | Same engine |
| UI | Minimal allocation view | Full FinOps console |
| Retention | Whatever your Prometheus keeps | ~15d free, years on paid (ETL store) |
| Multi-cluster | DIY (Thanos/Mimir + your dashboards) | Unified view on paid tiers |
| Rightsizing recommendations | No — export data, decide yourself | Yes, with concrete request values |
| Budgets / alerts | Build with PromQL + Alertmanager | Built-in, UI-configured |
| Network/egress cost | Limited | Daemonset-based attribution |
| Billing reconciliation (CUR etc.) | Basic cloud cost ingestion | Mature, supported |
| On-prem custom pricing | Yes (custom pricing config) | Yes |
| Ops footprint | One deployment beside Prometheus | Prometheus + ETL + frontend stack |
Caveats both tools share
Garbage requests in, garbage allocation out. Cost is attributed from requests (plus usage for efficiency). Pods with no requests get idle-cost treatment and your per-team numbers stop meaning anything. Fix requests first — it's the same prerequisite that makes Karpenter's bin-packing actually save money.
Idle cost policy is a political decision. A node that's 50% empty costs real money; whether that idle slice lands on the teams sharing the node, on a platform cost center, or nowhere changes every chargeback number. Both tools let you choose — decide the policy before you show anyone a dashboard, or the first report kicks off a fairness argument instead of an optimization.
Estimates until reconciled. Without billing-export reconciliation, treat every number as directionally correct, not invoice-accurate. Directional is fine for finding waste; it is not fine for chargeback.
Decision framework
| Your situation | Run |
|---|---|
| Prometheus + Grafana already core to your stack, want cost as metrics | OpenCost |
| Single cluster, want visibility today with zero build effort | Kubecost free |
| Need chargeback/showback across many clusters with SSO | Kubecost paid |
| Feeding cost data to automation or an agent via API | OpenCost (lighter, no license gates) |
| FinOps team that wants savings recommendations, not raw data | Kubecost |
| Air-gapped / strict OSS-only policy | OpenCost |
A common evolution: start with OpenCost because it's a 10-minute Helm install against Prometheus you already run; adopt Kubecost when the org starts asking for reports, budgets, and multi-cluster rollups you'd otherwise be hand-building in Grafana. Because the engine is shared, the numbers survive the migration — your FinOps practice doesn't reset.
Bottom line
OpenCost gives you the cost engine for free and assumes you'll integrate it like any other metrics source; Kubecost sells you the cost product on top of the same math. Pick OpenCost when cost should be one more PromQL dimension in a stack you already operate. Pick Kubecost when you need recommendations, budgets, reconciliation, and multi-cluster reporting without building them — and budget for the paid tier when "single cluster, 15 days" stops being enough. Either way, allocation is only the visibility layer: the actual savings come from acting on it — honest requests, rightsizing, and node-level bin-packing.
📌 Read the latest version of this guide — plus the full library of DevOps, SRE, Kubernetes, observability & cloud-cost guides — on devtocash.com.
Top comments (0)