3.1 Network Architecture Design
Networking is the hardest enterprise-onboarding decision to walk back later. Get an IAM role wrong and you fix it with a one-line binding change; get the network architecture wrong and you're typically re-planning CIDR ranges and firewall rules across every workload already running, possibly scheduling a midnight cutover to re-segment the network. Follow Google's own network design guide and its decision framework — think it through before you touch anything, rather than standing up a VPC first and figuring it out later.
Google documents 4 network topologies for enterprise deployments, ordered by how much autonomy teams get versus how centralised control is:
| Option | Approach | Best fit |
|---|---|---|
| Option 1: One Shared VPC per environment (Google's own default recommendation for most cases) | The host project centrally manages the network; service projects attach to share it | You want centralised control over firewalls/routing and a simple, maintainable architecture |
| Option 2: Hub-and-spoke with a centralised network appliance (NVA) | The hub VPC runs a third-party firewall appliance; spoke-to-spoke traffic routes through the hub | Compliance requires Layer‑7 inspection, or you're locked into an existing NVA vendor contract |
| Option 3: Hub-and-spoke without an appliance | The hub only carries shared on-premises connectivity; environments stay isolated from one another | You want environments kept independent while still sharing one leased line/VPN |
| Option 4: Private Service Connect producer/consumer model | Every VPC is fully independent, exposing only specific services via PSC endpoints | Teams need full autonomy, with services communicating only through explicitly defined endpoints |
Unless you have a specific reason not to, just pick Option 1. Most rollouts aren't special enough to need anything else — start with the simplest option, the one Google itself says fits "most cases", rather than designing for maximum complexity from day one. Complex architecture should solve a problem you've actually hit, not prove how well the team understands the cloud.
If environments do need to talk to each other (Options 2/3), there are three actual mechanisms for the hub-and-spoke connectivity itself, each with its own trade-offs:
| Mechanism | Bandwidth | Spoke-to-spoke (transitive)? | Notes |
|---|---|---|---|
| Network Connectivity Center (NCC) | Full bandwidth | Yes | Google's current recommended approach; supports star and mesh topologies |
| VPC Network Peering | Full bandwidth | No (non-transitive) | Subject to peering connection limits — you'll hit quota at scale |
| Cloud VPN | Limited by tunnel bandwidth | Yes | Insufficient bandwidth can be addressed by stacking tunnels, but complexity and cost stack up with it |
The actual Shared VPC + hierarchical firewall policy Terraform lives in the network-design/ sub-project.