GCP Shared VPC vs. VPC Peering: Multi-Project Network Topologies 🌐☁️

1. The Foundation: Google Cloud's Global VPC Architecture

To understand inter-project networking in Google Cloud Platform (GCP), one must first appreciate how GCP fundamentally differs from AWS and Azure:

In AWS and Azure, a Virtual Private Cloud or VNet is strictly bound to a single geographic region. Connecting resources across regions requires global peering or transit gateways. In Google Cloud, a VPC is a global resource by default. A single GCP VPC can span every Google Cloud region across North America, Europe, and Asia, with individual subnets allocated inside specific regional datacenters.

However, as enterprise footprints expand, organizational governance mandates deploying workloads across multiple isolated GCP Projects for billing attribution, security blast-radius reduction, and least-privilege IAM management. Connecting these distributed projects requires choosing between two primary networking paradigms: Shared VPC or VPC Network Peering.

2. Comprehensive Architectural Comparison: Shared VPC vs. VPC Peering

The decision between Shared VPC and VPC Peering dictates how your organization manages network administration, firewall policies, and route tables:

3. Deep Dive: Shared VPC (The Enterprise Governance Standard)

Shared VPC designates one project as the Host Project and attaches one or more Service Projects to it. The subnets of the Shared VPC in the Host Project are shared with the Service Projects.

                     ┌──────────────────────────────────────────────┐
                     │         HOST PROJECT: prj-network-core       │
                     │  - Global Shared VPC (vpc-enterprise-shared) │
                     │  - Cloud Interconnect / Cloud VPN Gateways   │
                     │  - Cloud NAT Gateway & Centralized Firewalls │
                     │  - Managed Subnets:                          │
                     │    • snet-prod-frontend (10.10.1.0/24)       │
                     │    • snet-prod-backend  (10.10.2.0/24)       │
                     └──────────────┬───────────────────────────────┘
                                    │ (IAM Subnet Binding)
             ┌──────────────────────┴──────────────────────┐
             ▼                                             ▼
┌─────────────────────────────┐               ┌─────────────────────────────┐
│ SERVICE PRJ: prj-app-web    │               │ SERVICE PRJ: prj-analytics  │
│  - Compute VMs & GKE Pods   │               │  - BigQuery & Dataproc Nodes│
│  - Deployed into:           │               │  - Deployed into:           │
│    snet-prod-frontend       │               │    snet-prod-backend        │
└─────────────────────────────┘               └─────────────────────────────┘

The IAM Least-Privilege Advantage

Shared VPC enforces a strict division of administrative responsibilities:

• Network Admins hold the roles/compute.networkAdmin role in the Host Project. They create subnets, manage firewall rules, and maintain Cloud Routers.
• Application Developers hold the roles/compute.networkUser role scoped only to specific subnets in the Host Project. They can launch VMs or GKE clusters attached to their assigned subnet, but cannot modify firewall rules, route tables, or gateway configurations.

Provisioning Shared VPC via Google Cloud CLI:

# 1. Enable the Host Project at the Organization level
gcloud compute shared-vpc enable prj-network-core

# 2. Associate Service Projects to the Host Project
gcloud compute shared-vpc associated-projects add prj-app-web \
  --host-project=prj-network-core

gcloud compute shared-vpc associated-projects add prj-analytics \
  --host-project=prj-network-core

# 3. Grant Application Team Network User permission on their specific subnet ONLY
gcloud compute networks subnets add-iam-policy-binding snet-prod-frontend \
  --project=prj-network-core \
  --region=asia-south1 \
  --member="group:web-devs@cicdclouds.com" \
  --role="roles/compute.networkUser"

4. Deep Dive: VPC Network Peering (Decentralized Autonomy)

VPC Network Peering interconnects two independently administered VPC networks—whether they reside in the same project, different projects within the same organization, or separate GCP organizations altogether.

Peered VPC networks communicate entirely over Google's SDN private backbone. Traffic incurs zero latency overhead, zero hops through NAT gateways, and full wire-speed line performance.

Establishing Bidirectional Peering via CLI

Both VPC owners must independently consent to the peering connection before routing is enabled:

# 1. Initiate Peering from VPC-A to VPC-B (Project A)
gcloud compute networks peerings create peer-a-to-b \
  --project=prj-corp-analytics \
  --network=vpc-analytics \
  --peer-project=prj-thirdparty-partner \
  --peer-network=vpc-partner \
  --auto-create-routes

# 2. Complete Handshake from VPC-B to VPC-A (Project B)
gcloud compute networks peerings create peer-b-to-a \
  --project=prj-thirdparty-partner \
  --network=vpc-partner \
  --peer-project=prj-corp-analytics \
  --peer-network=vpc-analytics \
  --auto-create-routes

5. The Non-Transitive Peering Trap & Enterprise Workarounds

The most critical constraint of Google Cloud VPC Network Peering is that it is strictly non-transitive:

The Non-Transitive Rule: If VPC-A is peered with VPC-B, and VPC-B is peered with VPC-C, workloads in VPC-A cannot communicate with workloads in VPC-C through VPC-B. Furthermore, VPC-A cannot use VPC-B's on-premises Cloud VPN or Cloud Interconnect gateway to reach corporate datacenters.

Enterprise Workarounds for Transitive Routing:

1. Shared VPC (The Native Fix): Consolidate workloads into a single Shared VPC. Since all service projects attach to the same VPC, all workloads naturally share transit gateways without peering boundaries.
2. Hub-and-Spoke with Network Virtual Appliances (NVAs): Deploy active-active firewall appliances (Palo Alto, Fortinet) inside a central Transit VPC. Configure custom User-Defined Routes (UDRs) pointing cross-VPC traffic to the internal IP of the NVA load balancer.
3. Google Cloud Private Service Connect (PSC): For microservice-to-microservice communication across disconnected VPCs, publish services via Private Service Connect endpoints. PSC uses Layer-4 TCP proxying to route packets securely over internal IP mappings without establishing full network peering or exposing entire subnets.

6. Production Troubleshooting & Operational Pitfalls

When managing enterprise network topologies in GCP, engineers frequently confront these edge-case failures:

1. Peering Status Stuck in INACTIVE

Issue: You executed the peering command on VPC-A, but the status remains INACTIVE, and packets are dropped.

Root Cause: Peering requires a mutual handshake. The administrator of the remote project has not yet executed the reverse peering command matching your exact project ID and network name.

Remedy: Confirm that both sides have applied matching configurations. Once both sides register, the status transitions automatically to ACTIVE.

2. Custom Subnet IP Range Overlaps (Silent Failure)

If VPC-A uses 10.0.0.0/16 and VPC-B subsequently attempts to add a new subnet within 10.0.128.0/24, Google Cloud will reject the subnet creation immediately if peering is active. If peering is attempted after overlapping subnets exist, the peering command will fail with an explicit CIDR collision error.

Remedy: Implement an enterprise-wide IP Address Management (IPAM) registry and reserve non-overlapping address allocations for every project.

3. Hierarchical Firewall Policy Precedence

In Shared VPC architectures, teams frequently complain that local firewall rules deployed inside Service Projects fail to allow traffic.

Root Cause: Google Cloud evaluates Hierarchical Firewall Policies attached at the Organization and Folder levels before evaluating VPC-level firewall rules. If a security team sets an organization-level DENY rule on port 22, no Service Project admin can override it.