Introduction to VPC Design and Hierarchy
In Google Cloud the Virtual Private Cloud is not just a network — it is a global, software-defined fabric that backs every Compute Engine instance, every GKE node, every Cloud Run direct-VPC egress connection, and every Cloud SQL private IP. The PCNE exam tests whether you can stretch that fabric across an organization without painting yourself into a corner six months later, when the team that built the original default VPC has moved on and three business units want to attach without renumbering. This study note walks through the choices the exam actually asks about: auto-mode versus custom-mode, subnet and CIDR planning, secondary ranges for Alias IP and GKE, MTU tuning, Shared VPC topology, Network Connectivity Center hub-and-spoke, multi-VPC trade-offs, quotas, and the organization policy constraints that prevent your day-one mistakes from becoming day-365 outages.
The Google Cloud Resource Hierarchy — Organization, Folders, Projects — wraps every VPC. Where you place the host project and which folder owns it determines who can attach, who can audit, and how billing rolls up. VPC design and hierarchy is therefore as much a governance topic as a routing topic.
白話文解釋（Plain English Explanation）
Networking abstractions are easier to remember when they are anchored to physical things you have already touched.
Think of a VPC as a private highway system
Most clouds give you a regional toll road that stops at the state line. Google's VPC is a global interstate. You plan one highway system, you pour subnets like off-ramps in each city, and a car (packet) entering in São Paulo can reach an exit in Singapore without leaving your asphalt. The Cloud Router is the traffic-control office that talks to outside highways over BGP. Auto-mode is the cookie-cutter highway the builder gives you for free with /20 ramps in every region; custom-mode is the highway you survey and pave yourself, sized to the trucks you actually plan to run. Most production teams want custom-mode for the same reason cities reject pre-fab highways that ignore local geography.
Think of Shared VPC as a shopping mall
A shopping mall has one landlord who owns the building, parking lot, plumbing, and electrical panel. Tenants — the food court, the bookstore, the gym — rent space and run their own businesses but plug into the landlord's infrastructure. In Shared VPC the host project is the landlord that owns the network, subnets, firewall rules, and Cloud Router. The service projects are tenants whose VMs and GKE clusters live in the landlord's subnets. One plumber (network admin) handles every leak; tenants cannot redraw the floor plan but they can decorate their own shop. That separation is why central network teams insist on Shared VPC instead of letting every product team build its own VPC and then peer them all together.
Think of NCC as an airport hub
Before hub-and-spoke airports, every flight needed a direct route from city A to city B, and the schedule looked like a spaghetti diagram. Hubs (think Atlanta or Doha) collapsed that mesh: spokes connect to the hub, the hub manages every transfer. Network Connectivity Center is the airport hub for site-to-cloud and cloud-to-cloud traffic. Your VPCs, VPN tunnels, and Interconnect attachments become spokes. The hub coordinates the transfers so you do not have to build a full mesh of peerings, count peering quotas, or audit a thousand bilateral routes. When the exam asks how to connect 30 VPCs across 4 regions without melting under quotas, the answer is almost always NCC.
Core Concepts of VPC Design and Hierarchy
A VPC design and hierarchy on Google Cloud is built from a handful of primitives. The skill is composing them so the network survives reorganizations, mergers, and the inevitable second wave of GKE clusters.
Global VPC, regional subnets, zonal VMs
The VPC itself is a global resource — gcloud compute networks create prod-vpc --subnet-mode=custom creates one object that lives in every Google region simultaneously. Subnets are regional: gcloud compute networks subnets create web-use1 --network=prod-vpc --region=us-east1 --range=10.10.0.0/22. VMs and GKE node pools are zonal or regional consumers of those subnets. The exam loves to test whether you can articulate that a single VPC reaches all regions but that you still need a subnet per region for any region you want to use.
Auto-mode vs custom-mode
Auto-mode VPCs receive a /20 subnet in every Google region automatically, all carved out of the 10.128.0.0/9 reserved block. They are convenient for labs but dangerous for production: the ranges overlap with common on-prem blocks, you cannot resize them, and every new Google region silently adds a subnet. Custom-mode VPCs start empty and require you to create each subnet explicitly. The organization policy compute.skipDefaultNetworkCreation prevents the implicit auto-mode default network from being created in new projects, and compute.restrictVpcPeering lets the platform team gate who can peer.
Subnets and the regional resource boundary
Every subnet has a primary IPv4 range, an optional secondary range list, an optional IPv6 range, and a region. Subnet ranges cannot overlap inside the same VPC. You can expand a primary range non-disruptively (gcloud compute networks subnets expand-ip-range), but you cannot shrink it, and you cannot move a subnet between regions. Private Google Access is a per-subnet toggle, not a per-VPC one — a detail the exam checks repeatedly.
Dynamic routing modes
A VPC's BGP scope is set by its dynamic routing mode. regional means a Cloud Router only advertises subnets in its own region and only learns routes for its own region. global means every Cloud Router advertises every subnet in the VPC, regardless of region, and the VPC accepts inbound BGP prefixes everywhere. Production hybrid designs almost always want global so a single Interconnect failure in us-east1 does not strand workloads in europe-west1. gcloud compute networks update prod-vpc --bgp-routing-mode=global is the switch.
CIDR Planning for the Long Game
CIDR planning is the part of VPC design and hierarchy that engineers regret skipping when the company doubles in size.
Reserve before you allocate
Treat your VPC like an IP allocator, not an IP consumer. Carve a supernet — for example 10.0.0.0/9 — and then sub-allocate per region, per environment, and per zone. A pragmatic layout reserves 10.0.0.0/12 for production us-east, 10.16.0.0/12 for production us-west, 10.32.0.0/12 for production europe-west, and so on, with a parallel 10.128.0.0/9 reserved for non-prod. The exam expects you to recognize when ranges collide and how to repair them without renumbering live workloads (spoiler: you cannot, so do this once).
Stay clear of Google-reserved ranges
169.254.0.0/16 (link-local), 192.168.0.0/16 and 172.16.0.0/12 (RFC1918 fragments commonly used on-prem), and Google's own load balancer ranges should be avoided for routable subnets. The Private Service Connect range, the 35.191.0.0/16 and 130.211.0.0/22 health check ranges, and the auto-mode 10.128.0.0/9 are not yours to use either — health checks must be allowed but never assigned to VMs.
Plan for VPN and Interconnect overlap
On-prem networks frequently sit on 10.0.0.0/8 or 192.168.0.0/16. If your new VPC overlaps even one /24 with the corporate office network, the HA VPN session will refuse to install a conflicting route. Pick VPC supernets that are documented in the corporate IPAM and treat them as immutable.
A Google Cloud VPC supports up to roughly 300 secondary ranges per subnet (default soft quota) and 100 subnets per region per VPC by default. These numbers are bigger than they look only until a single GKE cluster eats two secondary ranges (Pods + Services). Plan the CIDR map before you create the first cluster — renumbering a live GKE cluster is a rebuild.
Secondary Ranges, Alias IP, and GKE
Alias IP is the Google Cloud mechanism that lets one VM or GKE node own many additional IP addresses without a second NIC. Every alias address must live inside a subnet secondary range.
How secondary ranges work
A subnet declares a primary range (for the node's own NIC) and zero or more named secondary ranges. gcloud compute networks subnets create gke-use1 --range=10.10.0.0/22 --secondary-range=pods=10.20.0.0/16,services=10.30.0.0/20 produces a subnet where the NIC sits in 10.10.0.0/22, Pod IPs are drawn from 10.20.0.0/16, and Service ClusterIPs are drawn from 10.30.0.0/20. Each Pod gets a real routable IP — no overlay encapsulation — which is why VPC-native (Alias IP) is the default GKE networking mode.
Sizing Pod and Service ranges
GKE node pools default to 110 Pods per node, which means each node consumes a /24 slice of the Pods range. A 100-node cluster therefore needs 100 × /24 = /17 of headroom. Doubling for autoscaling is normal practice. Service ranges are smaller — /20 is comfortable for most clusters — but they cannot be expanded after the cluster is created, so plan for growth.
Discontiguous multi-Pod CIDR
Newer GKE versions support multiple non-contiguous Pod CIDRs per cluster, which rescues teams that did not pre-allocate enough address space. Adding --additional-pod-ipv4-ranges lets you bolt on a second secondary range without rebuilding the cluster — a workaround the exam may hint at when the scenario starts with "we ran out of Pod IPs."
A subnet's secondary ranges count against per-VPC and per-project quotas, and they cannot overlap any primary or secondary range in the same VPC. Teams that "reuse" the same 10.20.0.0/16 across two regional subnets discover at peering time that the second range silently failed to import. Always allocate distinct, non-overlapping secondaries even if no peering is planned today.
MTU: 1460, 1500, and 8896
MTU is the most overlooked knob in VPC design and hierarchy, and the only one that can cut Dataflow shuffle throughput in half.
The three valid VPC MTU values
A Google Cloud VPC accepts three MTU values: 1460 (legacy default), 1500 (standard Ethernet, default for new VPCs since 2021), and 8896 (jumbo frames). gcloud compute networks update prod-vpc --mtu=8896 switches it, but the change only takes effect for VMs created or restarted after the change. Mixed-MTU VPCs are not supported — every subnet inherits the VPC-level MTU.
When jumbo frames pay off
Jumbo frames at 8896 reduce per-packet overhead for high-throughput east-west traffic — Dataflow shuffle, BigQuery export, Filestore Enterprise, GKE node-to-node Pod traffic. Throughput gains of 10–20% are routine when the workload is not already CPU-bound. Internet egress will fragment to 1500 at the edge, so jumbo frames are an internal optimization, not a WAN trick.
Interconnect and VPN MTU mismatches
A Dedicated Interconnect attachment supports 1440, 1460, 1500, or 8896 depending on configuration; HA VPN tops out at 1460 because of the IPSec overhead on top of an underlay that is itself only 1500. The classic failure mode is a VPC set to 8896 talking to on-prem over an HA VPN tunnel — TCP works because of PMTU discovery, but UDP-based workloads like DNS or game traffic see silent black-holing. Always set the VPC MTU to the smallest MTU on the hybrid path, or accept that you must clamp MSS on the egress side.
VPC MTU values: 1460 (legacy default), 1500 (current default), 8896 (jumbo). HA VPN ceiling: 1460. Dedicated Interconnect ceiling: 8896. PMTU discovery is enabled by default but requires ICMP "Fragmentation Needed" to traverse on-prem firewalls — a frequent break-fix scenario.
Shared VPC Topology Patterns
Shared VPC is the canonical way to give one network team central control while letting many product teams ship.
Host project and service projects
A Shared VPC host project owns the VPC, subnets, firewall rules, and Cloud Routers. Service projects are attached to the host with gcloud compute shared-vpc associated-projects add service-proj --host-project=host-proj. Users in service projects can create VMs, GKE clusters, internal load balancers, and Cloud SQL instances that consume subnets in the host project, but they cannot create new subnets, modify firewall rules, or change routes. The compute.networkUser role on a subnet is what grants a service-project user the right to use that specific subnet — not the entire VPC.
Single host vs multi-host
Most organizations need at least two host projects: one for production, one for non-production, sometimes a third for security/DMZ workloads. Inside each host you can still split by environment with subnet-level IAM. A common anti-pattern is collapsing everything into one host project to "simplify" — the moment you need an emergency firewall change for production while non-prod is mid-deployment, you discover why separate host projects exist.
Shared VPC vs VPC Peering
Peering connects two VPCs at the routing layer but each project still owns its own VPC, with its own firewall surface and quota footprint. Shared VPC collapses governance into one VPC. The exam likes scenarios where the right answer is "Shared VPC — peering would require N×(N-1)/2 connections and force every team to re-implement firewall policy."
Use one Shared VPC host project per environment (prod, non-prod, dmz) and one folder per environment to hold the host plus its service projects. That mapping makes IAM inheritance predictable and lets you delete an entire non-prod environment by deleting one folder without touching production.
Hub-and-Spoke with Network Connectivity Center
Network Connectivity Center (NCC) is Google's answer to the peering quota wall.
Hub, spokes, and resource attachments
An NCC hub is a global control object you create once per organization domain: gcloud network-connectivity hubs create global-hub. Spokes attach to the hub and represent VPCs, HA VPN tunnels, Interconnect attachments, or third-party SD-WAN routers. A VPC spoke effectively lets multiple VPCs exchange routes through the hub without N×(N-1)/2 peerings. Site-to-cloud traffic over Interconnect attached at the hub becomes reachable from every spoke VPC without site-to-site VPN sprawl.
Site-to-cloud vs cloud-to-cloud
NCC has two data planes. Site-to-cloud (the original) carries on-prem traffic via VPN/Interconnect spokes into a single transit VPC. Cloud-to-cloud (newer) lets multiple production VPCs become full mesh through the hub itself, eliminating the transit VPC and its bottleneck Compute appliance. The exam differentiates the two by the question's symptoms: if the customer has "30 VPCs and rising peering quota," cloud-to-cloud is the answer.
When NCC replaces a transit VPC
A traditional transit VPC architecture put a third-party firewall or router in the middle and forced every flow through it. NCC removes that single point of failure for east-west traffic by letting the hub itself perform the route exchange. You still need stateful firewalling, but you can place it at the spoke perimeter (Cloud NGFW, Cloud Armor) instead of choking the middle.
Multi-VPC vs Single VPC Trade-Offs
The "one big VPC versus many small VPCs" debate is the single most common architecture review topic for a PCNE.
When a single VPC wins
If your security model accepts subnet-level firewall isolation, if every team uses overlapping IAM, and if you stay below quota ceilings, one global VPC keeps routing trivial. Internal load balancers reach every region, Private Service Connect endpoints work uniformly, and there is one firewall surface to audit.
When multiple VPCs win
Strong tenancy boundaries (HIPAA workload that cannot share a control plane with marketing analytics), regulatory data residency that forbids egress paths, mergers and acquisitions where two networks must coexist for years, and projects that exceed the per-VPC firewall rule limit (default 500 ingress, expandable but capped) push you into multiple VPCs. Multi-VPC also reduces blast radius — a fat-finger BGP advertisement in one VPC does not poison the other.
Hybrid: Shared VPC plus selective peering
Most mature organizations end up with a small number of Shared VPC host projects (one per environment) connected by NCC or selective peering, with PSC consumer endpoints bridging into vendor-managed VPCs. That hybrid is the answer the exam usually expects when the question is "how do we scale beyond 10 teams without N×N peerings."
VPC Quotas, Limits, and Project Footprint
Quotas are not exam trivia — they shape what is even possible.
Per-VPC and per-project limits
Defaults worth memorizing: 5 VPC networks per project (soft, raisable), 100 subnets per region per VPC, 25 VPC peering connections per VPC, 200 routes per VPC, 500 firewall rules per VPC (soft), 7 Cloud Routers per region per project. Secondary ranges per subnet default to ~300. Aggregate IP addresses per VPC are unlimited as long as the underlying CIDR is large enough.
Peering math and why NCC matters
Peering is transitive only across NCC, not across raw VPC peering. To full-mesh 10 VPCs with raw peering you need 45 peerings, each counting against the 25-per-VPC limit. The wall is unavoidable past ~6 VPCs. NCC cloud-to-cloud spokes replace those 45 peerings with 10 spoke attachments, eliminating the quadratic explosion.
How to monitor quotas
Cloud Monitoring exposes per-resource quota metrics under compute.googleapis.com/quota/usage. Wire alerts at 70% consumption — once you cross 90% on routes or firewall rules an emergency change can be impossible without quota increase tickets that take hours.
Organization Policy Constraints and Governance
VPC design and hierarchy is only as durable as the org policies that protect it from well-meaning project owners.
Constraints that lock down day-zero mistakes
compute.skipDefaultNetworkCreation prevents the auto-mode default VPC from being created in any new project — the single most useful constraint for production folders. compute.restrictVpcPeering allow-lists which projects may initiate peering. compute.restrictSharedVpcHostProjects and compute.restrictSharedVpcSubnetworks control which host projects and subnets a service project may attach to.
Constraints that prevent data exfiltration
compute.vmExternalIpAccess allow-lists which VMs may have external IPs — critical for compliance-sensitive workloads. Paired with VPC Service Controls perimeters around BigQuery, Storage, and Pub/Sub, this constraint stops a developer from spinning up an ephemeral VM with public IP to copy data out.
Folder inheritance and exception handling
Org policies are evaluated with folder-level inheritance and per-folder overrides. The pattern that works is: deny by default at the organization, allow with exceptions at sandbox or dev folders, deny again at production. Audit the inheritance with gcloud resource-manager org-policies list --folder=FOLDER_ID whenever a new folder appears.
Set compute.skipDefaultNetworkCreation = true at the organization level the day you create the org. The default VPC ships with "allow all internal" firewall rules and predictable 10.128.0.0/9 ranges that conflict with on-prem. Cleaning it up after thousands of projects exist is a multi-quarter project.
Operational Patterns and Exam Traps
A handful of operational patterns recur on the PCNE exam.
Subnet expansion is forward-only
gcloud compute networks subnets expand-ip-range can widen /24 to /22 but never the reverse. If you over-allocate, you live with it. If you under-allocate, you can expand once before colliding with the next neighboring subnet.
Migration from auto-mode to custom-mode
There is a one-way migration: gcloud compute networks update <name> --switch-to-custom-subnet-mode. Auto-mode VPCs cannot be peered with custom-mode VPCs that have overlapping ranges, which is one reason teams hit a wall when an acquired company shows up with auto-mode default.
IPv6 dual stack
External IPv6 is per-subnet, allocated by Google from /64 blocks. Internal IPv6 (ULA) is per-VPC, drawn from fd20::/20. Internal IPv6 cannot be turned off after enabling, so opt in deliberately. Firewall rules need both v4 and v6 ingress entries — the most common dual-stack failure is forgetting the v6 ACL.
VPC-native (Alias IP): A GKE cluster networking mode where Pod IPs are routable inside the VPC because they are drawn from a secondary range of the node subnet rather than overlayed. This is the default and required mode for Private Service Connect, internal Pod-to-Pod across regions, and most regulated workloads.
FAQs
Can a subnet span multiple regions?
No. Every subnet is regional. A single VPC, however, spans every region, and you typically create one subnet per region you intend to use.
Can I shrink a subnet's primary range after creation?
No. Expansion is supported with gcloud compute networks subnets expand-ip-range, but shrinking is not — you would have to migrate workloads to a new subnet and delete the old one.
What is the difference between Shared VPC and VPC Peering for inter-project connectivity?
Shared VPC centralizes one network under a host project that many service projects consume; peering connects two independently-owned VPCs at the routing layer. Shared VPC scales to dozens of teams without per-project firewall duplication; peering hits the 25-per-VPC quota wall around 6 VPCs.
When should I use Network Connectivity Center instead of plain VPC peering?
When you need to connect more than ~6 VPCs, when you want transitive routing between sites and clouds, or when you want a single hub for hybrid traffic instead of a traditional transit VPC.
What MTU should a new production VPC use?
1500 is the safe default and works with HA VPN. Use 8896 only if you control both ends, you do not depend on HA VPN, and your workload benefits from jumbo frames (Dataflow shuffle, GKE inter-node throughput, Filestore Enterprise).
How many secondary ranges can a single subnet hold?
The default soft quota is around 300, but realistic clusters use 2–5. The bigger constraint is that secondary ranges cannot overlap any other primary or secondary range in the same VPC.
Does the compute.skipDefaultNetworkCreation constraint affect existing projects?
No — it only prevents the default VPC from being auto-created in new projects. Existing default networks must be deleted manually or by an automation pipeline.
Can I switch a VPC's dynamic routing mode without downtime?
Yes. gcloud compute networks update <name> --bgp-routing-mode=global is a control-plane change that takes effect within minutes and does not interrupt existing flows. New BGP sessions may need to be re-established on Cloud Routers in remote regions to start advertising the wider scope.