Implementing a landing zone: policy before workloads

Google Cloud’s implementation guidance recommends limiting direct internet access to resources that need it. Private Google Access can let resources without external addresses reach supported Google services, while organisation policies can prevent categories of resources from acquiring unintended public exposure.

The underlying principle is default posture. Instead of reviewing every new workload for accidental public addresses, make external reachability an explicit exception.

• Restrict external protocol forwarding
• Constrain external IP use on virtual machines
• Disable external IPv6 where it is not required
• Disable automatic default-network creation

The source recommends least-privilege or microsegmentation: block traffic by default and allow only required protocols and ports. Hierarchical firewall policies provide organisation- and folder-level controls, while network firewall policies operate at the VPC layer.

Rule logging and a deliberate priority-numbering scheme make the policy operable during normal changes and incidents. Specific rules should take precedence over broad ones, and reserved priority ranges can preserve space for emergency response.

The implementation guide covers Shared VPC per environment, hub-and-spoke with central appliances, hub-and-spoke without appliances and a Private Service Connect producer-consumer model. Each option changes how subnets, transit, workload projects and service endpoints are assembled.

The common baseline remains recognisable: restrict public exposure, define firewall policy, configure the VPC structure, establish hybrid connectivity if needed, provide controlled outbound access and verify the resulting network.

Cloud NAT supports internet-bound traffic for resources that should not carry public addresses. Cloud Interconnect or VPN provides hybrid connectivity according to availability, bandwidth and operational requirements.

These mechanisms should be treated as governed paths rather than general escape hatches. Routes, DNS, firewall policy and failure modes need to agree across cloud and on-premises boundaries.

The guide closes each topology with observability. Network Intelligence Center, Connectivity Tests and Firewall Insights are used to monitor, troubleshoot and verify that the implemented paths behave as designed.

This is an important implementation rule: configuration is not proof. A landing zone should carry enough logging and testability to demonstrate that permitted paths work and prohibited paths remain blocked.

Development, staging and production environments should inherit the same architectural controls even when their workloads differ. Repeating a governed network pattern reduces accidental drift and makes review easier because differences become explicit exceptions.

The implementation is complete when a new workload enters an environment whose network policy, connectivity and observability already exist—not when the first application team invents them.

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

This note focuses on the implementation controls repeated across the source’s four topology options rather than reproducing the provider-specific step-by-step configuration.