18.20 — Multi-Cloud Concepts

1. What is it?

A conceptual map of how the Enterprise AI Assistant's AWS-based architecture (18.1–18.19) translates to Azure and GCP — not a second deep dive into each, but the specific question an AI FDE actually needs answered: "what changes if this must run on a different cloud," per the source spec's explicit framing.

2. Why does it exist?

Real AI FDE work is not always AWS — a customer may already standardize on Azure or GCP (their own version of 18.9's "we already use Kubernetes" scenario), or a deal may require multi-cloud for redundancy or contractual reasons. This chapter exists so an AWS-depth understanding (18.1–18.19) transfers as a mental model, not stranded knowledge useless outside one specific provider.

3. What problem does it solve?

It solves "I understand this architecture deeply on AWS — how do I reason about the same architecture on Azure or GCP without restarting from zero," by mapping AWS services to their closest equivalents and — more importantly — explaining where the equivalence is genuinely close versus where it meaningfully diverges.

4. How does it work internally?

The service-equivalence map, with honest caveats

Concept	AWS (this track)	Azure	GCP
Compute (18.3)	ECS/EKS/Lambda	AKS/Container Apps/Functions	GKE/Cloud Run/Cloud Functions
Object storage (18.4)	S3	Blob Storage	Cloud Storage
Relational DB (18.4)	RDS	Azure Database for PostgreSQL	Cloud SQL
Cache (18.14)	ElastiCache	Azure Cache for Redis	Memorystore
Queue (18.4/18.15)	SQS	Service Bus / Storage Queues	Pub/Sub / Cloud Tasks
IAM (18.3)	IAM	Entra ID / Azure RBAC	Cloud IAM
VPC (18.5)	VPC	Virtual Network	VPC
Kubernetes (18.9)	EKS	AKS	GKE
Secrets (18.5)	Secrets Manager	Key Vault	Secret Manager

The equivalence is closest for the most "commodity" services — object storage, basic relational databases, managed Kubernetes — since these solve genuinely similar problems with genuinely similar shapes across providers. It diverges most for IAM/identity models and networking terminology/defaults — AWS's IAM role/policy model, Azure's Entra ID (identity-centric, integrated with the broader Microsoft identity ecosystem many enterprises already use for SSO, Part 10.1), and GCP's IAM (project-and-resource-hierarchy-centric) are conceptually similar (least privilege, identity-based permissions) but different enough in mechanics that "just translate the IAM policy" is not a safe assumption — each provider's actual documentation needs to be consulted for the specific mechanics, not inferred from AWS familiarity alone.

What genuinely doesn't change

The concepts this entire track has taught are provider-agnostic: public/private network segmentation (18.2/18.5), least-privilege identity (18.3), the queue/worker pattern and its idempotency requirement (18.4/18.15), circuit breakers and graceful degradation (18.12), the bottleneck-identification discipline (18.13), and the infrastructure-to- AI-security bridge (18.19) all apply identically regardless of which cloud implements the specific mechanism — this is precisely why this track deliberately taught concepts first, cloud implementation second (the source spec's explicit "learning progression" instruction), so this chapter's job is genuinely narrow: map implementation details, not re-teach concepts that don't actually change.

What genuinely does change, beyond the naming

• Terraform provider: the aws provider (18.6) is replaced by azurerm or google — the workflow (init/plan/apply, state, modules) is identical; the resource types and their specific arguments are not.
• Networking defaults and terminology: Azure's "Virtual Network" and GCP's "VPC" have their own specific subnetting, routing, and firewall-rule models — conceptually parallel to 18.2/18.5 but not drop-in identical in mechanics (GCP's VPC firewall rules, for instance, work somewhat differently from AWS security groups' stateful, resource-attached model).
• Managed Kubernetes specifics: AKS/GKE both run standard Kubernetes (18.9's concepts transfer directly — pods, Deployments, HPA all work the same way), but cluster provisioning, node-pool management, and cloud-specific integrations (load balancer controllers, IAM-to- Kubernetes-RBAC bridging) differ per provider.
• GPU/AI-specific offerings (18.16): each provider has its own managed-model-hosting and GPU-instance catalog, with different available hardware, different provisioned-throughput offerings, and different pricing — a self-hosting decision (18.16/18.18) needs provider-specific research, not an assumption that AWS's GPU catalog and pricing directly transfers.

Portability vs. cloud-native optimization — the actual trade-off

Building for genuine multi-cloud portability (avoiding provider-specific managed services in favor of, e.g., self-managed Kubernetes and self-hosted Postgres everywhere) trades away much of the operational simplicity managed services provide (18.4's entire "why use RDS instead of running your own Postgres" rationale) in exchange for the ability to move between clouds without a significant rearchitecture. Most real systems reasonably choose cloud-native optimization (embracing a chosen provider's managed services fully, as this entire track has done with AWS) unless multi-cloud portability is a genuine, stated requirement — building for hypothetical future portability "just in case" is a real instance of Part 3's premature-abstraction anti-pattern, now at the infrastructure-architecture level.

5. Simple mental model

If AWS-depth knowledge (18.1–18.19) is fluency in one language, this chapter is a phrasebook plus grammar notes for the other major languages in the same family — you won't be immediately as fluent, but you recognize the grammar (the concepts) and can look up the specific vocabulary (the exact service names and API details) quickly, rather than needing to relearn the underlying ideas from scratch.

6. Real-world example

A customer already runs their entire technology stack on Azure and wants the Enterprise AI Assistant deployed there instead of AWS. The concrete translation exercise: AKS instead of EKS (18.9's Kubernetes concepts transfer directly), Azure Database for PostgreSQL instead of RDS (18.4's Multi-AZ/replica concepts have an Azure-specific equivalent worth verifying in current documentation), Azure Cache for Redis instead of ElastiCache (18.14's cache-vs-system-of-record principle is unchanged), and — the piece requiring the most genuinely new research rather than direct translation — Entra ID's identity model for the least-privilege IAM design this whole track has emphasized (18.3/18.19), since Azure's identity mechanics are meaningfully different from AWS IAM's, not simply renamed.

7. Architecture diagram

Conceptsprovider-agnostic, this whole track — least privilege, network segmentation, queue/worker idempotency, circuit breakers, bottleneck-first scaling, infra-to-AI-security bridge, cache-is-not-system-of-record

AWSthis track's concrete implementation

AzureAKS/Blob/Azure DB/Entra ID/Key Vault

GCPGKE/Cloud Storage/Cloud SQL/IAM

8. Production considerations

• Don't assume IAM/identity mechanics translate directly between providers — verify each provider's actual current identity model before designing a least-privilege policy on an unfamiliar cloud.
• Choose cloud-native optimization over speculative portability unless multi-cloud is a genuine, stated requirement — matching 18.14's broader "don't build for hypothetical requirements" principle.
• When genuinely multi-cloud (e.g., for contractual redundancy), Terraform's provider-agnostic workflow (18.6) is the practical mechanism, but expect real, provider-specific module differences, not one shared module working unchanged across providers.

9. Common mistakes

• Assuming a security group's stateful, resource-attached model translates directly to another provider's firewall-rule model, without verifying the actual mechanics differ.
• Building excessive cloud-agnostic abstraction for a system with no actual near-term multi-cloud requirement, at real ongoing complexity cost, for a hypothetical future need.
• Assuming GPU/self-hosting economics (18.16/18.18) transfer directly between providers without checking that specific provider's actual current hardware catalog and pricing.

10. Security considerations

The infrastructure-to-AI-security bridge (18.19) applies identically in concept across any cloud — but the specific mechanism (which IAM/RBAC model, which secrets service, which network firewall model) implementing each side of that bridge must be re-verified per provider, not assumed equivalent by name similarity alone.

11. Performance considerations

Cross-cloud latency (if a genuinely multi-cloud architecture spans providers for any single request path) is a real, additional consideration with no single-cloud equivalent — generally a strong reason to avoid splitting a single logical system across clouds unless a specific requirement demands it.

12. Cost considerations

Pricing models, discount structures, and committed-use offerings (18.18's reserved-capacity point) differ meaningfully across providers — a cost analysis done for AWS does not transfer numerically to Azure or GCP even for conceptually identical services, and must be redone with that provider's actual current pricing.

13. When to use it

When a customer's existing infrastructure, contractual requirements, or genuine redundancy needs point to a cloud other than AWS, or to a multi-cloud architecture specifically.

14. When NOT to over-apply it

Don't design for multi-cloud portability by default — the source spec's explicit instruction stands: use AWS as the primary implementation platform, and reach for this chapter's translation exercise only when an actual, stated requirement calls for it.

15. Alternatives and trade-offs

See section 4's portability-vs-cloud-native-optimization trade-off — the central, recurring judgment call this entire chapter revolves around.

16. Practical example — a Terraform provider swap, structurally

# AWS (this track's default, 18.6)
provider "aws" { region = "us-east-1" }
resource "aws_db_instance" "app" { engine = "postgres"; instance_class = "db.r6g.large" }

# Azure — same WORKFLOW (init/plan/apply, state, modules), different
# provider and resource types entirely — not a drop-in syntax swap
provider "azurerm" { features {} }
resource "azurerm_postgresql_flexible_server" "app" {
  sku_name = "GP_Standard_D2s_v3"
  # ... Azure-specific arguments, verified against current azurerm
  # provider documentation, not assumed from the AWS example's shape
}

17. Production-quality example — a provider-comparison decision memo excerpt

# Cloud Provider Decision — [Customer], AI Assistant Deployment

## Constraint
Customer's existing infrastructure and enterprise agreements are on
Azure; no genuine multi-cloud requirement exists.

## Recommendation
Deploy natively on Azure (AKS, Azure Database for PostgreSQL, Azure
Cache for Redis, Entra ID for identity) rather than AWS or a
cloud-agnostic abstraction layer — per section 4/14, cloud-native
optimization is preferred absent an actual portability requirement.

## What transfers directly from this track's AWS-based design
- All architectural CONCEPTS: network segmentation, least privilege,
  queue/worker idempotency, circuit breakers, bottleneck-first scaling.
- Kubernetes workload definitions (Deployments, Services, HPAs, PDBs) —
  AKS runs standard Kubernetes, unchanged from 18.9's YAML.

## What requires genuine, provider-specific re-verification
- IAM/identity model (Entra ID mechanics, not a renamed AWS IAM)
- Networking firewall/NSG specifics
- Current GPU instance catalog and pricing, if self-hosting (18.16/18.18)

18. Short exercise

Take 18.5's complete VPC architecture diagram and redraw it using Azure's networking terminology (Virtual Network, Network Security Groups, subnets) — noting explicitly which elements map directly and which require you to look up Azure-specific mechanics you're not yet certain of.

19. Interview questions

• What genuinely transfers between AWS, Azure, and GCP for an AI system's architecture, and what doesn't?
• Why is IAM/identity the area most likely to require genuine new research when moving to a different cloud, rather than simple renaming?
• When is cloud-native optimization the right choice over multi-cloud portability, and when is the reverse true?
• Why shouldn't you build for hypothetical multi-cloud portability by default?

20. FDE/customer scenario

A customer says: "We're on Azure, not AWS — can you still build this the same way?" A strong response confirms yes, at the conceptual level (every principle in 18.1–18.19 transfers), while being explicit that specific mechanics — especially identity/IAM — need genuine, provider-specific verification rather than being assumed equivalent, and that the resulting architecture will use AKS/Azure Database/Entra ID as direct analogues of this track's EKS/RDS/IAM choices, not a compromised or lesser version of the same design.

---

Key takeaways

• This track's CONCEPTS (least privilege, network segmentation, idempotent queues, circuit breakers, bottleneck-first scaling) are provider-agnostic; only their SPECIFIC IMPLEMENTATION changes per cloud.
• IAM/identity mechanics diverge the most across providers and need genuine, provider-specific research — not confident translation from AWS familiarity alone.
• Cloud-native optimization (embracing a chosen provider's managed services) is the right default; multi-cloud portability is a deliberate, requirement-driven choice, not a default engineering posture.

Things you should be able to explain

• Which AWS services map most cleanly to Azure/GCP equivalents, and which diverge meaningfully in mechanics, not just naming.
• The portability-vs-cloud-native-optimization trade-off.

Things you should be able to build

• A provider-comparison decision memo for a customer's specific cloud-platform constraint.
• A conceptual (not necessarily syntactically complete) translation of this track's VPC/IAM design to a different cloud provider's terminology.

Common mistakes

• Assuming IAM/security-group mechanics translate directly by name similarity between providers.
• Building unnecessary cloud-agnostic abstraction with no real multi-cloud requirement.
• Assuming GPU/self-hosting economics transfer numerically across providers.

Recommended next chapter

21-production-incidents-playbook.md