Kubernetes was never really built with a hard cap on cluster size, but every major cloud provider puts one on it anyway. Why? Because the underlying engine (etcd, the API server, and the scheduler) can only track and process so much data before things start falling apart.
Over the last couple of years, the big four managed services—AWS (EKS), Oracle (OKE), Google (GKE), and Microsoft (AKS)—have been pushing those caps higher and higher. But they aren't doing it for the same reasons, nor are they building it the same way.
Here is where the max worker nodes per cluster stand right now:
What’s driving these massive numbers?
AWS went all-in on AI. AWS raised the EKS ceiling to a massive 100,000 nodes. But this isn't for standard microservices—it's built specifically for giant AI and machine learning workloads. When you're training a massive model across tens of thousands of GPUs, splitting that job across multiple separate clusters is a nightmare. AWS built this so everything can live in one single place.
Oracle is chasing the same crowd. Oracle pushed OKE up to 20,000 nodes. Similar to AWS, they are targeting heavy compute and AI jobs. However, Oracle doesn't just hand you this limit out of the box—you have to meet specific setup requirements to unlock it.
Google takes an engineering approach. GKE supports 15,000 nodes. Google builds its control plane on top of Spanner (their massive distributed database), so they treat this limit less like a marketing stunt and more like an engineering rule based on what their backend can comfortably hold.
Azure is sitting comfortable at 5,000. AKS tops out at 5,000 nodes, which used to be the industry standard limit across the board. Microsoft hasn't rushed to join the mega-cluster war yet, focusing instead on feature stability and node pool limits (where individual pools cap at 1,000 nodes).
What "Extreme Scale" Actually Takes
Those big headlines hide a lot of fine print. Before you go building a 20,000-node cluster, keep these realities in mind:
1. Oracle hides scale behind an upgrade tier
To cross that 5,000-node mark in OKE, you can’t use the standard free "Basic" tier. You have to move to "OKE Enhanced," run a recent version of Kubernetes, and turn on specific encryption tools. Enhanced clusters give you a proper money-backed uptime guarantee (SLA) along with extra enterprise features, but it means reaching extreme scale requires paying for a higher management tier.
2. AWS built a tool for a specific job
Just because EKS can run 100,000 nodes doesn't mean you should move your company's web apps into one giant cluster. AWS explicitly framed this upgrade around AI training. If you aren't running massive distributed jobs that require raw GPU-to-GPU coordination, a massive cluster just adds risk.
3. Google cares about workload density, not just node count
Google's guidelines are refreshingly honest: node count isn't the only thing that breaks a cluster. If you run thousands of tiny pods that create, crash, and restart constantly, you will overwhelm the API server long before you hit 15,000 physical machines.
4. Azure’s limits depend on how you set it up
With AKS, hitting 5,000 nodes requires using standard load balancers and Virtual Machine Scale Sets. If you fall back to basic networking setups, your limit plummets to 100 nodes. Furthermore, while Azure offers a completely free control plane tier, Microsoft warns against running more than 10 nodes on it for real production workloads.
What Does it Cost?
When it comes to base control plane pricing, all four providers have basically settled on the same price:
- The baseline cost across the board is $0.10 per cluster, per hour.
- That comes out to roughly $74 a month just to keep the cluster's control plane alive.
However, the real differences come out in the extra options:
AWS EKS: Offers high-performance control planes for extra-heavy API loads (costing anywhere from $1.65 to over $13 an hour), plus an extended support fee if you refuse to upgrade older Kubernetes versions.
Google GKE: Gives you a ~$74 monthly credit that basically makes your first basic cluster's control plane free. They also offer Autopilot, which changes the game entirely: instead of paying for the servers in your cluster, you only pay for the exact CPU, RAM, and storage your individual pods use.
Azure AKS & Oracle OKE: Both offer totally free control planes on their basic tiers (you only pay for the underlying VMs). But if you want financial uptime guarantees or massive scale, you have to jump to their $0.10/hour paid tiers.
Takeaway on cost: For 99% of teams, the control plane fee is just noise. The real money goes to the compute instances (the actual servers) running your workloads.
Operational Reality: What Actually Breaks First?
If you talk to the engineers who maintain these platforms, they’ll all tell you the same thing: The node cap isn't usually what breaks your cluster.
When clusters fall over at scale, it’s usually because of:
Network exhaustion: Running out of IP addresses in your subnet for pods and services.
Container registry bottlenecks: Trying to pull a 10GB Docker image to 5,000 machines at the exact same second.
API server overload: Thousands of pods constantly talking to the cluster control plane at once.
In fact, the official documentation for almost all of these providers quietly says the same thing: Don't build one giant cluster if you don't have to.
For almost every company, running four or five medium-sized clusters is much safer than running one mega-cluster. It isolates failures, makes updates less terrifying, and lets different teams move at their own pace.
Unless you're training a massive AI model, don't worry too much about who has the biggest number. Focus on SLA tiers, how easy it is to manage multiple small clusters, and how compute costs fit your budget.