Multicloud Network Design Fundamentals
Last reviewed: August 2026
Why Inter-Cloud Networking Matters
Section titled “Why Inter-Cloud Networking Matters”The first technical challenge encountered in a multicloud environment is: “how does a workload in Cloud A communicate with a workload in Cloud B?” Within a single vendor, this is simply solved with VPC peering or a private link, but once you cross vendor boundaries, network design, cost, and security all become more complex.
CIDR Planning — Preventing IP Conflicts
Section titled “CIDR Planning — Preventing IP Conflicts”The first rule of multicloud: no VPC/VNet CIDR across any cloud should overlap.
If IPs overlap, routing becomes impossible, and changing it later requires redeploying workloads. Plan the entire IP space from the start.
Splitting Principles
Section titled “Splitting Principles”What matters in CIDR splitting is not a rule that assigns a specific range to a specific vendor, but the following principles.
- No overlap — Divide the entire IP space up front so that no range across any cloud or on-premises environment overlaps.
- Room to grow — Leave generous blocks per area, accounting for growth in regions, environments (prod/dev), and workloads.
- Include on-premises — If you have (or plan) hybrid connectivity, include on-premises ranges in the plan too.
- Consistent sizing — For example, assigning a
/16per vendor and splitting into/24subnets within it keeps management and expansion simple.
Divide the RFC 1918 private ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) according to the principles above. The table below is just one possible layout — which range goes to which vendor is up to your organization.
| Range (example) | Layout (example) | Sub-split (example) |
|---|---|---|
10.0.0.0/8 |
Vendor A | 10.0.0.0/16 (prod), 10.1.0.0/16 (dev) |
172.16.0.0/12 |
Vendor B | 172.16.0.0/16 (prod), 172.17.0.0/16 (dev) |
192.168.0.0/16 |
Vendor C / other | 192.168.0.0/20, 192.168.16.0/20 |
Cautions
Section titled “Cautions”- Since a Google Cloud VPC is global, only the per-region subnets need to differ
- An Azure VNet is regional, so a separate CIDR must be allocated per region
Inter-Cloud Connection Methods
Section titled “Inter-Cloud Connection Methods”Site-to-Site VPN
Section titled “Site-to-Site VPN”The fastest way to get started. Builds an IPsec tunnel over the internet.
| Item | AWS | Azure | Google Cloud | OCI |
|---|---|---|---|---|
| Service name | Site-to-Site VPN | VPN Gateway | Cloud VPN | Site-to-Site VPN |
| Max bandwidth | 1.25 Gbps (per tunnel) | 10 Gbps (VpnGw5) | 3 Gbps (HA VPN) | 250 Mbps (per tunnel) |
| HA configuration | 2 tunnels provided by default | Active-Active mode | HA VPN (99.99% SLA) | Redundant tunnels recommended |
| Cost (example) | ~$0.05/h + egress | ~$0.19/h (VpnGw1) | ~$0.075/h + egress | Hourly billing + egress. Varies by region |
The figures above are as of the time of writing and are subject to change. Check each vendor’s official pricing for the latest figures.
Example AWS ↔ Google Cloud connection:
- On AWS, create a Customer Gateway (Google Cloud’s external IP) + VPN Connection
- On Google Cloud, create an External VPN Gateway (AWS’s external IP) + HA VPN tunnel
- Exchange routes via BGP (AWS ASN: 64512, Google Cloud ASN: 65001, etc.)
Dedicated Connection (Dedicated Interconnect)
Section titled “Dedicated Connection (Dedicated Interconnect)”A connection over a dedicated physical circuit. Low latency and high bandwidth, but installation takes several weeks.
| Item | AWS | Azure | Google Cloud | OCI |
|---|---|---|---|---|
| Service name | Direct Connect | ExpressRoute | Cloud Interconnect | FastConnect |
| Max bandwidth | 100 Gbps | 100 Gbps | 200 Gbps | 100 Gbps |
| PoP | Vendor IX/colocation. See country guides | Same | Same | Same |
| Minimum commitment | None (billed hourly per port) | None to 1 year | None | None (billed hourly per port) |
| Egress discount | ~50% discount vs. standard | Unlimited egress included | Discount vs. standard | 10TB/month egress free |
The figures above are as of the time of writing and are subject to change. Check each vendor’s official pricing for the latest figures.
Cloud Exchange (Megaport, Equinix Fabric)
Section titled “Cloud Exchange (Megaport, Equinix Fabric)”A Cloud Exchange is a service that lets you connect to multiple clouds simultaneously through a single physical connection. It’s the most efficient connection method in a multicloud environment.
graph LR
AWS[AWS DX] --> IX[Cloud Exchange · IX]
Azure[Azure ER] --> IX
GCP[Google Cloud CI] --> IX
OCI[OCI FC] --> IX
Cloud Exchange options (global):
- Megaport, Equinix Fabric — PoPs in many regions. Check country guides for whether a local PoP exists in the target country
- Country-specific IXes (e.g., KINX in Korea) are covered in country guides such as Korea
Connection Method Selection Guide
Section titled “Connection Method Selection Guide”| Criterion | Site-to-Site VPN | Dedicated connection (DX/ER/CI/FC) | Cloud Exchange |
|---|---|---|---|
| Bandwidth | ~1 Gbps | 10-100 Gbps | 1-10 Gbps |
| Latency | Via internet (variable) | Dedicated circuit (stable) | Dedicated circuit (stable) |
| Build time | Minutes to hours | Weeks to months | Days to weeks |
| Initial cost | Low | High (port fee, circuit fee) | Medium |
| Monthly data transfer volume | < 1TB | > 5TB | 1-5TB |
| Connection target | 1:1 (2 clouds) | 1:1 | 1:N (multiple clouds simultaneously) |
| Suitable for | PoC, small scale, quick start | Large volume, high reliability required, production | Connecting 3+ clouds, flexibility |
Design Checklist
Section titled “Design Checklist”- Do the CIDRs of every cloud/on-premises environment avoid overlap?
- Was the connection method (VPN vs. dedicated connection vs. Cloud Exchange) chosen based on bandwidth/cost?
- Was the egress cost estimated on a monthly basis?
- Is cross-cloud name resolution possible via DNS conditional forwarding?
- Is there an alternate path (failover) for a hub failure?
- Do security group/firewall rules allow inter-cloud traffic?
Common Mistakes
Section titled “Common Mistakes”- Using the default VPC in each cloud without CIDR planning — Overlapping IP ranges make connectivity impossible later. Plan the entire IP space by vendor from the start.
- Using the VPN from a PoC directly in production — Insufficient bandwidth and variable internet-path latency cause incidents. Consider a dedicated connection for over 1TB/month.
- Not allowing inter-cloud traffic in security groups/firewalls — Even with a VPN/dedicated connection configured, communication fails without firewall rules on both sides.
Related Documents
Section titled “Related Documents”Transit architecture patterns, a detailed egress cost comparison, and DNS integration strategy are covered in the following document.
References
Section titled “References”Google Cloud
Section titled “Google Cloud”Standards & Interconnect
Section titled “Standards & Interconnect”- RFC 1918 — Address Allocation for Private Internets
- Megaport — global Cloud Exchange
- Equinix Fabric — global Cloud Exchange. See country guides for local IXes