Skip to content

Multi-Cloud Governance -- Architecture

Component breakdown, canonical topology patterns, and reference architectures for enterprises running across AWS, GCP, Alibaba Cloud, and Tencent Cloud.

Networking Patterns

Hub-and-Spoke

The most common multi-cloud topology. A central network hub (often an on-premises data center or a dedicated transit VPC/VNet) routes all inter-cloud traffic. Each cloud environment is a "spoke" connected via dedicated interconnect.

                    [ On-Prem DC / Transit Hub ]
                     /        |          \
                    /         |           \
            [ AWS TGW ]  [ GCP NCC ]  [ Alibaba CEN ]
                |            |              |
            [ VPCs ]     [ VPCs ]       [ VPCs ]

Key services per cloud:

Cloud Hub Service Interconnect Service
AWS Transit Gateway Direct Connect (1/10/100 Gbps)
GCP Network Connectivity Center (NCC) Dedicated / Partner Interconnect
Alibaba Cloud Cloud Enterprise Network (CEN) Express Connect (physical dedicated line)
Tencent Cloud Cloud Connect Network (CCN) Direct Connect

Advantages: Centralized routing policy, single audit point, clear blast-radius boundary. Disadvantages: Hub is a single point of failure. All cross-cloud traffic incurs hub hairpinning latency.

Full Mesh

Every cloud peer connects directly to every other cloud peer, typically via dedicated point-to-point circuits or an SD-WAN overlay. No central transit hub.

            [ AWS TGW ] ------ [ GCP NCC ]
                |    \          /     |
                |     \        /      |
                |    [ Alibaba CEN ]   |
                |         |            |
                +---[ Tencent CCN ]----+

Advantages: Lowest inter-cloud latency (direct paths). No single point of failure. Disadvantages: O(n^2) circuit management. Complex routing tables. Higher cost at scale.

Transit (Backbone)

A provider-agnostic backbone -- often a third-party fabric like Equinix Fabric, Megaport, or PacketFabric -- acts as the Layer 2/3 transit layer. Each cloud connects to the nearest fabric node via its dedicated interconnect service. The backbone provides any-to-any reachability with per-circuit QoS and bandwidth policies.

            [ Equinix Fabric / Megaport Backbone ]
              /         |            |          \
        [ AWS DC ]  [ GCP DC ]  [ Alibaba PoP ] [ Tencent PoP ]
             |           |            |              |
          [ VPCs ]    [ VPCs ]     [ VPCs ]       [ VPCs ]

Advantages: Centralized bandwidth management. Sub-cloud provisioning. Any-to-any reachability without full mesh circuits. Disadvantages: Added cost of third-party fabric. Dependency on fabric provider SLA.

SD-WAN Overlay

Some enterprises cannot justify dedicated circuits at every edge. For these enterprises, SD-WAN solutions create encrypted IPsec/GRE tunnels over the public internet between cloud VPCs and branch offices. Common products are Cisco Viptela, VMware Velocloud, Palo Alto Prisma SD-WAN, and Fortinet Secure SD-WAN.

Advantages: Rapid provisioning. Internet-based (no colo requirement). Built-in WAN optimization. Disadvantages: Higher and variable latency. Bandwidth limited by internet path. Not suitable for latency-sensitive workloads.

Decision Matrix

Factor Hub-Spoke Full Mesh Transit Backbone SD-WAN Overlay
Latency Medium (hairpin) Low (direct) Low-Medium High-Variable
Complexity Low High Medium Low-Medium
Cost Medium High Medium-High Low
Blast Radius Hub is SPOF Isolated per link Fabric is SPOF Per-tunnel
Use Case Regulated enterprise Low-latency apps Global scale Branch / DR

Key Interconnect Services Reference

Service Cloud Bandwidth Protocol
AWS Direct Connect AWS 1/10/100 Gbps 802.1Q VLAN, BGP
AWS Transit Gateway Connect AWS Up to 50 Gbps per attachment GRE/BGP
GCP Dedicated Interconnect GCP 10/100 Gbps per link 802.1Q, BGP4
GCP Partner Interconnect GCP 50 Mbps -- 50 Gbps Varies by partner
GCP Cross-Cloud Interconnect GCP 10 Gbps (GA) Dedicated to other clouds
Alibaba Cloud Express Connect Alibaba 1/10/100 Gbps Physical dedicated line, BGP
Alibaba Cloud CEN Alibaba Bandwidth packages Transit routing
Tencent Cloud Direct Connect Tencent 1/10/100 Gbps Physical dedicated line, BGP
Tencent Cloud CCN Tencent Bandwidth limits per instance Transit routing
Equinix Fabric Vendor-neutral 50 Mbps -- 100 Gbps Software-defined L2/L3
Megaport Vendor-neutral 1 Mbps -- 100 Gbps Software-defined L2

DNS and Traffic Management

Provider DNS Services

Service Cloud Key Routing Policies
Amazon Route 53 AWS Latency, geolocation, weighted, failover, multivalue, IP-based
Google Cloud DNS GCP Geolocation, weighted round-robin (via Traffic Director / Cloud CDN)
Google Cloud Global LB GCP L7/LB with cross-region failover
Alibaba Cloud DNS (Alidns) Alibaba Geolocation, weighted, ISP-line routing (telecom/unicom/mobile)
Tencent DNSPod Tencent Geolocation, weighted, ISP-line routing, search-engine lines
Cloudflare DNS Vendor-neutral Geolocation, weighted, failover, load balancing
NS1 (IBM) Vendor-neutral Filter chains, regional targeting, Pulsar active telemetry

Multi-Cloud DNS Strategy Patterns

1. Delegated Subdomain per Cloud

Each cloud owns a subdomain zone (for example, aws.example.com, gcp.example.com, cn.example.com). A global apex zone delegates NS records per subdomain to the respective cloud DNS service.

example.com (Route 53 / Cloudflare)
  ├── aws.example.com   NS → Route 53 hosted zone
  ├── gcp.example.com   NS → Cloud DNS zone
  ├── cn.example.com    NS → Alidns zone
  └── global.example.com → GSLB (weighted/latency routing across clouds)

2. GSLB Overlay with Health Checks

A global DNS layer (Route 53, Cloudflare, NS1) resolves global.example.com by evaluating health-check endpoints in each cloud. On failure, traffic shifts to the next healthy cloud within TTL convergence time.

  • Route 53 health checks: HTTP/HTTPS/TCP, configurable intervals (10s-30s), failure threshold.
  • Cloudflare Load Balancing: Health checks per pool, failover steering, session affinity.
  • NS1 Filter Chain: Programmatic DNS decisions based on telemetry feeds (Pulsar), availability, and geolocation.

3. China-Specific DNS Consideration

Mainland China DNS resolution for example.cn domains requires ICP filing. Alidns and DNSPod both support ISP-line resolution (routing queries from China Telecom, China Unicom, China Mobile to the nearest endpoint). For multi-cloud within China, DNSPod or Alidns serve as the apex. For global-with-China architectures, a split-horizon DNS configuration is typical -- international queries resolve via Route 53/Cloudflare. China queries resolve via Alidns/DNSPod.

Traffic-Management Tools Beyond DNS

Tool Layer Multi-Cloud
Istio L7 (service mesh) Cross-cluster multi-primary on different clouds
Cilium L3-L7 (CNI + service mesh) Cluster mesh across clouds via tunnel or direct routing
Google Cloud Traffic Director L7 Can manage Envoy proxies outside GCP
AWS App Mesh L7 Tied to AWS. Can manage Envoys on EKS/ECS
Kong Gateway / Traefik L7 API Gateway Cloud-agnostic. Deploy anywhere

Infrastructure-as-Code

Terraform / OpenTofu

The dominant multi-cloud IaC tool. HCL configurations declare resources across providers in a single state or split across workspaces. OpenTofu is the Linux-foundation-governed fork created after HashiCorp's BSL license change in 2023.

Multi-provider configuration example:

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 5.0"
    }
    google = {
      source  = "hashicorp/google"
      version = "~> 5.0"
    }
    alicloud = {
      source  = "aliyun/alicloud"
      version = "~> 1.220"
    }
    tencentcloud = {
      source  = "tencentcloudstack/tencentcloud"
      version = "~> 1.80"
    }
  }
}

provider "aws" {
  region = "ap-southeast-1"
}

provider "google" {
  project = "my-project"
  region  = "asia-southeast1"
}

provider "alicloud" {
  region = "cn-hangzhou"
}

provider "tencentcloud" {
  region = "ap-guangzhou"
}

Multi-cloud deployment with identity tokens (Terraform Stacks):

identity_token "aws" {
  audience = ["aws.workload.identity"]
}

identity_token "gcp" {
  audience = ["gcp.workload.identity"]
}

deployment "multi_cloud" {
  inputs = {
    aws_token = identity_token.aws.jwt
    gcp_token = identity_token.gcp.jwt
    aws_role  = "arn:aws:iam::123456789012:role/terraform-role"
    gcp_sa    = "[email protected]"
  }
}

State isolation strategy: Use separate workspaces or separate state backends per cloud to limit blast radius. Common backend choices: S3 (AWS), GCS (GCP), OSS (Alibaba), COS (Tencent).

Pulumi

General-purpose IaC using TypeScript, Python, Go, C#, or Java. Same provider ecosystem as Terraform (bridged providers) plus native providers (AWS Native, Azure Native) that offer same-day support for new cloud services.

Multi-cloud provider configuration (TypeScript):

import * as aws from "@pulumi/aws";
import * as gcp from "@pulumi/gcp";
import * as alicloud from "@pulumi/alicloud";

const awsProvider = new aws.Provider("aws-provider", {
  region: "ap-southeast-1",
});

const gcpProvider = new gcp.Provider("gcp-provider", {
  project: "my-project",
  region: "asia-southeast1",
});

const aliProvider = new alicloud.Provider("ali-provider", {
  region: "cn-hangzhou",
});

Pulumi ESC (Environments, Secrets, and Configuration) provides dynamic OIDC credentials for AWS, Azure, and GCP. This eliminates static access keys. Stack references allow one stack to consume outputs from another. This enables dependency tracking across cloud boundaries.

Crossplane

Kubernetes-native IaC. Infrastructure is declared as CRDs and reconciled by provider controllers running inside the cluster. Crossplane Compositions allow platform teams to create abstract, cloud-agnostic APIs (XRDs) that map to cloud-specific managed resources underneath.

Multi-cloud composition concept:

# Abstract XRD -- cloud-agnostic
apiVersion: apiextensions.crossplane.io/v1
kind: CompositeResourceDefinition
metadata:
  name: xdatastores.example.org
spec:
  group: example.org
  names:
    kind: XDataStore
  versions:
  - name: v1alpha1
    served: true
    referenceable: true
    schema:
      openAPIV3Schema:
        type: object
        properties:
          spec:
            type: object
            properties:
              engine:
                type: string
                enum: ["mysql", "postgresql"]
              size:
                type: string
              cloudProvider:
                type: string
                enum: ["aws", "gcp", "alibaba"]

Provider ecosystem (2025-2026):

Provider Maturity Notes
provider-upjet-aws High Full AWS coverage
provider-upjet-gcp High Full GCP coverage
provider-upjet-azure High Full Azure coverage
provider-alicloud Medium Community-maintained, growing coverage
provider-tencentcloud Low-Medium Community contribution, limited resources

Crossplane is strongest when the organization has already standardized on Kubernetes as its platform layer. It integrates natively with GitOps tools (ArgoCD, Flux) since CRDs are just Kubernetes objects.

Decision Matrix

Factor Terraform/OpenTofu Pulumi Crossplane
Learning curve Low (HCL) Medium (code) High (K8s CRDs)
Multi-cloud maturity Highest High Growing (AWS/GCP/Azure strong, Alibaba/Tencent developing)
GitOps native Via Atlantis Via Pulumi Deployments Native (CRDs)
State management External backend Pulumi Cloud or self-managed Kubernetes etcd
Platform abstraction Modules ComponentResource Compositions + XRDs
Best fit General infra teams Developer-heavy teams Platform engineering / K8s-first orgs

CI/CD and GitOps

GitOps Patterns for Multi-Cloud

GitOps uses Git as the single source of truth for declarative infrastructure and application state. Automated controllers (ArgoCD, Flux) continuously reconcile the live state with the desired state in Git.

Hub-and-Spoke GitOps:

A central management cluster runs ArgoCD/Flux, which deploys to remote target clusters across clouds via ApplicationSets or Flux's Kustomization resources.

[ Management Cluster (ArgoCD/Flux) ]
        |                |               \
   [ AWS EKS ]     [ GCP GKE ]    [ Alibaba ACK ]
  • ArgoCD ApplicationSets with git-directory or matrix generators create one Application per target cluster.
  • Flux Kustomization resources with spec.kubeConfig reference kubeconfigs for remote clusters.

Per-Cluster GitOps:

Each cluster runs its own ArgoCD/Flux instance. Simpler blast radius but harder to enforce global policy. Useful for regulated environments where clusters must be autonomous.

Progressive Delivery:

  • Argo Rollouts: Canary / blue-green / experiment strategies with metric analysis.
  • Flagger (with Flux): Automated canary deployments with Prometheus metric analysis.
  • ArgoCD Image Updater / Flux Image Automation: Automatically update image tags in Git when new images are published.

Multi-Cloud CI Pipeline Structure

[ Git Push ]
     |
[ CI Pipeline (GitHub Actions / GitLab CI) ]
  ├── Build container image
  ├── Run tests
  ├── Push image to multi-cloud registries
  │   ├── ECR (AWS)
  │   ├── Artifact Registry (GCP)
  │   └── ACR / Alibaba Container Registry
  ├── Update GitOps manifest (image tag)
  └── GitOps controller detects change and rolls out

Secret management in GitOps: Sealed Secrets (Bitnami), SOPS (Mozilla) with KMS per cloud, or External Secrets Operator. External Secrets Operator syncs from HashiCorp Vault or cloud-native secret stores (AWS Secrets Manager, GCP Secret Manager, Alibaba KMS).

Tool Reference

Tool Type Multi-Cluster License
ArgoCD Pull-based GitOps ApplicationSets, Sync Waves Apache 2.0
Flux Pull-based GitOps Remote Kustomization, KubeConfig refs Apache 2.0
Argo Rollouts Progressive delivery Multi-cluster rollouts Apache 2.0
Flagger Progressive delivery Per-cluster, pairs with Flux MIT
External Secrets Operator Secret syncing Multi-cloud secret store backends Apache 2.0
Sealed Secrets In-cluster encryption Cloud-agnostic Apache 2.0
SOPS File-level encryption KMS per cloud MPL 2.0

Reference Architecture

A vendor-neutral enterprise multi-cloud architecture built on CNCF and open-source components.

graph TB
    subgraph "Identity Layer"
        IdP[IdP: Okta / Entra ID / Keycloak]
        SPIFFE[SPIFFE / SPIRE]
    end

    subgraph "Control Plane"
        Git[Git Repository]
        CI[CI Pipeline]
        ArgoCD[ArgoCD / Flux]
        IaC[Terraform / Crossplane]
    end

    subgraph "Networking Layer"
        Fabric[Equinix Fabric / Megaport]
        DNS[Global DNS: Route 53 / Cloudflare]
    end

    subgraph "Workload Plane"
        AWS[AWS EKS]
        GCP[GCP GKE]
        ALI[Alibaba ACK]
        TENCENT[Tencent TKE]
    end

    subgraph "Observability Plane"
        OTel[OTel Collectors]
        Backend[Grafana LGTM / Datadog]
    end

    subgraph "Policy Layer"
        OPA[OPA / Gatekeeper]
        Sentinel[Sentinel / Cloud Org Policies]
    end

    IdP -->|SAML/OIDC| AWS
    IdP -->|SAML/OIDC| GCP
    IdP -->|SAML/OIDC| ALI
    IdP -->|SAML/OIDC| TENCENT

    Git --> CI --> ArgoCD
    ArgoCD --> AWS
    ArgoCD --> GCP
    ArgoCD --> ALI
    ArgoCD --> TENCENT

    IaC --> AWS
    IaC --> GCP
    IaC --> ALI
    IaC --> TENCENT

    Fabric --> AWS
    Fabric --> GCP
    Fabric --> ALI
    Fabric --> TENCENT

    DNS --> AWS
    DNS --> GCP
    DNS --> ALI
    DNS --> TENCENT

    OTel --> Backend
    AWS --> OTel
    GCP --> OTel
    ALI --> OTel
    TENCENT --> OTel

    OPA --> AWS
    OPA --> GCP
    OPA --> ALI
    OPA --> TENCENT

Layer Descriptions

Layer Components Purpose
Identity IdP (SAML/OIDC), SPIFFE/SPIRE Unified human + workload identity
Control Plane Git, CI, GitOps controller, IaC engine Declarative intent and reconciliation
Networking Interconnect fabric, global DNS Cross-cloud connectivity and traffic steering
Workload Plane Managed K8s clusters per cloud Application runtime
Observability OTel Collectors, central backend Traces, metrics, logs, profiles
Policy OPA/Gatekeeper, Sentinel, org policies Governance, compliance, cost guardrails

How It Works

  1. Identity federation: The IdP issues SAML assertions (human SSO) and OIDC tokens (workload identity) to each cloud. SPIRE agents on each workload node provide mTLS workload identity independent of cloud IAM.

  2. Infrastructure provisioning: Terraform or Crossplane declares VPCs, databases, queues, and other cloud resources. Changes land in Git, CI validates with terraform plan or crossplane dry-run, and applies after approval.

  3. Application delivery: CI builds images, pushes to per-cloud registries, and updates GitOps manifests. ArgoCD/Flux reconciles manifests to clusters across all clouds.

  4. Networking: Equinix Fabric or Megaport provides any-to-any private connectivity. Global DNS routes users to the nearest healthy cloud endpoint.

  5. Observability: OTel Collectors in each cluster collect traces, metrics, and logs. They export to a central backend (Grafana LGTM stack or a SaaS observability platform) via OTLP.

  6. Policy enforcement: OPA/Gatekeeper enforces Kubernetes-level policies (resource limits, allowed images, labeling). Cloud-native org policies (AWS SCPs, Azure Policy, GCP Org Policy, Alibaba RAM policies) enforce cloud-resource-level governance. HashiCorp Sentinel adds policy-as-code guardrails for Terraform operations.

Security

Identity federation, access control, compliance baselines, and threat-modeling patterns for multi-cloud environments spanning AWS, GCP, Alibaba Cloud, and Tencent Cloud.

Identity Federation

Problem

Each cloud has its own IAM system (AWS IAM, GCP IAM, Alibaba RAM, Tencent CAM). Without federation, operators maintain separate credentials per cloud. This violates the principle of centralized identity governance and creates credential-sprawl risk.

Federation Protocols

Protocol Primary Use Token Format
SAML 2.0 Human user SSO (browser-based) XML assertion
OIDC (OpenID Connect) Workload identity, service-to-service JWT
OAuth 2.0 API authorization, consent flows Bearer token

Per-Cloud Federation Configuration

AWS

  • IAM Identity Center (successor to AWS SSO): Accepts SAML assertions from an external IdP. Maps SAML attributes to AWS permission sets.
  • IAM OIDC Federation: Accepts OIDC tokens from trusted IdPs (Okta, Entra ID, GitHub Actions). Used for workload identity (CI/CD assuming AWS roles).
  • Key config: SAML provider in IAM, trust policy with sts:AssumeRoleWithSAML, OIDC provider with sts:AssumeRoleWithWebIdentity.
{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {
      "Federated": "arn:aws:iam::ACCOUNT::saml-provider/Okta"
    },
    "Action": "sts:AssumeRoleWithSAML",
    "Condition": {
      "StringEquals": {
        "SAML:aud": "https://signin.aws.amazon.com/saml"
      }
    }
  }]
}

GCP

  • Workforce Identity Federation: SAML/OIDC federation for human users. Maps external IdP groups to GCP IAM roles.
  • Workload Identity Federation: OIDC federation for service accounts. A GitHub Actions OIDC token, for example, can impersonate a GCP service account without static keys.
  • Key config: WorkloadIdentityPoolProvider (OIDC or SAML), IAM policy binding the pool identity to a service account.
# GCP Workload Identity Pool Provider for GitHub Actions
resource "google_iam_workload_identity_pool_provider" "github" {
  workload_identity_pool_id = google_iam_workload_identity_pool.github.pool_id
  provider_id               = "github-actions"
  attribute_mapping = {
    "google.subject"            = "assertion.sub"
    "attribute.repository"      = "assertion.repository"
    "attribute.branch"          = "assertion.ref"
  }
  oidc {
    issuer_uri = "https://token.actions.githubusercontent.com"
  }
}

Alibaba Cloud

  • RAM SSO (SAML): Supports SAML-based SSO with external IdPs (Okta, Azure AD, OneLogin). Configured via RAM console: Identity Provider > SAML provider > role mapping.
  • RAM OIDC Federation: Accepts OIDC tokens for workload identity. RAM roles can be assumed via AssumeRoleWithOIDCToken API.
  • Key config: SAML provider in RAM, OIDC provider in RAM, RAM role with trust policy referencing the provider.
# Alibaba RAM OIDC role trust policy
{
  "Statement": [{
    "Action": "sts:AssumeRoleWithOIDC",
    "Effect": "Allow",
    "Principal": {
      "OIDC": "acs:ram::ACCOUNT:oidc-provider/okta-provider"
    },
    "Condition": {
      "StringEquals": {
        "oidc:aud": "alibaba-cloud-oidc"
      }
    }
  }],
  "Version": "1"
}

Tencent Cloud

  • CAM SAML Federation: Supports SAML SSO with enterprise IdPs. Configured via CAM console: Identity Provider > SAML > role-for-SAML.
  • CAM OIDC Federation: OIDC-based role assumption for workloads. CAM roles with OIDC trust policies accept JWTs from trusted issuers.
  • Key config: SAML provider in CAM, OIDC provider in CAM, role with sts:AssumeRoleWithWebIdentity trust policy.
                    [ Central IdP ]
                    (Okta / Entra ID / Keycloak)
                    /      |         |          \
              SAML  /  OIDC|    SAML |    SAML  \
                  /        |         |            \
          [ AWS IAM      [ GCP IAM ] [ Alibaba  [ Tencent
          Identity       Workforce   RAM         CAM
          Center ]       / Workload  SSO+OIDC ] SSO+OIDC ]
                        Identity
                        Federation ]

Best practices:

  1. Use SAML 2.0 for human user SSO across all clouds.
  2. Use OIDC for workload-to-workload and CI/CD identity federation.
  3. Map IdP groups to cloud roles with least-privilege permission sets. Do not map individual users.
  4. Enforce MFA at the IdP level. Require MFA in cloud role trust conditions where supported.
  5. Centralize audit logs (CloudTrail, Cloud Audit Log, ActionTrail, CloudAudit) into a SIEM.
  6. Rotate IdP signing certificates on a regular cadence with overlap periods.
  7. Use conditional access policies (device compliance, IP ranges) at the IdP layer.

SPIFFE / SPIRE for Workload Identity

SPIFFE (Secure Production Identity Framework for Everyone) provides a cloud-agnostic workload identity layer. SPIRE is its reference implementation.

  • Each workload gets a SPIFFE ID (for example, spiffe://example.org/billing-service).
  • SPIRE agents on each node issue X.509 SVIDs (SPIFFE Verifiable Identity Documents) to workloads via workload API.
  • mTLS between workloads is bootstrapped by SVIDs, independent of cloud-specific IAM.
  • In a multi-cloud Kubernetes deployment, SPIRE federates trust domains across clusters. This enables workloads on AWS to authenticate workloads on Alibaba Cloud without cloud-specific trust configuration.

Integration points:

Component Integration
Istio SPIRE as the CA backend for Istio mTLS
Envoy SDS (Secret Discovery Service) with SPIRE
Kubernetes SPIRE via CSI driver or DaemonSet
Cloud KMS SPIRE server keys stored in AWS KMS / GCP KMS / Alibaba KMS

Workload Identity Comparison

Feature AWS GCP Alibaba Tencent
Service accounts IAM Roles for Service Accounts GCP Service Accounts RAM Roles for ECS/ACK CAM Roles for CVM/TKE
OIDC federation IAM OIDC Provider Workload Identity Federation RAM OIDC CAM OIDC
K8s integration IRSA (IAM Roles for SA) Workload Identity RRSA (RAM Roles for SA) TKE CAM Pod Identity
CI/CD identity OIDC from GitHub/GitLab OIDC pool providers OIDC provider in RAM OIDC provider in CAM
Token lifetime Configurable (900s-12h) 1h default, configurable 900s-3600s Configurable

Security Baseline and Compliance

CIS Benchmarks

The Center for Internet Security publishes cloud-specific benchmarks with Level 1 (prescriptive, minimal disruption) and Level 2 (proactive, more restrictive) controls.

Cloud Benchmark Key Areas
AWS CIS AWS Foundations Benchmark v2.0 IAM (root account, MFA, password policy), logging (CloudTrail, Config), networking (VPC flow logs, default SG), encryption (S3, EBS, RDS)
GCP CIS GCP Foundations Benchmark v2.0 IAM (service account keys, org policies), logging (Audit Logs), networking (VPC flow logs, firewall rules), storage (bucket policy)
Alibaba Cloud CIS Alibaba Cloud Foundations Benchmark RAM (root account, MFA, access keys), ActionTrail, Security Center, VPC flow logs, OSS encryption
Tencent Cloud No official CIS benchmark published as of April 2026. Use Tencent Cloud's MLPS 2.0 compliance framework as the closest equivalent. CAM, CloudAudit, Security Center, VPC flow logs, COS encryption

Compliance Frameworks

Framework Scope Multi-Cloud Relevance
ISO 27001/27017/27018 InfoSec management, cloud security, PII in cloud Audit once, covers all cloud providers
SOC 2 Type II Trust service criteria (security, availability, confidentiality) Each cloud provider has SOC 2 reports. Inherit controls
NIST CSF 2.0 Cybersecurity functions (Identify, Protect, Detect, Respond, Recover) Maps to all cloud providers' compliance offerings
PCI DSS 4.0 Payment card data Network segmentation and encryption enforced per cloud
HIPAA Healthcare data (US) BAA required with each cloud provider
GDPR / PIPL Data privacy (EU / China) Data residency enforcement per cloud region
CSA CCM v4 Cloud-specific controls matrix Cross-cloud assessment framework
MITRE ATT&CK Cloud Adversary tactics and techniques for cloud Threat model across AWS, GCP, Azure, Alibaba

Automated Compliance Scanning

Tool Clouds Covered CIS Benchmarks License
Prowler AWS, Azure, GCP Yes Apache 2.0
ScoutSuite AWS, Azure, GCP, Alibaba Partial GPL 2.0
Checkov AWS, Azure, GCP, Alibaba (via Terraform) Partial (IaC scanning) Apache 2.0
tfsec AWS, Azure, GCP (Terraform) Partial MIT
GCP Security Command Center GCP Yes (built-in) Managed service
AWS Security Hub AWS Yes (CIS benchmark standard) Managed service
Alibaba Cloud Security Center Alibaba Partial (baseline checks) Managed service
Prisma Cloud (Palo Alto) AWS, Azure, GCP, Alibaba Yes Commercial
Wiz AWS, Azure, GCP, Alibaba, Tencent Yes Commercial
Orca Security AWS, Azure, GCP, Alibaba Yes Commercial

Policy-as-Code Enforcement

Tool Scope Language Integration
OPA / Gatekeeper Kubernetes resources Rego Admission controller in each cluster
HashiCorp Sentinel Terraform operations Sentinel (HCL-like) Terraform Cloud / Enterprise
AWS Service Control Policies (SCPs) AWS Organizations JSON policy AWS-level
Azure Policy Azure resources JSON / aliases Azure-level
GCP Organization Policy GCP resources Constraint templates GCP-level
Alibaba RAM Control Policies Alibaba resources JSON policy Alibaba-level
Kyverno Kubernetes resources YAML-native K8s admission controller
Cloud Custodian AWS, Azure, GCP YAML Event-driven, serverless

Multi-Cloud Security Baseline Checklist

This is a minimal cross-cloud baseline. Adapt per compliance requirements.

Identity and Access:

  • Root/admin account has MFA enabled and is not used for daily operations.
  • Federation configured via SAML/OIDC from a single IdP to all clouds.
  • No long-lived access keys for human users. Use temporary credentials via federation.
  • Service accounts use workload identity (IRSA, Workload Identity, RRSA, TKE Pod Identity) rather than static keys.
  • Least-privilege role mapping from IdP groups to cloud roles.
  • Regular access reviews (quarterly) for all cross-cloud roles.

Networking:

  • No 0.0.0.0/0 ingress rules on security groups / firewall rules.
  • VPC flow logs enabled in all clouds.
  • Inter-cloud traffic traverses private interconnect (Direct Connect, Interconnect, Express Connect), not public internet.
  • Network segmentation between environments (dev/staging/prod) via separate VPCs or projects.

Data Protection:

  • Encryption at rest enabled for all storage services (S3, GCS, OSS, COS) using cloud KMS or customer-managed keys.
  • Encryption in transit enforced (TLS 1.2+) for all inter-service and client-to-service communication.
  • Secrets stored in dedicated secret stores (Vault, AWS Secrets Manager, GCP Secret Manager, Alibaba KMS), not in environment variables or code.

Logging and Monitoring:

  • Cloud audit logs enabled in all clouds (CloudTrail, Cloud Audit Log, ActionTrail, CloudAudit).
  • Logs centralized in a SIEM or log aggregation platform.
  • Alerting on suspicious activity (root account usage, new admin role creation, security group changes).
  • Container runtime security monitoring (Falco) deployed on all clusters.

Incident Response:

  • Incident response plan covers multi-cloud scenarios (for example, compromised credentials in one cloud affecting federated access to others).
  • Automated playbook for revoking federation trust in the IdP (kill switch).
  • Regular tabletop exercises covering cross-cloud incident scenarios.

Threat Model

Multi-Cloud-Specific Threats

Threat Description Mitigation
Credential compromise in one cloud leading to lateral movement Attacker obtains credentials for one cloud and attempts to pivot to others via shared identity Conditional access policies, IP-based trust conditions, MFA requirement in trust policies, SPIFFE workload identity boundary
Misconfigured federation trust policy Overly broad SAML/OIDC trust allows any user from the IdP to assume high-privilege roles Tight attribute conditions in trust policies, group-to-role mapping with least privilege
Inconsistent security baseline across clouds Different teams manage different clouds with varying security posture CIS benchmark scanning, Policy-as-Code, cross-cloud security dashboards
Data exfiltration via inter-cloud transfer Attacker moves data from a secured cloud to a less-secured cloud or external endpoint DLP policies, egress filtering, data residency constraints, flow-log anomaly detection
Supply chain attack on IaC modules Compromised Terraform module or Helm chart deploys malicious infrastructure Pin module versions, scan IaC with Checkov/tfsec, sign commits, require PR approval
DNS hijacking across multi-cloud zones Attacker compromises DNS credentials and redirects traffic DNSSEC, multi-factor authentication on DNS registrar, DNS change monitoring
Cloud provider supply chain Vulnerability in managed service affects workloads Multi-cloud deployment for critical workloads, regular patch cycle, vulnerability scanning