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.

Table of Contents

• 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

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.

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.

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

Architecture Tradeoff Matrix

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.

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

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

VMware Cloud Foundation 9.0 Documentation (Tech Docs): https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0.html
VMware Cloud Foundation 9.0 Release Notes: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/vmware-cloud-foundation-90-release-notes.html
Design (VMware Cloud Foundation 9.0): https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/design.html
Architectural Options in VMware Cloud Foundation: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/design/vmware-cloud-foundation-concepts.html
Fleet Management (VCF Operations): https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/overview-of-vmware-cloud-foundation-9/what-is-vmware-cloud-foundation-and-vmware-vsphere-foundation/vcf-operations-overview/fleet-management.html
VCF Single Sign-On Architecture: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/fleet-management/what-is/sso-architecture.html
Identity Providers and Protocols Supported for VCF Single Sign-On: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/fleet-management/what-is/protocols-suported-for–sso.html
Linking vCenter instances in VCF Operations: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/fleet-management/linking-vcenter-systems-in-vmware-cloud-foundation-operations.html