Kubecost on EKS: measuring the real cost per team and per service

A ten-namespace EKS cluster shows up as a single line on the AWS bill: the cost of the EC2 (or Fargate) capacity behind the node groups, plus the control plane fee. No breakdown by team, service or environment — just a total. Cast AI’s 2026 Kubernetes optimization report, based on tens of thousands of analyzed clusters, measures average CPU utilization at 8% and memory at 20% before any optimization — both down from the prior year. Datadog’s State of Cloud Costs reaches a similar conclusion: 83% of container costs go to idle resources, split between 54% over-provisioned infrastructure and 29% oversized pod requests. On a cluster shared by several teams, nobody knows who caused what — so nobody fixes anything.

Two paths get you out of that fog: the free AWS-native feature, and Kubecost, the third-party tool that has dominated the Kubernetes cost-visibility market since IBM acquired it in 2024. This article details what each actually covers, where native stops, and how to roll them out without burning a full sprint.

What AWS already gives you, for free

Split Cost Allocation Data for Amazon EKS, launched in April 2024, breaks down EC2 and Fargate node costs at the pod level in the Cost and Usage Report (CUR), prorated by actual CPU and memory consumption — at no extra cost, available in every AWS commercial region. Two recent additions extend its reach:

• November 2024: the feature can use CloudWatch Container Insights metrics to refine pod-by-pod attribution, including for GPU/accelerator workloads (Trainium, Inferentia, NVIDIA/AMD GPUs).
• October 2025: support for importing up to 50 custom Kubernetes labels per pod as cost allocation tags — team, cost-center, application, environment become directly filterable in the CUR, with no extra tooling.

In practice, once allocation tags are activated in Billing and Cost Management, every EKS node line in the CUR splits into sub-lines by namespace and label. That’s enough for monthly finance reporting or quarterly chargeback between teams — and it requires neither Helm nor a component running on the cluster.

The structural limitation: the CUR updates with a typical 24-48 hour delay, and the granularity stays that of a billing report — not an operational dashboard a team checks daily to decide on a rightsizing move.

Where Kubecost and OpenCost go further

Kubecost runs on OpenCost, the cost-calculation engine IBM pushed into CNCF incubation (Apache 2.0 license) after acquiring Kubecost in September 2024 — the same deal folded the tool into IBM’s FinOps suite alongside Cloudability (formerly Apptio) and Turbonomic. Three concrete gains over the AWS-native option:

1. Real time instead of T+1 day. Kubecost queries Prometheus continuously — dashboards reflect cluster state within minutes, catching a cost spike during a deployment rather than at month-end.
2. Actionable rightsizing recommendations. Kubecost calculates, pod by pod, the gap between requests and actual consumption, and suggests corrected requests/limits values you can apply directly — not just an idle percentage.
3. Multi-cluster aggregation and network costs. Beyond a single EKS cluster, Kubecost consolidates several clusters (multi-region, multi-account) and models inter-AZ and inter-region data-transfer costs, a line item Split Cost Allocation Data doesn’t cover.

To sharpen accuracy further, Kubecost can integrate directly with the AWS CUR to reconstruct the rate actually paid per resource — Reserved Instances, Savings Plans and Spot instances included — instead of a theoretical on-demand rate, via a dedicated cloud reconciliation pipeline.

What it actually costs

The often-overlooked point: Kubecost has a permanently free tier, not just a trial. The self-hosted Foundations tier covers up to 250 combined cores, unlimited clusters within that cap, 15-day metric retention, unlimited users, multi-cloud support (EKS, AKS, GKE, on-prem) and OpenCost integration — plenty for an organization running one or two modestly sized clusters. The free cloud version caps at 50 nodes and 5 users, also with 15-day retention. AWS also distributes an AWS-optimized Kubecost bundle at no extra charge via the EKS add-on.

Beyond 250 cores, or for advanced features (SSO, fine-grained RBAC, support SLAs), you move to the Enterprise Self-Hosted or Enterprise Cloud tiers — quote-only pricing. Figures circulating for real deployments range roughly from $40,000 to $144,000/year, an order of magnitude to weigh against the actual Kubernetes compute volume in play before committing.

Rolling it out on an existing cluster

The most direct path is the official Helm chart, with CUR integration configured at install time:

resource "kubernetes_secret" "kubecost_cur_integration" {
  metadata {
    name      = "cloud-integration"
    namespace = "kubecost"
  }
  data = {
    "cloud-integration.json" = jsonencode({
      aws = [{
        athenaBucketName = "aws-athena-query-results-kubecost"
        athenaRegion     = "eu-west-3"
        athenaDatabase   = "athenacurcfn_kubecost_cur"
        athenaTable      = "kubecost_cur"
        projectID        = "470508210570"
        masterPayerARN   = "arn:aws:iam::470508210570:root"
      }]
    })
  }
}

resource "helm_release" "kubecost" {
  name             = "kubecost"
  repository       = "oci://public.ecr.aws/kubecost"
  chart            = "cost-analyzer"
  namespace        = "kubecost"
  create_namespace = true

  values = [yamlencode({
    kubecostProductConfigs = {
      clusterName            = "prod-eks-eu-west-3"
      cloudIntegrationSecret = kubernetes_secret.kubecost_cur_integration.metadata[0].name
    }
    prometheus = {
      server = { retention = "15d" }
    }
  })]
}

On the team-attribution side, the piece that makes the breakdown usable — whether for Kubecost or for Split Cost Allocation Data — is labeling discipline at the namespace level, not the pod level:

apiVersion: v1
kind: Namespace
metadata:
  name: team-checkout
  labels:
    team: checkout
    cost-center: "eng-payments"
    env: production

Without these labels set upfront (ideally enforced via an admission controller or an OPA/Kyverno policy at creation time), even the most sophisticated tool on the market falls back to a default breakdown by technical namespace — rarely aligned with how product teams are actually organized.

Native or Kubecost: how to decide

Across the FinOps audits we run at organizations operating EKS, three signals point toward Kubecost rather than stopping at Split Cost Allocation Data:

• More than 3-4 product teams share the same cluster and need chargeback checked continuously, not just at month-end by finance.
• Rightsizing requests/limits is an active workstream — Kubecost’s automated recommendations save weeks compared to reprocessing a CUR export by hand.
• Multiple clusters or AWS accounts need consolidating into one view, including inter-cluster data-transfer costs.

Conversely, an organization with a single EKS cluster, one team operating it, and a need for monthly finance reporting likely doesn’t need to run an extra Kubecost component: Split Cost Allocation Data, activated in a few clicks in Billing and Cost Management, covers the need at zero cost.

Our take

The real hidden cost on EKS is almost never the $73/month control plane covered in our ECS vs EKS vs Fargate comparison — it’s provisioned capacity that’s never consumed, invisible until it’s tied to a team that can act on it. Turning on Split Cost Allocation Data is a half-day project that should be standard on any multi-team EKS cluster, free tier or not. Kubecost only becomes a justified investment once the question shifts from “how much does the cluster cost” to “who’s accountable for which line” — and someone actually acts on the recommendations continuously. A DevSecOps audit can settle this on your actual topology before adding one more component to operate.

Conclusion

EKS never bills by team — that’s a deliberate AWS choice that leaves cost attribution to whoever operates the cluster. Split Cost Allocation Data covers most of the need for free, with a T+1 day delay that’s acceptable for financial reporting. Kubecost (and its open-source engine OpenCost) takes over once the need becomes operational: real time, actionable rightsizing, multi-cluster. The point both approaches share, and both often get skipped: without team/cost-center labels set at the namespace level from creation, no tool can reconstruct a reliable attribution after the fact.

Sources: AWS — Split Cost Allocation Data for EKS launch, AWS — Kubernetes labels support (October 2025), AWS — CloudWatch Container Insights metrics (November 2024), AWS docs — Kubernetes labels for EKS cost allocation, Kubecost — pricing tiers, TechCrunch — IBM acquires Kubecost, Cast AI — 2026 State of Kubernetes Optimization Report.