Network topology is an authority model

Google Cloud’s landing-zone guidance reduces the decision to a small set of architectural questions: whether Layer 7 inspection is required, how much hybrid connectivity exists, whether workloads can communicate through private producer-consumer endpoints, and whether routing and firewall policy should be centrally administered.

Those questions are more durable than choosing a diagram by familiarity. They expose the organisation’s operating model before the VPC layout is selected.

For most use cases, the source recommends a separate Shared VPC for each deployment environment. Network resources and IP space can be managed centrally while development, testing and production remain isolated.

The model works when central firewalling, routing and simple scalable infrastructure are priorities. It is less suitable when teams need complete networking autonomy or when mandatory Layer 7 inspection requires central appliances.

A hub-and-spoke design with next-generation firewall appliances routes workload, internet or on-premises traffic through inspection infrastructure. That adds operational and routing complexity, so the source ties it to explicit Layer 7 inspection or mandated appliance requirements.

Inspection is therefore the reason for the topology, not a decorative enterprise pattern. Without that requirement, the additional transit layer may be unnecessary.

In the non-appliance hub-and-spoke option, spokes share on-premises connectivity through a hub while remaining unable to communicate transitively through VPC peering. Teams can manage their own firewall and routing rules.

This topology is useful when workloads should remain internally isolated and teams need autonomy. It is a poor fit when central routing policy or east-west Layer 7 inspection is required.

The producer-consumer pattern gives workloads independent VPCs and exposes required services through Private Service Connect. It fits environments where teams manage their own address space and policy but cross-workload communication can be reduced to defined endpoints.

This is a strong boundary when interfaces are stable. It becomes awkward when services rely on many changing ports or communication patterns that do not fit the supported endpoint model.

The guidance explicitly allows combinations: Shared VPC can participate in hub-and-spoke structures, while selected workloads can be isolated and exposed only through Private Service Connect. Architecture does not become purer by forcing every workload into one pattern.

Whichever topology is selected, the source recommends custom-mode networks, reduced public IP use, controlled NAT, redundant hybrid connectivity where required, organisation policies, hierarchical firewalls and sound DNS practice.

Primary source: Google Cloud Architecture Center, “Decide the network design for your Google Cloud landing zone”. Canonical source: https://docs.cloud.google.com/architecture/landing-zones/decide-network-design . Source capture reviewed 7 August 2026.

This note preserves the source’s four network options and their stated selection criteria, while interpreting topology as an organisational authority and isolation decision.