When Managed Kubernetes Gets Expensive Enough to Justify Running Your Own

The control plane fee is not where managed Kubernetes gets expensive. EKS and GKE charge $73 per cluster per month to run the control plane. That’s a rounding error for most organizations. What actually drives the bill is the layer underneath: node compute, cross-zone data transfer, persistent storage IOPS, load balancers, NAT gateways, monitoring ingestion, and egress. If you’re running Kubernetes at any real scale, those line items typically dwarf the headline fee. This article shows you what the full bill looks like and where the math changes.

How Managed Kubernetes Billing Works

Managed Kubernetes pricing is split across multiple billing dimensions, most of which are invisible until you look at your invoice.

Control plane fees. EKS and GKE Standard each charge $0.10 per cluster per hour, which works out to approximately $73 per cluster per month. AKS offers a free tier with no uptime SLA and a Standard tier at the same $0.10/hr rate for production clusters.

One important EKS cost that often surprises teams: clusters running a Kubernetes version past the standard support window are charged at $0.60 per cluster per hour, which is $438 per cluster per month. Kubernetes releases a new minor version roughly every four months, and EKS drops standard support after 14 months. Teams that are slow to upgrade do not just face security risk. They get a 6x increase in the control plane fee.

Node compute. The control plane fee is rarely more than a few percent of the total bill. Node compute is where the real money goes. Every worker node is a cloud VM billed at on-demand, reserved, or Spot rates depending on how you’ve configured your node groups. On-demand m5.xlarge instances on EKS (4 vCPU, 16GB) run approximately $0.192 per hour, or around $140 per node per month. A 10-node cluster built on those instances puts $1,400 on your compute line before anything else is added.

Cross-zone data transfer. Kubernetes spreads pods across availability zones for resilience. Every time a pod in one zone communicates with a pod in another, you pay for cross-zone traffic. AWS charges $0.01 per GB for cross-AZ data transfer. On a busy cluster, this is not trivial. Microservice architectures with high inter-service traffic can rack up hundreds of dollars per month on this line alone, and most teams don’t see it until it shows up in Cost Explorer. We cover how hyperscaler networking billing compounds across internal traffic in more detail separately.

Egress. Traffic leaving your cluster to users or external systems is billed per GB. AWS charges approximately $0.09 per GB, Azure approximately $0.087 per GB, and GCP approximately $0.085 per GB for outbound transfers. A cluster generating 10TB of monthly egress pays $900 on AWS just for data out. That number scales directly with user traffic, so it grows as your product grows.

Persistent volumes. Storage in managed Kubernetes is billed separately from compute. EBS on EKS runs $0.10 per GB per month for GP3 volumes. GKE’s persistent disk pricing is approximately 2.1x EKS disk pricing, though GKE bundles baseline IOPS. On EKS, higher IOPS are provisioned separately and billed accordingly. A cluster with ten nodes each using a 200GB volume adds $200 per month at EKS rates, more if you need provisioned IOPS.

NAT gateways and load balancers. Every production cluster needs at least one NAT gateway for outbound traffic from private subnets and at least one load balancer for ingress. On AWS, a NAT gateway costs $0.045 per hour plus $0.045 per GB of processed data. An Application Load Balancer runs $0.008 per LCU-hour plus a base fee. These are small individually but they show up on every invoice.

Monitoring and logging. Production clusters generate substantial log and metrics volume. CloudWatch, GCP Cloud Logging, and Azure Monitor all bill based on ingestion volume. Pushing everything to the managed observability stack is the default, and it adds up.

What a 10-Node Production Cluster Costs

Using current on-demand rates and reasonable assumptions for a production cluster (10 x m5.xlarge nodes, 5TB monthly egress, 200GB persistent storage per node, one NAT gateway, one load balancer, basic CloudWatch logging):

That’s around $27,600 per year for a 10-node cluster at on-demand rates. Reserved instances reduce the compute line significantly, typically around 30-40% for a 1-year commitment. But the egress, storage, and ancillary costs don’t shrink with reservations.

These are conservative numbers. High-traffic applications pushing 20TB+ of monthly egress, workloads with frequent cross-zone pod communication, and clusters with heavy persistent storage requirements will all push this figure higher.

The Multi-Cluster Problem

Control plane fees are easy to dismiss at one cluster. The math changes when you’re running several.

A typical engineering organization with separate clusters for development, staging, and production runs three clusters by default. Teams following a one-cluster-per-team-per-environment pattern can reach ten to twenty clusters quickly. At five clusters, EKS and GKE Standard charge $365 per month in control plane fees before a single pod runs. At twenty clusters, that’s $1,460 per month.

AKS’s free-tier clusters avoid the control plane fee, but they carry no uptime SLA. Standard tier AKS matches EKS and GKE pricing at $73 per cluster per month for production-grade clusters.

The multi-cluster pattern also multiplies the ancillary costs. Each cluster has its own NAT gateway, load balancers, and logging infrastructure. These don’t scale linearly with cluster count, but each additional cluster adds its fixed overhead.

Where the Crossover Point Is

Managed Kubernetes is the right choice when you want to run a small number of clusters without the operational overhead of managing the control plane, etcd, and Kubernetes upgrades yourself. For a single production cluster below 20 nodes, the operational savings from managed usually outweigh the cost premium.

The picture changes as you scale up:

At 20 or more nodes per cluster, the control plane fee is under 3% of your total bill. You’re paying the managed premium mostly for upgrade convenience and control plane availability.

With multiple production clusters, the monthly overhead from control plane fees, NAT gateways, and per-cluster infrastructure becomes significant enough to justify looking at alternatives.

With high egress or inter-service traffic, the per-GB billing model means your infrastructure costs scale directly with your traffic, not just with the number of nodes you’re running.

When your team has dedicated platform engineering capacity, the operational cost of managing your own Kubernetes cluster is largely absorbed by people who are already maintaining the platform layer.

A platform team that is already doing Kubernetes operations, that is running multiple clusters, and that is generating substantial egress, is in the zone where self-managed on dedicated hardware makes financial sense.

What Changes on Private Bare Metal

Running Kubernetes on OpenMetal’s bare metal or private cloud infrastructure changes the billing model at a structural level. If you want the full performance comparison alongside the cost breakdown, Kubernetes on a Private Cloud: Cost and Performance vs. EKS and GKE covers the network and compute benchmarks in detail. This section focuses on where the billing model differs.

No inter-node transfer costs. OpenMetal servers include dual 10 Gbps private links per server, providing 20-40 Gbps of private bandwidth per server. Traffic between worker nodes crosses the private network and is unmetered. Cross-zone pod communication, inter-service calls, and storage traffic don’t trigger per-GB charges. For microservice-heavy applications, this alone can be material.

No control plane fee. Your Kubernetes control plane runs on your own nodes. There is no managed service fee.

No per-IOPS storage charges. Your storage runs on NVMe drives that are part of the server you’re already paying for. There is no separate persistent volume billing. v5 servers use Micron 7500 MAX NVMe drives. Storage performance is a function of your hardware configuration, not a billing tier.

Fixed monthly pricing. You pay for dedicated hardware capacity regardless of how much traffic your cluster generates. A traffic spike that doubles your egress does not double your infrastructure bill. OpenMetal bills egress using 95th percentile measurement, which means short-lived spikes don’t trigger overage charges.

Better pod density. Running containers directly on physical hardware removes the hypervisor overhead present in cloud VMs. Each server’s full compute capacity is available to your workloads. On equivalent hardware, bare metal typically yields meaningfully better pod density than cloud VMs.

What You Give Up

Self-managed Kubernetes is not a free lunch. The tradeoffs are real and should be weighed honestly.

Upgrades are your responsibility. In managed K8s, the control plane upgrade is handled for you. On self-managed clusters, your platform team owns the Kubernetes version lifecycle, including etcd backups, control plane upgrades, and worker node drain-and-replace operations. If you don’t have the expertise in-house, this is a real cost.

No node autoscaling out of the box. Cloud managed Kubernetes integrates with the provider’s autoscaling groups. On bare metal, horizontal scaling means adding servers to your cluster. OpenMetal adds nodes to existing clusters in approximately 20 minutes, but it’s not the same as an autoscaling group responding to a sudden traffic spike in under a minute.

You own availability. Managed control planes come with uptime SLAs. Your control plane availability is a function of your own infrastructure design and practices. A three-node private cloud with proper HA configuration is stable, but the responsibility is yours.

If your workload sees large, unpredictable traffic spikes that require rapid scale-out, public cloud managed Kubernetes handles that better. If your workload is more predictable, or if you can plan capacity ahead, the fixed-cost model at OpenMetal works well.

Where OpenMetal Fits

OpenMetal’s private cloud and bare metal infrastructure supports Kubernetes with OpenStack and Ceph deployed in approximately 45 seconds using our automation. Kubernetes clusters run on top of that infrastructure, with OpenStack Cinder available for persistent volume management and Neutron handling network configuration.

For teams with an existing Kubernetes footprint that is generating substantial egress, running multiple clusters, or hitting the limits of what managed K8s cost structures allow, OpenMetal’s fixed pricing model is worth a direct comparison against your current bill. The point isn’t that managed Kubernetes is bad. It’s that the billing model works better for some workloads and worse for others, and knowing where you fall is worth understanding before you commit to a reserved instance pricing plan for another year.

You can model your configuration using the OpenMetal deployment calculator, or explore the Kubernetes Workloads use case page for more on how teams run K8s on OpenMetal. If you want to run the comparison against your actual workload, the PoC path at OpenMetal is designed for exactly that: a defined evaluation period with engineer-to-engineer support and ramp pricing for migrations.

Frequently Asked Questions

Is managed Kubernetes always more expensive than self-managed?

No. For a single cluster running fewer than 20 nodes without significant egress, the operational overhead of managing your own Kubernetes often costs more in engineering time than the managed premium. Self-managed on dedicated hardware makes the most economic sense at scale: multiple clusters, high egress, or large node counts where the per-GB and per-VM billing adds up.

What is the main hidden cost in managed Kubernetes?

Egress is typically the line item that surprises teams most. Cross-zone data transfer (which Kubernetes generates automatically by spreading pods across availability zones for resilience), outbound traffic to users, and data transfer to external services all generate per-GB charges that scale with your traffic, not your infrastructure size.

Why does EKS extended support cost so much more?

Amazon EKS charges $0.10 per cluster per hour for clusters running a supported Kubernetes version. Clusters running a version in the extended support window (past the 14-month standard support period) are charged $0.60 per cluster per hour, a 6x increase. Staying current with Kubernetes version releases is a cost control measure on EKS, not just a security practice.

Does OpenMetal charge for inter-node Kubernetes traffic?

No. Traffic between nodes crosses OpenMetal’s private network, which provides 20 Gbps of unmetered bandwidth per server. There are no per-GB charges for pod-to-pod communication, cross-node storage traffic, or any other internal cluster traffic.

What Kubernetes tooling works on OpenMetal?

Standard Kubernetes tooling (kubeadm, Helm, kubectl, Flux, ArgoCD, Prometheus, and others) works on OpenMetal’s infrastructure without modification. OpenStack integrations are available for persistent volumes via Cinder and for networking via Neutron. There are no proprietary node agents or plugins required.

How quickly can I add nodes to a Kubernetes cluster on OpenMetal?

OpenMetal adds servers to existing clusters in approximately 20 minutes. This is not comparable to cloud autoscaling, which operates in under a minute. Capacity planning matters more on dedicated infrastructure than on managed cloud Kubernetes.