Operating workloads across Azure, AWS, Google Cloud and Oracle Cloud Infrastructure does not mean maintaining four copies of the same platform. It also does not mean pretending those clouds work the same way. A mature multi-cloud approach standardizes the outcomes and operating contracts the organization needs, then implements them using each provider’s native control plane and services.
The distinction matters. If every cloud gets a completely separate process for identity, onboarding, change review, cost attribution and operations, the organization duplicates avoidable work. If every cloud is forced behind one lowest-common-denominator abstraction, teams lose capabilities, accuracy and operational context. Neither extreme is a good platform strategy.
The goal is common intent, consistent workflows and provider-native implementation. Decide what must be predictable across the estate, what needs to vary by provider, and why each workload belongs where it does.
First ask why the workload spans clouds
Multi-cloud can be a deliberate response to an acquisition, a business-unit choice, existing application dependencies, data residency, a provider-specific capability or a documented resilience strategy. It can also be an inherited reality that the organization needs to govern better.
Write down the driver for each workload and the operating skills it requires. “Avoid lock-in” alone is not a complete design. Portability has a cost: teams maintain more landing zones, more identity and network integrations, more policies and deployment paths, and more incident knowledge. A multi-cloud failover design also requires tested data replication, compatible dependencies, capacity and recovery procedures; workloads do not become resilient merely because they exist in two providers. The Engineering Library’s Multi-Cloud Architecture and Governance guide provides a deeper provider-neutral operating model.
Microsoft’s landing zone guidance and AWS’s Control Tower guidance both describe provider-specific foundations for organizing, securing and governing workloads. OCI’s Cloud Adoption Framework likewise treats its landing zone as a foundation for ongoing management and operations. These models share architectural goals, but their implementation constructs are not interchangeable.
Standardize the outcomes and the delivery contract
Across providers, enterprises benefit from a consistent set of control objectives and platform interactions:
- Ownership and workload context: identify the product team, environment, data classification, business criticality, service owner and cost owner.
- Security outcomes: require least privilege, strong authentication, protected secrets, encryption, approved network exposure and auditable access.
- Governance intent: define acceptable regions, data-handling rules, policy exceptions, backup expectations and evidence needed for review.
- Infrastructure delivery: use version control, pull requests, validation, policy checks, plan review and controlled deployment.
- Operations: provide service ownership, incident severity, escalation, recovery objectives and useful telemetry in a form teams can correlate.
- Cost visibility: apply a common business taxonomy so spending can be attributed to products, teams, environments and workloads.
These standards should describe the behavior the organization expects, not require identical resource names or policy engines. For example, require restricted production access and an auditable approval path, while documenting how those controls are implemented and evidenced in each provider.
Keep implementation details provider-native
Cloud providers differ in resource hierarchies, identity systems, networking, policy evaluation, logging, managed databases, Kubernetes services and AI platforms. Those differences are often useful. A provider-native managed service may improve reliability or reduce operating work compared with reproducing the same function on a self-managed stack.
- Organization boundaries: map the common concept of workload isolation to Azure management groups and subscriptions, AWS Organizations and accounts, Google Cloud organizations, folders and projects, or OCI tenancies and compartments.
- Identity and authorization: federate to enterprise identity where appropriate, then express permissions using Azure RBAC, AWS IAM, Google Cloud IAM or OCI IAM policies. Do not assume role definitions or resource scopes map one-to-one.
- Network design: standardize exposure and segmentation requirements, but implement them using VNets, VPCs, Google Cloud VPC networks or OCI VCNs and their native routing and security controls.
- Platform services: choose each cloud’s managed application, data, analytics and AI services against workload needs, team capability, resilience and cost.
- Policy and evidence: preserve common policy intent and audit expectations while using the provider’s native policy, organization, security and logging mechanisms.
Google’s Well-Architected Framework and AWS’s Well-Architected Framework each organize their guidance around cloud workload qualities such as security, reliability, operations and cost, while applying it to their respective platforms. That is a useful model: align on review questions and desired outcomes, then make informed provider-specific architecture choices.
Use abstraction where it reduces work without hiding reality
A practical platform can offer a common workload contract and workflow with provider-specific modules behind it. For example, a team might request a production application environment by declaring its owner, environment, region, data sensitivity and service tier. The platform selects a tested implementation for the chosen cloud, attaches the right baseline policies, configures cost attribution and logging, and returns the provider-specific details the application team needs to operate it.
Keep the abstraction at the level that can genuinely be shared. Standardize repository structure, module quality checks, change review, policy intent, release conventions and output documentation. Keep provider-specific resource definitions and advanced options visible when teams need them. Maintain separate tested modules where implementations differ materially instead of concealing the difference inside dozens of conditional parameters.
Terraform can use provider plugins to manage multiple cloud platforms from one workflow, but each provider defines its own resources and data sources. Its provider documentation makes that boundary explicit. A shared Terraform workflow is useful; it does not make the underlying services or architectures portable by itself.
One operating model, several landing-zone implementations
- Shared outcomesDefine common identity, security, evidence and delivery expectations.
- Provider mappingImplement those controls with each cloud’s native services and resource model.
- Workload placementChoose the provider and pattern that fit each workload’s requirements.
- Portability testVerify exit paths that matter instead of requiring identical infrastructure everywhere.
The platform team should make it clear how a team onboards a workload, requests an environment, proposes a change, receives an approval, views its costs and gets operational help. The implementation can vary by provider while the user journey remains recognizable.
That operating model may share a source-control organization, pipeline conventions, identity federation patterns, policy review process, workload metadata and telemetry standards. Provider platform teams then own the resource hierarchies, control mappings, modules and native services for each cloud. Workload teams select from supported options and remain accountable for their application and data.
This is where Cloud Foundation and Platform Engineering meet: each provider needs a secure, operated foundation, while the enterprise needs a coherent path for consuming those foundations. See also Infrastructure as Code to Platform as Code and why infrastructure change belongs in a reviewable code path.
Make the cloud choice explicit per workload
For each workload, record the reason for the provider choice, the required provider-specific services, portability expectations, data and network boundaries, support model, exit or recovery assumptions, and the cost of operating there. Review the decision when business needs or provider capabilities change.
Do not build a portable platform by removing useful cloud capabilities from every application. Build a platform that makes those choices visible, governed and supportable. Some workloads should be deliberately cloud-neutral; others should use native services because those services are the right fit. The architecture should say which is which.
| Concern | Standardize | Keep provider-native |
|---|---|---|
| Identity | Federation, least privilege, ownership and access review. | Role definitions, scopes and policy constructs. |
| Network | Exposure, segmentation, private-access and inspection requirements. | VNet, VPC, VPC network or VCN topology and services. |
| Delivery | Git review, validation, approvals, promotion and evidence. | Provider resource modules, plans and deployment APIs. |
| Operations | Service ownership, incident expectations, recovery objectives and cost attribution. | Native telemetry, managed services and operational control planes. |
Test portability against the workload’s real exit needs
A portable design is useful only when portability is a requirement worth paying for. For each workload, state what must move in a provider change—data, application code, identity relationships, deployment definitions or operating procedures—and what can remain provider-specific. Test the hardest dependency rather than counting how many resources use a shared module. Include data export formats, network reconnection, service behavior differences, recovery time and the people needed to operate the destination. A documented exit plan that has never been exercised is an assumption; a small migration rehearsal can reveal which abstractions help and which simply hide a dependency. If the business has no funded requirement or tested procedure to move a workload, be candid that the design is optimized for its current provider. That clarity is more useful than claiming portability based on Terraform syntax, Kubernetes packaging or a common dashboard alone.
Continue reading
References
- What is an Azure landing zone? — Microsoft Cloud Adoption Framework.
- What is AWS Control Tower? — AWS documentation.
- Google Cloud Well-Architected Framework — Google Cloud documentation.
- Oracle Cloud Infrastructure Cloud Adoption Framework — Oracle documentation.
- Configure Terraform providers — HashiCorp Developer.