TL;DR · Key Takeaways
- A tenant organization is an isolation boundary, one per line of business or customer, with access only to its allocated resources.
- Creating one is quick: a name that becomes the URL, a first admin, and VCF Automation auto-provisions the quota, transit gateway, and VPC.
- Do not manage local users at scale. Connect each organization to an external identity provider over OIDC, LDAP, or SAML.
- Tenants are scoped with quotas on networking resources, and with a provider gateway that is either shared across tenants or dedicated to one.
- Predefined roles cover the split between Organization Administrators and Application Teams; finer-grained scoping happens at the project level, in the next Part.
A tenant in VCF Automation is a wall, not a folder. That distinction is the whole point of this Part. A folder organizes things that can still see each other. A tenant organization is an isolation boundary: a line of business or a customer that operates in its own secure space, with access only to the resources you allocated to it and nothing else. Get that mental model wrong and you build tenants that leak into each other. Get it right and multi-tenancy does what it promises.
What a tenant organization actually is
Multi-tenancy is native to VCF Automation through organizations, a model it inherits from its VMware Cloud Director lineage. Each organization represents a tenant and operates in a secure, isolated environment. A user in tenant A cannot see tenant B’s deployments, networks, or catalog, because the boundary is enforced by the platform, not by convention or careful naming. This is the isolation that lets you put a finance business unit and a development team, or two unrelated customers, on the same VCF Automation instance without either being able to reach the other.
The design implication is the one I push hardest with clients. A tenant boundary should map to a real ownership boundary: a business unit that owns its budget and its workloads, or a customer with a contract. Drawing tenants by org-chart convenience, or worse, one giant tenant for everyone with projects standing in for isolation, gives away the protection the model exists to provide. Decide what genuinely needs to be walled off from what, and let those walls be your tenants.
Creating a tenant
The mechanics are the same as the first organization you created in Part 6, and deliberately light. You supply a name, which becomes the unique identifier in the tenant’s URL, an optional description, and a first administrator. VCF Automation then provisions the tenant’s quota and networking on its own, standing up the transit gateway and VPC so the tenant has somewhere to run workloads from the moment it exists.
# Tenant organization, creation inputs (example)
organization:
name: finance # becomes the URL, choose once and keep
description: Finance business unit
first_user:
username: fin-admin
password: '<15+ chars, mixed categories>'
role: Organization Administrator
provider_gateway: shared # or 'dedicated' for isolated WAN egress
# On create, VCF Automation auto-builds the quota, transit gateway and VPC.Two predefined role types frame who does what inside the tenant: Organization Administrators, who run the tenant, and Application Teams, who consume it. That split is enough to get a tenant working. Finer-grained control, who can deploy what inside which slice of the tenant, lives at the project level, which is the next Part. Resist the urge to model everything with org roles; the projects layer exists precisely so you do not have to.
Identity: federate, do not hand-roll users
The first local admin gets a tenant off the ground. It should not be how the tenant runs. Both organization types can connect to an external identity provider over OIDC, LDAP, or SAML, and that is how real tenants should authenticate. Federating means users sign in with the credentials they already have, group membership drives access, and an offboarding in your directory removes platform access without anyone touching VCF Automation. Managing local users by hand across multiple tenants is a slow-motion security incident; it is where stale accounts and shared passwords live.
Scoping with quotas and gateways
Isolation answers who can see a tenant. Scoping answers how much it can consume and how it reaches the outside. VCF Automation manages networking resources by quota, including the individual IPs and prefixes a tenant draws from an IP Space. Setting those quotas is how you stop one tenant from exhausting shared address space and starving the others. A quota is not bureaucracy; it is the backpressure that keeps a shared platform fair.
Shared or dedicated provider gateway
The provider gateway you built in Part 6 can be shared across tenants or dedicated to one. A shared gateway is simpler and fine for tenants that just need general egress. A dedicated gateway makes sense when a tenant needs to reach a specific external or WAN network of its own, or when isolation requirements extend to the north-south path and not just the workloads. Choose shared by default and reach for dedicated when a tenant has a real, separate connectivity requirement.
| Dimension | Shared gateway | Dedicated gateway |
|---|---|---|
| Complexity | Lower, one to manage | Higher, one per tenant |
| External networks | Common egress | Tenant-specific WAN |
| Best for | Most internal tenants | Isolation or dedicated connectivity |
Worked example
Say you onboard three tenants onto one /16 IP Space. Give each a quota of, for example, a /20 worth of addresses, and you have carved the space into bounded slices that cannot starve one another, with room left over for a fourth tenant later. Federate all three to your corporate directory so the same group, finance-cloud-admins, grants admin in the finance tenant and nothing in the others. Put two on the shared provider gateway and the third, which needs a dedicated WAN link to a partner, on its own gateway. Three tenants, three different scoping decisions, all made on purpose at onboarding rather than retrofitted after something broke.
Onboarding a tenant cleanly
Pulling the pieces together, a clean tenant onboarding is five decisions made in order, not a single create button. Draw the boundary, federate identity, set the quota, choose the gateway model, and hand off the first admin role. Skip any one and you store up a problem that surfaces later, usually in front of the tenant you were trying to impress.
The mistake I see most at onboarding is role confusion. The first user you create is an Organization Administrator, and it is tempting to hand that role to everyone who needs to use the tenant, because it works. It works the way giving everyone root works: until it does not. Application Teams consume the tenant; they do not need to run it. Give the admin role to the small group that actually administers the tenant, and let everyone else come in through projects with the access their job requires. Getting that split right at onboarding is far easier than clawing back over-granted admin once people have it and expect it.
The other onboarding habit worth building is documentation that travels with the tenant. Record which boundary it represents, which identity provider and groups it federates to, what its IP quota is, and whether its gateway is shared or dedicated. That one short record is what lets the next admin, or you in six months, understand a tenant without reverse-engineering it from the portal. A tenant you cannot explain is a tenant you cannot safely change, and on a multi-tenant platform the changes never stop coming.
The Bottom Line
Treat each tenant as a wall you are putting up on purpose. My recommendation: map tenants to real ownership boundaries rather than the org chart, federate identity to an external provider from day one instead of nursing local accounts, set networking quotas at creation so no tenant can starve the others, and default to a shared provider gateway, reserving dedicated gateways for tenants with a genuine separate connectivity need. The platform enforces the isolation for free; your job is to draw the boundaries where they belong and scope what flows across them. Do that and a tenant is a safe place to hand someone the keys. Skip it and multi-tenancy becomes a shared folder with extra steps.
Next we go inside the tenant to projects, where members, roles, and resource limits get specific. For the model that frames all of this, see Part 1 on provider, tenant and project. How are you drawing your tenant boundaries, by business unit, by customer, or by environment? Tell me in the comments.
Previous: Part 6, the provider organization. Next: Part 8, projects, roles and limits (coming soon). Up: VCF Automation Guide (pillar).
References
- Organization Management (Broadcom TechDocs)
- VCF Automation 9.0 Networking Deep Dive (Tom Fojta)
- VCF Automation All Apps Organization Configurations (VCF Blog)
About The Author
