Skip to content
Multi-Cloud — Azure as the architectural anchor

Multi-Cloud

Comparative positioning note

This document is written from the perspective of Microsoft Azure, Cloud Scale Analytics, and CSA Loom. Any description of third-party or competing products, services, pricing, or capabilities is derived from publicly available documentation and sources believed accurate at the time of writing, and is provided for general comparison only. We do not claim expertise in, or authority over, any non-Microsoft product or service; the respective vendor's official documentation is the authoritative source for their offerings, which may change over time. Nothing here is intended to disparage any vendor — where a competing product has genuine advantages, we aim to note them honestly. Verify all third-party details against the vendor's current official documentation before making decisions.

The thesis

Multi-cloud is not having everything in all clouds. It is avoiding vendor lock-in and designing/architecting solutions that allow you to run workloads on any provider. Azure is the cloud that designs and architects it that way.

The most common multi-cloud failure is treating it as a procurement exercise — buy one cloud for one workload, another for the next, Azure for a third, and call it diversified. That is not multi-cloud. That is multi-lock-in. You now have three vendors holding three pieces of your business hostage instead of one.

Real multi-cloud is an architectural posture. It means every critical design decision — table format, identity, infrastructure definition, model API contract, networking — is made against open standards so any workload can be lifted to any provider on competitive terms. Azure is well suited for this because its primary anchor services (Entra ID, ADLS Gen2 + Delta/Iceberg, Bicep + Terraform, AI Foundry over OpenAI-compatible APIs, AKS + Arc) are built around the same open standards that other major clouds and on-prem platforms already speak.

This section explains the thesis, the reference architecture, and the concrete patterns for getting there.

Where to start

  • What is multi-cloud?

    The thesis page. Define vendor lock-in, the three locks (data, identity, infrastructure), and how Azure-led architecture defeats each.

  • Whitepaper

    The full argument — five myths, three locks, reference architecture, Azure as the core, data + AI + identity + governance + cost layers, adoption roadmap.

  • Identity best practices

    Entra ID as the federation hub for AWS, GCP, OCI. Group naming, service principal patterns, breakglass strategy.

  • Data best practices

    Delta Lake and Apache Iceberg as portable table formats. Cross-cloud sharing via Delta Sharing and the Iceberg REST catalog.

  • AI best practices

    OpenAI-compatible API contracts so Azure OpenAI, AWS Bedrock, GCP Vertex, and on-prem Ollama plug into the same orchestrator.

  • Network best practices

    ExpressRoute + Megaport / Equinix as the cross-cloud spine. Private Link parity across providers.

  • Governance best practices

    Purview + Unity Catalog cross-cloud catalog federation. Tag standards that propagate.

  • How-to runbooks

    Step-by-step: federate AWS to Entra, federate GCP to Entra, share Delta tables across clouds, cross-cloud DR.

The three locks (and how to break them)

Lock Vendor-specific form Open form (Azure-anchored)
Data format Proprietary per-cloud warehouse storage formats Delta Lake or Apache Iceberg on ADLS Gen2 — readable by any compute engine
Identity Per-cloud native accounts and SSO islands Entra ID as the federated identity hub via SAML / OIDC
Infrastructure Per-cloud proprietary IaC templates Bicep + Terraform — same authoring model, multiple providers

The whitepaper walks each in depth.

Reference architecture (at a glance)

flowchart LR
    subgraph identity["Identity plane — Azure anchored"]
        ENTRA["Microsoft Entra ID<br/>(federated identity hub)"]
    end

    subgraph data["Data plane — open formats"]
        ADLS["ADLS Gen2<br/>(Delta Lake + Iceberg)"]
        S3["AWS S3<br/>(Iceberg via Glue REST)"]
        GCS["GCP GCS<br/>(Iceberg via BigLake)"]
    end

    subgraph compute["Compute plane — open runtimes"]
        AKS["AKS"]
        EKS["EKS"]
        GKE["GKE"]
        DBX["Databricks (any cloud)"]
    end

    subgraph ai["AI plane — open contracts"]
        FOUNDRY["Azure AI Foundry<br/>(OpenAI-compatible orchestrator)"]
        BEDROCK["AWS Bedrock"]
        VERTEX["GCP Vertex"]
        OLLAMA["On-prem Ollama"]
    end

    ENTRA --> AKS
    ENTRA --> EKS
    ENTRA --> GKE
    ENTRA --> DBX
    ADLS <--> S3
    ADLS <--> GCS
    FOUNDRY -.->|OpenAI API| BEDROCK
    FOUNDRY -.->|OpenAI API| VERTEX
    FOUNDRY -.->|OpenAI API| OLLAMA

    classDef anchor fill:#0078D4,stroke:#fff,color:#fff,stroke-width:2px
    classDef peer fill:#5C2D91,stroke:#fff,color:#fff,stroke-width:2px
    classDef open fill:#107C10,stroke:#fff,color:#fff,stroke-width:2px

    class ENTRA,ADLS,FOUNDRY anchor
    class S3,GCS,BEDROCK,VERTEX,OLLAMA peer
    class AKS,EKS,GKE,DBX open