EKS bills are mostly nodes, and nodes are sized by what pods request, not what they use. The leaks we find most (inflated requests, half-empty nodes, cross-AZ chatter, one load balancer per service, clusters on extended support) and how split cost allocation data puts a price on every namespace in the Cost and Usage Report.
The EKS control plane is $0.10 an hour, about $73 a month. Almost everything else on a Kubernetes bill is EC2, and EC2 is bought for what pods request. A pod that requests 2 vCPU and uses 0.2 still holds a node's capacity, and the scheduler packs nothing else into the gap.
Book a free 30-minute call. You'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Split cost allocation data adds pod-level rows to the Cost and Usage Report: each pod's share of its node's amortized cost, based on the CPU and memory it reserved, and for GPU and Trainium or Inferentia instances, the accelerators too. It creates cost allocation tags for the cluster, namespace, node, workload and deployment (aws:eks:namespace and friends), enabled by default.
Turn it on in the Billing console for the CUR, then query cost by namespace in Athena.
Expect volume: two new rows per pod per hour (three on accelerated instances). A thousand short-lived pods an hour is about 48,000 rows a day.
Unallocated capacity (the gap between what pods reserve and what nodes cost) is the number to watch. It is the bin-packing waste, and it belongs to the platform, not to any team.
LimitRanges and ResourceQuotas per namespace, so a new service can't request a whole node by accident.
A weekly report of the top ten workloads by requested-minus-used, sent to their owners.
Budgets per namespace from the split cost data, with alerts at 80%.
An upgrade calendar so no cluster drifts into extended support.
Once a month: what changed in tech that month and what it means for you, from cloud and AI to security and the tools you build with. Every item links to its source. No sales pitch, unsubscribe in one click.
Book a free 30-minute call about it. Bring your setup and your bill; you'll leave knowing what we'd do first and roughly what it costs, whether or not you hire us.
Or keep reading
Karpenter in 2026: Static Capacity, Node Overlays, Balanced Consolidation and When to Use Auto Mode Instead
Karpenter went from v1.0 to v1.15 in two years: static capacity, NodeOverlay for pricing and capacity overrides, NodePool node limits, a grace period for do-not-disrupt, a Balanced consolidation policy, CapacityBuffer and DRA for GPUs. What each is for, a production NodePool, and the case for letting EKS Auto Mode run it.
Read
An EKS Reference Architecture for 2026, With Diagrams: The Small-Team Version and the Regulated Version
What a production EKS setup looks like in 2026, layer by layer: edge, entry, cluster, platform add-ons, data, security and observability. A lean version for a small team on Auto Mode, and a regulated version with separate node pools, network policies and audit logging, with the choices behind each box.
Read
As of November 2, 2026. Provided as is, for general information, and accurate to the best of our knowledge on the date shown. Not legal, compliance, tax, financial or other professional advice. Prices, limits and vendor services change; check current vendor documentation before relying on anything here. Terms of use.