Almost every team building a shared platform reaches this decision, and most reach it by accident: they start with namespaces because that is what a single cluster offers, and discover the constraints eighteen months later.
The technical differences are well documented. What tends to be missing is the running cost of each choice, which is what you actually live with.
Namespace per tenant
Cheapest to run, weakest to evidence. One cluster, good bin packing, one upgrade to perform, one set of shared components. If your tenants are teams inside one organisation and you have a single compliance boundary, this is very often correct and you should not talk yourself out of it.
The ongoing cost is vigilance. The isolation is real but it is made of many small configurations, each of which can be got wrong: quotas, network policy, RBAC, admission control, and anything cluster-scoped that a tenant can reach. Adding a cluster-scoped resource that leaks across namespaces is easy to do by accident and hard to notice.
Cluster per tenant
The middle option, and the one that surprises people on cost. Isolation is far easier to reason about and to explain to someone auditing it. What you pay is a control plane per tenant, worse packing, and every fleet operation multiplied by tenant count.
That multiplication is the part teams underestimate. It is not the cloud provider charge for the control plane. It is that every upgrade, every certificate, every shared component rollout and every inventory question now scales with the number of tenants. This is affordable only if fleet operations are automated first. Choosing cluster-per-tenant without that automation is choosing to do the same work repeatedly by hand.
Account or project per tenant
Strongest boundary, highest fixed cost. The blast radius of a mistake stops at the account, identity is genuinely separate, and the billing boundary matches the isolation boundary, which makes cost allocation almost free.
This is the only option where separation is the default and sharing is the exception.
The cost is a landing zone and everything that comes with it: account provisioning, network topology between accounts, centralised logging that spans them, and a way to grant temporary access that does not turn into a permanent credential. That is a real programme of work before your first tenant is onboarded.
The questions that actually decide it
In our experience four questions settle this faster than any comparison table:
- Does an auditor need to see the separation, or only you? Evidencing namespace isolation annually is a recurring cost that account separation avoids entirely.
- Can one tenant incident be investigated using data from another? If not, your telemetry boundary has to match your isolation boundary, which usually rules out the cheapest option.
- Do tenants have different upgrade appetites? A tenant that cannot take a cluster upgrade during their peak season forces a boundary at cluster level or above.
- Is the billing boundary the same as the tenant boundary? If finance needs per-tenant cost with no estimation, accounts give it to you for free and the alternatives need real work.
Mixing is allowed and usually right
Nothing requires one answer across the estate. Regulated tenants can sit in their own accounts while internal teams share namespaces in a shared cluster, provided the machinery that builds and delivers to both is the same.
That is the part worth protecting. The isolation boundary can vary by tenant without much pain. What causes pain is each boundary developing its own way of being built, upgraded and deployed to, because then you are not running one platform with three shapes, you are running three platforms.
