A managed Kubernetes control plane is cheap. AWS EKS charges $0.10 per cluster per hour, which is about $73 a month. Google GKE charges the same $0.10 per cluster per hour and hands you one cluster effectively free through a $74.40 monthly credit. Azure AKS is free without an SLA, or $73 a month with one. So the control-plane fee is a rounding error. The number that actually decides whether to buy managed Kubernetes is the salary of the person who runs the cluster. A US platform engineer averages $133,026 a year. That’s the real price tag, and it’s the one nobody puts on the pricing page.
We’re gmware, a software development firm headquartered at 5900 Balcones Drive in Austin, TX, with engineering centers in Bangalore and Mohali, India. We run our own production systems on managed clusters: Shield Suite, our retail-intelligence product, pulls data across 60,000+ beverage-alcohol storefronts, which means nodes fail, upgrades land on a Tuesday, and someone has to be paged when they do. So the “who keeps the cluster alive” part of this post isn’t a hypothetical. Below: what “managed Kubernetes” actually means (there are two very different versions), the real cost drivers, the honest verdict on when you don’t need Kubernetes at all, and the managed-ops model that sits between running it yourself and pretending you can.
Managed Kubernetes cost, at a glance
What does “managed Kubernetes” actually mean
The phrase covers two things that cost wildly different amounts, and people conflate them constantly.
Cloud managed Kubernetes is what EKS, GKE, and AKS sell. The vendor runs the Kubernetes control plane for you: the API server, the scheduler, etcd, the parts that fail in ways that ruin a weekend. You get a healthy control plane and an SLA. Everything above the control plane is still yours. You own the worker nodes, the version upgrades, the networking config, the security policies, the monitoring, and the pager. This is a service tier, not a team. It removes maybe 20% of the operational load, the gnarly 20%, and leaves the rest on your desk.
Managed-ops Kubernetes is the other version. A provider runs the whole cluster, control plane and everything above it. They handle upgrades, node pools, scaling, the CI/CD wiring, the alerting, and the 2am page. You get clusters that work without hiring a platform engineer to keep them working. This is a team you rent, and it’s the version most people picture when a vendor says “fully managed.”
The distinction decides your budget. Cloud managed Kubernetes costs $73 a month. Managed-ops costs a fraction of a platform engineer’s $133,026 salary. Sign up for the first thinking you got the second, and you’ve bought a control plane and inherited a full-time job.
The real cost drivers of managed Kubernetes, ranked
Three things drive the bill, and they’re wildly unequal.
Control-plane fees are the smallest. All three big clouds land in the same narrow band. EKS is $0.10 per cluster per hour. GKE is $0.10 per cluster per hour, with the first cluster covered by that $74.40 monthly credit. AKS is free without an SLA and $73 a month with one. Run ten clusters and you’re at a few hundred dollars a month. Nobody’s cloud budget dies here.
Node compute is the biggest visible line. Your pods run on worker nodes, and those nodes are regular VMs you pay for whether or not they’re busy. A cluster sized for peak traffic that mostly sits idle burns money all night. This is where most Kubernetes overspend actually lives, and it’s the part the control-plane pricing page never mentions.
The platform engineer is the hidden line, and it’s the whole story. Someone has to run the cluster: upgrade Kubernetes versions before support lapses, right-size node pools, debug why a pod won’t schedule, patch the CNI, respond when a node dies at 2am. That person averages $133,026 a year, with the middle of the market between $105,000 and $153,500. One of them costs more than a decade of control-plane fees. If your Kubernetes decision doesn’t account for this salary, you haven’t priced Kubernetes. You’ve priced the receipt and ignored the mortgage.
Where the money actually goes
EKS vs GKE vs AKS control-plane pricing, side by side
These are the managed Kubernetes offerings from AWS, Google Cloud, and Azure. The control-plane fees are close enough that they rarely decide anything. Node compute and which cloud you already live on decide it.
| Offering | Control-plane fee | Notable | Extended/premium support |
|---|---|---|---|
| AWS EKS | $0.10 per cluster per hour (~$73/mo) | No free control-plane tier | $0.60/hr on end-of-life versions |
| Google GKE | $0.10 per cluster per hour (~$73/mo) | $74.40/mo credit ≈ one free cluster | +$0.50/hr on extended-support versions |
| Azure AKS | Free (no SLA) or $73/mo (Standard, SLA) | Free tier not for production scale | $438/mo for Premium + long-term support |
A word on the “free” and “extended support” numbers, because they trap people. AKS’s free control plane has no SLA and Microsoft caps it well below production scale; it’s for dev, not for the thing that pages you. And every one of these clouds charges a penalty to stay on an old Kubernetes version. EKS jumps from $0.10 to $0.60 an hour once your version hits extended support. That’s a six-times markup that quietly appears if nobody’s upgrading the cluster, which loops right back to needing someone whose job is upgrading the cluster.
Managed provider, self-managed, or serverless containers: a decision matrix
Three real options sit in front of most teams, and the right one depends on how many services you run and whether you have a platform team. Read across your row, not down a column.
| Option | What you run | Best fit | Cost shape | Where it bites |
|---|---|---|---|---|
| Self-managed Kubernetes | Everything above the control plane | You have a platform team; k8s is core | Control plane ($73/mo) + nodes + $133K/yr operator | The salary. And the on-call. |
| Managed-ops provider | The provider runs the cluster for you | Need prod k8s, can’t justify a full-time platform hire | Nodes + a service fee under a full salary | Less control; you trust a partner |
| Serverless containers | Nothing; no nodes, no cluster | Few services, spiky or small traffic | $0.04048/vCPU-hr + $0.004445/GB-hr, pay only while running | Unit cost climbs at large steady scale |
Which one fits you
Most teams over-index on the middle column of the pricing page and skip the operator column entirely. The operator column is the decision.
When you genuinely don’t need Kubernetes
Here’s an opinion we’ll defend: most teams that adopt Kubernetes didn’t need to, and the tell is that they can’t name the platform engineer who owns it.
Kubernetes is a tool for a specific problem shape: many services, uneven and spiky load, fine-grained autoscaling, multi-region deploys, and a team that already speaks it. 82% of container users now run it in production, up from 66% two years earlier, and 98% of organizations have adopted cloud-native techniques. It’s the default now. But “default” and “right for you” are different sentences.
Skip Kubernetes, or delay it, when any of these are true. You run three or five services with steady traffic. Nobody on your team can debug a pod stuck in Pending. Your load is predictable enough that a couple of VMs behind a load balancer covers it. Or your workload is spiky and small, in which case serverless containers like Fargate bill you only while a container runs and vanish when it doesn’t, no cluster to babysit. Picture a five-person shop running a web app and a background worker. On Kubernetes, they’re paying node compute around the clock plus edging toward a platform hire. On Cloud Run or Fargate or two VMs, they’re paying for what they use and their engineers stay on the product.
And the interesting twist in the same survey: the hard part of Kubernetes stopped being the technology. The top adoption challenge is now “cultural changes with the development team,” cited by 47%, while complexity dropped to 34%. The clusters got easier. Getting a team to run them well, and deciding whether you should at all, got harder. That’s the part a pricing page can’t help you with. We think about the same fork on every cloud project; we laid out the wider version in our take on where cloud spend actually leaks.
The managed-ops provider model, and where gmware fits
Between “run it yourself” and “don’t use Kubernetes” sits the option most mid-sized teams should look at first: a managed-ops provider running the cluster for you. You get production-grade Kubernetes, upgrades, autoscaling, and the on-call rotation, without carrying a $133,026 platform hire before your product justifies one. You trade some control for not staffing a role you can’t yet fill. For a lot of companies, that trade is obviously correct and they still hesitate on it.
That’s the corner of our practice this sits in. We run clusters and the boring parts that keep them alive: version upgrades before support lapses and the fee jumps, node pools right-sized so you’re not paying for idle capacity all night, alerting that pages us before it surprises you, and the CI/CD wiring so a deploy doesn’t need a Kubernetes expert on your side. Our DevOps and infrastructure practice runs delivery from Austin with engineering in Bangalore and Mohali, which keeps senior eyes on the cluster during US hours without US-only rates. When the real project is getting off legacy infrastructure and onto containers in the first place, that’s a cloud migration before it’s a Kubernetes question, and we’ll tell you if that’s the actual order of operations. We size the same honest way on any move to the cloud in our breakdown of what a cloud migration really costs a small business, and the same rule holds when the starting point is aging software in our legacy modernization cost guide.
Tell us how many services you’re running, what your traffic looks like, and whether anyone on your side wants to own a cluster. Reach out and we’ll give you a straight answer on whether you need managed Kubernetes, a managed-ops provider, or nothing this complicated at all, with the cost and timeline, within 48 hours.