terraform/modules/multi-cloud-network/main.tf

e.

Step 2: Implement Federated Identity & Centralized Policy

Avoid per-cloud IAM silos. Use a central identity provider (OIDC/SAML) with cross-cloud federation. Enforce policy-as-code at the control plane level, then translate policies to native IAM/ABAC constructs during deployment.

Step 3: Design Network Topology

Choose between:

• Hub-and-spoke peering: Central transit VPC/VNet connects to provider-specific spokes. Best for moderate cross-cloud traffic.
• SD-WAN overlay: Vendor-agnostic routing with dynamic path selection. Best for global latency optimization.
• Direct peering + global load balancing: Use provider-native global load balancers with health-based routing. Best for stateless, latency-sensitive APIs.

Step 4: Standardize State & IaC Execution

Fragmented Terraform/CDK state causes drift. Use a remote backend with workspace isolation per cloud, but maintain a single source of truth for topology definitions. Implement automated drift detection and plan approval gates.

Step 5: Implement Cross-Cloud Observability & SLO Routing

Aggregate logs, metrics, and traces into a centralized observability stack. Use synthetic probes to measure cross-cloud latency. Route traffic based on real-time SLO compliance, not static DNS.

Architecture Decision: TypeScript Abstraction with Native Delegation

Rather than forcing a lowest-common-denominator abstraction, define a consistent interface that delegates to cloud-native providers. This pattern preserves developer ergonomics while enabling provider-specific optimizations.

// multi-cloud/src/infrastructure/routing.ts
import * as aws from "@pulumi/aws";
import * as azure from "@pulumi/azure-native";
import * as gcp from "@pulumi/gcp";

export interface CloudProvider {
  name: "aws" | "azure" | "gcp";
  region: string;
  createGlobalRouter(config: RouterConfig): Promise<RouterEndpoint>;
}

export interface RouterConfig {
  primaryEndpoint: string;
  failoverEndpoint: string;
  healthCheckInterval: number;
  latencyThresholdMs: number;
}

export interface RouterEndpoint {
  dnsName: string;
  provider: string;
  status: "active" | "standby";
}

export class MultiCloudRouter {
  private providers: Map<string, CloudProvider>;

  constructor() {
    this.providers = new Map([
      ["aws", new AWSRouter()],
      ["azure", new AzureRouter()],
      ["gcp", new GCPRouter()],
    ]);
  }

  async deploy(config: RouterConfig): Promise<RouterEndpoint[]> {
    const endpoints: RouterEndpoint[] = [];

    for (const [name, provider] of this.providers) {
      const endpoint = await provider.createGlobalRouter({
        ...config,
        region: this.resolveRegion(name),
      });
      endpoints.push(endpoint);
    }

    return endpoints;
  }

  private resolveRegion(provider: string): string {
    const regionMap: Record<string, string> = {
      aws: "us-east-1",
      azure: "eastus",
      gcp: "us-central1",
    };
    return regionMap[provider] ?? "us-east-1";
  }
}

class AWSRouter implements CloudProvider {
  name = "aws" as const;
  region = "us-east-1";

  async createGlobalRouter(config: RouterConfig): Promise<RouterEndpoint> {
    const healthCheck = new aws.route53.HealthCheck("aws-health", {
      fqdn: config.primaryEndpoint,
      port: 443,
      type: "HTTPS",
      requestInterval: config.healthCheckInterval,
    });

    const record = new aws.route53.Record("aws-routing", {
      zoneId: "Z123456789",
      name: "app.example.com",
      type: "A",
      setIdentifier: "aws-primary",
      failoverRoutingPolicy: { type: "PRIMARY" },
      ttl: 60,
      records: [config.primaryEndpoint],
    });

    return {
      dnsName: record.fqdn,
      provider: "aws",
      status: "active",
    };
  }
}

// Azure and GCP implementations follow the same contract,
// delegating to Azure Traffic Manager and GCP Cloud DNS/Load Balancing.
// This ensures native performance while maintaining a unified deployment interface.

Rationale: The interface enforces consistency, but each provider implements routing using native services. This avoids the latency and cost penalties of running a generic proxy layer while keeping CI/CD pipelines unified. State remains provider-scoped, but topology is defined once.

Pitfall Guide

1. The "One Abstraction to Rule Them All" Fallacy

Attempting to abstract every cloud service behind a custom SDK or Kubernetes CRD creates version drift, incomplete coverage, and hidden performance penalties. Provider APIs evolve independently. Abstraction layers become maintenance liabilities. Best Practice: Abstract only the control plane (deployment, policy, observability). Let the data plane use native services. Define clear boundaries where abstraction stops and cloud-native routing begins.

2. Ignoring Cross-Cloud Egress Pricing

Data transfer between clouds is rarely free. Egress fees compound quickly with replication, backup sync, and API cross-calling. Teams often design architectures that assume seamless, cost-free inter-cloud communication. Best Practice: Map data flows explicitly. Cache aggressively at edges. Use cloud-native replication only for compliance-critical data. Implement egress budgeting in CI/CD gates.

3. Fragmented Identity & Entitlement Management

Per-cloud IAM silos create policy drift, audit gaps, and privilege escalation risks. Cross-cloud service-to-service authentication becomes a maintenance nightmare. Best Practice: Federate all clouds to a central OIDC provider. Use workload identity federation (e.g., AWS STS, Azure Managed Identity, GCP Workload Identity). Enforce least privilege via policy-as-code (OPA/Conftest) applied before deployment.

4. Data Sovereignty & Replication Lag Blind Spots

Multi-cloud data strategies often ignore regulatory boundaries (GDPR, CCPA, sector-specific mandates) and replication latency. Asynchronous cross-cloud replication can cause stale reads or compliance violations. Best Practice: Tag resources with data classification labels. Enforce placement policies at the IaC level. Use synchronous replication only within compliance zones. Document RPO/RTO per dataset and validate during disaster recovery drills.

5. IaC State Fragmentation

Running separate Terraform workspaces or CDK stacks per cloud without a unified topology map causes drift, resource collisions, and deployment failures. State files become disconnected from actual runtime topology. Best Practice: Use a remote backend with strict workspace isolation. Maintain a single source of truth (YAML/JSON) for cross-cloud dependencies. Implement automated plan validation and drift detection in the CI pipeline.

6. Observability Silos

Logging, metrics, and tracing remain trapped in provider ecosystems. Cross-cloud troubleshooting requires manual correlation, delaying incident response. Best Practice: Deploy a centralized observability stack (OpenTelemetry collectors, Prometheus/Grafana, or commercial SaaS). Standardize span contexts across clouds. Use synthetic monitoring to validate cross-cloud SLOs continuously.

7. Ignoring Provider-Specific Optimizations

Treating all clouds as interchangeable leads to suboptimal resource selection. AWS Graviton, Azure Confidential Computing, and GCP Preemptible VMs offer distinct cost/performance profiles that abstraction layers often mask. Best Practice: Profile workloads per provider. Use instance right-sizing automation. Allow IaC templates to accept provider-specific overrides for compute, storage, and networking tiers.

Production Bundle

Action Checklist

• Map control plane vs. data plane boundaries: centralize deployment, policy, and identity; delegate execution to native clouds.
• Implement workload identity federation: use OIDC/SAML with cloud-native STS/Managed Identity to eliminate static credentials.
• Define explicit network routing: choose hub-and-spoke, SD-WAN, or global load balancing based on traffic volume and latency requirements.
• Standardize IaC state management: isolate workspaces, centralize topology definitions, and enable automated drift detection.
• Enforce data placement policies: tag resources with compliance labels and validate placement during plan execution.
• Deploy centralized observability: standardize OpenTelemetry instrumentation, aggregate metrics, and run synthetic cross-cloud probes.
• Establish egress cost controls: monitor cross-cloud data transfer, implement caching strategies, and set budget alerts per workload.

Decision Matrix

Scenario	Recommended Approach	Why	Cost Impact
Global SaaS with latency-sensitive APIs	Cloud-Native Federation + Global Load Balancing	Native routing minimizes hop count; GLB handles health-based failover without proxy overhead	Moderate (higher GLB fees, lower egress)
Compliance-heavy workloads (GDPR, HIPAA)	Hub-and-Spoke + Policy-as-Code Placement	Centralized control plane enforces data residency; spokes isolate regulated workloads	Higher upfront (transit gateways, policy engine), lower compliance risk
Cost-optimized batch processing	Unified Abstraction (K8s) + Spot/Preemptible Routing	Kubernetes scheduler optimizes across clouds for compute cost; spot/preemptible instances reduce baseline spend	Low to Moderate (scheduler complexity, spot interruption handling)
Legacy monolith migration	Cloud-Native Federation + Strangler Fig Pattern	Gradual decomposition avoids big-bang risk; native services handle stateful components efficiently	Higher short-term (dual-run costs), lower long-term technical debt

Configuration Template

# terraform/modules/multi-cloud-network/main.tf
variable "cloud_provider" {
  type    = string
  default = "aws"
}

variable "vpc_cidr" {
  type    = string
  default = "10.0.0.0/16"
}

variable "peer_vpc_id" {
  type    = string
  default = ""
}

resource "aws_vpc" "main" {
  count              = var.cloud_provider == "aws" ? 1 : 0
  cidr_block         = var.vpc_cidr
  enable_dns_support = true
  enable_dns_hostnames = true
}

resource "aws_vpc_peering_connection" "cross_cloud" {
  count     = var.cloud_provider == "aws" && var.peer_vpc_id != "" ? 1 : 0
  vpc_id    = aws_vpc.main[0].id
  peer_vpc_id = var.peer_vpc_id
  auto_accept = true
}

resource "aws_route" "cross_cloud_route" {
  count                  = var.cloud_provider == "aws" ? 1 : 0
  route_table_id         = aws_vpc.main[0].main_route_table_id
  destination_cidr_block = "10.1.0.0/16" # Azure VNet CIDR
  vpc_peering_connection_id = aws_vpc_peering_connection.cross_cloud[0].id
}

# Azure equivalent uses azurerm_virtual_network_peering with identical logic.
# GCP uses google_compute_network_peering.
# Topology definition remains centralized; provider-specific resources deploy via workspace isolation.

Quick Start Guide

1. Initialize provider workspaces: Run terraform workspace new aws, terraform workspace new azure, terraform workspace new gcp. Configure remote backends per workspace with identical state schema.
2. Define topology manifest: Create topology.yaml specifying VPC/CIDR ranges, peering relationships, and identity federation endpoints. Validate with terraform validate in each workspace.
3. Deploy networking: Execute terraform apply -workspace=aws, then repeat for other clouds. Verify peering status and route propagation using ping or traceroute across subnets.
4. Federate identity: Configure your central IdP (Okta, Azure AD, or Keycloak) with OIDC client IDs for each cloud. Update IAM roles to trust the federation endpoints. Test with aws sts assume-role-with-web-identity or equivalent.
5. Enable observability: Deploy OpenTelemetry collector as a sidecar or daemonset. Configure exporters to your central monitoring stack. Run synthetic probes against app.example.com across regions to validate routing and latency SLOs.