Skip to content

PATTERN Cited by 1 source

EKS Cost Allocation Tags

What it is

Use AWS Billing's split cost allocation data for EKS to map Kubernetes-native identity dimensions (cluster / namespace / deployment / node) directly onto AWS cost allocation tags, so EKS spend lands in the same Cost Explorer view and chargeback reports as the rest of AWS spend — without building a separate K8s-only cost tool.

The four cost allocation tags

AWS Billing's split-cost-allocation-data-for-EKS feature exposes four K8s-native dimensions as native AWS cost allocation tags:

Tag Kubernetes dimension
aws:eks:cluster-name EKS cluster
aws:eks:deployment Workload / Deployment
aws:eks:namespace Tenant / project boundary
aws:eks:node Physical EC2 node

These are AWS-managed tags (the aws: prefix indicates AWS sets them automatically from the cluster's observed runtime). They behave like any other cost allocation tag in the Cost & Usage Report (CUR) and in Cost Explorer's group-by dimensions.

Why namespace is the load-bearing axis

In most multi-tenant EKS clusters, the namespace is the tenant / project boundary — the same axis that typically drives:

  • RBAC scoping (namespaced roles, RoleBindings)
  • Network policy scope
  • Per-project dashboards (AMG per Generali)
  • Resource quotas
  • PodSecurity policy

Using namespace as the cost axis aligns billing with all the other tenancy-bearing constructs. One consistent dimension across RBAC, networking, observability, and cost is the architectural property.

Why this is better than a K8s-native FinOps tool

The typical alternative is Kubecost / OpenCost / a home-grown K8s cost tool that attributes pod CPU/memory × hourly EC2 price. Those tools work fine in isolation but fragment the finance view — your EKS cluster cost lives in Kubecost, your RDS cost lives in Cost Explorer, your Lambda cost lives in Cost Explorer again, and no single dashboard answers "what did Project X spend across all AWS services this month?"

Cost allocation tags at the billing layer keep everything in one view. Generali mentions this explicitly:

"The company can map Amazon EKS consumption against lines of business and applications … gaining insights into Kubernetes costs alongside other AWS spend." (Source: sources/2026-03-23-aws-generali-malaysia-eks-auto-mode)

The word alongside is the architectural key — EKS costs share one dashboard with non-EKS costs.

Composition with Savings Plans

Generali pairs this with Savings Plans for compute — the combination gives per-project cost visibility over discounted compute. The tags reveal who is using the compute; Savings Plans determine the effective hourly rate.

Caveats

  • Requires that customer tags aws:eks:* be activated in Billing Console before they show up in CUR / Cost Explorer — they're available but off by default for new accounts.
  • Does not attribute non-compute AWS costs (RDS, S3, managed services) to K8s namespaces — those need independent tagging strategies (Project=X, Environment=prod at the AWS resource level).
  • Tag activation is retroactive only for CUR, not for Cost Explorer — historical data before tag activation isn't attributed.

Seen in

Last updated · 200 distilled / 1,178 read