Of all the decisions in a VCF deployment, the tenancy model is the one I see made worst. Not because it is hard, but because of when it gets made.
The pattern is familiar. Infrastructure goes in, the platform team is busy, and somebody needs organisations and projects created so the pilot can start. So they get created, sensibly enough, based on whatever the org chart looked like that week. Eighteen months later there are forty projects, a quota model nobody can explain, and a request to reorganise it all that quietly never gets scheduled because too much now depends on it.
Tenancy is the one decision in the whole build that gets more expensive every month you leave it. Worth spending a fortnight on properly.
What a tenant actually is
Start here, because the answer changes everything downstream. In most enterprises a tenant is one of three things, and plenty of places have all three.
A department or business unit
The most common. Finance, retail banking, claims. Boundaries follow budget, which makes chargeback straightforward and makes the isolation requirement moderate. Usually these people trust each other, they just need their spend kept separate and their capacity protected.
A project or application team
More granular, shorter-lived, and the boundary disappears when the project ends. The trap here is that projects outlive their names. You will end up with a project called something nobody recognises, still running production, and nobody willing to delete it.
An external customer
Service providers, or enterprises with genuine third-party workloads. This is where isolation stops being about tidiness and becomes a real security boundary, with everything that implies for network separation, data handling and evidence.
Write down which one you mean before you create anything. If the answer is more than one, you need a hierarchy that accommodates both, and that is much easier to design up front than to retrofit.
The five decisions
1. Hierarchy depth
Organisation and project. Do you use organisation as a business unit and project as a team, or organisation as a legal entity and project as a business unit. Both work. Picking one and being consistent is what matters, because inconsistency here is what makes reporting impossible later. The tenancy deployment models documentation covers the supported shapes.
2. Quota strategy
Three broad approaches. Hard quotas per tenant, which is predictable and wastes capacity. Soft quotas with overcommit, which uses capacity well and produces arguments. Or tiered quotas where a small guaranteed allocation sits under a larger burst pool. I favour the third for most enterprises, because it gives finance a number and gives the platform team room to breathe. Whichever you pick, decide who can raise a quota and how fast, because a self-service platform where quota changes take three weeks is not self-service.
3. Isolation boundaries
Network isolation, storage policy separation, identity scope. The question to answer honestly is whether tenants need to be unable to reach each other or merely expected not to. Those are very different designs and very different costs. For business units inside one company, expected-not-to is often adequate. For external customers it never is.
4. Who is the provider
Someone curates the catalogue, owns quotas, and answers when a self-service workload misbehaves. If that role is not named, it defaults to whoever is most responsive, which is not a sustainable operating model. This is the organisational decision inside the technical one, and it is the reason a lot of platforms stall at pilot.
5. What happens at the end
How a tenant gets decommissioned. Data, quota return, identity cleanup, and for anything GPU-backed, what happens in accelerator memory between occupants. Nobody designs this at the start and everybody needs it eventually. Worth ten minutes now.
Where the newer constraints bite
Region is a hard edge for GitOps
The Argo CD based GitOps service in 9.1.1 runs one instance per hosting namespace, and it can sync across multiple namespaces and VKS clusters only within the same region. A multi-region estate needs multiple instances by construction. If your tenancy design assumed one delivery control point spanning regions, that assumption does not hold. It is Tech Preview, so this is a design input rather than a build item, but it is worth knowing before you draw the diagram. Detail here.
GPU tenancy is its own conversation
Broadcom's September performance testing found a single tenant using 36 to 38% of GPU streaming multiprocessors on a light inference workload, rising to 71% with four tenants sharing. So consolidation works. The constraint worth knowing at design time is that co-locating multiple tenants inside one VM is supported only with manual tenancy management, because VCF Automation requires each tenant in its own VM. If self-service is the goal, that decides your isolation model for you. Source.
Edition boundaries shape what tenants can be offered
Application and database management packs are VCF or VCF Edge only. If your catalogue promises database provisioning with monitoring included, check the entitlement covers it before it appears in a service description. Feature comparison.
A shape that usually works
Not a recommendation for your estate, just the pattern I find myself drawing most often for a mid-sized enterprise.
Organisation per business unit, with the business unit owning its budget. Project per application team or product, created from a template so they are consistent. Tiered quota, with a guaranteed floor per project and a shared burst pool at organisation level. Network isolation at organisation boundary, not project, because project-level isolation multiplies quickly and rarely earns its complexity. And a named provider team with a published service description, so people know what they are getting and what they are not.
The bit people skip is the service description. If a tenant cannot find out what the platform promises without asking someone, they will keep raising tickets, and you will have built self-service that nobody self-serves.
Before you create anything
That last one catches most design problems. A model that works for six tenants and falls apart at twenty is common, and you only find out when you are already at fifteen.
Want a score rather than a reading list?
I built a short self-assessment covering the same ground. Fifteen questions, about four minutes, and it scores your estate across five areas with what I would do next in each. Nothing is sent anywhere, it all runs in your browser.
