multi-cloud-networking-patterns

Multi-Cloud Networking Patterns

Purpose

Network design decisions made when the first VPC/VNet is created are among the hardest to unwind later — overlapping CIDR blocks block future peering, a flat network with no segmentation makes blast-radius containment impossible, and ad hoc point-to-point VPN connections become an unmanageable mesh as account/subscription/project count grows. This skill defines the hub-and-spoke (or transit) topology pattern that scales across AWS, Azure, and GCP, the IP address management (IPAM) discipline that prevents collisions, and the connectivity options (VPN, dedicated interconnects, private endpoints) for both intra-cloud and cross-cloud traffic — so networking is a deliberate, centrally managed layer rather than an emergent mess of one-off peering connections.

When to use

• Designing the network topology for a new landing zone (paired with the relevant *-landing-zone-setup skill).
• Connecting a new spoke VPC/VNet/project-VPC to existing shared network infrastructure.
• Planning IP address ranges across accounts/subscriptions/projects before any are created, to avoid future collisions.
• Setting up a site-to-site VPN or dedicated connection (AWS Direct Connect, Azure ExpressRoute, GCP Cloud Interconnect) to on-premises.
• Connecting workloads across cloud providers (e.g. an AWS-hosted service calling a GCP-hosted data warehouse privately).
• Replacing public-endpoint access to managed services (databases, storage, message queues) with private connectivity.
• Diagnosing "why can't service A reach service B" across account/ subscription/project or VPC/VNet boundaries.

Prerequisites & environment

• The relevant landing zone (AWS Organizations/Control Tower, Azure Management Groups, or GCP folders) already exists, since network hub placement follows the account/subscription/project structure — see the three *-landing-zone-setup skills.
• Terraform ≥ 1.5 with the relevant provider(s) if managing network infrastructure as code; for cross-cloud Terraform, expect to run multiple provider blocks (aws, azurerm, google) in the same or linked configurations.
• A single source of truth for IP address allocation before any VPC/VNet is created — a spreadsheet-as-code, AWS VPC IPAM, Azure Virtual Network Manager IPAM, or a third-party tool (e.g. phpIPAM, NetBox) for anything beyond a handful of networks.
• Decide the connectivity model up front: hub-and-spoke (single hub per region handles all shared connectivity/inspection) vs. full transit (AWS Transit Gateway / Azure Virtual WAN / GCP Network Connectivity Center) for topologies spanning many regions or requiring dynamic routing at scale.
• For cross-cloud connectivity: an understanding of which side initiates the VPN (each cloud's VPN gateway has different BGP ASN defaults and quirks — confirm compatible IKE/IPsec parameters before provisioning).