Managing Hundreds of Amazon EKS Clusters at Fleet Scale · Part 15 of 18

What an EKS Fleet Actually Costs: The Four Billing Streams and Per-Tenant Showback

Every earlier decision in this series — how many clusters, which autoscaler, when to upgrade — shows up here as a number on the invoice. This is the article that adds them up: the four independent streams an EKS bill is made of, where the money actually goes at fleet scale, and how to attribute every dollar back to the team that spent it.

Pricing and version facts current as of 2026-06-30 · all dollar figures are AWS list pricing that rolls forward — re-verify against the EKS pricing page before you build a budget on them.

Where an EKS bill actually comes from — four independent streams

The first mistake teams make with EKS cost is treating it as a single meter. It isn't. An EKS bill is four independent streams that grow on different axes, and you can't optimize the total until you can see them apart (Figure 1).¹

Stream one is the control plane. AWS charges $0.10 per cluster-hour for a cluster in standard support, or $0.60 once it falls onto extended support — a fixed fee you owe per cluster whether it runs three pods or three thousand.¹ Small per cluster, but it is the one number that scales with the many-vs-few decision from Part 02, and it is the subject of the next section.

Stream two is the Provisioned Control Plane tiers — optional, and GA since November 2025. If a single cluster is large enough to need a bigger, dedicated control plane, you can provision it in tiers (XL $1.65, 2XL $3.40, 4XL $6.90, 8XL $13.90 per hour) that stack on top of the base $0.10 fee.¹ Most fleets never touch this; it matters for the handful of very large clusters that would otherwise hit the ceilings covered in Part 02.

Stream three is worker compute, and for almost everyone it dominates the total. This is EC2 or Fargate for your nodes, plus the EBS volumes attached to them, plus $0.005 per hour for every public IPv4 address (a charge that has applied to all public IPv4 since February 2024), plus cross-AZ data transfer.¹ It scales with what you run, not how many clusters you run — which is exactly why it's the most optimizable stream, and the one Part 12's autoscaling work targets.

Stream four is EKS Capabilities and Auto Mode. If you let EKS run the data plane for you with Auto Mode, that convenience carries a management fee of roughly 12% on top of the underlying EC2 cost (Part 07).¹ Hybrid Nodes — your own on-prem hardware attached to an EKS control plane — bill separately per vCPU-hour on a declining tier, from $0.020 down to $0.006 above 11.52M vCPU-hours a month.¹

Keep these four apart in your head and in your cost reports. Two of them (control plane, Provisioned CP) are fixed floors that compound with cluster count; two of them (compute, Capabilities) compound with usage. That single distinction tells you which lever moves which number — consolidating clusters attacks the first pair, right-sizing compute attacks the second.

The fee you pay before any workload runs — the control-plane floor

The control-plane fee is the fixed floor of the whole model, and it's the one number that turns an architecture decision into a budget line. At $0.10 per cluster-hour it's about $74/month per cluster ($0.10 × 730 hours) — trivial for one cluster, and a six-figure annual line item for a fleet.¹

The arithmetic is the one from Part 02, and it's worth repeating because it anchors the entire cost case: 300 clusters × $0.10 × 730 hours ≈ $21,900/month in control-plane fees alone, before a single EC2 node or load balancer (Figure 2).¹ Push to 500 clusters and the floor is about $36,500/month. This is the strongest quantitative argument for consolidation, and the reason "a cluster per app" quietly becomes an expensive habit.

Consolidation attacks this stream and this stream only. It does not cut your compute bill — the same 200 nodes cost roughly the same whether they sit in one cluster or ten, because compute is a separate stream that scales with node count, not cluster count.¹ So when you attribute cost, attribute the ~$74/month floor to each cluster you chose to create, and make every split earn it against the isolation it buys (the Part 02 decision).

One nuance keeps the model honest over time. Averaged across a full 26-month version lifecycle — 14 months at $0.10 plus 12 months at the extended-support $0.60 — a cluster works out to about $0.33 per cluster-hour.¹² If your upgrade discipline is good, you live near $0.10. If clusters routinely slip behind, your real floor drifts toward that blended $0.33 — which is the leak the next section is about.

Where the money actually goes — compute, the stream you can move

For most fleets, worker compute is the largest line on the invoice by a wide margin — and, conveniently, it's also the most optimizable. The control-plane floor is fixed; you can only reduce it by running fewer clusters. Compute you can genuinely shrink without giving anything up.

The lever is Karpenter, the fleet-standard autoscaler covered in Part 12.³ It provisions best-fit EC2 instances for the pods that are actually pending, mixes Spot and On-Demand in a single NodePool, and consolidates idle or under-used nodes back down — so you stop paying for the headroom that fixed node groups leave stranded.³ The three moves that matter, in order of impact:

• Right-size and consolidate. Let Karpenter pack workloads onto fewer, better-fit nodes and reclaim the idle ones. This is the single biggest compute win because most clusters run with large, permanent slack.
• Push Spot. For fault-tolerant and batch workloads, Spot capacity is dramatically cheaper than On-Demand. One team (Grover, per the AWS Containers Blog) reported reaching around 80% Spot in production — a practitioner outcome, not a guaranteed number, but it shows the ceiling is high.⁴
• Trim the compute add-ons. EBS volumes, cross-AZ chatter between pods, and public IPv4 addresses all ride on this stream and all leak — the subject of the next section.

There's an honest tradeoff to name. EKS Auto Mode (Part 07) will run Karpenter and the data plane for you for roughly 12% on top of EC2 — you're buying operational simplicity, and paying for it as a fifth of your typical Spot savings.¹ Auto Mode also runs the autoscaler off-cluster, which reduces the log and metric visibility you'd have if you operated Karpenter yourself.¹ For a small platform team the fee is often worth it; for a team already fluent in Karpenter, self-managing keeps both the savings and the visibility. Note too that AWS provides no SLA for Karpenter itself — operational ownership stays with you when you self-manage it, and Auto Mode only shifts that burden to AWS in exchange for the ~12% fee.³

The silent leaks — extended-support drift, idle IPv4, cross-AZ

The streams above are the visible bill. The damage that surprises people at fleet scale comes from three leaks that don't announce themselves — each small per unit, each multiplied by cluster or node count.

Extended-support drift is the big one, and it's a budget bug, not a line item. The moment a cluster falls off standard support its control-plane fee jumps from $0.10 to $0.60 per cluster-hour — a 6× increase, roughly $438/month per cluster instead of $74.¹² A fleet of 300 clusters that has drifted onto extended support costs about $131,400/month in control-plane fees, versus $21,900 current. Nobody decides to pay 6×; clusters rot there because the upgrade machine (Part 14) couldn't keep up. Treat any cluster on extended support as a bug with a dollar value attached, not as a stable state.

Idle public IPv4 is the quiet one. Since February 2024 AWS charges $0.005 per hour for every public IPv4 address, in use or not — about $3.65/month each.¹ One address is a rounding error; a fleet of clusters with public IPs on nodes, load balancers, and NAT gateways it forgot to consolidate adds up. Audit for public IPv4 you don't need and move nodes to private subnets.

Cross-AZ transfer is the invisible one, because it's billed on data movement, not on a resource you can see in a console list. Pods chatting across Availability Zones, or a service in one AZ hitting a database in another, generate inter-AZ transfer charges that never show up as a named object.¹ Topology-aware routing and AZ-aware scheduling keep traffic in-zone where correctness allows. This is the leak that most often explains a compute bill that's higher than the node count says it should be.

Making every team see its bill — showback and chargeback

A fleet cost model is only half the job. The other half is attribution: putting each dollar in front of the team that spent it, so the people who can reduce a bill are the ones looking at it. That's showback (everyone sees their number) or chargeback (they're actually billed for it). At fleet scale, showback is the practical starting point.

The split has two halves, and they're handled differently (Figure 3). Direct costs — the compute, EBS, and public IPv4 a namespace or workload consumes — attach cleanly to a tenant if you tag them. A disciplined tagging strategy (team, environment, cost-center on every node group and namespace) is the entire foundation; without it, nothing else in this section works.⁵ Shared costs — the control-plane fee, platform add-ons, GitOps controllers, shared observability — belong to no single tenant, so you split them by a usage key: each team's share of cluster CPU or memory, or a flat per-namespace division when that's fairer.

Splitting the shared control-plane fee is the subtle part on a soft-multi-tenant cluster (Part 02). Ten teams sharing one cluster share one $74/month floor, so each carries about $7.40 — a useful signal that consolidating onto a shared cluster is cheap per team, and that spinning up a dedicated cluster means owning the whole floor alone. Making that number visible is often what stops a team from asking for its own cluster it doesn't need.

You don't have to build the plumbing by hand. OpenCost (the CNCF project) and Kubecost implement exactly this model — per-namespace and per-label cost breakdowns that split shared cluster cost from direct workload cost — and read the same allocation you'd design here. The tool matters less than the discipline: tags on everything, a defined split rule for shared cost, and a bill each team actually receives.

The levers that move the bill, ranked

Not all savings are equal, and spending optimization effort in the wrong order is its own waste. Ranked by how much they typically move a fleet bill:

Notice the pattern: the top of the list is compute, not the control plane. The control-plane floor is what makes headlines because $21,900/month is a striking number, but it's fixed and bounded — you can only cut it by running fewer clusters, and isolation often forbids that. Compute is where the elastic, repeatable savings live, which is why it earns the primary optimization effort even though the control-plane number is the one that gets quoted in the meeting.

What to actually do — a fleet cost model in five decisions

Pull it together and the CFO-ready version is short. Build the model, attribute it, then optimize in the order the levers rank:

• Model four streams, never one. Control plane and Provisioned CP compound with cluster count; worker compute and Capabilities / Auto Mode compound with usage. A budget that hides them as one number can't be steered.
• Attribute the ~$74/month floor per cluster. Make every cluster name the isolation driver that justifies its floor (Part 02). If it can't, it's a candidate to consolidate.
• Make compute the primary target. Right-size and consolidate with Karpenter first, then push Spot for fault-tolerant work (Part 12). This is where the repeatable money is.
• Treat extended-support drift as a bug. A cluster on the $0.60 rate is a 6× defect with a dollar value, not a stable state — wire the upgrade machine (Part 14) to prevent it.
• Give every tenant a showback view. Tag direct costs, split shared costs by a usage key, and put a bill in front of each team. Attribution is what turns a cost model into cost behaviour.

Do that and the fleet's cost stops being a surprise at month-end and becomes a set of knobs with owners. The numbers here are AWS list pricing as of 2026-06-30 and they roll forward — re-check the EKS pricing page before you commit a budget — but the shape of the model (four streams, a fixed floor, an optimizable middle, three leaks, and per-tenant attribution) is stable, and it's the thing worth building once and reusing.