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. Both used the same Terraform patterns and naming conventions, and the same person wrote both. The cause was an assumption: that a VPC means the same thing everywhere.

Compute, storage, and even identity mostly line up across providers once you learn the vocabulary. Network topology diverges in architecture as well as naming, and that difference decides how much operational cost a 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 differs, because the primitive itself changes shape from one provider to the next.

AWS gives you a VPC that is 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 will 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 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 is a different console, a different API, and a different mental model to hold in your head during an incident.

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. The abstraction is 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 is not 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 DNS Private Resolver handles bidirectional hybrid resolution without additional appliances. On AWS, Route 53 Resolver with inbound and outbound endpoints covers the same use case, but requires more explicit configuration for split-horizon scenarios. GCP Cloud DNS and Alibaba require more manual setup for equivalent hybrid topologies. If your organisation runs hybrid infrastructure and DNS resolution across providers, do not assume parity. Test the resolution paths before an incident relies on them.

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. A more permissive default on one provider is no reason to accept a public endpoint on any of the four.

Abstract where the concept is shared but the implementation differs enough that the shared layer should be an interface. 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. The platform team works with one model while the state underneath stays provider-specific.

Accept divergence where standardising costs more than the inconsistency it removes. If you are 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 have not used before:

  • Confirm whether the provider's VPC model is regional or global, and redraw the peering and connectivity diagram from scratch for that model
  • Identify the provider's actual mechanism for cross-account or cross-project traffic, and whether it matches the hub-and-spoke pattern you have standardised on elsewhere
  • Test private connectivity to managed services explicitly. A PrivateLink-equivalent is usually not the default path
  • 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 an incident depends on it

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.