Managing Hundreds of Amazon EKS Clusters at Fleet Scale · Part 2 of 18

Many Small EKS Clusters or a Few Large Ones? The Fleet Decision

The first hard architecture decision in the series, and the one every later article assumes you've made. The real tradeoff is blast radius and isolation against the per-cluster cost floor and operational overhead. Here's the cost math, the scale ceilings, the tenancy question, and a decision tree you can pick a side with and defend in a review.

Pricing and version facts current as of 2026-06-30 · re-verify against AWS pricing and docs before you act on them.

The tradeoff that actually decides it — blast radius vs. per-cluster overhead

Strip away the noise and the many-vs-few question has exactly two sides. Every cluster you add buys you a stronger isolation boundary and a smaller blast radius: a bad upgrade, a runaway controller, a compromised namespace stays contained to that cluster instead of taking down the whole estate. And every cluster you add costs you a fixed control-plane fee plus a share of operational overhead — another thing to provision, patch, monitor, and upgrade.

So the decision is not "it depends." It's finding the point where your isolation requirements stop being worth the cost and ops you pay for them (Figure 1). That point is knowable, because the inputs are: how hard your isolation rules really are, whether you're near a scale ceiling, what the control-plane floor costs at your fleet size, and how you run upgrades. The rest of this article makes each of those concrete so you can place your own line.

One framing that keeps teams honest: a cluster boundary is the strongest isolation Kubernetes offers, but it is also the most expensive unit of isolation you can buy. Treat an extra cluster the way you'd treat an extra AWS account — worth it for a real boundary, wasteful for a cosmetic one.

What a fleet of control planes costs — the $21.9K/month floor

EKS charges $0.10 per cluster-hour for a cluster in standard support.¹ That's roughly $74/month per cluster ($0.10 × 730 hours), and it is a fixed floor: you owe it for an empty cluster and a packed one alike. One cluster, nobody notices. A fleet is a different story.

Do the arithmetic at scale and the number gets loud. 300 clusters × $0.10 × 730 hours ≈ $21,900/month in control-plane fees alone — and that's before a single EC2 node, EBS volume, or load balancer (Figure 2).¹ Push to 500 clusters and the floor is about $36,500/month. This is the single strongest argument for consolidation, and it's why "a cluster per app" or "a cluster per team" quietly becomes a six-figure annual line item.

It gets sharper if clusters fall behind. A cluster that slips onto extended support jumps to $0.60/cluster-hour — a 6× increase, roughly $438/month each.¹ A fleet of 300 on extended support would cost about $131,400/month in control-plane fees.

Averaged over a full 26-month version lifecycle (14 months standard, 12 months extended) a cluster works out to $0.33/cluster-hour — but that 6× rate bites for every hour a cluster sits behind. More clusters means more of them to keep current, so the upgrade discipline you can sustain (Part 14 in this series) directly caps how many clusters you can afford to run.

One caveat that keeps the argument honest: consolidating clusters cuts the control-plane floor and the ops multiplier, not your compute bill. Worker compute is a separate billing stream that scales with node count regardless of how many clusters those nodes sit in.¹ The same 200 nodes cost about the same whether they're one cluster or ten. So the many-vs-few decision is really a fight over the control-plane fee and human overhead, not raw EC2.

Why a single cluster can't just keep growing — the scale ceilings

If cost pulled only one way, you'd collapse everything into one giant cluster. You can't, and it's worth knowing exactly where the walls are — because they push back toward more clusters no matter what your cost model says.

The hard ceilings come from the control plane and the underlying AWS primitives:²

• etcd caps at 8 GiB. This is an upstream limit on the cluster's entire state store. Cram in enough objects — Secrets, ConfigMaps, CRDs, churn from a busy CI system — and you approach it. There is no "buy a bigger etcd" knob.
• ~10,000 services per cluster (and 5,000 per namespace). A large multi-service estate hits this well before it feels "big."
• The Nitro 28-attachment limit. A Nitro instance shares one budget of 28 attachments across EBS volumes, ENIs, and NVMe devices — which quietly caps pod density and networking per node, and by extension how much you can pack into one cluster's node fleet.
• Load-balancer target ceilings — ALB defaults to 1,000 targets, NLB to 3,000 (500 per AZ) — bound how much traffic one cluster's ingress can front.

None of these is a soft "best-practice" number you can quota-bump your way past; etcd and the Nitro limit in particular are architectural. The practical consequence: past a certain size, sharding into more clusters isn't a design preference — it's forced. A single cluster genuinely cannot grow forever, so any "one big cluster" plan needs a headroom check against these numbers before it survives an architecture review.

How much isolation you actually need — namespaces, clusters, or accounts

The isolation question is where most of the real disagreement lives, so be precise about the ladder you're choosing on. There are three rungs, each stronger and more expensive than the last.

Namespace-as-a-service (soft multi-tenancy). Tenants share one cluster and its control plane, separated by namespaces, RBAC, resource quotas, and NetworkPolicy.³ It's the cheapest option by far — one control-plane fee, one thing to upgrade — and it's the natural home for the "fewer, larger clusters" camp. The cost is real, though: tenants share a kernel, a scheduler, and a control plane, so you carry noisy-neighbor risk and a wider blast radius. A namespace boundary is a Kubernetes-level control, not a hard security wall.

Cluster-as-a-service / account-per-tenant (hard multi-tenancy). Each tenant (or environment) gets its own cluster, often in its own AWS account.³ This gives strong isolation and a clean compliance story — separate control planes, separate failure domains, separate blast radius — at the price of the per-cluster floor and multiplied operations.

The deciding question is blunt: can a namespace plus RBAC, quotas, and NetworkPolicy satisfy your "must never happen" rule? If yes, stay soft and save the money. If an auditor needs a hard compliance boundary, or you're running genuinely untrusted tenants, or a breach in one workload must not be able to reach another, a namespace won't hold and you pay for separate clusters. AWS's own scalability guidance lands in the same place for environments: use separate clusters for dev, test, and prod rather than namespaces when you need hard environment isolation.³

How cluster count reshapes every upgrade — surface vs. blast radius

Upgrades are where the many-vs-few tradeoff shows up as ongoing work, not just a one-time design choice, and the two sides trade the same problem in opposite directions.

The two sides trade the same problem in opposite directions — less surface buys a bigger blast radius, and vice versa:

EKS keeps a version in standard support for 14 months, so the treadmill is real either way — more clusters just means more laps running at once.

This is the crux for platform teams. If you have the automation to drive fleet-wide upgrades — GitOps, a rollout pipeline, upgrade-insight scanning (Part 14) — the "more clusters" surface becomes manageable and the contained blast radius is pure upside. If you don't, fewer clusters is the honest choice, because an upgrade surface you can't keep current is how clusters rot onto extended support and blow up the cost floor from the previous section.

How to pick a side and defend it — the decision framework

Put the pieces together and the decision resolves to a short walk down three questions (Figure 3). Default to fewer, larger clusters with strong namespace isolation, and require every split to earn its ~$74/month floor plus its ops overhead. Then split when — and only when — a real driver forces it:

• A hard isolation rule a namespace can't satisfy — a compliance scope, an untrusted tenant, a security boundary that must survive a breach. Go to separate clusters, often account-per-tenant.
• Independent upgrade cadence or self-owned blast radius — teams that must not move in lockstep, or failures that must stay contained. Split by team or domain.
• A scale ceiling — etcd 8 GiB, ~10,000 services, the Nitro 28-attachment limit. Here sharding is forced, not chosen.

If none of those applies, the answer is fewer and larger, because the only thing more clusters would buy you is a bigger control-plane bill and more upgrade surface. That's the defensible position in a review: name the driver that justifies each cluster, and if you can't name one, the cluster shouldn't exist.

This decision cascades into the rest of the series. How many clusters you run sets the shape of your tenancy model (Part 6, policy-as-code), your cost and showback story (Part 15), and how heavy your day-2 upgrade machine has to be (Part 14). Get this one right first — it's expensive to reverse once workloads and traffic depend on the boundaries you drew.