TL;DR
If you want alignment fast, standardize on this hierarchy and ownership split:
Organizational private cloud (program term) -> VCF Fleet -> VCF Instance -> VCF Domains (management and workload) -> vSphere clusters
A fleet is the boundary for shared fleet services (operations, automation, identity, governance). It is not “one shared SDDC management plane.”
An instance is the boundary for a discrete SDDC footprint with its own management domain and workload domains.
A domain is your lifecycle and isolation unit. It is where you place blast radius and change windows on purpose.
Scope and code levels referenced in this post (VCF 9.0 GA BOM):
VCF 9.0 Release: Build 24755599
VCF Installer: 9.0.1.0 Build 24962180 (required to deploy VCF 9.0.0.0 components)
SDDC Manager: 9.0.0.0 Build 24703748
vCenter: 9.0.0.0 Build 24755230
ESX: 9.0.0.0 Build 24755229
NSX: 9.0.0.0 Build 24733065
VCF Operations: 9.0.0.0 Build 24695812
VCF Operations fleet management: 9.0.0.0 Build 24695816
VCF Automation: 9.0.0.0 Build 24701403
VCF Identity Broker: 9.0.0.0 Build 24695128
Architecture Diagram
Table of Contents
Scenario
Series map
Assumptions
Core vocabulary your org should standardize
The hierarchy that prevents org-wide confusion
What the fleet actually owns vs what stays per instance
Day-0, day-1, day-2 map
Challenge: one private cloud vs multiple fleets
Deployment posture patterns
Who owns what
Failure domain analysis
Anti-patterns
Summary and Takeaways
Conclusion
Scenario
You need architects, operations, and leadership to answer the same questions the same way:
“What is VCF actually managing?”
“What breaks if something fails?”
“Who is on point when something needs to change?”
“How do we scale without turning upgrades into drama?”
If you do not standardize vocabulary, you end up with:
Fleet and instance used as synonyms.
Change windows scheduled at the wrong layer.
Mis-scoped identity decisions that are expensive to unwind.
Incorrect assumptions about blast radius.
Series map
This topic is usually too big for one post, so here is the split:
Part 1 (this post): Vocabulary, hierarchy, and ownership boundaries that stop misunderstandings.
Part 2: The new management layer in VCF 9.0: VCF Installer, VCF Operations fleet management, and where lifecycle actually runs.
Part 3: Topology patterns and isolation: single site, two sites in one region, multi-region, and the identity options that go with them.
Later: Brownfield converge/import from a large vSphere estate.
Assumptions
You are greenfield for VCF 9.0 GA.
You plan to deploy both VCF Operations and VCF Automation from day-1, not phased.
You want patterns for single site, two sites in one region, and multi-region.
You may need either:
Shared SSO boundary (single enterprise),
Separate SSO boundaries (regulated isolation or hard multi-tenancy).
Core vocabulary your org should standardize
Use these terms consistently. Treat anything else as “slang” that must map back here.
TermWhat it means in your operating modelWhat it is notOrganizational private cloudYour program label for “the service you provide” (budget, roadmap, stakeholders)Not a VCF object you create in the UIVCF fleetGovernance and shared-services boundary for fleet management componentsNot “one shared vCenter”Fleet management componentsShared services for operations, lifecycle, automation, identityNot the same thing as SDDC ManagerVCF instanceA discrete VCF deployment footprint (management domain + workload domains)Not a tenant boundary by defaultVCF domainLifecycle and isolation boundary (management domain or workload domain)Not always a “site”Management domainA domain that hosts the instance’s core management components (and fleet components for the first instance)Not “never runs workloads” (you should still avoid putting random workloads here)Workload domainA domain built to run consumer workloadsNot a catch-all dumping ground for everythingvSphere clusterThe scale unit inside a domainNot the lifecycle boundary for VCF components
Recommended internal phrasing
This is the phrasing that reduces ambiguity in meetings:
Fleet = shared fleet services and governance scope
Instance = discrete VI footprint with its own core management stack
Domain = lifecycle and workload isolation boundary
Cluster = capacity and scaling unit
The hierarchy that prevents org-wide confusion
You are building a private cloud, but you manage fleets, instances, and domains
Leadership will say “private cloud.” That is fine.
Your platform team must translate that into platform objects:
Fleets
Instances
Domains
If you do not do this translation explicitly, you will end up with “one private cloud” being interpreted as “one vCenter,” which is the wrong mental model in VCF 9.0.
The hierarchy you should teach
Fleet is the umbrella for shared services and governance.
Instances are discrete deployments under that umbrella.
Domains are where lifecycle and isolation live.
Clusters are where you scale capacity.
This is the hierarchy you use in architecture reviews, operational runbooks, incident triage, and change calendars.
What the fleet actually owns vs what stays per instance
This is the most important correction to get right.
Fleet scope
The fleet gives you shared services across multiple instances, typically including:
VCF Operations as the day-to-day operate interface.
VCF Operations fleet management for lifecycle of management components (download binaries, deploy, patch, upgrade, backup workflows).
VCF Automation for self-service consumption and governance.
VCF Identity Broker to enable VCF Single Sign-On models (optional designs, but still a fleet concern).
Operational implication:
A fleet issue impacts visibility, governance, lifecycle workflows, and self-service.
A fleet issue does not delete your vCenter or turn off your ESX hosts.
Instance scope
Each instance remains a discrete SDDC management footprint:
SDDC Manager (instance lifecycle and orchestration)
vCenter for the management domain
NSX for the management domain
Domain-level vCenter and NSX as designed
Operational implication:
If an instance’s SDDC Manager or management domain is down, you lose instance-level lifecycle and potentially some management operations.
Workloads may continue running, but your ability to change and recover cleanly is reduced.
Domain scope
Domains are where you place:
Lifecycle boundaries
Change windows
Isolation boundaries
Blast radius boundaries
In VCF 9.0, a workload domain commonly has:
Its own vCenter
Its own vCenter SSO domain
NSX that may be dedicated to the domain or shared (design choice)
Operational implication:
Domain-level incidents are the “tenant impact” layer.
Domain-level upgrades can be scheduled per domain, not “everything at once.”
Day-0, day-1, day-2 map
This is the “where do we do the thing” map you want in every runbook.
Day-0 design decisions
These choices are difficult or expensive to reverse later:
Fleet count and scope (how many governance boundaries you want)
Instance alignment strategy (site, region, failure domain, or org boundary)
Domain strategy (how many workload domains, what is isolated)
Identity model choice (shared vs separate SSO boundaries)
Network segmentation for management components and workload domains
Backup and restore architecture for fleet management components
Day-0 outcome you want:
You can answer “what is the blast radius if X fails?” without hand-waving.
Day-1 bring-up
Day-1 is about standing up the first production-quality slice:
Deploy the first fleet (which includes deploying the first instance with its initial management domain and hosting fleet components in that initial management domain)
Deploy additional instances (if needed)
Create initial workload domain(s)
Deploy and integrate VCF Operations and VCF Automation (your chosen posture is “both from day-1”)
Day-1 outcome you want:
A working operating model where platform team, VI admin, and app/platform teams can each do their jobs without stepping on each other.
Day-2 operations
Day-2 is where most pain lives if the model is wrong:
Lifecycle operations (patch, upgrade, drift management)
Capacity management and domain scaling
Identity lifecycle (cert rotation, provider changes, recovery)
Adding instances to a fleet
Adding workload domains and mapping them into your cloud org structure
Incident response based on correct blast radius
Day-2 outcome you want:
Changes are scoped to the right layer, and rollback paths are clear.
Challenge: one private cloud vs multiple fleets
The challenge
You want “one private cloud” from a service catalog perspective, but you also need:
Scale
Isolation
Independent change windows
Regulatory separation (sometimes)
In VCF terms, that means deciding how many fleets you run.
Solutions
Solution A: One private cloud program, one fleet
Best when:
You have one enterprise governance boundary.
You want the simplest operating model.
You can tolerate a single fleet services layer as a shared dependency.
Tradeoffs:
Fleet services outage affects the entire program’s visibility and provisioning workflows.
Change windows for fleet services are shared.
Solution B: One private cloud program, multiple fleets
Best when:
You have regulated tenants or business units requiring separation.
You want different change windows per fleet.
You want to reduce fleet-level blast radius.
Tradeoffs:
You run multiple copies of fleet services (more overhead).
You must standardize your cross-fleet operating model (naming, RBAC, monitoring, backup).
Solution C: Multiple private cloud programs, multiple fleets
Best when:
You have hard organizational separation (budget, risk, compliance, separate leadership).
You expect different service tiers and roadmaps.
Tradeoffs:
Highest overhead.
Harder to create consistent enterprise-wide consumption patterns.
Architecture tradeoff matrix
DecisionIsolationScaleOps overheadUpgrade coordinationTypical use caseOne fleetMediumHighLowestHighest coupling at fleet layerSingle enterprise platformMultiple fleetsHighHighMedium to highIndependent per fleetRegulated isolation, large enterprisesMultiple programsVery highVariesHighestFully independentSeparate business entities
Deployment posture patterns
Single site
A practical default:
One fleet
One instance
One management domain
Multiple workload domains aligned to isolation needs (prod vs non-prod, regulated vs general, platform vs apps)
Operational posture:
Simple identity.
Simple change calendar.
Domain boundaries do most of the work for isolation.
Two sites in one region
Your main design fork is: “Do I want a single operational footprint or two?”
Common patterns:
One fleet, two instances (one per site)
Clear site-level failure domains.
Fleet services are still shared.
One fleet, one instance with stretched constructs (only if your latency and storage architecture supports it)
Can simplify some operations.
Stretched designs raise day-2 complexity and recovery requirements.
Operational posture:
Instance boundaries are often your “site boundary.”
Domains remain your “tenant and lifecycle boundary.”
Multi-region
You are balancing:
WAN dependency
Fleet services blast radius
Identity and compliance boundaries
Common patterns:
One fleet, multiple instances across regions
Central governance, but higher WAN dependency.
Multiple fleets (often one per region)
Lower regional coupling.
Better regulated isolation story.
Operational posture:
Multi-fleet becomes attractive when you want regional autonomy and reduced shared dependency.
Who owns what
This is the “stop paging the wrong team” table.
ScopePlatform team (cloud foundation)VI admin (infrastructure)App/platform teams (consumers)Fleet services (VCF Operations, fleet management, Automation, Identity Broker)Own and operate. Standards, backups, certs, lifecycle, RBACSupport integration points for their instancesConsume. No admin of fleet servicesFleet topology (how many fleets, where)Accountable decisionConsultedInformedInstance management stack (SDDC Manager, mgmt vCenter, mgmt NSX)Guardrails and standardsOwn and operate day-2Not responsibleDomain lifecycle (create, patch, expand, decommission)Guardrails and patternsExecute and operateConsume outcomesWorkload operations inside guest OS and KubernetesNot responsibleNot responsibleOwn and operate
Design-time vs day-2 ownership
Design-time: Platform team owns topology and identity model decisions.
Day-2: VI admins own SDDC-level lifecycle execution. Platform team owns fleet services lifecycle. App/platform teams own workload lifecycle inside the platform.
Failure domain analysis
Use this to set expectations with leadership.
Fleet services failure
What breaks:
Centralized visibility and governance
Automation workflows and self-service
Fleet-level lifecycle workflows
What usually keeps running:
Existing workloads in vSphere clusters
Core vCenter and ESX operations inside an instance (depending on what is down)
Instance management domain failure
What breaks:
Instance-level lifecycle orchestration
Some management operations for domains in that instance
Potentially NSX control plane for that instance if scoped there
What might keep running:
Workloads already running (until something requires management intervention)
Workload domain failure
What breaks:
Workloads and services in that domain
Tenant-specific operations
What keeps running:
Other domains in the instance
Other instances in the fleet
Anti-patterns
These are the patterns that create long-term operational pain.
Treating fleet and instance as synonyms.
Planning change windows at “the vCenter level” instead of domain and fleet services levels.
Putting regulated tenants into the same fleet without a governance and identity strategy.
Running meaningful production workloads in the management domain because “there is spare capacity.”
Out-of-band changes without an inventory and drift practice.
Summary and Takeaways
If you want the org aligned, lock in these rules:
Fleet is a shared services and governance boundary, not a shared vCenter boundary.
Instance is your discrete SDDC footprint boundary.
Domain is your lifecycle, isolation, and blast radius boundary.
“Private cloud” is what you call the program. Fleets, instances, and domains are what you operate.
If you standardize vocabulary now, you will reduce friction in design reviews, incident triage, and change governance.
Conclusion
VCF 9.0 becomes easier to operate when you stop thinking “one vCenter” and start thinking in fleet, instance, and domain boundaries.
When you do that, you get:
Clear ownership and escalation paths
Predictable blast radius
Change windows that match the topology
A platform posture that scales from single site to multi-region without rewriting your operating model
NSX-T Security Group Automation with PowerCLI: Static, Dynamic, and Tag-Based Membership
Introduction NSX-T security groups form the foundation for microsegmentation, dynamic firewalling, and tiered access. Manual group management is error-prone and inefficient. With…
The post VCF 9.0 GA Mental Model Part 1: Fleets, Instances, Domains, and the Fleet Management Layer appeared first on Digital Thought Disruption.