When designing multi-project architectures in GCP, these two approaches present fundamentally different network models:

// Shared VPC creates hierarchical ownership
gcloud compute shared-vpc enable HOST_PROJECT_ID
gcloud compute shared-vpc associate SERVICE_PROJECT_ID \
    --host-project=HOST_PROJECT_ID

// VPC Peering establishes bidirectional connection
gcloud compute networks peerings create PEER_NAME \
    --network=VPC_NETWORK \
    --peer-project=PEER_PROJECT \
    --peer-network=PEER_NETWORK \
    --auto-create-routes

Shared VPC operates with identical subnet ranges across projects, while peering requires non-overlapping CIDR blocks:

# Shared VPC scenario (single subnet space)
10.0.0.0/16 - Shared across all service projects

# VPC Peering scenario (must be disjoint)
Project A: 10.1.0.0/16
Project B: 10.2.0.0/16
Project C: 192.168.0.0/24

Hub-and-Spoke with Shared VPC:

1 Host Project (Network Admin)
├── 50 Service Projects (Dev Teams)
└── Centralized firewall management

Multi-Org Peering Architecture:

Organization A (VPC X) ↔ Peering ↔ Organization B (VPC Y)
        ↑
Peering (max 25 connections)
        ↖
Organization C (VPC Z)

Transitioning from Shared VPC requires careful planning:

gcloud compute instances network-interfaces update INSTANCE_NAME \
    --zone=ZONE \
    --network=NEW_NETWORK \
    --subnet=NEW_SUBNET \
    --network-tier=PREMIUM

For hybrid scenarios combining both approaches:

# Dual-NIC configuration (Beta)
gcloud beta compute instances create INSTANCE_NAME \
    --network-interface=network=SHARED_VPC,subnet=SUBNET_A \
    --network-interface=network=PROJECT_VPC,subnet=SUBNET_B

• Peering: 25 connections per VPC network limit
• Shared VPC: 50,000 instances per host project
• Transitive routing only available through Cloud Router

When designing multi-project architectures in GCP, engineers must choose between two primary networking models:

// Shared VPC configuration example (Terraform)
resource "google_compute_shared_vpc_host_project" "host" {
  project = "host-project-id"
}

resource "google_compute_shared_vpc_service_project" "service1" {
  host_project    = "host-project-id"
  service_project = "service-project1-id"
}

// VPC Peering configuration example (gcloud)
gcloud compute networks peerings create peer-ab \
  --network=vpc-a \
  --peer-project=project-b \
  --peer-network=vpc-b \
  --auto-create-routes

The IP addressing models differ fundamentally:

• Shared VPC: All service projects utilize the same subnet ranges from the host project
• VPC Peering: Each peered VPC must maintain unique, non-overlapping CIDR ranges

Consider these governance models for your use case:

# Shared VPC IAM permissions example
gcloud projects add-iam-policy-binding host-project-id \
  --member='serviceAccount:service-admin@service-project.iam.gserviceaccount.com' \
  --role='roles/compute.networkUser'

The transitive routing behavior differs significantly:

• Shared VPC enables transitive routing automatically
• VPC Peering is non-transitive beyond one hop

// Testing connectivity in peered networks
gcloud compute ssh instance-a --zone=us-central1-a \
  --command="ping -c 4 $(gcloud compute instances describe instance-b \
  --zone=us-west1-b --format='value(networkInterfaces[0].networkIP)')"

Key operational differences to note:

# Shared VPC detachment procedure
1. Create new VPC in service project
2. Update instance NICs:
gcloud compute instances network-interfaces update instance-1 \
  --zone=us-central1-a \
  --network=projects/service-project/global/networks/new-vpc \
  --subnet=projects/service-project/regions/us-central1/subnets/new-subnet
3. Update firewall rules
4. Validate connectivity
5. Remove service project from Shared VPC

For complex architectures:

• Hub-and-spoke with Shared VPC supports up to 500 service projects
• VPC Peering is limited to 25 peerings per network
• Cross-organization peering is exclusive to VPC Peering

# Cross-org peering example
gcloud compute networks peerings create peer-org \
  --network=vpc-org-a \
  --peer-project=org-b-project \
  --peer-network=vpc-org-b \
  --peer-billing-project=org-b-billing

Decision matrix for common scenarios: