Ask for the Kubernetes bill and you will get the compute line. The real cost of a Kubernetes platform is spread across five other places: the managed control plane, observability, network transfer, capacity that is reserved but unused, and the engineers who keep the whole thing current. None of those appear in the cluster's cost dashboard by default, and together they routinely exceed the node spend they surround.
The traps below are structural, not the result of anyone being careless. Each one has a plausible justification at the moment it is introduced, which is why it survives the next budget cycle.
The control plane is cheap per cluster and expensive per portfolio
AWS charges $0.10 per Amazon EKS cluster per hour for standard Kubernetes version support, which is about $73 a month, and $0.60 per hour for extended version support. The AWS pricing page also lists the charges that surround the cluster: worker nodes, EBS volumes, public IPv4 addresses, and cross-AZ traffic between nodes and the control plane.
Seventy-three dollars is not a decision. Thirty clusters is $2,190 a month before a single pod runs, and a fleet that drifts onto extended support multiplies that by six. Ten clusters on extended support cost an extra $3,650 a month compared with the standard rate, which is a version-management failure presenting as an infrastructure bill. Cluster sprawl usually arrives one environment at a time: a per-team staging cluster, a per-region failover cluster, a cluster created for a migration that finished last spring. Nobody consolidates because nobody owns the portfolio.
Observability grows until someone caps it
Metrics, logs, and traces are billed by volume, and volume is set by developers who never see the rate card. Prometheus stores one time series per unique combination of metric name and labels, so a label carrying a user identifier, request identifier, or container hash multiplies the series count by the cardinality of that label. A single histogram with a high-cardinality label can cost more than the workload it observes.
A second control is tiering. Most teams keep everything at the same retention and the same query performance, then pay premium prices for debug output nobody reads after a week. Splitting retention into a short, searchable window and a cheap archive changes the bill faster than any dashboard cleanup, and it forces the question of what actually needs to be queryable.
Logs are worse because they are unbounded by default. A debug line added during an incident becomes permanent ingest, and an ingress controller that logs every request in a busy service produces more data than some databases. Traces are the one signal with a natural control: sample at the collector, not at the agent, and sample differently for errors than for successes. A useful governance rule is that every dashboard and alert must have a named owner and a retention decision, because unused signals are pure cost with no offsetting value.
Egress and NAT charge you for your own architecture
Traffic between availability zones is billed, roughly a cent per gigabyte in each direction in US regions, on top of standard internet egress at about nine cents per gigabyte for the first ten terabytes. A chatty service mesh or an over-eager cache replication pattern pays that cross-AZ charge continuously, and the cost lands in a networking account that the application team never reads.
NAT gateways add a second layer: an hourly charge plus a per-gigabyte processing charge, and standard data transfer applies to everything that flows through. It is common to find a cluster routing internal traffic to a NAT gateway because a service needed one external endpoint and the subnet's route table sent everything that way. VPC endpoints and private link paths exist precisely to keep that traffic off the metered path, and the ones with the best payback are the ones for the services your workloads call most often.
The lines that quietly compound
Three smaller charges deserve a standing review because they accumulate without anyone deciding to spend. Persistent volumes survive the workloads that created them, and a storage class that provisions a new volume per test run leaves a trail of unattached disks across the account. Load balancers are created per service by default in many charts, so a hundred-service cluster can carry a hundred billable ingress points, most of them serving traffic that a shared gateway could handle. Public IPv4 addresses are now billed per address-hour, and a cluster that assigns an address to every pod that asks for one pays for the habit continuously.
None of these is large on its own. Together they explain why a platform bill can rise while node count and traffic are flat, and why the monthly variance meeting ends with everyone pointing at a different account. The fix is boring: a weekly report of unattached volumes, idle load balancers, and unused addresses, owned by the platform team, with a deletion policy rather than a discussion.
Idle capacity hides behind requests
Kubernetes schedules against requests, not against real usage. The Kubernetes documentation on managing resources for containers is explicit that the scheduler uses requests to decide placement and limits to enforce ceilings. If every pod requests 500 millicores and uses 120, the cluster buys four times the CPU it needs while reporting healthy utilization in the control plane.
A worked example with labeled assumptions: 120 pods requesting 500 millicores each hold 60 vCPUs of committed capacity, while actual usage is 12%. On 16-vCPU nodes that is four nodes to satisfy requests versus one node to satisfy demand. At an assumed $0.25 per node-hour, the difference is about $550 a month for one service, and it compounds across every service that adopted the same defaults. Vertical Pod Autoscaling in recommendation mode, then in-place resize, is the cheapest fix; node-level consolidation with Karpenter or the cluster autoscaler is the next. Both depend on requests being honest, which means an owner must review them.
Engineer time is the largest unbudgeted line
Kubernetes releases three minor versions a year and supports each for a limited window, so every cluster must be upgraded on a regular cadence to stay in support. Add add-on upgrades, certificate rotation, admission policy maintenance, incident response, and the platform's own product work. A four-person platform team at an assumed $220,000 fully loaded cost each is $880,000 a year; if 40% of that time goes to keeping the platform current rather than improving it, the toil budget is $352,000, five times the control plane bill for a single cluster.
That number is the honest comparison for a managed container service or a simpler deployment model. It is also the reason platform teams should publish an upgrade calendar and a support-matrix cost, so the organization can see the trade between staying current and paying for extended support.
A twelve-point cost checklist
- Count clusters by environment and owner, and list which ones are on extended support.
- Set requests from measured p95 usage, not from a template copied in 2022.
- Run Vertical Pod Autoscaling in recommendation mode on the ten largest workloads.
- Enable node consolidation and set disruption budgets that tolerate it.
- Find the top ten metric families by active series and delete the high-cardinality labels.
- Cap log retention per namespace and sample traces at the collector.
- Audit NAT gateway gigabytes and route internal traffic through VPC endpoints.
- Map cross-AZ traffic by service pair; co-locate the chatty ones.
- Delete unused load balancers, public IPs, and persistent volumes from finished migrations.
- Put every cluster on a published upgrade cadence with a named owner.
- Allocate cost to namespaces with OpenCost or the provider's native tooling, and show it to product teams.
- Review the portfolio quarterly, including the option to leave Kubernetes for workloads that never needed it.
What to do next
- Build one page that adds control plane, observability, network, and platform labor to node spend. The gap between that total and the compute line is your real platform cost.
- Assign an owner to the cluster portfolio and give that person authority to delete clusters, not just create them.
- Publish a cost per namespace to product teams. Visibility changes request sizes faster than any central mandate.
- Retire extended-support clusters this quarter; version drift is the most expensive form of procrastination in this stack.