One Big Cluster or Many: The AKS Tenancy Decision

Every platform team eventually holds the same meeting. One camp wants a single big cluster: efficient, one thing to upgrade, easy to reason about. The other wants a cluster per team or per service: clean blast radius, no noisy neighbors, real isolation. Both sides are right, which is why the meeting never ends.

The argument is unwinnable because "how many clusters" is the wrong question. The right one is: what's the smallest boundary you're willing to let a failure or a breach cross?

The two kinds of isolation

Soft isolation lives inside one cluster: namespaces, RBAC, network policies, resource quotas. It's cheap, dense, and one upgrade covers everyone. But the isolation is only as strong as your configuration, and some things are simply shared: the control plane, the node OS, the CNI, a cluster-wide CRD a careless controller can wedge.

Hard isolation is separate clusters. The boundary is real. A compromised or broken cluster can't touch its siblings, and each can run its own version, node strategy, and blast radius. The cost is multiplication: every cluster is another thing to upgrade, monitor, secure, and pay a baseline for. Ten clusters is roughly ten times the day-2 surface.

Namespaces separate workloads that trust each other. Clusters separate workloads that don't. Decide which sentence describes your tenants.

What should actually push you apart

Don't split on instinct. Split when a real boundary demands it:

• Compliance and data residency. A workload under a regime that mandates isolation gets its own cluster. This isn't an architecture debate; it's a requirement.
• Blast radius you can't accept sharing. If a misbehaving tenant taking down the cluster would be catastrophic for another tenant, that's a hard boundary.
• Divergent lifecycles. Teams that must control their own upgrade cadence, Kubernetes version, or node hardware will fight a shared cluster forever. Give them their own.
• Genuinely untrusted tenants. Multi-tenant SaaS running customer code is the textbook case for hard isolation. Namespaces are not a security boundary against an adversary.

If none of these apply, you're usually paying the multi-cluster tax for a boundary you didn't need.

The shape most teams converge on

Not one cluster, not one-per-team. A tiered model:

• A small number of clusters per environment, say, prod and non-prod, maybe split again by region or by a genuine compliance line.
• Namespace-based tenancy within each, with RBAC, quotas, and network policies doing the soft isolation for teams that trust each other.
• A separate cluster only when a tenant trips one of the hard-boundary tests above, and that exception is documented, because the next person will ask why it exists.

This keeps day-2 toil bounded while giving you real isolation exactly where it's required, and nowhere it isn't.

The takeaway

The teams who consolidated into one cluster and got burned, and the teams who sprawled into forty clusters and drowned, made the same mistake: they picked a number instead of a boundary. Start from what must never share fate, draw your hard lines there, and let namespaces handle everything else. The cluster count falls out of the boundary, not the other way around.