EKS vs GKE vs Self-Managed Kubernetes: Where the Cost Actually Goes

The number everyone compares is the one that does not matter

Ask which managed Kubernetes is cheaper and you will get an answer about control plane fees. At the time of writing, in September 2026, both AWS EKS and Google GKE charge about $0.10 per cluster per hour — roughly $72 a month — with GKE offering a free-tier credit that covers approximately one zonal or Autopilot cluster per billing account. (Cloud pricing moves; check the provider pages before you build a model on these numbers.)

For any cluster large enough to be worth having, $72 a month is noise. I have never once seen a Kubernetes bill where the control plane was the problem. What I see instead, on nearly every cost engagement, is compute that costs several thousand a month and is somewhere between 30% and 50% utilised.

So the useful comparison is not “which control plane is cheaper” but “which platform lets me run fewer, fuller nodes, and how much engineer time does each one consume”. That reframing is the whole article.

Where a Kubernetes bill actually goes

Sorted by how often each one turns out to be the largest surprise:

1. Compute. Usually 60-80% of the bill. The dominant variable is not the instance price, it is the gap between resource requests and real usage, because requests are what the scheduler reserves and therefore what determines node count. A cluster where every workload requests three times what it uses is running three times the nodes. On the AWS bill reduction engagement compute was about 60% of spend and a lot of it sat idle — rightsizing against 30 days of real usage was the single biggest lever, and it is platform-independent.

2. Persistent storage. Volumes that outlive the pods that created them, snapshots with no lifecycle policy, and default storage classes chosen once and never revisited. Orphaned volumes are pure waste and nobody notices them because they do not appear on any dashboard.

3. Network. The one that catches people. On AWS, cross-availability-zone traffic between pods is chargeable, and a service mesh or a chatty microservice architecture spread across three AZs generates a lot of it. NAT Gateway data processing charges apply to everything your pods pull from the internet, including every container image on every node scale-up. Internet egress is charged on both clouds.

4. Load balancers. Every Service of type LoadBalancer provisions a cloud load balancer with its own hourly charge. Twenty services exposed individually is twenty load balancers; the same twenty behind one ingress or Gateway is one. This is often the fastest single fix available, and the Gateway API migration is a natural moment to consolidate.

5. Observability. Log ingestion and retention, metrics cardinality, and control-plane audit logs shipped to a managed logging service. Audit logging on a busy cluster produces an astonishing volume, and it is billed by ingestion.

6. The control plane fee. Last. Genuinely last.

What each platform charges for

	EKS	GKE Standard	GKE Autopilot	Self-managed
Control plane	~$0.10/cluster/hr	~$0.10/cluster/hr (free-tier credit covers ~1)	~$0.10/cluster/hr	Your own 3 HA nodes + etcd storage
Node billing	EC2 instances you run	Compute Engine instances you run	Pod resource requests	Instances you run
Out-of-support version	Extended support at ~$0.60/cluster/hr	Release channels; extended channel available	Same as Standard	Entirely your problem
Upgrades	Managed control plane, you drive node upgrades	Managed, with release-channel automation	Fully managed	You, including etcd
Bin-packing responsibility	Yours	Yours	Google’s	Yours
Node autoscaling	Cluster Autoscaler or Karpenter	Cluster Autoscaler or node auto-provisioning	Automatic	Cluster Autoscaler
Typical hidden cost	Cross-AZ traffic, NAT data processing, CloudWatch	Egress, logging	Per-request pricing on poorly-sized pods	Engineer time

Two rows deserve expansion.

Extended support is a real cost. On EKS, when a cluster version leaves standard support it moves to extended support and the per-cluster fee rises roughly six-fold. One cluster is $72 to $430 a month; a fleet of fifteen clusters nobody has upgraded is a meaningful line item created entirely by deferred maintenance. It is one of the very few cloud costs you can delete by doing routine work.

Autopilot inverts who pays for waste. Standard clusters bill you for nodes, so the empty space on a half-full node is yours. Autopilot bills for pod resource requests, so the empty space is Google’s problem — but your inflated requests are still yours, and now you pay for them directly rather than diluted across a node. Autopilot punishes bad requests more visibly and rewards good ones more directly. If your bin-packing is poor and unlikely to improve, it can genuinely come out cheaper.

What self-managed actually saves

Running your own control plane on cloud instances saves the per-cluster fee and replaces it with:

• Three control-plane nodes for a genuinely highly-available setup, spread across availability zones, plus their storage.
• etcd operations. Backups you have tested restoring, defragmentation, disk latency monitoring, and the knowledge that etcd is unforgiving about slow disks.
• Upgrades. Control-plane version upgrades, certificate rotation before expiry, and the coordination of both against node upgrades.
• On-call for the control plane. When the API server is down, that is now your page.

For a single cluster, the instance cost alone typically exceeds the $72 you saved, before any human time. The honest cases for self-managing are: you are on-prem or on bare metal, where there is no managed option; you run enough clusters that the per-cluster fee multiplies into something material; you have a regulatory or air-gap constraint; or you genuinely have a platform team whose job this already is.

“We want more control” on its own is not one of them, in my experience. The control you gain is over components most teams never touch, and the control you lose is over your engineers’ calendars.

A model you can fill in

Skip the vendor calculators and build this from your own numbers. It takes twenty minutes and it is more accurate than anything generic.

monthly_cost =
    nodes × instance_hourly × 730 × (1 − discount_coverage)
  + persistent_storage_gb × storage_rate
  + snapshot_gb × snapshot_rate
  + cross_az_gb × cross_az_rate
  + internet_egress_gb × egress_rate
  + nat_processed_gb × nat_rate
  + load_balancer_count × lb_hourly × 730
  + log_gb_ingested × log_rate
  + clusters × control_plane_hourly × 730
  + engineer_days_per_month × loaded_day_rate      ← the term people omit

Then compute the number that actually decides things:

node_efficiency = sum(actual_usage) / sum(requests)

If that ratio is below about 0.5, your platform choice is not your problem. Fix requests first — the Kubernetes cost optimization guide covers the rightsizing method, and OOMKilled debugging covers why those requests got inflated in the first place, which is almost always a memory incident that someone “fixed” by doubling a number.

The last term in that model is the one that flips most self-managed business cases. Two engineer-days a month of control-plane maintenance, at any realistic loaded rate, dwarfs a $72 fee.

The levers that work on every platform

Ranked by return on effort, and none of them depend on which platform you chose:

1. Rightsize requests and limits against 30 days of real usage, with sane headroom. Biggest lever, every time.
2. Improve bin-packing. Fewer, fuller nodes. This is where the Karpenter vs Cluster Autoscaler decision earns its keep, because node-group-shaped clusters fragment by construction.
3. Buy commitment coverage for your steady-state baseline — savings plans, committed use discounts — and leave the peak on demand.
4. Move interruption-tolerant workloads to spot. CI runners, batch, dev and staging, stateless services with several replicas.
5. Consolidate load balancers behind one ingress or Gateway.
6. Keep cluster versions in standard support. On EKS this is directly a bill item.
7. Put a lifecycle policy on logs and snapshots. Retention set once at “forever” is a cost that compounds silently.
8. Delete orphaned volumes and idle environments. Staging clusters running at 3am for nobody are the easiest money on this list.

Notice that “migrate cloud providers” is not on the list. The cost difference between well-run EKS and well-run GKE is small relative to the difference between a well-run cluster and a badly-run one on either. A migration is a quarter of engineering time and a fresh set of unknowns — worth doing for capability, latency, contractual, or team-skill reasons, rarely worth doing for the control-plane fee.

How to decide

Choose EKS if your organisation is already on AWS. Data gravity, IAM, VPC design and commitment discounts all pull the same direction, and fighting that for platform reasons rarely pays.

Choose GKE if you are on Google Cloud, and consider Autopilot specifically if you do not have a team who will actively manage bin-packing. Paying for requests instead of nodes is a reasonable trade when nobody is going to tune node shapes.

Choose self-managed when you are on-prem or bare metal, when the per-cluster fee multiplies across a large fleet, when compliance requires it, or when you already have a platform team who owns this. Not to save $72.

Whatever you choose, fix requests first. A team that moves platforms without fixing utilisation carries the same waste to the new bill, plus a migration.

If you want this modelled against your actual bill rather than a generic calculator, that is cloud cost optimization work I do — usually a two to three week pass ending in a ranked list of changes with the saving attached to each. If the question is which platform to build on rather than how to trim the current one, that is DevOps and platform engineering.