Building a Portable Control Plane Across AWS, Azure, and GCP

A portable control plane isn’t about running the same VM image on three clouds — that’s the lie vendors have been selling since Java in the 90s. Docker promised it. Cloud vendors promise it now, usually right before they lock you into a proprietary service mesh or a database that only exists in us-east-1. Real portability means making the intent portable, not the infrastructure.

Let’s be real for a minute: Infrastructure is not portable. An AWS S3 bucket behaves fundamentally differently than an Azure Blob Storage container. Their consistency models differ. Their latency profiles differ. Even their error codes differ.

If you try to abstract all that away with a “lowest common denominator” script, you end up with the worst of all worlds: generic infrastructure that leverages the strengths of none.

But you can make the intent portable.

This isn’t about running the exact same VM image on three clouds. It’s about building a Unified Control Plane (UCP) where a developer’s request for a “High-Performance Database” is automatically translated into the best-fit service for whichever cloud they happen to be deploying to. That shift — from infrastructure portability to intent portability — is the same control plane shift reshaping every layer of modern infrastructure.

Here is how we stop chasing the “portability” ghost and start engineering actual platform resilience.

The “Polycloud” vs. Multi-Cloud Distinction

Most organizations I audit aren’t running multi-cloud; they are running “Polycloud.”

• Polycloud: You have an AWS team using CloudFormation and an Azure team using ARM templates. They don’t talk. Policy changes have to be manually replicated. This is OpEx suicide.
• True Multi-Cloud (via UCP): You have one API surface — a Unified Control Plane. Push a policy once, and it propagates to AWS, Azure, and GCP simultaneously. This is what vendors mean when they say “multi-cloud.” This is not what most organizations actually have.

To get to the latter, we have to stop treating Kubernetes as just a container orchestrator. We need to treat K8s as the Universal API for Infrastructure. This is the foundation of platform engineering architecture — one API surface, one policy layer, zero manual replication.

The Stack: Why We Need a “Control Loop”

I love Terraform. I’ve written thousands of lines of HCL. But Terraform is a CLI tool. It fires, it applies, and it exits. If someone logs into the Azure Portal three days later and opens port 22 to the world, Terraform won’t know until the next time a human (or a CI pipeline) runs a plan.

For a portable control plane, we need Active Reconciliation. We need a system that wakes up every 60 seconds, looks at your cloud, realizes, “Hey, that firewall rule doesn’t match the blueprint,” and fixes it automatically.

The Control Plane Stack:

Component	Tool Choice	The “Why”
The API Server	Kubernetes	It’s the only standard API that everyone (tools, CI/CD, developers) speaks fluently.
The Translator	Crossplane	It turns K8s YAML into AWS/Azure API calls. It manages the lifecycle, not just the creation.
The Source	Git (ArgoCD)	“Infrastructure as Data.” The state lives in Git, not on an engineer’s laptop.
The Guardrails	OPA / Kyverno	Policy enforcement. “No public buckets” is defined once and enforced everywhere.

The “Composite” Pattern: How to Actually Achieve Portability

Here is the secret sauce. Do not let your developers define cloud resources. If a developer writes YAML asking for an aws_db_instance, you have failed. You have locked them into AWS.

Instead, you define a Composite Resource (XR). Let’s call it CompositePostgres.

When a developer asks for a CompositePostgres:

1. If targeting AWS: The Control Plane spins up an RDS instance, a Parameter Group, and a Subnet Group.
2. If targeting Azure: The Control Plane spins up an Azure Database for PostgreSQL and a VNet Rule.
3. If targeting On-Prem: The Control Plane spins up a VM on Nutanix or calls the VMware API.

The developer’s request file looks identical in all three scenarios. This is portability.

Note on Legacy Migration: If you are sitting on a massive stack of on-prem VMware VMs and wondering how to map them to this new world, check out the VMware VVF/VCF Core Calculator. It helps you baseline your current compute density before you try to map it to cloud instances.

Portable Control Plane: Financial Realities

Design discussions often ignore the invoice. A portable control plane creates new ways to lose money.

The Latency & Egress Trap

A common disaster architecture: Putting the App in AWS (because the devs like Lambda) and the Data in GCP (because the data scientists like BigQuery).

• The Result: You will pay egress fees on every single query.
• The Fix: Data Gravity dictates location. The Control Plane is portable; the Data Plane is heavy. Move the compute to the data, not the other way around. This is the same principle behind exit cost architecture — the cost of moving data is an architectural constraint, not a billing footnote.

The Management Overhead

Running a Control Plane cluster isn’t free. You are essentially becoming your own mini-cloud provider.

• OpEx Savings: High. You slash the time spent on manual ticket processing.
• CapEx / Cloud Bill: Moderate increase. You are running 3-5 highly available nodes 24/7 just to manage the logic.

Where to Start (Don’t Boil the Ocean)

If you try to build a “Universal Cloud Abstraction” for everything on Day 1, you will fail. The scope is too large, the failure modes too varied, and the team learning curve too steep. Start with Networking — and start small enough that a single engineer can own the first composite resource end-to-end.

Why networking first? It’s the only layer where a misconfiguration in the abstraction creates a direct security failure across all three clouds simultaneously. A broken CompositePostgres fails a deployment. A broken NetworkPolicy composite opens port 22 to the internet on AWS, Azure, and GCP at the same time. The blast radius of a networking abstraction error is larger than any other layer — which means it’s also the layer where proving correctness first builds the most confidence in the pattern.

Networking is also the hardest layer to port manually. AWS Security Groups, Azure NSGs, and GCP Firewall Rules all look different but enforce the same intent. The gap between “I have three sets of firewall rules that do the same thing” and “I have one NetworkPolicy composite that generates all three” is where the Unified Control Plane proves its value — or fails to.

The three-step sequence:

1. Define the composite. Create a NetworkPolicy Composite Resource Definition (XRD) that exposes only the intent — allowed ports, traffic direction, isolation level. No cloud-specific fields.
2. Write the compositions. One composition per provider: AWS maps to Security Groups, Azure maps to NSGs, GCP maps to Firewall Rules. Each composition translates the intent into provider-native resources.
3. Validate drift detection. Don’t declare success until ArgoCD is reconciling the live state back to the Git source. The test: manually open a port in the AWS console. Within 60 seconds, ArgoCD should close it. If it does, the control loop works. If it doesn’t, the reconciliation logic has a gap.

Migration note: If you are coming from NSX-T on-prem, the rule translation problem is solved before you reach Crossplane. Use the NSX-T to Flow Translator to map your existing micro-segmentation rules into a portable format first — then use that output as the baseline for your NetworkPolicy composite definitions. Trying to hand-translate NSX-T rules into three cloud-native formats simultaneously is the kind of task that stalls migrations for months.

Once the NetworkPolicy composite is live, reconciling correctly, and validated under adversarial conditions (manual portal changes, provider API failures, network partitions), move to compute. Then storage. The sequence matters because each layer depends on the network layer beneath it being trustworthy. The full Modern Infrastructure & IaC architecture guide covers the Day-2 operational patterns for managing this stack once it’s in production.

Architect’s Verdict

The portable control plane is not a weekend project — and it’s not for everyone. If you have fewer than five DevOps engineers, the complexity of Crossplane + ArgoCD + OPA will consume more engineering hours than it saves. Pick one cloud, use Terraform, and move fast.

But if you’re operating at enterprise scale with compliance requirements, hybrid on-prem workloads, and more than one cloud in production, the Unified Control Plane architecture pays back its engineering investment in three specific ways: policy enforcement that doesn’t require manual replication, infrastructure drift detection that doesn’t wait for a human to run terraform plan, and a developer API surface that doesn’t leak cloud-provider implementation details into application code.

Start with networking. Map one composite resource correctly. Prove the pattern before you scale it. The alternative — continuing to run polycloud disguised as multi-cloud — just means paying two sets of bills for one set of problems.

Additional Resources

For deeper technical context on the concepts covered in this guide: