Module 10 · Multi-Cloud — The Complexity Tax

Last updated: April 29, 2026

Multi-cloud was sold as “avoid vendor lock-in.” In practice, multi-cloud means carrying the attack surface of every cloud you use. Each cloud has its own IAM, its own security tools, its own event schema, its own corner cases. Security teams manage complexity N times instead of once. This module closes the Cloud Mindset track by addressing the tax of multi-cloud.

Why this happens

• Acquisitions inherit workloads on different clouds
• Different teams choose based on skill or preference
• Specific services only on specific clouds (AWS for breadth, GCP for BigQuery, Azure for M365 integration)
• Region availability / pricing / compliance drives splits
• Vendor-negotiation leverage (whether achieved or not)

Reality: most “multi-cloud” organizations are single-cloud-primary with 10-20% in secondary clouds. The 10-20% carries disproportionate operational cost.

Security costs of multi-cloud

Per-cloud skillset

AWS IAM ≠ Azure RBAC ≠ GCP IAM. Each has syntactic and semantic differences. Security engineers need depth in each. One organization’s AWS expertise may be weak on Azure.

Divergent defaults

• AWS: S3 public-block now strong default; legacy accounts weaker
• Azure: Security Defaults applies some baselines; custom Conditional Access often disables them
• GCP: Organization Policies required for tight defaults

You can’t copy-paste hardening guidance.

N × CSPM

Either one CSPM covering all clouds (commercial tools like Wiz, Orca, Prisma) or native CSPM per cloud (Defender for Cloud + AWS Security Hub + GCP SCC). Either approach is expensive and requires team familiarity.

Identity federation complexity

• Entra ID as corporate directory
• Federated to AWS via SAML
• Federated to GCP via Cloud Identity SAML
• Per-cloud roles mapped from SAML claims
• Group changes in Entra must propagate
• Service accounts per cloud separate

Inter-cloud connectivity

Cloud-to-cloud trust paths (AWS role trusting GCP workload identity, etc.) add new attack vectors. Each federation is a potential compromise path.

Specific attack scenarios unique to multi-cloud

• Cross-cloud lateral movement: compromise dev team’s GCP account → find federated identity with AWS access → pivot to production AWS.
• Credential sprawl: service tokens stored in secrets managers across all clouds; one compromised secret manager = impact to others.
• Inconsistent detection: AWS has GuardDuty tuned; Azure has Defender with default rules; GCP has SCC Standard (free tier). Attacker targets the weakest.
• Compliance gap: controls implemented in primary cloud; secondary cloud has legacy state. Audit finds gap in the secondary.

Defenses

1. Minimize cross-cloud: consolidate workloads where possible. One cloud primary + specific secondary needs is realistic.
2. Unified CSPM across clouds: single pane of glass for posture.
3. Unified SIEM with cloud logs from all three ingesting.
4. Consistent identity provider (Entra or Okta) with federation to all clouds.
5. Baseline per cloud documented separately; treat each as its own domain.
6. Tabletop exercises covering cross-cloud incidents.
7. Audit cross-cloud trust paths quarterly.
8. Accept the tax: budget accordingly for N teams / N tools.

When multi-cloud pays off

• Regulatory requirement (EU + US + India each with residency rules)
• Specific vendor feature truly unique (BigQuery for some analytics, Entra for M365 integration)
• Real acquisition integration — you inherited it, not chose it

When multi-cloud is a choice for “vendor independence” without concrete driver: often net negative on security.

Mindset takeaway

Multi-cloud isn’t inherently bad. Multi-cloud without the operational investment to secure each is. If you’re multi-cloud, budget for it: N security engineers, N security tool license, N audit cycles. Skipping the tax means accepting higher breach risk in the less-invested clouds.

Closing the Cloud Mindset track

Across 10 modules: shared responsibility illusion, IAM complexity, metadata endpoints, cross-account trust, Kubernetes, serverless, supply chain, data exposure, detection gaps, multi-cloud tax. The through-line: cloud changes the attack surface from network-centric to identity-centric, from patch-centric to configuration-centric. Defender skills must follow.

For pentesters: cloud engagements need different recon (Pacu/ROADtools/GCP enumeration) and different exploitation paths (IAM privesc instead of kernel exploits). The economics favor misconfiguration hunting over 0day research.

For defenders: tools help but don’t solve. CSPM + SIEM + EDR + identity controls + posture measurement — each is part of the picture. Budget for all of them in each cloud you operate.