VCF 9.0 GA Mental Model Part 3: Day-0 to Day-2 Ownership Across Fleets, Instances, and Domains

TL;DR

If you want clean accountability in VCF 9.0, anchor your operating model to the official hierarchy:

VCF private cloud -> VCF fleet -> VCF instance -> VCF domain -> vSphere clusters.

This post translates that hierarchy into an operating model: who owns what, where day-0/day-1/day-2 work happens, and how topology (single site vs two sites vs multi-region) changes your posture.

Scope and code levels referenced in this article (VCF 9.0 GA component set):

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
VCF Installer: 9.0.1.0 build 24962180 (used to deploy the 9.0.0.0 component set)

Architecture Diagram

Legend:

Fleet-level management components centralize governance and shared services across a fleet.
Instances retain discrete infrastructure management stacks (they do not merge into one giant vCenter/NSX).
Domains are your lifecycle and isolation boundary for compute + storage + network resources.

Scenario
Assumptions
Scope and Code Levels
The Ownership Model You Actually Need
Day-0, Day-1, Day-2 Map
Decision Criteria: Fleet vs Instance vs Domain vs Cluster
Topology Posture
Identity Boundaries and SSO Scope
Failure Domain Analysis
Operational Runbook Snapshot
Anti-patterns
Troubleshooting workflow
Conclusion

Scenario

You are aligning architects, operations, and leadership on what VCF 9.0 is actually managing, and how responsibilities split across:

Fleet-level services (VCF Operations, VCF Operations fleet management, VCF Automation, identity)
Instance-level foundations (SDDC Manager and the instance management domain)
Domain-level lifecycle and isolation (management domain and VI workload domains)
Consumption teams (VMs, Kubernetes, platforms, and automation templates)

The goal is predictable ownership and predictable blast radius.

Assumptions

You are deploying greenfield VCF 9.0.
You are building at least one VCF private cloud containing one or more VCF fleets.
You plan to deploy VCF Operations and VCF Automation early enough that the platform team uses them as the primary operational console for the environment.
You will support three physical site configurations over time:
- Single site
- Two sites in one region
- Multi-region

Scope and Code Levels

This article is pinned to the VCF 9.0 GA component set (versions and builds listed in TL;DR). If you are on a later 9.0.x maintenance release, terminology remains consistent, but exact UI placement and lifecycle sequencing can shift.

Version Compatibility Matrix

Layer	Component	Version	Build	Why you care operationally
Deployment	VCF Installer	9.0.1.0	24962180	The day-1 bring-up entrypoint for fleets and instances
Instance foundation	SDDC Manager	9.0.0.0	24703748	Drives instance lifecycle workflows and inventory control
Domain foundation	vCenter	9.0.0.0	24755230	Domain-level management boundary and API surface
Host layer	ESX	9.0.0.0	24755229	Your cluster capacity and patching blast radius unit
Network layer	NSX	9.0.0.0	24733065	Network segmentation, security policy, and edge services
Fleet services	VCF Operations	9.0.0.0	24695812	Central ops, visibility, grouping, and platform workflows
Fleet services	VCF Operations fleet management	9.0.0.0	24695816	Lifecycle for fleet services and related management components
Fleet services	VCF Automation	9.0.0.0	24701403	Self-service, governance, and policy-driven provisioning
Identity	VCF Identity Broker	9.0.0.0	24695128	Enables VCF Single Sign-On models and SSO scope decisions

The Ownership Model You Actually Need

A clean VCF program usually stabilizes when you stop assigning ownership by product name and start assigning it by boundary:

Fleet boundary -> governance and shared services
Instance boundary -> discrete infrastructure footprint and operational control plane
Domain boundary -> lifecycle, isolation, and workload placement
Cluster boundary -> scale unit and maintenance blast radius

“Who owns what” chart

Use this as a starting point for your internal RACI.

Construct or capability	Primary owner	Secondary owner	Day-2 responsibilities that must be explicit
VCF private cloud (org boundary)	Platform team	Security/GRC	Portfolio decisions, fleet count, policy and compliance guardrails
VCF fleet	Platform team	Architecture	Fleet service lifecycle, shared governance, change windows, identity posture
Fleet-level management components (VCF Operations, VCF Operations fleet management, VCF Automation)	Platform team	SRE/Operations	Backups, upgrades, integrations, tenant and RBAC guardrails
VCF instance	Platform team	Regional ops	Capacity lifecycle, adding domains, instance-level networking standards
Management domain	Platform team	VI admin	“Keep the platform running” discipline: patching, certificates, backups
VI workload domain	VI admin	Platform team	Day-2 LCM inside guardrails, cluster operations, domain health
Domain networking (NSX segments, T0/T1 patterns, edge capacity)	Platform team	Network/security	Network design standards, firewall policy model, edge scaling ceilings
VM provisioning and templates	App/platform teams	VI admin	Golden image ownership, config drift control, tagging standards
Kubernetes platform on vSphere	App/platform teams	Platform team	Namespace policy, cluster lifecycle, RBAC, platform SLOs
VCF Automation catalogs, projects, policies	Platform team	App/platform teams	Self-service guardrails, approvals, quotas, blueprint governance
FinOps reporting and showback	Platform team	Finance	Tagging accuracy, allocation rules, cost anomaly response

Design-time vs day-2 operations

This split is where most teams get surprised.

Design-time decisions (day-0) are expensive to unwind:

Fleet count and boundaries
Instance placement (site and region alignment)
Domain topology (number of workload domains, shared vs dedicated services)
Identity model and SSO scope
Network consumption model (and how much change control you want to enforce)

Day-2 operations should be routine, repeatable, and low-toil:

Adding workload domains and clusters
Capacity rebalancing
Patch and upgrade sequencing
RBAC lifecycle and access review
Drift detection and remediation

Day-0, Day-1, Day-2 Map

Use this map to stop “platform work” from leaking into “workload work”, and vice versa.

Phase	What you do	Where it happens	Why it matters
Day-0	Decide VCF private cloud -> fleets -> instances -> domains topology	Architecture/design	This locks your governance and blast radius posture
Day-0	Choose identity model and SSO scope	Architecture/security	Identity boundaries are hard to change later without operational pain
Day-0	Define network consumption model and tenant isolation model	Platform + network/security	Network decisions dictate scale ceilings and operational toil
Day-1	Deploy first fleet + first instance management domain	VCF Installer + first instance management domain	The first instance becomes the anchor location for fleet services
Day-1	Stand up fleet-level management components	Fleet services (hosted in first instance management domain)	This is your “platform services layer” for operations and governance
Day-1	Deploy initial VI workload domain(s)	Instance lifecycle workflows	Workload domains become your default lifecycle and isolation unit
Day-2	Add instances (new sites or regions)	Fleet services + new instance management domain	Expands footprint while keeping governance centralized
Day-2	Add workload domains and clusters	Instance workflows + domain operations	Expands capacity and isolates workloads cleanly
Day-2	Operate identity, automation, and lifecycle	Fleet services	Centralizes day-2 governance across attached instances

Decision Criteria: Fleet vs Instance vs Domain vs Cluster

Most “VCF design debates” are actually “where do I want the blast radius to stop?”

Quick decision table

If you need…	Add a fleet	Add an instance	Add a domain	Add a cluster
Separate governance plane and change windows	Yes	No	No	No
Regulated isolation with hard separation	Often yes	Sometimes	Sometimes	No
New site or region footprint	Sometimes	Yes	No	No
More lifecycle isolation for workloads	No	No	Yes	Sometimes
Different SLA or patch cadence for a workload group	No	No	Yes	Sometimes
More capacity in same workload boundary	No	No	No	Yes
Separate SSO boundary	Yes (cleanest)	Sometimes	No	No
Reduced shared service blast radius	Yes	Sometimes	Sometimes	No

Architecture Tradeoff Matrix

Option	Governance isolation	Operational overhead	Scale ceiling	Typical use
One private cloud, one fleet	Lowest	Lowest	Medium to high, depending on identity model	Standard enterprise starting point
One private cloud, multiple fleets	High	Higher	Higher overall, but duplicated services	Regulated zones, different change windows
Multiple private clouds	Highest	Highest	Highest	Mergers, hard org separation, distinct GRC boundaries

Topology Posture

You can support all three topologies with the same mental model. What changes is how you set your fleet and instance boundaries.

Single site

This is the simplest operating posture:

One VCF private cloud
One fleet
One instance
Management domain + one or more workload domains

Operational posture:

One change window for platform services is acceptable for most orgs.
Use workload domains to isolate “platform workloads” from “business workloads”.
Treat the management domain as the platform control plane. Keep it boring.

Two sites in one region

Challenge:

You want higher availability and operational continuity, but you do not want to turn every incident into a “distributed systems lesson”.

Solutions:

A) One fleet, one instance, stretched where justified

Best when latency is low enough and your network supports the design.
Operational reality: stretched designs raise complexity. Treat it as an advanced pattern, not the default.

B) One fleet, two instances (one per site)

Clear failure domains.
You can keep lifecycle and capacity operations site-aligned.
Fleet-level services still centralize governance.

C) Two fleets (one per site)

You get maximum isolation at the cost of duplicated fleet services and duplicated operations.
Use this when you need separate change windows or regulated separation even within a region.

Multi-region

Challenge:

Regions are real failure domains. Latency and inter-region dependency will punish “single control plane” assumptions.

Solutions:

A) One private cloud, one fleet, multiple instances (region aligned)

You keep centralized governance while allowing region-specific instances.
Plan identity carefully. SSO scope can become too large too quickly.

B) One private cloud, multiple fleets (region aligned or regulation aligned)

You isolate fleet services, identity posture, and change windows.
You pay in duplicated management footprint and duplicated operational effort.

C) Multiple private clouds

Use when organizational or regulatory boundaries require hard separation.
Expect duplicated tooling and duplicated platform practices unless you standardize aggressively.

Identity Boundaries and SSO Scope

In VCF 9.0, identity is not a footnote. It is a design-time decision that changes:

Admin experience
Audit posture
Blast radius during identity incidents
How your teams move between instances and domains

VCF Single Sign-On models you should reason about

Treat these as scope control knobs.

Model	SSO scope	Availability posture	Operational overhead	When it fits
Fleet-wide SSO	Large	Lower (single identity service per fleet)	Low	One fleet, tight governance, smaller instance count
Cross-instance SSO	Balanced	Balanced	Medium	Larger fleets, want to limit identity blast radius
Single-instance SSO	Small (per instance)	Higher per instance	Higher	Regulated isolation or region autonomy

Scale note you should plan for:

A common planning guideline is to size a VCF Identity Broker deployment for a limited number of instances. If you intend to exceed that, plan multiple identity brokers or multiple fleets.

Separate IdP and separate SSO boundaries (do both)

You typically implement “separate identity boundaries” two ways.

A) Separate fleets, separate IdPs

Cleanest separation.
Strongest isolation for regulated tenants.
Duplicates fleet services footprint.

B) One fleet, multiple identity brokers (cross-instance model)

Keeps a single governance plane.
Reduces blast radius of identity events.
You must be disciplined about which instances authenticate through which broker.

Design-time warning:

Resetting VCF Single Sign-On is a non-trivial event. Treat identity changes like a change program, not a quick admin task.

Failure Domain Analysis

This is the mental model that reduces panic during incidents.

Practical blast radius map

Failure	What breaks first	What usually keeps running	Your first triage question
Fleet services outage (VCF Operations, VCF Automation)	Visibility, governance workflows, self-service provisioning, central policy operations	Existing workloads in domains, core hypervisor operations	Is this governance down or is core infrastructure down?
Identity broker outage (in-scope instances)	Logins and SSO flows for in-scope components	Existing workloads and dataplane continue	What is the SSO scope for this identity broker?
Instance management domain incident	Instance lifecycle workflows, management vCenter/NSX for that instance	Workloads can keep running, but operations become constrained	Can you still reach workload domain vCenter/NSX?
Workload domain incident	Domain-specific provisioning and lifecycle	Other domains and instances	Is isolation working the way you intended?
Cluster-level capacity failure	Placement, HA behavior, performance	Other clusters/domains	Did you design cluster boundaries around maintenance and failure?

Operational Runbook Snapshot

This is the minimum you want documented before you call the platform “ready”.

Fleet services runbook (platform team)

Backups and restore procedures for:
- VCF Operations
- VCF Operations fleet management
- VCF Automation
- VCF Identity Broker (if used)
Certificate lifecycle and rotation plan
Upgrade sequencing plan:
- Fleet-level management components first
- Core instance components next (SDDC Manager, NSX, vCenter, ESX, vSAN)
Health checks:
- Fleet service availability and telemetry ingestion
- Identity broker health and readiness
- Automation integration health

Real-world RTO/RPO examples you can start with

These are starting targets that many teams use to set expectations. Tune them to your recovery strategy and staffing model.

Fleet services (ops and automation):
- RPO: 4 to 24 hours depending on your backup cadence and whether you treat it as “governance state” vs “mission critical”
- RTO: 2 to 8 hours depending on appliance recovery automation and runbook maturity
Identity services:
- RPO: 1 to 8 hours
- RTO: 1 to 4 hours, because identity outages create broad administrative impact
Instance management domain:
- RPO: 15 minutes to 4 hours depending on backup tools and datastore replication
- RTO: 4 to 24 hours depending on whether you can rebuild vs restore

The key is consistency: define targets per boundary and test them.

Anti-patterns

These are the patterns that inflate toil and create “mystery outages”.

Treating “fleet” and “instance” as synonyms.
Putting regulated tenants in the same fleet without a clear identity and change-window strategy.
Running business workloads in the management domain.
Sprawling workload domains with no lifecycle boundary strategy.
Trying to retrofit complex identity changes without a reset and rollback plan.
Assuming multi-region behaves like a LAN.

Troubleshooting workflow

When something breaks, the fastest teams classify the problem by boundary first.

Identify the boundary:
- Fleet service issue?
- Identity issue?
- Instance management domain issue?
- Workload domain issue?
- Cluster or host issue?
Confirm scope:
- One domain, one instance, or the whole fleet?
Validate impact:
- Provisioning impacted?
- Visibility impacted?
- Existing workloads impacted?
Choose the right console:
- Fleet-level visibility and operations -> start with VCF Operations
- Instance lifecycle workflows -> validate instance health and management domain state
- Domain operational state -> validate domain vCenter and NSX health
Stabilize, then remediate:
- Restore service first
- Then fix drift, misconfiguration, or lifecycle backlog

Conclusion

If you want VCF 9.0 to feel operable at scale, you need an ownership model that matches the platform hierarchy:

VCF private cloud is your organizational boundary for platform outcomes.
Fleet is where you place shared governance services and shared operational responsibility.
Instance is your discrete infrastructure footprint, often aligned to a site or region.
Domain is the lifecycle and isolation boundary you use to protect workloads from each other.
Cluster is your capacity and maintenance blast radius unit.

When those boundaries map cleanly to “who owns what”, day-2 operations becomes repeatable instead of heroic.

Sources

Azure Unmanaged Disks Retirement: How to Tell If You’re at Risk Before End of March 2026

TL;DR If any Azure IaaS VM in your estate still uses unmanaged disks, it is on a hard clock: after March 31, 2026 those VMs can’t be started, and running…