Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.costory.io/llms.txt

Use this file to discover all available pages before exploring further.

EKS cost allocation helps you see which pods, namespaces, and teams use shared cluster capacity. This guide compares AWS Split Cost Allocation, AWS-managed usage metrics, and Kubecost or OpenCost so you can choose the right Kubernetes cost visibility method and normalize the result in Costory. Costory Cost Explorer showing EKS costs grouped by team and application Use EKS labels to group cluster costs by team, application, or environment in Costory.

​
Prerequisites

  • You have an AWS EKS cluster running.
  • You have an AWS provider connected to Costory with your data ingested.
  • You have labels or tags applied to your pod deployments, or you plan to add them.
  • For Kubecost or OpenCost, you can export allocation data to a shared S3 bucket that Costory can access.

​
Output

  • Granular cost visibility at the Kubernetes label level, including team, app, environment, namespace, and cluster.
  • A clear choice between request-based, usage-based, and OpenCost-backed allocation.
  • Ability to track per node pool and identify over-provisioned clusters.
  • Foundation for and across teams.
  • Stable cost data using Contracted Cost, so Savings Plan reassignments between clusters do not create false cost spikes.

​
Choose an EKS cost allocation method

Pick the method that matches the allocation signal you trust most: Kubernetes requests, measured CPU and memory usage, or OpenCost allocation data.
OptionHow it worksBest forLimitations
AWS with Kubernetes labelsAWS adds pod-level cost records to your based on requested CPU and memory. EKS Kubernetes labels can be activated as .Fast setup when you want agentless EKS cost allocation in billing data.Costs follow requests, not actual usage. Over-requesting workloads can receive more cost than they consume.
AWS-managed usage metricsAWS reads CPU and memory usage metrics from CloudWatch or Amazon Managed Service for Prometheus, then uses those metrics for split cost allocation.Teams that want allocation closer to actual CPU and memory consumption while keeping AWS billing as the source.Requires a metrics collector or agent in the cluster. Direct outbound network costs are not split at workload level.
Kubecost or OpenCostYou install the Kubecost or OpenCost agent on each cluster, then export allocation data to a shared S3 bucket that Costory can access.Clusters where outbound network costs or Kubernetes-native allocation reports are material.Requires agent management, export jobs, and access to a shared storage location.
If you are starting from scratch, start with AWS . Add usage metrics or OpenCost data only when requests are too coarse or network allocation is material.
Start with a small label set that answers who owns the workload, what it runs, and where it runs. You can add more labels later, but these fields cover most EKS workflows.
LabelExample valuesUse it to
teamplatform, data, paymentsRoute costs to the right engineering or product team.
app or serviceapi, worker, checkoutFind which service drives spend inside a team.
envproduction, staging, devSeparate production costs from non-production usage.
clusterprod-eu, shared-usCompare clusters and find placement issues.
namespacepayments, observabilityAllocate shared cluster costs when teams map to namespaces.
Use consistent lowercase values. Avoid aliases like prod, prd, and production unless you plan to normalize them in .

​
Set up your chosen EKS cost allocation method

1

Configure the allocation data source

AWS Split Cost Allocation adds pod-level cost records to your . Kubernetes custom labels for EKS became available as cost allocation tags in October 2025, so you can attribute EKS costs by business labels such as team, application, and environment.
  1. Go to the AWS Cost and Usage Report settings.
  2. Follow the AWS guide for enabling split cost allocation data.
  3. Include resource IDs and use hourly reports when you need the most granular data.
  4. Activate the relevant in the Billing console.
2

Add labels to pod deployments

Add labels that reflect ownership and purpose to each Kubernetes workload:
metadata:
  labels:
    app: my-service
    team: platform
    env: production
Use the same label keys across clusters. If teams already use different names, such as owner, team, and cost_center, keep them for now and merge them later in Costory.
3

Wait for data to flow into Costory

After configuring AWS , wait 2-3 days for the data to appear in your Cost and Usage Report and flow into Costory.For Kubecost or OpenCost, the delay depends on your export schedule and the Costory ingestion cadence for the shared S3 bucket.
4

Validate labels in Costory

Before you build dashboards or views, check that your labels are present and populated:
  1. Open .
  2. Filter to your AWS account and EKS services.
  3. Group by one label, such as team or app.
  4. Check the null or unallocated bucket.
  5. Fix missing labels at the deployment level, then wait for the next billing export or OpenCost export.
If labels are present under different names, merge them with . For example, merge k8s_label_team, team, and owner into one reporting field.

​
Analyze EKS costs in Costory

Once EKS labels appear in Costory, use them to find waste, build team reporting, and share cost changes.

​
Find waste by node pool

Use to group by node pool and spot clusters with unusually high waste. Costory Cost Explorer showing EKS waste ratio by node pool Cost Explorer can show waste ratio by node pool so you can find over-provisioned cluster capacity. See the Kubernetes waste guide for detailed waste analysis steps.

​
Identify over-requesting deployments

For native split allocation, sort by requested CPU or memory to find workloads that reserve more capacity than they use. Costory Cost Explorer showing EKS deployments with high requested CPU Deployment-level views help you find workloads that drive EKS waste through high resource requests.

​
Share recurring updates

Turn any saved view into a and send it to your team. Costory Slack report showing EKS cost changes Slack Reports send saved EKS cost views to the teams that own the workloads.

​
Surface cost changes in Digest

Add your Kubernetes labels to the so highlights what changed. Costory Digest tree configured with EKS labels Digest can use EKS labels in its cost breakdown tree to explain workload-level cost changes.

​
Create a chargeback-ready EKS view

Use one saved view as the source of truth for team reporting:
  1. Filter to container infrastructure costs, then group by the normalized team label.
  2. Add a secondary group-by for app, service, or namespace so teams can see their main cost drivers.
  3. Use Contracted Cost when you want stable team-level reporting across Savings Plan movements.
  4. Save the view with a name like EKS chargeback by team.
  5. Schedule the view through Slack Reports or add it to a Dashboard.
For shared namespaces or platform services, create a that assigns the cost to the teams that consume the service.

​
Next steps

Explore costs by cluster and label

Use to drill into EKS costs by cluster, namespace, and label.

Set up Slack reports

Turn saved views into a and share weekly or monthly updates.

Configure monthly cost summaries

Tune the so highlights what changed.

Measure Kubernetes efficiency

Quantify and track over-provisioned clusters.

​
FAQ

The option you choose determines agent requirements. AWS does not require an agent in your cluster. AWS-managed usage metrics require a collector or agent to send metrics from the cluster. Kubecost and OpenCost require an agent on each cluster.
Expect a 2-3 day delay after enabling and activating . The data must first appear in your , then be ingested by Costory. For Kubecost or OpenCost, timing depends on the S3 export schedule.
Start with team, app or service, and env. Standardizing these labels across clusters gives you consistent and reporting.
Unallocated costs usually mean the pod or underlying resource does not have the label you are grouping by, or the label has not appeared in the yet. Check the deployment labels, confirm the relevant are active, then wait for the next export.
Use requests when you want simple, stable allocation that reflects Kubernetes scheduling decisions. Use actual usage when you want allocation closer to what workloads consumed. Actual usage requires CloudWatch, Amazon Managed Service for Prometheus, or another usage data source.
Keep the original workload labels for investigation, then add a for reporting. For example, allocate observability, ingress, or CI runner costs to consuming teams based on namespace, service ownership, or another usage metric.
Last modified on May 27, 2026