TL;DR
VCF Protection and Recovery 9.1 changes disaster recovery from a service that infrastructure administrators configure manually into a capability that organization administrators, project administrators, and authorized users can consume through VCF Automation.
That does not mean every tenant should be allowed to create arbitrary replication relationships, reserve unlimited recovery capacity, or initiate a production failover without oversight.
A sustainable self-service disaster recovery service needs separate controls for:
requesting protection
selecting an approved replication class
consuming recovery-site capacity
defining network and IP mappings
creating and testing recovery plans
authorizing planned migrations and emergency failovers
recording costs and audit evidence
retiring protection when the workload is decommissioned
The right mental model is not unrestricted self-service. It is delegated disaster recovery inside a provider-defined service boundary.
Introduction
Traditional disaster recovery often begins with an infrastructure ticket.
An application owner identifies a workload that needs protection, submits a request, waits for a virtualization or storage administrator, answers questions about recovery objectives, and eventually receives confirmation that replication has been configured.
The technical work may be straightforward. The operating model is not.
Every request creates coordination across application owners, infrastructure teams, network administrators, security teams, capacity planners, and business continuity stakeholders. As the number of protected applications grows, the ticket queue becomes part of the recovery architecture.
VCF Protection and Recovery 9.1 begins to change that model. Through VCF Automation, authorized organization users can configure VM-level replication, while provider and organization administrators establish the underlying regions, namespace relationships, infrastructure, replication classes, and governance boundaries. VCF 9.1 also introduces foundational multi-tenant disaster recovery for Supervisor VM Service VMs in VCF-to-VCF protection scenarios.
That is a meaningful shift.
It moves disaster recovery closer to the application team. It also introduces a risk that many self-service platforms eventually encounter: a faster request path can create resources more quickly than the organization can govern them.
The design objective is therefore not simply to make replication available in a portal. It is to create a disaster recovery service that gives application teams useful autonomy without giving away control of recovery capacity, network topology, incident authority, or organizational risk.
Self-Service DR Changes Decision Rights
Self-service disaster recovery is often described as an automation improvement. It is more accurately an operating-model change.
The technical workflow may start with a user selecting a VM and a replication class, but the real change is that several decisions move away from a centralized infrastructure team.
Those decisions include:
which workloads should be protected
which recovery tier they should consume
which recovery region should receive the replica
how much capacity should be reserved
which network the recovered workload should use
who can test the recovery plan
who can declare a disaster
who pays for the service
when the protection relationship should be removed
These are not all the same kind of decision.
A platform can safely delegate a repeatable protection request while retaining tighter control over recovery execution. It can allow an organization administrator to pair namespaces while preventing an ordinary project user from changing provider-level mappings. It can let an application team test its workload without granting that team authority to redirect production traffic during an enterprise incident.
The first governance principle is therefore simple:
Permission to request protection is not permission to declare a disaster.
Without that separation, self-service reduces ticket volume by transferring operational risk to users who may not understand the full application, network, capacity, and business-continuity consequences of their actions.
The Multi-Tenant Recovery Scenario
Consider a VCF environment serving three internal organizations:
a payments organization operating revenue-critical applications
an engineering organization running development and internal platforms
a corporate services organization operating shared business systems
All three organizations consume infrastructure through VCF Automation. Each has its own namespaces, users, network boundaries, quotas, and service entitlements.
The platform team operates a shared recovery region.
The payments organization expects short RPOs, pre-reserved compute, quarterly recovery tests, and a tightly controlled failover process. Engineering needs protection for selected platform services but can tolerate longer recovery times. Corporate services requires protection for several critical systems, but not every VM in the organization.
A shared recovery platform can support all three. It should not treat all three the same.
The service must allow each organization to consume an appropriate protection tier while preserving provider control over the scarce resources and high-risk actions that affect the whole recovery region.
Architecture at a Glance
The architecture separates the consumption request from the controls that make the request safe.
The important boundary is the policy layer in the center.
VCF Automation provides the consumption interface, but the platform team still defines which services exist, who can use them, what infrastructure they consume, and which controls apply. VCF Protection and Recovery performs replication and recovery orchestration, but it should not become the only place where ownership, approval, cost, and business priority are recorded.
Scope and Terminology Guardrails
Several terms must remain separate for the service model to stay understandable.
Self-Service Protection
Self-service protection means an authorized user can request or configure protection for an eligible workload without waiting for an infrastructure administrator to perform every UI action.
It does not automatically mean the user can:
create provider-level site relationships
modify shared recovery infrastructure
consume unlimited target capacity
change organization-wide mappings
run an unapproved production failover
declare an enterprise disaster
Disaster Recovery
Disaster recovery restores an application after a site, region, infrastructure, or workload-level disruption. It normally assumes that the replicated workload is operationally trustworthy.
Cyber Recovery
Cyber recovery determines whether a recovery point is clean before returning it to production. It introduces isolated recovery environments, malware analysis, identity separation, controlled connectivity, and clean-point validation.
Tenant-aware replication is not a replacement for cyber recovery.
A workload can be replicated successfully and still carry corrupted data, malicious persistence, compromised credentials, or application-level damage into the recovery region.
Recovery Point Objective
RPO defines the acceptable potential data-loss window. In VCF Automation protection workflows, users consume approved replication classes rather than inventing an arbitrary replication policy for every VM.
Recovery Time Objective
RTO is the target time for restoring the business service.
Replication does not establish the RTO by itself. Application dependencies, boot order, network readiness, DNS, identity, database recovery, external integrations, validation, and business approval all contribute to the actual recovery time.
Recovery Capacity
Recovery capacity includes more than datastore space for replicas.
It includes:
compute needed to power on recovered workloads
memory reservations
storage performance
network throughput
IP address availability
load-balancing capacity
security enforcement
test recovery capacity
platform overhead
operational headroom
Design Assumptions
This operating model assumes:
VMware Cloud Foundation 9.1 is deployed across multiple regions managed through VCF Automation.
Protection and Recovery appliances are deployed and paired between the participating sites.
Required Layer 3 connectivity exists between the protection and recovery components.
A Supervisor is deployed where VM Service VM protection is required.
Namespace relationships and recovery network mappings are configured before organization users consume the service.
The recovery region is shared but still enforces organization and network isolation.
Application teams retain responsibility for application dependency documentation and functional validation.
The article covers disaster recovery service design, not ransomware clean-room design.
Product behavior and known issues are validated against the current 9.1 release notes before production deployment.
Research and product validation are current as of August 2, 2026.
The Provider and Consumer Responsibility Model
VCF Automation introduces a layered administration model. The most useful design assigns each layer only the decisions it can safely own.
RolePrimary responsibilitiesDecisions that should remain restrictedProvider administratorDeploys and operates the protection infrastructure, establishes site connectivity, creates regions, assigns organization capacity, exposes replication classes, and maintains provider-wide controlsTenant application priority, business validation, and unilateral application failover decisionsOrganization administratorPairs eligible namespaces, assigns organization users, selects available policies, maintains application ownership, and coordinates organization-level recovery requirementsProvider infrastructure, cross-organization mappings, and recovery-region capacity policyProject administratorManages protection within an approved project or namespace boundary and helps maintain workload metadataChanges affecting other projects, organizations, or provider mappingsOrganization userCreates protected VMs or configures replication for eligible existing VMs using approved service choicesSite pairing, unrestricted capacity changes, shared network configuration, and unapproved production failoverApplication ownerDefines dependencies, startup order, validation steps, business priority, and acceptable data lossProvider capacity allocation and recovery platform administrationIncident commander or continuity authorityAuthorizes emergency production recovery based on business impact and incident scopeRoutine protection configurationSecurity incident authorityDetermines whether disaster recovery is appropriate or whether cyber-recovery procedures are requiredNormal platform service administration
This separation prevents the common mistake of reducing the entire service to two roles: administrator and user.
The organization administrator is an important middle layer. Provider administrators should not need to understand every application dependency, but ordinary organization users should not control the organization’s recovery topology.
Protection Should Be Offered as a Platform Service
A platform service is more than a UI action.
It is a defined product with eligibility rules, service objectives, ownership, capacity, support expectations, lifecycle controls, and cost.
A self-service DR offering should contain at least the following fields:
Service fieldPurposeService nameGives users a recognizable recovery productEligible workload typesDefines traditional VM and VM Service VM support boundariesReplication classControls the RPO choices exposed to the organizationTarget recovery regionIdentifies the approved destinationCapacity classDefines reserved, pooled, or best-effort recovery resourcesNetwork mapping profileMaps production, test, and recovery connectivityRecovery-plan requirementDetermines whether protection can exist without an approved planTest frequencyEstablishes recurring validationFailover authorityIdentifies who can approve production recoveryCost centerConnects consumption to financial accountabilityService ownerIdentifies the accountable business or application ownerExpiration or review datePrevents permanent orphaned protectionSupport modelDefines response and escalation expectations
A user should not be asked to understand the underlying appliance topology each time protection is requested. The platform team should translate that complexity into a small number of service classes.
RPO and RTO Service Tiers
Broadcom’s VCF Automation documentation uses replication classes to control the frequency available to users. Its example Gold class replicates every five minutes. Enhanced vSphere Replication can support RPOs as low as one minute in appropriately licensed and designed environments.
That does not mean every organization should receive the lowest available RPO.
Lower RPOs increase replication activity, network demand, storage writes, monitoring volume, and operational expectations. A service tier should therefore connect the replication class to the complete recovery commitment.
The following catalog is illustrative and is not a set of VMware defaults.
Service tierExample RPOTarget RTORecovery capacityTestingTypical useCritical5 minutes60 minutesPre-reservedQuarterlyRevenue, customer-facing, or regulated servicesImportant30 minutes4 hoursPooled with committed priorityTwice yearlyMajor internal platforms and business systemsStandard4 hours24 hoursBest effort after higher tiersAnnuallyNoncritical internal workloadsProtection onlyDefined by approved classNo application RTOReplica capacity onlyReplication validationWorkloads not yet accepted into an orchestrated recovery service
The final row is intentionally uncomfortable.
Many environments have replicated VMs that do not have a tested application recovery plan. Calling those workloads “DR protected” creates false confidence. A more honest catalog labels them as data replicated or protection only until the application has a validated recovery process.
RPO and RTO Must Be Sold Together
A five-minute replica does not create a one-hour application recovery.
An application may require:
directory services
DNS updates
database recovery
certificate services
message queues
API dependencies
firewall changes
external SaaS connectivity
load-balancer configuration
application-owner testing
The service tier should state both the data objective and the service restoration objective. It should also record which dependencies are included in the commitment.
Recovery-Site Quotas and Reservations
VCF Automation region quotas provide a useful organizational boundary for compute and storage consumption. However, normal cloud capacity and disaster-recovery capacity answer different questions.
A production quota answers:
How much infrastructure can this organization deploy?
A recovery reservation answers:
How much infrastructure will be available when the source environment is unavailable?
The second question is harder because the organization may need capacity precisely when many other tenants also need it.
Choose an Explicit Recovery Capacity Model
A shared recovery region normally uses one of three models.
Capacity modelDescriptionMain tradeoffFully reservedCapacity exists for all protected workloads to run simultaneouslyStrongest recovery confidence, highest costPriority reservedCapacity is guaranteed for selected services, with the remainder pooledBalances cost and recovery priorityOversubscribedReplica storage is committed, but recovery compute is allocated during an eventLowest cost, highest contention risk
Oversubscription is not automatically wrong.
It becomes dangerous when the organization sells a guaranteed RTO while operating a best-effort capacity model. The service description must match the actual reservation posture.
Include Test Capacity
Recovery testing consumes real infrastructure.
A platform that reserves enough compute for an emergency failover but no capacity for regular testing will gradually become untested. Include a test-concurrency allowance in the capacity model.
A practical reservation calculation includes:
committed production failover capacity
concurrent recovery-test capacity
Protection and Recovery platform overhead
network and security service capacity
operational safety margin
expected growth before the next capacity review
Protect the Recovery Region from Noisy Tenants
Quotas should control more than the number of protected VMs.
Consider limits for:
protected vCPU and memory
replica storage
daily changed-block volume
concurrent initial synchronizations
concurrent test recoveries
concurrent reprotect operations
recovery-plan execution
retained test environments
recovery network and IP consumption
This turns the recovery region into a governed shared platform rather than a datastore where every organization sends replicas.
Network and IP Mapping Are Part of the Service
Replication can complete successfully while recovery still fails because the network was never designed.
VCF Protection and Recovery includes workflows for namespace pairing, network mappings, test network mappings, and IP customization. Those capabilities need a provider-defined model.
Production Recovery Networks
For each organization, define:
source network
recovery network
routing behavior
firewall policy
gateway ownership
IP preservation or reassignment
DNS update process
load-balancer behavior
external connectivity
return-path routing
Do not make network mapping a free-form choice for every user. Publish approved mapping profiles and allow users to select only the profiles assigned to their organization.
Test Recovery Networks
A test recovery should not accidentally connect a duplicate application to the production network.
Test networks should be:
isolated from production
isolated between tenants where required
able to provide controlled supporting services
observable by the platform team
cleaned up after testing
protected from uncontrolled outbound communication
The application team should know whether the test environment uses simulated dependencies, test copies, or controlled access to production-adjacent services.
IP Address Strategy
There are three common approaches:
preserve the production IP and move the network identity
assign a recovery-specific IP
use an abstraction such as DNS, load balancing, or application routing
The correct approach depends on distance, routing architecture, NSX design, application behavior, and external dependencies. It should be decided during onboarding, not during the outage.
Recovery Plans Need Named Owners
A recovery plan is both an orchestration artifact and an operational contract.
The platform team may create the execution framework, but it cannot independently determine whether an application is healthy. The application team understands the business service, but it may not understand infrastructure sequencing or shared recovery constraints.
Ownership should therefore be split.
Recovery-plan concernAccountable ownerProtection infrastructureProvider or recovery platform ownerVM membershipApplication and project ownerStartup and shutdown orderApplication ownerNetwork mappingsNetwork and recovery platform ownersInfrastructure dependenciesPlatform ownerApplication dependenciesApplication ownerTest executionJoint platform and application ownershipFunctional validationApplication ownerEmergency failover authorizationIncident or continuity authorityCyber incident decisionSecurity incident authorityReprotect and failbackJoint platform, application, and change ownership
No recovery plan should enter production without:
a business owner
a technical owner
a recovery tier
dependency documentation
network mappings
an approval path
validation criteria
a test schedule
a failback procedure
Failover Approval Is a Separate Control Plane
VCF Automation provides approval policies for deployment and day-two requests. That makes it a useful governance layer, but architects should not assume that every Protection and Recovery action automatically enters the same approval path.
Validate the exact behavior in the deployed VCF 9.1 build.
When a sensitive recovery action is not natively covered by the required approval policy, place it behind an orchestrated workflow, IT service-management process, or restricted recovery role.
A practical authorization model looks like this:
ActionRecommended authorityRequest protectionAuthorized organization or project userChange replication classOrganization administrator, within entitlementPair namespacesOrganization administratorModify provider mappingsProvider administratorRun isolated recovery testApplication owner and delegated recovery operatorRun planned migrationChange authority, application owner, and recovery operatorRun emergency disaster failoverIncident commander or continuity authorityInitiate cyber-recovery processSecurity incident authorityReprotect workloadRecovery operator with application confirmationFail back to productionChange authority, application owner, and recovery operator
Use a Two-Key Model for Production Recovery
For critical workloads, separate:
the authority to approve recovery
the technical permission to execute recovery
The incident commander should not need broad administrative credentials. The recovery administrator should not be able to declare a business disaster independently.
The two-key model reduces accidental failovers, malicious misuse, and confusion during high-pressure incidents.
Tenant Isolation Must Survive Recovery
A shared recovery site does not remove tenant boundaries.
The recovery design must preserve isolation across several layers.
Identity Isolation
Use organization and project roles that align to actual support responsibilities. Avoid shared recovery administrator credentials across unrelated application teams.
Emergency access should be controlled, logged, time-limited where possible, and reviewed after use.
Network Isolation
Each organization’s recovery and test networks should remain separate unless an approved shared service requires connectivity.
Shared DNS, identity, monitoring, or security services should be exposed through controlled paths rather than broad network adjacency.
Resource Isolation
A tenant should not be able to exhaust recovery compute, storage, replication bandwidth, test capacity, or IP space needed by another tenant.
Quotas and concurrency limits should enforce this boundary.
Operational Isolation
Users should see only their authorized workloads, mappings, plans, reports, and recovery operations.
A multi-tenant platform can share infrastructure without sharing operational visibility.
Failure-Domain Isolation
Do not place all tenants behind one unexamined dependency.
Shared recovery services such as DNS, identity, routing, load balancing, and automation appliances need their own resilience and recovery design. Otherwise, the shared recovery region becomes dependent on a small set of unprotected control-plane services.
Cost Allocation and Showback
Self-service without cost visibility encourages overconsumption.
VCF Automation and VCF Operations provide organization and project cost visibility, pricing mechanisms, chargeback capabilities, and showback dashboards. The DR service should use those capabilities to make recovery consumption visible.
Charge for the Service Actually Consumed
A useful DR cost model includes:
protected storage capacity
replica storage capacity
replication change rate
network transfer
reserved recovery compute
shared platform overhead
test recovery runtime
premium operational support
security or compliance requirements
retention and reporting requirements
The showback record should identify:
organization
project or namespace
application
business owner
cost center
protection tier
protected capacity
reserved failover capacity
test consumption
current recovery status
Separate Replica Cost from Recovery Commitment
Two applications with the same storage footprint may have very different recovery costs.
One may use pooled capacity and a 24-hour RTO. Another may require dedicated compute, a five-minute RPO, quarterly testing, 24-hour operator coverage, and a one-hour RTO.
Charging only by protected terabyte hides the cost of the operational commitment.
Use Showback Before Chargeback
Many enterprises should begin with showback.
Show teams what their protection consumes, identify stale and duplicated protection, and validate the cost model before turning the numbers into formal chargeback. The objective is accountable consumption, not creating arguments over an immature pricing model.
Audit Evidence and Recovery Testing
A disaster recovery service is credible only when it can produce evidence.
VCF Protection and Recovery supports recovery-plan testing and recovery-plan history reporting. VCF Automation and the wider VCF operations layer also provide audit and operational records.
The platform team should assemble those records into a standard evidence package.
Minimum Evidence Package
For every protected business service, retain:
original protection request
workload owner and approver
selected replication class
recovery target
namespace pairing
network and IP mappings
capacity assignment
recovery-plan version
test execution history
recovery-plan history report
application validation result
failed steps and exceptions
remediation owner
next test date
last entitlement review
last cost review
Test the Business Service, Not Just the VM
A powered-on VM is not proof of application recovery.
A test should validate:
operating-system startup
database consistency
service dependencies
authentication
DNS and routing
firewall policy
application transactions
monitoring
backup or protection after recovery
user acceptance criteria
The application owner should sign off on the result. Infrastructure teams should not certify application functionality on the owner’s behalf.
Vary the Test Scenario
Do not repeat the easiest recovery test every quarter.
Rotate scenarios such as:
single-VM failure
complete application recovery
namespace recovery
source-cluster loss
site loss
dependency unavailable
constrained recovery capacity
failed network mapping
application startup failure
reprotect and failback
The purpose of testing is not to create a green dashboard. It is to discover which assumptions are wrong before an incident.
Preventing Uncontrolled Recovery Sprawl
Recovery sprawl appears when protection is easy to create but difficult to review or remove.
Typical symptoms include:
replicas for retired VMs
protection without an owner
critical tiers assigned to noncritical workloads
recovery plans that have never been tested
orphaned network mappings
stale IP customization rules
reservations that exceed realistic demand
duplicate protection services
workloads with no failback plan
unresolved RPO violations
organization users who retain access after changing roles
The service needs a lifecycle, not just a create action.
Require Protection Metadata
Do not allow long-lived protection without:
owner
application identifier
business criticality
cost center
service tier
recovery-plan reference
test frequency
review date
retirement trigger
Add Expiration and Renewal
Protection should have a review date.
Renewal can be automatic for critical approved services, but it should still verify ownership, cost, application status, test results, and tier suitability.
Temporary environments should use explicit expiration dates.
Reconcile Protection Against Inventory
Regularly compare:
active VMs
protected VMs
replicas
recovery-plan membership
application inventory
organization membership
cost-center status
The reconciliation process should identify both unprotected critical workloads and protected workloads that no longer need the service.
A Phased Implementation Path
A successful rollout should begin with service design, not with granting users access.
Define the Service
Document:
supported workload types
service tiers
replication classes
RTO commitments
capacity models
network profiles
approval requirements
testing expectations
cost model
support responsibilities
retirement rules
Do not expose a generic “enable replication” action before these decisions are complete.
Build the Provider Foundation
The provider team should:
deploy and validate Protection and Recovery components
establish site connectivity
configure recovery infrastructure
define regions and quotas
create replication classes
confirm organization and project roles
define namespace-pairing standards
build recovery and test networks
establish observability
test provider-level failure scenarios
Pilot with Two Different Tenants
Choose tenants with different recovery requirements.
For example:
one critical production application
one lower-priority internal application
This tests whether the catalog can express meaningful differences rather than treating every workload as the same service.
Validate the Complete Lifecycle
The pilot should include:
protection request
initial synchronization
RPO monitoring
isolated test
application validation
production-style recovery exercise
reprotect
failback
service renewal
service removal
A pilot that ends after successful replication has not tested the operating model.
Scale Through Entitlements
After the pilot, publish approved service tiers to additional organizations.
Use organization assignments, quotas, roles, and policy controls rather than recreating the service manually for every team.
Add Cost and Compliance Reporting
Introduce showback, recurring evidence packages, exception reporting, and capacity forecasting after the technical workflow is stable.
These functions should become normal platform operations, not annual audit projects.
Risks, Caveats, and Operational Gotchas
Foundational Does Not Mean Complete
VCF 9.1 introduces foundational multi-tenant disaster recovery for Supervisor VM Service VMs. Treat that wording seriously.
Confirm workload, storage, networking, application-consistency, and orchestration requirements before assuming that every modern application pattern has the same protection behavior as a traditional VM.
The Self-Service Workflow Is Not a Retention Strategy
The VCF Automation replication workflow documentation states that only one replica copy is retained at the secondary site for the described workflow.
Organizations requiring deep recovery-point history, long-term retention, or ransomware clean-point selection need additional protection design. Do not treat a current replica as a substitute for backup or cyber recovery.
Reprotect Preserves the Replication Class
The documented reprotect workflow retains the replication class used by the recovered VM.
If the application needs a different service tier after recovery, plan the policy transition rather than assuming it can be changed during reprotect.
Application Consistency Remains an Application Concern
VM replication does not automatically guarantee transactional consistency across a distributed application.
Database-native protection, quiescing, application agents, coordinated shutdown, or application-level replication may still be required.
Shared Infrastructure Creates Shared Failure Modes
A shared recovery region concentrates:
capacity risk
network dependencies
administrative access
appliance dependencies
operational workload during an incident
Design the recovery platform itself as a critical service.
Concurrent Recovery Operations Need Testing
Large numbers of tenants, namespaces, replications, tests, and reprotect actions create concurrency that a small pilot will not reveal.
Review current release notes, establish operational concurrency limits, and test the expected recovery scale before committing to tenant RTOs.
Removal Is a Controlled Operation
Decommissioning a service requires more than deleting a catalog entitlement.
Remove or reconcile:
replication
replicas
recovery-plan membership
mappings
reservations
test resources
cost records
user entitlements
application inventory records
Platform lifecycle operations can fail or leave orphaned objects when dependencies remain. Build deprotection into the service workflow.
Decision Checklist
Before enabling self-service DR for an organization, confirm:
DecisionRequired answerWho owns the application?Named business and technical ownersWhat protection tier applies?Approved RPO, RTO, test frequency, and capacity classIs the workload eligible?Supported VM type, storage, site, and namespaceWhere does it recover?Named region, cluster, datastore, and network profileIs capacity committed?Reservation or documented oversubscription policyAre dependencies mapped?Infrastructure and application dependencies documentedIs recovery authorized separately?Named test, planned migration, disaster, and cyber authoritiesIs the recovery plan tested?Current evidence and application-owner sign-offIs cost visible?Organization, project, application, and cost-center mappingIs there an expiration or review date?Renewal and retirement workflow definedIs failback documented?Reprotect, validation, cutback, and cleanup steps definedAre current release limitations accepted?Product and concurrency caveats reviewed
Conclusion
Self-service disaster recovery can remove a major infrastructure bottleneck, but only when protection is delivered as a governed platform service.
VCF Protection and Recovery 9.1 and VCF Automation provide the technical foundation for organization-aware replication, namespace pairing, recovery workflows, replication classes, shared recovery infrastructure, and foundational protection for VM Service VMs. Those capabilities allow platform teams to move routine protection closer to the application teams that understand the workloads.
The platform team should still retain control over the boundaries that affect everyone: site architecture, capacity, provider mappings, service entitlements, network profiles, security controls, and operational concurrency. Application teams should own dependency information and functional validation. Incident and continuity authorities should control the decision to run a production failover.
The most important separation is between requesting protection and authorizing recovery.
When that separation is combined with RPO and RTO tiers, capacity reservations, tenant isolation, network mapping, showback, audit evidence, regular testing, and lifecycle controls, self-service becomes a scalable recovery operating model.
Without those controls, it becomes a faster way to create recovery sprawl.
This mental model also provides the operating-model bridge to two related design questions: how VCF Protection and Recovery capabilities fit together as a platform, and how a shared recovery site should be sized for multiple clusters, storage platforms, and tenants.
External References
Broadcom TechDocs: Using Protection and Recovery with VCF AutomationCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/multi-tenant-disaster-recovery-for-vcf-automation.html
Broadcom TechDocs: Prerequisites for Protection and Recovery in VCF AutomationCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/protection-and-recovery-installation/deploy-and-configure-multi-tenant-protection-and-recovery/prerequisites.html
Broadcom TechDocs: Software Components for Protection and Recovery for VCF AutomationCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/protection-and-recovery-installation/deploy-and-configure-multi-tenant-protection-and-recovery/protection-and-recovery-for-vcf-automation-main-components.html
Broadcom TechDocs: Configure Replication for Existing VMsCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/multi-tenant-disaster-recovery-for-vcf-automation/configure-vm-replication.html
Broadcom TechDocs: Reprotect a VM After RecoveryCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/multi-tenant-disaster-recovery-for-vcf-automation/reprotect-a-vm.html
Broadcom TechDocs: Protection and Recovery 9.1 Release NotesCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/protection-and-recovery/9-1/release-notes/protection-and-recovery-91-release-notes.html
Broadcom TechDocs: Region Quota of a VCF Automation OrganizationCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/provider-management/managing-organizations/region-quota-of-an-organization.html
Broadcom TechDocs: Configure Approval Policies in VCF AutomationCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/organization-management/creating-policies-for-all-apps-orgs/vcfa-approval-policies-all-apps.html
Broadcom TechDocs: Chargeback and Billing with VCF AutomationCanonical URL: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/design/design-library/vcf-automation-deployment-models-9-x/chargeback-and-billing.html
VMware Cloud Foundation Blog: Continuous Compliance, Integrated Cyber Recovery and Enhanced Platform Security for VCF 9.1Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/05/continuous-compliance-integrated-cyber-recovery-and-enhanced-platform-security-for-vcf-9-1/
VMware Cloud Foundation Blog: Optimize, Modernize and Protect Your Private Cloud Storage with vSAN in VCF 9.1Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/05/announcing_vsan_in_vcf_9-1/
VMware Cloud Foundation Blog: Mastering Infrastructure Policies in VMware Cloud Foundation Automation 9.1Canonical URL: https://blogs.vmware.com/cloud-foundation/2026/05/28/vcf-automation-infrastructure-policies/
VMware Cloud Foundation as a Vertical City: A Practical Mental Model for Private Cloud Architecture
TL;DR VMware Cloud Foundation is easier to understand when it is viewed as a vertically integrated city rather than a collection of…
The post Self-Service Disaster Recovery with VCF Automation: Multi-Tenant Protection Without Losing Governance appeared first on Digital Thought Disruption.