TL;DR
Multicloud is no longer just a workload placement problem.
The harder problem is control-plane sprawl.
Azure, AWS, Google Cloud, and VMware Cloud Foundation each bring their own identity model, policy engine, hierarchy, observability stack, network control plane, automation surface, and operational lifecycle. Those native control planes are useful. They become dangerous when each platform team turns them into an independent governance model.
The answer is not to flatten every platform into one generic cloud console. The better pattern is to build a shared enterprise governance spine that defines intent, ownership, metadata, evidence, and exceptions, then lets each platform enforce that intent using native controls.
This article focuses on the multicloud control-plane architecture. The next article in the series focuses on AI agents, tool access, agent identity, and observability across the same platforms.
Why Workload Placement Is No Longer the Hard Part
For years, multicloud conversations started with a familiar question:
Where should the workload run?
That question still matters. Some workloads belong in Azure because of Microsoft integration, identity, data services, or regional design. Some belong in AWS because of service depth, account patterns, or existing engineering investment. Some belong in Google Cloud because of data, analytics, AI, or Kubernetes-driven patterns. Some belong on VCF because the enterprise still needs private cloud control, locality, licensing alignment, operational continuity, or application dependency support.
But workload placement is no longer the whole architecture problem.
The larger problem is this:
Who controls the workload after it lands?
That question cuts across identity, policy, logging, networking, automation, backup, tagging, lifecycle, vulnerability management, approvals, exceptions, and evidence.
A workload might run in AWS but authenticate through Microsoft Entra ID. It might send telemetry to a central SIEM. It might use Terraform from a shared platform engineering pipeline. It might call a private API hosted on VCF. It might consume data from Google Cloud. It might be monitored by multiple operational teams.
That is not just multicloud.
That is multi-control-plane.
What Counts as a Control Plane?
In this context, a control plane is any system that defines, enforces, observes, or automates platform behavior.
That includes obvious control planes such as cloud consoles, APIs, and policy engines. It also includes less obvious ones such as CI/CD platforms, identity providers, observability systems, network controllers, service catalogs, configuration databases, ITSM workflows, and exception registers.
A practical control-plane inventory should include at least these domains:
Control DomainWhat It GovernsIdentityWho can sign in, assume roles, deploy, approve, operate, or break glassResource hierarchyHow subscriptions, accounts, projects, folders, workload domains, and tenants are organizedPolicyWhat is allowed, denied, audited, remediated, or exceptedObservabilityWhat telemetry is collected, retained, correlated, and acted onNetworkingHow zones, routing, inspection, segmentation, and egress are controlledAutomationHow resources are provisioned, changed, validated, and rolled backLifecycleHow platforms, services, certificates, passwords, upgrades, and dependencies are maintainedEvidenceHow teams prove compliance, drift status, exceptions, and remediation progress
The mistake is assuming these domains naturally line up across platforms.
They do not.
Control-Plane Sprawl at a Glance
The diagram below shows the architectural tension. Each platform has a native control plane, but the enterprise still needs a common governance spine above them. The spine defines intent. The native platforms enforce that intent in their own ways. Evidence flows back up.
The important detail is the direction of authority.
The enterprise governance spine should define the control objective. Azure, AWS, Google Cloud, and VCF should implement that objective using native controls. Evidence should flow back into a shared review model.
Without that pattern, each platform team eventually builds its own interpretation of governance.
Native Constructs Are Not Equivalent
A common architecture mistake is treating platform constructs as if they are interchangeable.
They are not.
Azure management groups are not the same thing as AWS organizational units. AWS service control policies are not the same thing as Azure Policy. Google Cloud folders are not the same thing as VCF workload domains. NSX distributed firewall policy is not the same enforcement point as an Azure NSG, AWS security group, or Google Cloud VPC firewall rule.
The constructs may solve similar problems, but they do not behave the same way operationally.
Governance NeedAzure ExampleAWS ExampleGoogle Cloud ExampleVCF ExamplePlatform hierarchyManagement groups, subscriptions, resource groupsOrganizations, OUs, accountsOrganization, folders, projectsFleet, VCF instances, workload domainsIdentity assignmentEntra ID, Azure RBACIAM, IAM Identity CenterCloud IAM, federationVCF identity, vCenter, NSX rolesPolicy enforcementAzure Policy, initiativesSCPs, RCPs, Control Tower controlsOrganization Policy constraintsVCF Operations, NSX, automation guardrailsObservabilityAzure Monitor, Log AnalyticsCloudWatch, CloudTrailCloud Monitoring, Cloud LoggingVCF Operations, NSX logsAutomationARM, Bicep, Terraform, Azure DevOps, GitHub ActionsCloudFormation, Terraform, CDK, Systems ManagerTerraform, Cloud BuildVCF Automation, PowerCLI, APIsNetwork controlVNets, NSGs, Azure Firewall, Virtual WANVPCs, security groups, NACLs, Transit Gateway, Cloud WANVPCs, firewall rules, NCCNSX segments, DFW, edge services
The goal is not to hide these differences.
The goal is to stop those differences from becoming governance fragmentation.
The Governance Spine Pattern
A governance spine is not another tool.
It is an operating model that defines common intent before implementation.
The spine should answer a small set of hard questions:
What is the control objective?
Who owns the control?
Which workloads and environments does it apply to?
What is the default decision: allow, deny, audit, or remediate?
What metadata is required?
What evidence proves the control is working?
What exception process exists?
How long can an exception live?
Which platform team owns native translation?
This prevents each platform team from reinventing policy language.
For example, the enterprise control might say:
Production workloads cannot expose direct public inbound access unless the endpoint is an approved ingress, edge, or brokered access pattern with a documented exception.
That one sentence can map to multiple native controls:
PlatformNative TranslationAzureAzure Policy initiative for public IPs, NSG exposure, firewall routing, private endpoint patternsAWSControl Tower control, SCP or RCP where appropriate, security group review, public subnet detectionGoogle CloudOrganization Policy constraint, VPC firewall review, project-level exception workflowVCFNSX distributed firewall policy, edge placement review, VCF Automation catalog constraint
The control stays consistent. The enforcement stays native.
That is the balance.
Identity Fragmentation Is Usually the First Warning Sign
Most multicloud governance problems show up first in identity.
At the beginning, the model looks simple. Centralize workforce authentication. Use SSO. Federate users into each cloud. Map groups to platform roles.
That is necessary, but it is not enough.
Enterprise identity governance has to cover more than sign-in:
Identity TypeGovernance ConcernHuman administratorRole scope, privileged access, MFA, session logging, approval flowPlatform operatorSeparation of duties across networking, compute, security, and automationDeployment identityPipeline permissions, credential storage, workload federation, rollback rightsWorkload identityService-to-service access, secretless authentication, rotation, ownershipBreak-glass identityEmergency access path, monitoring, after-action reviewThird-party operatorTime-bound access, contract scope, evidence, revocationAutomation identityAPI access, change authority, logging, rate limits
The naming will differ across platforms. The intent should not.
A “network security operator” should have a recognizable enterprise meaning even if the actual permissions are Azure RBAC assignments, AWS IAM permission sets, Google Cloud IAM roles, or NSX roles.
If every cloud team defines its own administrator model without a shared role taxonomy, entitlement review becomes a spreadsheet exercise. That does not scale.
Policy Needs an Intent Layer
Native policy engines are powerful, but they are platform-specific.
Azure Policy, AWS SCPs and RCPs, Google Organization Policy, NSX rules, VCF Automation constraints, and CI/CD checks all enforce controls differently. Trying to make them identical is usually wasted effort.
Instead, define policy as intent first.
A useful policy intent record should include:
Policy FieldWhy It MattersControl IDGives the policy a stable reference across toolsRisk domainConnects the control to security, compliance, cost, or operationsOwnerIdentifies who can approve changes or exceptionsScopeDefines platforms, environments, and workload typesDefault actionAvoids ambiguity between deny, audit, warn, and remediateRequired metadataMakes compliance and reporting possibleEnforcement mappingsShows how each platform implements the intentEvidence mappingsShows where proof comes fromException modelDefines approval, expiration, and compensating controls
This turns policy from a pile of tool-specific rules into a governed control catalog.
Observability Is Not the Same as Telemetry Collection
Most enterprises already collect a lot of telemetry.
That does not mean they have observability.
In a multi-control-plane environment, observability has to support correlation. A production incident should not require four teams to manually compare four dashboards with four naming conventions and four resource-tagging models.
A minimum multicloud metadata standard should include:
Metadata FieldPurposeapplication_idConnects resources, logs, traces, cost, and ownershipenvironmentSeparates production, non-production, sandbox, and regulated workloadsdata_classificationSupports security, retention, and data-use controlsbusiness_ownerIdentifies business accountabilitytechnical_ownerIdentifies operational support ownershipplatformIdentifies Azure, AWS, Google Cloud, VCF, SaaS, or edgecontrol_idConnects findings back to governance controlsexception_idShows whether a deviation is approved, expired, or unknowndeployment_sourceIdentifies whether the resource came from approved automation
The dashboards can differ.
The evidence model should not.
Networking Governance Breaks When Every Platform Invents Its Own Zone Model
Networking is another place where multicloud control-plane fragmentation becomes expensive.
Azure, AWS, Google Cloud, and VCF each have strong network services. The problem is not capability. The problem is inconsistent intent.
One platform might define “shared services” as a hub VNet. Another might define it as a shared services account. Another might define it as a folder-level project model. VCF might define it through workload domains, NSX segments, edge clusters, and firewall policy.
Those models can all be valid. But the enterprise still needs shared network language.
A practical network zone model might look like this:
Enterprise ZoneTypical Native ImplementationsInternet edgeWAF, firewall, load balancer, ingress gateway, edge servicePrivate application zoneVNet, VPC, project, workload domain, NSX segmentShared services zoneDNS, identity, logging, patching, secrets, automation brokersRegulated zoneRestricted subscriptions, accounts, projects, workload domains, segmentsManagement plane zoneAdmin access, platform APIs, SDDC management, privileged operationsData services zoneDatabases, storage, analytics, backup, replicationEgress control zoneNAT, firewall, proxy, inspection, SaaS/API broker
The goal is not to make every network look the same.
The goal is to make every network decision traceable to the same intent.
Automation Is a Control Plane Too
Automation often gets treated as delivery plumbing.
That is a mistake.
Automation is one of the most powerful control planes in the environment because it creates, changes, deletes, remediates, and sometimes approves infrastructure.
A mature multicloud operating model should define:
which automation tools are approved
which platforms they can touch
which identities they run as
what approval flow is required
what metadata they must stamp
where logs and deployment records land
how rollback is handled
which exceptions allow manual change
how drift is detected after deployment
This matters because manual change is where governance often breaks.
The cloud policy might be correct. The network model might be clear. The tagging standard might be documented. But if a privileged operator can bypass the deployment path and create unmanaged resources, the control plane has a hole.
Approved automation should not just deploy infrastructure. It should preserve governance evidence.
VCF Must Be Treated as a First-Class Control Plane
VCF should not be treated as the place where older workloads live outside the modern governance model.
That split creates long-term operational debt.
VCF has its own management plane, lifecycle model, identity boundaries, certificate and password concerns, networking stack, automation layer, observability capabilities, and operational ownership model. If Azure, AWS, and Google Cloud are governed with modern platform rules while VCF is governed through tribal knowledge and ticket history, the enterprise has not solved multicloud governance. It has just hidden part of the problem.
A first-class VCF governance model should include:
Governance AreaVCF ConsiderationIdentityRole mapping across VCF, vCenter, NSX, automation, and operations toolingLifecycleFleet-level planning, upgrades, certificates, passwords, and component healthNetworkingNSX segmentation, edge design, routing, firewalling, and management accessObservabilityVCF Operations evidence, alerts, capacity, compliance, and driftAutomationVCF Automation catalog rules, approvals, policy, and ownershipExceptionsWorkload-domain-specific exceptions with expiration and evidence
The private cloud should answer to the same governance spine as the public cloud.
It does not need identical controls. It needs equivalent accountability.
A Practical Implementation Sequence
Do not try to solve multi-control-plane governance in one program.
Start with a sequence that produces usable evidence quickly.
Phase 1: Inventory the Current Control Planes
Document the control planes already in use across Azure, AWS, Google Cloud, and VCF.
Focus on identity, hierarchy, policy, observability, networking, automation, lifecycle, exceptions, and audit evidence.
The output should not be a tool list. It should show who owns each decision and where enforcement actually happens.
Phase 2: Define the Enterprise Metadata Standard
Agree on required metadata before expanding the control catalog.
At minimum, standardize application ID, environment, data classification, business owner, technical owner, platform, deployment source, control ID, and exception ID.
Without this layer, evidence correlation will stay manual.
Phase 3: Build a Small Control Catalog
Start with controls that matter and can be measured.
Good first controls include:
no unmanaged public inbound exposure
required ownership metadata
production changes must use approved automation
privileged access must be reviewed
regulated workloads must use approved locations and zones
logging must include application and environment context
exceptions must expire
Avoid launching with a 200-control spreadsheet that nobody can operate.
Phase 4: Map Each Control to Native Enforcement
For each control, define the native mapping in every platform.
Do not stop at enforcement. Include evidence, exception handling, remediation, and owner.
A control is not complete until the operating team can prove whether it is working.
Phase 5: Review Drift and Exceptions as an Operating Rhythm
Governance has to become observable.
Create regular review cycles for:
policy drift
missing metadata
unauthorized public exposure
privileged access changes
expired exceptions
unmanaged automation paths
VCF lifecycle and configuration drift
evidence gaps
The point is not more meetings. The point is to make control-plane drift visible before it becomes normal.
Conclusion
Multicloud governance is entering a new phase.
The next problem is not just deciding whether a workload belongs in Azure, AWS, Google Cloud, or VCF. The harder problem is deciding which control plane owns each decision and how that decision is enforced, observed, and reviewed across platforms.
A mature design does not pretend the platforms are the same. It defines a common governance spine and lets each platform enforce that intent in the way it was built to enforce it.
That is how you avoid governance fragmentation without fighting the native platform model.
The next article builds on this control-plane foundation and focuses on AI agents: identity, tool access, model boundaries, observability, human approval, and exception handling across Azure, AWS, Google Cloud, and VCF.
External References
Microsoft Learn: Azure management groupshttps://learn.microsoft.com/en-us/azure/governance/management-groups/overview
Microsoft Learn: Azure Policy overviewhttps://learn.microsoft.com/en-us/azure/governance/policy/overview
AWS Documentation: What is AWS Organizations?https://docs.aws.amazon.com/organizations/latest/userguide/orgs_introduction.html
AWS Documentation: Service control policieshttps://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
AWS Documentation: Resource control policieshttps://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html
AWS Documentation: AWS Control Tower controlshttps://docs.aws.amazon.com/controltower/latest/controlreference/controls.html
Google Cloud Documentation: Resource hierarchyhttps://docs.cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy
Google Cloud Documentation: Organization Policy overviewhttps://docs.cloud.google.com/organization-policy/overview
Broadcom TechDocs: VMware Cloud Foundation 9.1 documentationhttps://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1.html
Broadcom TechDocs: VCF Operations Fleet Managementhttps://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/fleet-management.html
Broadcom TechDocs: vDefend Distributed Firewallhttps://techdocs.broadcom.com/us/en/vmware-security-load-balancing/vdefend/vdefend-firewall/4-2/vdefend-distributed-firewall.html
OpenTelemetry Documentation: What is OpenTelemetry?https://opentelemetry.io/docs/what-is-opentelemetry/
Finding VM File Locks on ESXi: A Production-Safe Runbook Before You Kill Processes
A virtual machine file lock issue rarely shows up at a convenient time. It usually appears when a VM refuses to power…
The post Multi-Cloud Is Becoming Multi-Control-Plane: How to Avoid Governance Fragmentation Across Azure, AWS, Google Cloud, and VCF appeared first on Digital Thought Disruption.