EKS Cost Visibility: Kubecost vs AWS Native Tools vs OpenCost

You can’t optimize EKS costs without knowing which pods, namespaces, and teams are driving spend. AWS provides native billing tools like Cost Explorer and Cost & Usage Reports, while Kubernetes-native tools like Kubecost and OpenCost offer pod-level attribution. This guide compares all three approaches to help you choose the right visibility strategy for your environment.

Key Takeaways

• AWS Cost Explorer shows EKS spend by service but can’t attribute costs to individual pods or namespaces
• Kubecost integrates with AWS billing to provide per-pod, per-namespace cost allocation and rightsizing recommendations
• OpenCost is the open-source alternative to Kubecost with similar pod-level attribution but fewer enterprise features
• AWS split cost allocation (EKS add-on) bridges the gap by tagging EKS costs in Cost Explorer by cluster and namespace
• Most teams use a combination: Kubecost/OpenCost for engineering decisions and Cost Explorer for finance reporting

The Cost Visibility Problem in EKS

EKS clusters create costs across multiple AWS services:

• EKS control plane ($0.10/hour per cluster)
• EC2 instances (worker nodes)
• EBS volumes (persistent storage)
• Load balancers (ALB/NLB)
• Data transfer (cross-AZ, NAT gateway, internet egress)

AWS billing aggregates these charges at the service level—you see “$5,000 on EC2” but not “which namespace or application consumed those resources.” For multi-team environments, this makes cost accountability impossible.

Kubernetes-native cost tools solve this by mapping resource requests and actual usage to AWS pricing, providing granular attribution down to individual pods.

AWS Cost Explorer: The Finance View

What It Does

Cost Explorer is AWS’s built-in cost analysis tool. It aggregates spend across all services with daily or monthly granularity, supports filtering by tags, and provides basic forecasting.

Strengths

• Authoritative pricing data: Cost Explorer reflects actual AWS billing, including discounts from Savings Plans and Reserved Instances
• Multi-service visibility: See EKS control plane, EC2, EBS, data transfer, and load balancer costs in one place
• Tag-based filtering: Group costs by custom tags like Environment: production or Team: platform
• No installation required: Available in every AWS account at no extra cost
• Budget and anomaly alerts: Set spending thresholds and receive notifications

Limitations

• No pod-level attribution: Can’t map costs to namespaces, deployments, or pods
• Delayed data: Cost Explorer lags 24-48 hours behind actual usage
• Limited rightsizing guidance: AWS Compute Optimizer provides instance-level recommendations but not pod-level request tuning
• Manual correlation required: You must manually match EC2 instance IDs to Kubernetes node names to understand cluster-level spend

How to Use It

Query monthly EKS-related costs via CLI:

aws ce get-cost-and-usage \ --time-period Start=2025-01-01,End=2025-02-01 \ --granularity MONTHLY \ --metrics UnblendedCost \ --group-by Type=DIMENSION,Key=SERVICE \ --filter '{ "Dimensions": { "Key": "SERVICE", "Values": ["Amazon Elastic Kubernetes Service", "Amazon Elastic Compute Cloud"] } }'

Filter by cluster tag if you’ve tagged your node groups:

aws ce get-cost-and-usage \ --time-period Start=2025-01-01,End=2025-02-01 \ --granularity DAILY \ --metrics UnblendedCost \ --group-by Type=TAG,Key=Cluster

Best For

• Finance teams tracking overall AWS spend and budget compliance
• High-level cluster cost trends and service-level breakdowns
• Validating Savings Plans and Reserved Instance coverage

AWS Cost & Usage Reports (CUR): The Data Source

CUR is the most detailed AWS billing export, delivering hourly usage and cost data to S3. It’s the authoritative source both Kubecost and AWS split cost allocation use for accurate pricing.

Strengths

• Hourly granularity: Track costs hour-by-hour instead of daily aggregates
• Resource-level detail: Includes resource IDs, tags, and line-item charges
• Integration-friendly: Kubecost, OpenCost, and third-party FinOps tools all ingest CUR for accurate cost mapping

Limitations

• Raw data format: CUR delivers CSV/Parquet files—you need a tool to parse and visualize them
• Setup required: Must configure S3 bucket, enable resource IDs, and activate cost allocation tags

How to Enable

1. Go to AWS Billing Console → Cost & Usage Reports
2. Create a new report with hourly granularity
3. Enable resource IDs and split cost allocation data
4. Specify an S3 bucket for delivery
5. Configure Kubecost or OpenCost to read from that bucket

Best For

• Feeding accurate AWS pricing into Kubecost or OpenCost
• Building custom FinOps dashboards in Athena, Redshift, or QuickSight
• Validating discounts from Savings Plans and spot usage

Kubecost: The Full-Featured Option

What It Does

Kubecost runs inside your cluster and maps Kubernetes resource requests (CPU, memory, storage, network) to AWS pricing data from the Cost & Usage Report. It provides real-time cost attribution by pod, namespace, deployment, label, and annotation.

Strengths

• Pod-level attribution: See exactly which pods drive costs, with drill-down to container-level granularity
• Rightsizing recommendations: Suggests optimal CPU/memory requests based on actual usage
• Showback and chargeback: Generate per-team cost reports for internal billing
• Multi-cluster support: Aggregate costs across dozens of EKS clusters
• Savings opportunities dashboard: Highlights orphaned volumes, underutilized nodes, and Spot adoption candidates
• Efficiency scoring: Tracks “slack cost” (reserved but unused resources)
• Alert rules: Notify when namespace costs spike or budgets are exceeded

Limitations

• In-cluster footprint: Kubecost runs Prometheus, a cost model, and a frontend—adds ~1-2GB memory overhead
• Pricing model: Free tier covers single clusters; enterprise features (multi-cluster, SSO, long-term retention) require a license (~$500-$5,000+/year depending on scale)
• Initial configuration: Requires CUR integration and proper IAM permissions for accurate pricing

Installation

helm repo add kubecost https://kubecost.github.io/cost-analyzer/ helm upgrade --install kubecost kubecost/cost-analyzer \ --namespace kubecost --create-namespace \ --set kubecostToken="your-token" \ --set prometheus.server.persistentVolume.enabled=true

Access the UI:

kubectl port-forward -n kubecost svc/kubecost-cost-analyzer 9090:9090

Navigate to http://localhost:9090 to see cost breakdowns.

Integrating with CUR

Update Kubecost’s Helm values to point to your CUR S3 bucket:

kubecostProductConfigs: athenaProjectID: "your-aws-account-id" athenaBucketName: "s3://your-cur-bucket" athenaRegion: "us-east-1" athenaDatabase: "athenacurcfn_cur_database" athenaTable: "cur_table_name"

Kubecost will reconcile in-cluster metrics with actual AWS billing, providing accurate per-pod costs including discounts from Savings Plans.

Best For

• Platform teams needing actionable rightsizing and Spot recommendations
• Multi-cluster environments (10+ clusters) with centralized cost visibility needs
• Organizations implementing chargeback to application teams
• Teams willing to invest in a commercial tool for full-featured analytics

OpenCost: The Open-Source Alternative

What It Does

OpenCost is a CNCF sandbox project that provides the same core cost attribution logic as Kubecost—it’s actually the open-source foundation that Kubecost was built on. It maps pod resource requests to cloud pricing and exposes costs via Prometheus metrics and a basic API.

Strengths

• Truly open source: Apache 2.0 license with no vendor lock-in
• Lightweight: Smaller footprint than Kubecost (no frontend, just API and exporter)
• Prometheus integration: Exports cost metrics that you can query in Grafana
• Multi-cloud support: Works with AWS, GCP, Azure, and on-prem pricing
• Free forever: No enterprise tiers or licensing

Limitations

• No built-in UI: Requires Grafana or custom dashboards to visualize data
• Limited features: No automated rightsizing recommendations, no alerting, no multi-cluster aggregation UI
• DIY integration: You manage Prometheus retention, dashboard creation, and CUR integration yourself
• Community support only: No commercial support contracts

Installation

kubectl apply -f https://raw.githubusercontent.com/opencost/opencost/develop/kubernetes/opencost.yaml

Access the API:

kubectl port-forward -n opencost service/opencost 9003:9003

Query namespace costs:

curl http://localhost:9003/allocation/compute \ -d window=7d \ -d aggregate=namespace \ -G

Grafana Dashboard

Import the community OpenCost dashboard (ID: 15474) into Grafana to visualize pod and namespace costs over time.

Best For

• Small teams or startups with existing Prometheus/Grafana stacks
• Organizations that prefer open-source tooling without vendor dependencies
• Environments where custom dashboards and API integrations are sufficient
• Cost-conscious teams that don’t need enterprise support or advanced features

AWS Split Cost Allocation: The Native Bridge

AWS introduced split cost allocation as an EKS add-on that tags EC2 costs in Cost Explorer by cluster, namespace, and workload type.

How It Works

The split cost allocation controller runs in your cluster and periodically reports resource usage to AWS. AWS then tags EC2 instance costs with:

• eks:cluster-name
• eks:namespace
• eks:workload-type (Deployment, StatefulSet, DaemonSet, etc.)

These tags appear in Cost Explorer, allowing you to filter and group EKS costs without installing Kubecost or OpenCost.

Strengths

• Native AWS integration: Works directly in Cost Explorer—no third-party tools
• Finance-friendly: Non-technical stakeholders can query costs in the AWS Console
• Lightweight: Minimal in-cluster footprint (just a controller pod)

Limitations

• EC2 costs only: Doesn’t split EBS, data transfer, or load balancer costs
• No rightsizing recommendations: Just attribution, not optimization guidance
• Delayed visibility: Data appears in Cost Explorer with the usual 24-48 hour lag
• Namespace-level only: Can’t drill down to individual pods or containers

Enabling Split Cost Allocation

1. Install the EKS add-on:

aws eks create-addon \ --cluster-name my-cluster \ --addon-name eks-pod-identity-agent \ --resolve-conflicts OVERWRITE

2. Activate the cost allocation tags in Billing preferences
3. Wait 24-48 hours for data to populate
4. Filter Cost Explorer by eks:cluster-name or eks:namespace

Best For

• Teams already using Cost Explorer who want basic EKS attribution
• Finance departments needing namespace-level visibility without installing cluster tools
• Organizations uncomfortable with third-party agents running in production

Feature Comparison Matrix

Feature	Cost Explorer	Kubecost	OpenCost	Split Allocation
Pod-level attribution	No	Yes	Yes	No
Namespace costs	Via tags	Yes	Yes	Yes
Rightsizing recommendations	Instance-level	Pod-level	No	No
Multi-cluster aggregation	Manual	Yes	DIY	Per cluster
Real-time visibility	No (24-48h lag)	Yes	Yes	No (24-48h lag)
Built-in UI	Yes	Yes	No	Yes (Cost Explorer)
Cost	Free	Free tier + paid	Free	Free
In-cluster footprint	None	Medium	Small	Minimal
CUR integration	Native	Yes	Yes	Native
Spot/Savings Plan discounts	Yes	Yes (with CUR)	Yes (with CUR)	Yes

Recommended Approach: Layered Visibility

Most successful EKS cost optimization programs use a combination:

1. Enable Cost & Usage Reports for authoritative pricing data
2. Deploy Kubecost or OpenCost for engineering teams to see pod-level costs and rightsizing opportunities
3. Activate split cost allocation so finance teams can track namespace costs in Cost Explorer without learning Kubernetes
4. Use Cost Explorer for high-level trends, budget alerts, and Savings Plan management

This layered approach gives engineers actionable optimization data while providing finance teams with familiar AWS billing interfaces.

Decision Framework

Choose Kubecost if:

• You manage 5+ clusters and need centralized cost visibility
• You want automated rightsizing recommendations and Spot adoption guidance
• You need chargeback/showback with per-team cost reports
• You have budget for commercial tooling (~$500-$5,000+/year)

Choose OpenCost if:

• You prefer open-source tools and already run Prometheus/Grafana
• You’re comfortable building custom dashboards and integrations
• You want pod-level costs but don’t need a polished UI
• You have engineering resources to maintain the stack

Choose split cost allocation if:

• You only need namespace-level attribution (not per-pod)
• Finance teams drive cost reviews and prefer Cost Explorer
• You want minimal in-cluster footprint
• You’re uncomfortable installing third-party agents in production

Use Cost Explorer for:

• Overall AWS spend trends and forecasting
• Budget enforcement and anomaly detection
• Savings Plan and Reserved Instance coverage analysis
• Finance-driven reporting and compliance

Conclusion

Cost visibility is the foundation of EKS optimization—you can’t reduce spend without knowing where it’s going. AWS Cost Explorer and split cost allocation provide service and namespace-level visibility that works for finance teams, while Kubecost and OpenCost deliver the pod-level granularity engineering teams need to make rightsizing decisions. For most organizations, the winning strategy combines all three: enable CUR for accurate pricing, deploy Kubecost or OpenCost for engineers, activate split cost allocation for finance, and use Cost Explorer for high-level governance. Start with your existing Prometheus/Grafana stack and OpenCost if you want a lightweight open-source approach, or choose Kubecost if you need a full-featured platform with automated recommendations and multi-cluster support.