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 Domain | What It Governs |
|---|---|
| Identity | Who can sign in, assume roles, deploy, approve, operate, or break glass |
| Resource hierarchy | How subscriptions, accounts, projects, folders, workload domains, and tenants are organized |
| Policy | What is allowed, denied, audited, remediated, or excepted |
| Observability | What telemetry is collected, retained, correlated, and acted on |
| Networking | How zones, routing, inspection, segmentation, and egress are controlled |
| Automation | How resources are provisioned, changed, validated, and rolled back |
| Lifecycle | How platforms, services, certificates, passwords, upgrades, and dependencies are maintained |
| Evidence | How 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 Need | Azure Example | AWS Example | Google Cloud Example | VCF Example |
|---|---|---|---|---|
| Platform hierarchy | Management groups, subscriptions, resource groups | Organizations, OUs, accounts | Organization, folders, projects | Fleet, VCF instances, workload domains |
| Identity assignment | Entra ID, Azure RBAC | IAM, IAM Identity Center | Cloud IAM, federation | VCF identity, vCenter, NSX roles |
| Policy enforcement | Azure Policy, initiatives | SCPs, RCPs, Control Tower controls | Organization Policy constraints | VCF Operations, NSX, automation guardrails |
| Observability | Azure Monitor, Log Analytics | CloudWatch, CloudTrail | Cloud Monitoring, Cloud Logging | VCF Operations, NSX logs |
| Automation | ARM, Bicep, Terraform, Azure DevOps, GitHub Actions | CloudFormation, Terraform, CDK, Systems Manager | Terraform, Cloud Build | VCF Automation, PowerCLI, APIs |
| Network control | VNets, NSGs, Azure Firewall, Virtual WAN | VPCs, security groups, NACLs, Transit Gateway, Cloud WAN | VPCs, firewall rules, NCC | NSX 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:
| Platform | Native Translation |
|---|---|
| Azure | Azure Policy initiative for public IPs, NSG exposure, firewall routing, private endpoint patterns |
| AWS | Control Tower control, SCP or RCP where appropriate, security group review, public subnet detection |
| Google Cloud | Organization Policy constraint, VPC firewall review, project-level exception workflow |
| VCF | NSX 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 Type | Governance Concern |
|---|---|
| Human administrator | Role scope, privileged access, MFA, session logging, approval flow |
| Platform operator | Separation of duties across networking, compute, security, and automation |
| Deployment identity | Pipeline permissions, credential storage, workload federation, rollback rights |
| Workload identity | Service-to-service access, secretless authentication, rotation, ownership |
| Break-glass identity | Emergency access path, monitoring, after-action review |
| Third-party operator | Time-bound access, contract scope, evidence, revocation |
| Automation identity | API 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 Field | Why It Matters |
|---|---|
| Control ID | Gives the policy a stable reference across tools |
| Risk domain | Connects the control to security, compliance, cost, or operations |
| Owner | Identifies who can approve changes or exceptions |
| Scope | Defines platforms, environments, and workload types |
| Default action | Avoids ambiguity between deny, audit, warn, and remediate |
| Required metadata | Makes compliance and reporting possible |
| Enforcement mappings | Shows how each platform implements the intent |
| Evidence mappings | Shows where proof comes from |
| Exception model | Defines 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 Field | Purpose |
|---|---|
| application_id | Connects resources, logs, traces, cost, and ownership |
| environment | Separates production, non-production, sandbox, and regulated workloads |
| data_classification | Supports security, retention, and data-use controls |
| business_owner | Identifies business accountability |
| technical_owner | Identifies operational support ownership |
| platform | Identifies Azure, AWS, Google Cloud, VCF, SaaS, or edge |
| control_id | Connects findings back to governance controls |
| exception_id | Shows whether a deviation is approved, expired, or unknown |
| deployment_source | Identifies 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 Zone | Typical Native Implementations |
|---|---|
| Internet edge | WAF, firewall, load balancer, ingress gateway, edge service |
| Private application zone | VNet, VPC, project, workload domain, NSX segment |
| Shared services zone | DNS, identity, logging, patching, secrets, automation brokers |
| Regulated zone | Restricted subscriptions, accounts, projects, workload domains, segments |
| Management plane zone | Admin access, platform APIs, SDDC management, privileged operations |
| Data services zone | Databases, storage, analytics, backup, replication |
| Egress control zone | NAT, 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 Area | VCF Consideration |
|---|---|
| Identity | Role mapping across VCF, vCenter, NSX, automation, and operations tooling |
| Lifecycle | Fleet-level planning, upgrades, certificates, passwords, and component health |
| Networking | NSX segmentation, edge design, routing, firewalling, and management access |
| Observability | VCF Operations evidence, alerts, capacity, compliance, and drift |
| Automation | VCF Automation catalog rules, approvals, policy, and ownership |
| Exceptions | Workload-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 groups
https://learn.microsoft.com/en-us/azure/governance/management-groups/overview - Microsoft Learn: Azure Policy overview
https://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 policies
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html - AWS Documentation: Resource control policies
https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html - AWS Documentation: AWS Control Tower controls
https://docs.aws.amazon.com/controltower/latest/controlreference/controls.html - Google Cloud Documentation: Resource hierarchy
https://docs.cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy - Google Cloud Documentation: Organization Policy overview
https://docs.cloud.google.com/organization-policy/overview - Broadcom TechDocs: VMware Cloud Foundation 9.1 documentation
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1.html - Broadcom TechDocs: VCF Operations Fleet Management
https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/fleet-management.html - Broadcom TechDocs: vDefend Distributed Firewall
https://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/
A virtual machine file lock issue rarely shows up at a convenient time. It usually appears when a VM refuses to power...