Most enterprises don't choose one cloud — they inherit two. Here's the reference architecture we deploy for clients running serious workloads across AWS and Azure with on-premises data centers still in the mix.
The Core Building Blocks
On AWS, Transit Gateway (TGW) is the regional router: VPCs attach to it, route tables on the TGW segment traffic, and VPN or Direct Connect attachments bring in the on-prem world. On Azure, Virtual WAN (vWAN) plays the same role with hubs per region, VNet connections and ExpressRoute/VPN gateways integrated into the hub.
Route-Domain Isolation with BGP
The most common failure mode in hybrid designs is a flat routing domain where everything can reach everything. Instead, define route domains: production, non-production, shared services and on-prem. On TGW, that means separate route tables with explicit propagations. On vWAN, use custom route tables with labels.
BGP communities are your friend. Tag routes at the edge — for example 65000:100 for prod, 65000:200 for non-prod — and filter on communities at every boundary. This keeps intent visible and auditable.
Connecting the Two Clouds
You have three options: IPSec over the internet (cheap, 1.25 Gbps per tunnel with ECMP scaling), a cloud interconnect provider like Megaport or Equinix (predictable latency, private), or a hairpin through your on-prem DC (simple but adds latency). For most enterprises the interconnect provider wins on economics once you cross ~2 Gbps sustained.
Inspection Points
Decide deliberately where traffic is inspected. The clean pattern: a security VPC/VNet per cloud with a firewall cluster (Palo Alto VM-Series or Azure Firewall), and TGW/vWAN route tables steering inter-domain traffic through it. Never inspect twice for the same flow.
Key Takeaways
Keep one routing philosophy across both clouds, isolate route domains with BGP, and document your inspection matrix. The tooling differs; the network engineering doesn't.