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

“Write once, run anywhere.”

It’s the oldest lie in distributed computing. Java promised it in the 90s. Docker promised it in the 2010s. Now, cloud vendors promise it—usually right before they lock you into a proprietary service mesh or a database that only exists in us-east-1.

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.

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

Executive Summary

• The Shift: Move from “Imperative Scripting” (Terraform apply) to “Declarative Reconciliation” (Kubernetes control loops).
• The Architecture: We are treating the Cloud Provider API as just another dependency.
• The Tech: Crossplane is currently the only viable engine for this. Terraform is great for creating things; Crossplane is for managing them.
• The Money: Portability isn’t free. Expect a 15-20% “Control Plane Tax” in compute overhead to save 40% in operational toil.

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.
• Multi-Cloud: You have one API surface. You push a policy once, and it propagates to AWS, Azure, and GCP simultaneously.

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.

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:

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 our VMware VVF/VCF Core Calculator. It helps you baseline your current compute density before you try to map it to cloud instances.

Financial Realities: The “Egress Tax”

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.

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. Start with Networking.

Networking is the hardest part to port. AWS Security Groups, Azure NSGs, and GCP Firewall Rules all look different but do the same thing.

1. Create a unified NetworkPolicy definition in your Control Plane.
2. Map it to the three clouds.
3. Migration Tip: If you are coming from NSX-T on-prem, use our NSX-T Translator. It can help you visualize your existing rules so you can re-write them into your new portable format.

The Verdict: Build or Buy?

Additional Resources: