A team I worked with once spent three days debugging why their "identical" landing zone module worked perfectly on AWS and silently broke cross-region traffic on GCP. Same Terraform patterns, same naming conventions, same person writing both. The bug wasn't in the code. It was in an assumption: that a VPC means the same thing everywhere.

It doesn't. Compute, storage, even identity, they mostly rhyme across providers once you learn the vocabulary. Network topology doesn't rhyme. It diverges at the architecture level, not just the naming level, and that difference is what decides how much pain your team carries for years.

Why this control area is different

Most controls in a landing zone are policy decisions wearing different provider-native clothes. Identity is "federate to a central IdP," implemented differently per provider but conceptually identical everywhere. Network topology isn't like that, because the underlying primitive itself changes shape depending on where you're standing.

AWS gives you a VPC that's regional, with subnets tied to availability zones inside that region. Azure's VNet is also regional. GCP breaks the pattern entirely: a single VPC is global, spanning every region, with only the subnets scoped regionally. Alibaba Cloud lands closer to AWS's model, a regional VPC with a VSwitch per zone.

If you design your cross-region connectivity strategy assuming AWS's regional-VPC mental model and then extend it to a GCP environment without checking, you'll build unnecessary peering relationships for a problem GCP's architecture already solved by default.

Diagram comparing AWS, Azure, GCP, and Alibaba Cloud VPC models: regional versus global scope, and where subnets attach
Figure 1. Same word, four different shapes. GCP's global VPC is the outlier that breaks assumptions carried over from AWS or Alibaba.

Where teams actually get hurt

Cross-account and cross-region connectivity is where the real cost shows up. AWS's answer is Transit Gateway, a hub-and-spoke model, or direct VPC peering for simple pairs. Azure offers Virtual WAN or VNet peering routed through an Azure Firewall hub. GCP uses Shared VPC with host and service projects, plus peering for cross-project cases. Alibaba's Cloud Enterprise Network with a Transit Router is functionally the closest analog to AWS's TGW, but it's a different console, a different API, and a different mental model to hold in your head during an incident.

The good news: hub-and-spoke as a pattern is universal. You can standardise on the shape of the topology even when the implementation is entirely provider-native. That's the abstraction layer worth investing in, not a shared API, but a shared architectural diagram that every provider's implementation has to satisfy.

Egress control is the second place this bites. NAT Gateway plus Security Groups gets you basic AWS egress; deep packet inspection needs AWS Network Firewall on top. Azure's answer is more opinionated out of the box, an Azure Firewall sitting in a hub VNet with User Defined Routes forcing traffic through it. GCP requires you to bring your own network virtual appliance, or Secure Web Proxy for HTTP(S)-specific egress filtering. It isn't handed to you by default the way Azure hands it to you. If your security team assumes "the platform enforces L7 egress inspection" as a baseline, that assumption is true on Azure and false by default on GCP.

DNS is the quiet one. Every provider has private hosted zones for internal resolution, and every provider has some hybrid-DNS story for resolving on-prem and cloud names together. Azure's Private DNS Resolver is the most feature-complete of the four for genuinely complex hybrid setups. If your organisation runs hybrid infrastructure and DNS resolution across providers, don't assume parity here, test the actual resolution paths before you rely on them during an incident.

The standardise, abstract, diverge decision

I use three buckets when deciding how to handle a given network control across providers, and network topology forces you to use all three more than any other area.

Standardise where the underlying concept and the implementation are both close enough that divergence is pure risk with no benefit. Private service access for managed services is a good example. Every provider now has a PrivateLink-equivalent (PrivateLink itself on AWS, Private Endpoints on Azure, Private Service Connect on GCP, PrivateLink on Alibaba). Policy every managed service to go through it in production. There's no reason to accept a public endpoint on any of the four just because that provider's default is more permissive.

Abstract where the concept is shared but the implementation is genuinely different enough that a shared interface, not a shared implementation, is the right layer. Cross-account connectivity fits here. Build your Terraform module interface around "spoke connects to hub," and let the module implement that contract using Transit Gateway, Virtual WAN, Shared VPC, or CEN Transit Router underneath. Your platform team reasons in one mental model. Your Terraform state reasons in four.

Accept divergence where standardising costs more than the inconsistency it removes. If you're a small team on two providers, forcing identical VPC CIDR planning conventions across AWS's regional model and GCP's global model is often not worth the friction, at least not yet. Revisit this once team size, incident frequency, or a compliance review makes the divergence expensive rather than annoying.

Decision tree showing when to standardise, abstract, or accept divergence for a network control
Figure 2. The same three-way split that governs every control area, applied specifically to network topology.

What to check before you extend to a new provider

A short list I run through before any team stands up infrastructure on a provider they haven't used before:

  • Confirm whether the provider's VPC model is regional or global, and re-draw your peering and connectivity diagram accordingly, don't reuse the last provider's diagram with names swapped
  • Identify the provider's actual mechanism for cross-account or cross-project traffic, and whether it matches the hub-and-spoke pattern you've standardised on elsewhere
  • Test private connectivity to managed services explicitly, don't assume a PrivateLink-equivalent is the default path, it usually isn't
  • Verify what Layer 7 inspection requires on that specific provider, since "the firewall does it" is true on some providers and false on others
  • Walk through DNS resolution end to end for both directions of hybrid traffic before depending on it during an incident, not after

None of this requires exotic tooling. It requires treating network topology as its own decision, not a rounding error on top of your compute and identity decisions.

I built a multi-cloud control comparison matrix that covers this in more depth, filterable by area, with the network topology row set kept current on a quarterly review. It pairs with the decision wizard if you want a recommendation specific to your provider count and team size, and this note supports Security & governance.