Consolidating 38 Projects: Shared VPC Topology and a Three-Year IP Plan

Choose Shared VPC with one host project per environment, and attach the 38 projects (including the acquired company's projects) as service projects.

Why the alternatives fail:

• VPC peering mesh: peering is non-transitive, so 38 projects would need a full or hub-and-spoke mesh. Routes and firewall rules are still per-VPC, so the platform team would duplicate policy 38 times. Peering must also be re-established for every new project, and networking has already ruled it out.
• Standalone VPCs plus VPN: adds overlay routing and cost for what is really one administrative domain.
• One VPC per team with no connectivity: shared services (logging, CI runners, domain proxies) would be unreachable.

Structure:

1. net-host-prod and net-host-nonprod host projects own prod-vpc and nonprod-vpc. The Interconnect, Cloud Routers, Cloud NAT, and Private Google Access configuration all live in the host projects, so one hybrid attachment serves every service project.
2. Folders: org / prod / <business unit> and org / nonprod / <business unit>, with service projects under them. The acquired company's projects go in the same hierarchy so IAM and policy inheritance apply uniformly.
3. IAM: grant roles/compute.networkUser on specific subnets, not the whole VPC, to per-team groups. Grant roles/compute.securityAdmin at the folder (or project) so product teams own their firewall rules, but keep network, route, and interconnect administration in the host project where teams have no role.
4. Do not grant roles/compute.networkAdmin at the host project, which would let teams delete routes or subnet ranges that shared services depend on.

The decisive point: Shared VPC gives the central team one route table, one IP plan, and one hybrid attachment while the product teams retain self-service firewall control.

Usable address space: 10.0.0.0/8 belongs to on-premises, and 172.20.0.0/14 belongs to the acquired company. Use 172.24.0.0/13 (172.24.0.0 through 172.31.255.255), which is RFC 1918, overlaps neither range, and contains 8 contiguous /16 blocks. Keep 172.16.0.0/14 (172.16.0.0 to 172.19.255.255) as the reserve pool for future acquisitions or a second VPC.

Sizing per regional GKE cluster:

• Nodes: 30 nodes/zone x 3 zones = 90 nodes today. Node subnet /22 = 1,022 usable addresses, which covers 90 nodes plus surge upgrades, NVA addresses, and control-plane overhead.
• Pods: GKE allocates one /24 per node (110 pods fit inside a /24). 90 nodes therefore need 90 /24s. A /17 provides 128 /24s (about 42% headroom, roughly 128 nodes); a /16 provides 256 /24s if you expect to exceed that.
• Services: /20 (4,094 addresses), the GKE default, is appropriate for a single cluster.

Allocation: carve each cluster from its own /16 block inside 172.24.0.0/13. Cluster 1: nodes 172.24.0.0/22, pods 172.24.128.0/17, services 172.24.4.0/20. Cluster 2 uses the next /16, and so on. Four clusters consume four blocks; four /16 blocks remain for growth, and 172.16.0.0/14 remains an untouched reserve.

Gaps to avoid:

• Never allocate 199.36.153.0/24 (Google API VIP ranges) or 35.191.0.0/16 and 130.108.0.0/16 (load balancer probers).
• Avoid 100.64.0.0/10 (carrier-grade NAT space) unless you deliberately coordinate it with partners.
• Record the plan in a central IPAM document and check it before every new subnet or cluster; overlapping secondary ranges are painful to fix after the fact.

Use a hierarchical (org/folder-scoped) network firewall policy in front of the project-level VPC firewall rules, and target by service account rather than network tag.

Mechanics that matter:

1. Hierarchical policies are evaluated before project-level VPC firewall rules. Within the hierarchy, org policy is evaluated before folder policy, and each policy's rules are evaluated by priority (lowest number first). A deny in a folder policy therefore cannot be overridden by a product team creating an allow in their own project - which is exactly the control you need.
2. Attach a policy to the production folder (or the org node) with:
   • priority 1000: action=deny, direction INGRESS, src-ip-ranges=0.0.0.0/0, on the tag or secure tag that marks production workloads;
   • a final goto_next rule so legitimate lower-level rules still apply to traffic the deny does not match. Scope the deny to production tags rather than the whole folder if non-production must accept broad ingress for testing.
3. Target with service accounts or secure tags, not plain network tags. Anyone holding instance-update rights can attach an arbitrary network tag to a VM and thereby join a rule's target set, and the same tag can be removed from a production VM, silently dropping protection. Secure tags are IAM-governed; service-account targets require IAM to impersonate.
4. Keep roles/compute.securityAdmin at the service-project level so teams can create their own allows and denies, and reserve hierarchical policy administration for the central networking group only.

Validate before rollout: create the rules in preview/dry-run where supported, export firewall logs to BigQuery for a week, confirm no legitimate 0.0.0.0/0 traffic exists, then enforce. Re-test with a Connectivity Test from an internet source after enforcement.