GCP Shared VPC: Centralized Network Administration for Multi-Project

You deployed a new microservice in a separate project, and suddenly your production database is unreachable. The network team blames the app team, the app team blames IAM, and three hours later you discover someone deleted a VPC peering connection. This is the reality of managing networks without Shared VPC. GCP Shared VPC flips the model: one network, many projects, central control. It eliminates the complexity of VPC peering meshes, reduces attack surface by enforcing consistent firewall rules, and gives you a single pane of glass for audit logs. If you're running more than three projects with any inter-project communication, you're wasting time and risking outages without it. This article walks you through the architecture, implementation, and operational pitfalls of Shared VPC — from a production engineer who's cleaned up the mess when it's done wrong.

The Shared VPC Architecture: Host vs. Service Projects

Shared VPC splits responsibility into two project types: the host project owns the VPC network, subnets, firewall rules, and routes. Service projects attach to the host and consume its subnets for their resources (GKE, Compute Engine, Cloud SQL, etc.). This separation is critical: the host project is managed by a central network team, while service project owners deploy workloads without touching network configuration. The host project can have multiple VPCs, but each service project attaches to exactly one host project. Resources in service projects get IPs from the host project's subnets, and all traffic flows through the host project's firewall rules. This means you can enforce egress via Cloud NAT in the host project, block SSH from the internet globally, and audit all traffic with VPC Flow Logs from a single project. The key constraint: service projects cannot create their own subnets or modify host project firewall rules. This is a feature, not a bug — it prevents the sprawl that plagues multi-project setups.

#!/bin/bash
# Enable Shared VPC for host project
HOST_PROJECT_ID="network-host-prod"
SERVICE_PROJECT_ID="app-service-prod"

gcloud compute shared-vpc enable "$HOST_PROJECT_ID"

# Attach service project to host
gcloud compute shared-vpc associated-projects add "$SERVICE_PROJECT_ID" \
    --host-project "$HOST_PROJECT_ID"

# Grant service project network user role to a service account
gcloud projects add-iam-policy-binding "$SERVICE_PROJECT_ID" \
    --member="serviceAccount:app-sa@$SERVICE_PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/compute.networkUser" \
    --condition="expression=resource.name.startsWith('projects/$HOST_PROJECT_ID/regions/us-central1/subnetworks/app-subnet'),title=restrict_to_app_subnet"

Subnet Design: Carving Out Space for Scale

Subnet planning in Shared VPC is a one-time decision that haunts you forever if done wrong. Each subnet belongs to the host project and is assigned to a region. Service projects can use any subnet they have IAM access to. The golden rule: use non-overlapping CIDR ranges per environment and per region. For production, reserve /16 per region (e.g., 10.0.0.0/16 for us-central1, 10.1.0.0/16 for us-east1). For staging, use a different prefix like 10.64.0.0/16. Never use the same CIDR across environments — it breaks peering and migration. Secondary ranges are essential for GKE pods and services: allocate /16 for pods and /20 for services per cluster. Use a consistent naming scheme: 'subnet-prod-us-central1-app', 'subnet-prod-us-central1-gke-pods'. Avoid creating subnets larger than /16; you'll waste IPs and hit routing table limits. Also, plan for future regions: leave gaps in your IP space (e.g., skip 10.2.0.0/16 for future us-west1).

resource "google_compute_subnetwork" "subnets" {
  for_each = {
    prod-us-central1-app = {
      region    = "us-central1"
      cidr      = "10.0.0.0/20"
      secondary = {
        pods     = "10.0.16.0/20"
        services = "10.0.32.0/24"
      }
    }
    prod-us-east1-app = {
      region    = "us-east1"
      cidr      = "10.1.0.0/20"
      secondary = {
        pods     = "10.1.16.0/20"
        services = "10.1.32.0/24"
      }
    }
  }
  name          = "subnet-${each.key}"
  network       = google_compute_network.vpc.id
  region        = each.value.region
  ip_cidr_range = each.value.cidr
  secondary_ip_range {
    range_name    = "${each.key}-pods"
    ip_cidr_range = each.value.secondary.pods
  }
  secondary_ip_range {
    range_name    = "${each.key}-services"
    ip_cidr_range = each.value.secondary.services
  }
}

IAM and Access Control: The Network User Role

The compute.networkUser role is the linchpin of Shared VPC security. It grants a service project's identities (users, service accounts, groups) permission to use subnets in the host project. Without it, resources in the service project cannot create network interfaces. The role must be granted at the host project level, but you should scope it with IAM conditions to specific subnets. For example, a staging service project should only access staging subnets. Use groups for role assignment: create a group like 'gcp-network-users-prod' and add service accounts to it. This avoids managing individual bindings. Also, grant compute.networkUser to the GKE service agent (service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com) so GKE clusters can create nodes in the host project's subnets. Never grant compute.networkAdmin to service project users — that allows them to modify firewall rules and routes, defeating the purpose of centralization.

#!/bin/bash
HOST_PROJECT="network-host-prod"
SERVICE_PROJECT="app-service-prod"
SUBNET="projects/$HOST_PROJECT/regions/us-central1/subnetworks/subnet-prod-us-central1-app"

# Grant networkUser to a group
gcloud projects add-iam-policy-binding "$HOST_PROJECT" \
    --member="group:gcp-network-users-prod@example.com" \
    --role="roles/compute.networkUser" \
    --condition="expression=resource.name.startsWith('$SUBNET'),title=restrict_to_app_subnet"

# Grant networkUser to GKE service agent
GKE_SA="service-$(gcloud projects describe $SERVICE_PROJECT --format='value(projectNumber)')@container-engine-robot.iam.gserviceaccount.com"
gcloud projects add-iam-policy-binding "$HOST_PROJECT" \
    --member="serviceAccount:$GKE_SA" \
    --role="roles/compute.networkUser" \
    --condition="expression=resource.name.startsWith('$SUBNET'),title=gke_subnet_access"

Firewall Rules: Centralized Enforcement with Service Project Exceptions

Firewall rules in Shared VPC are defined in the host project and apply to all resources in attached service projects. This is powerful: you can block all inbound SSH from the internet with a single rule. However, service projects sometimes need their own rules (e.g., allow health checks from a specific range). You have two options: create global rules in the host project, or use service project firewall rules (which are allowed but discouraged). The best practice is to centralize all ingress rules in the host project and use network tags for fine-grained control. For example, tag all GKE nodes with 'gke-node' and create a rule allowing port 10250 from monitoring ranges. Avoid service project firewall rules because they create a fragmented policy that's hard to audit. Use hierarchical firewall policies for organization-level rules that apply across all host projects. Also, enable VPC Flow Logs on subnets to capture denied traffic — it's invaluable for debugging.

resource "google_compute_firewall" "allow-health-checks" {
  name    = "fw-allow-health-checks"
  network = google_compute_network.vpc.name

  allow {
    protocol = "tcp"
    ports    = ["80", "443"]
  }

  source_ranges = ["35.191.0.0/16", "130.211.0.0/22"]
  target_tags   = ["http-server"]
}

resource "google_compute_firewall" "deny-all-ssh" {
  name    = "fw-deny-all-ssh"
  network = google_compute_network.vpc.name

  deny {
    protocol = "tcp"
    ports    = ["22"]
  }

  source_ranges = ["0.0.0.0/0"]
  priority      = 1000
}

resource "google_compute_firewall" "allow-ssh-from-bastion" {
  name    = "fw-allow-ssh-from-bastion"
  network = google_compute_network.vpc.name

  allow {
    protocol = "tcp"
    ports    = ["22"]
  }

  source_ranges = ["10.0.100.0/24"]
  target_tags   = ["bastion-accessible"]
  priority      = 900
}

Private Google Access and Cloud NAT: Centralized Egress

Shared VPC enables centralized egress through Cloud NAT and Private Google Access. Configure Cloud NAT in the host project on each subnet that needs outbound internet access. Service project resources automatically use this NAT — no per-project configuration needed. This is critical for compliance: all outbound traffic goes through a single set of IPs, simplifying allowlisting with third parties. Private Google Access allows VMs without external IPs to reach Google APIs (e.g., Cloud Storage, BigQuery) over Google's internal network. Enable it per subnet in the host project. The combination means service project VMs can have zero public IPs, reducing attack surface. However, beware of NAT gateway limits: each Cloud NAT gateway supports up to 64,000 concurrent connections per VM. For high-throughput workloads, use multiple NAT IPs or consider a third-party NVA. Also, monitor NAT gateway utilization with Cloud Monitoring to avoid connection drops.

resource "google_compute_router" "router" {
  name    = "router-prod-us-central1"
  network = google_compute_network.vpc.name
  region  = "us-central1"
}

resource "google_compute_router_nat" "nat" {
  name                               = "nat-prod-us-central1"
  router                             = google_compute_router.router.name
  region                             = "us-central1"
  nat_ip_allocate_option             = "AUTO_ONLY"
  source_subnetwork_ip_ranges_to_nat = "LIST_OF_SUBNETWORKS"

  subnetwork {
    name                    = google_compute_subnetwork.subnets["prod-us-central1-app"].id
    source_ip_ranges_to_nat = ["ALL_IP_RANGES"]
  }

  # Enable logging for audit
  log_config {
    enable = true
    filter = "ERRORS_ONLY"
  }
}

# Enable Private Google Access on subnet
resource "google_compute_subnetwork" "subnet_with_pga" {
  name                     = "subnet-prod-us-central1-app"
  network                  = google_compute_network.vpc.id
  region                   = "us-central1"
  ip_cidr_range            = "10.0.0.0/20"
  private_ip_google_access = true
}

VPC Peering and Hybrid Connectivity: Extending the Shared VPC

Shared VPC networks can peer with other VPCs (including on-prem via Cloud VPN or Dedicated Interconnect). This allows you to extend the centralized network model to hybrid environments. For example, peer the host project's VPC with a on-prem network via Cloud VPN, and all service projects automatically get connectivity to on-prem resources. However, peering is not transitive: if VPC A is peered with VPC B, and VPC B is peered with VPC C, VPC A does not automatically reach VPC C. You must set up direct peering between A and C. Also, beware of overlapping CIDRs — they break peering. Use non-overlapping ranges from the start. For hybrid connectivity, use a dedicated project for VPN/Interconnect and peer it with the host project. This keeps the network team in control of the VPN tunnel while service projects remain unaware. Use Cloud Router with dynamic routing (BGP) to propagate routes automatically.

resource "google_compute_network_peering" "peer-with-onprem" {
  name         = "peer-host-to-onprem"
  network      = google_compute_network.vpc.id
  peer_network = "projects/onprem-project/global/networks/onprem-vpc"

  export_custom_routes = true
  import_custom_routes = true
}

# Cloud Router for dynamic routing
resource "google_compute_router" "hybrid-router" {
  name    = "router-hybrid"
  network = google_compute_network.vpc.name
  region  = "us-central1"
  bgp {
    asn = 64514
  }
}

# VPN tunnel (simplified)
resource "google_compute_vpn_tunnel" "tunnel" {
  name          = "tunnel-to-onprem"
  peer_ip       = "203.0.113.1"
  shared_secret = var.vpn_secret
  router        = google_compute_router.hybrid-router.id
  vpn_gateway   = google_compute_vpn_gateway.gateway.id
}

GKE in Shared VPC: Cluster Configuration and Node Pools

Deploying GKE clusters in a Shared VPC requires careful configuration. The cluster's VPC-native mode must use the host project's subnets. Specify the subnet for nodes, and secondary ranges for pods and services. The GKE service agent needs compute.networkUser on the subnet. Node pools can use different subnets, but all must be in the same region as the cluster. Use separate node pools for system and user workloads, each with its own subnet if needed. Enable Dataplane V2 for better network policy enforcement. Also, configure master authorized networks to restrict access to the control plane. A common pitfall: forgetting to grant the GKE service agent access to the subnet's secondary ranges. The error message is cryptic: 'failed to create cluster: googleapi: Error 400: Invalid value for field 'resource.clusterIpv4Cidr' — but the real issue is IAM. Always test cluster creation with a dry run.

#!/bin/bash
HOST_PROJECT="network-host-prod"
SERVICE_PROJECT="app-service-prod"
CLUSTER_NAME="app-cluster"
REGION="us-central1"
SUBNET="projects/$HOST_PROJECT/regions/$REGION/subnetworks/subnet-prod-us-central1-app"
POD_RANGE="subnet-prod-us-central1-app-pods"
SERVICE_RANGE="subnet-prod-us-central1-app-services"

gcloud container clusters create "$CLUSTER_NAME" \
    --project "$SERVICE_PROJECT" \
    --region "$REGION" \
    --network "projects/$HOST_PROJECT/global/networks/vpc-prod" \
    --subnetwork "$SUBNET" \
    --cluster-secondary-range-name "$POD_RANGE" \
    --services-secondary-range-name "$SERVICE_RANGE" \
    --enable-ip-alias \
    --enable-dataplane-v2 \
    --master-authorized-networks "10.0.100.0/24" \
    --enable-master-authorized-networks

Monitoring and Auditing: VPC Flow Logs and Network Intelligence Center

Visibility is non-negotiable in Shared VPC. Enable VPC Flow Logs on all subnets in the host project to capture traffic metadata. Sample rate of 1 in 10 is sufficient for most environments; increase to 1 in 2 for critical subnets. Export logs to BigQuery for analysis — you can detect anomalous traffic, identify unused IPs, and troubleshoot connectivity. Use Network Intelligence Center (NIC) for topology visualization and connectivity tests. NIC can simulate traffic between any two endpoints and show the path, firewall rules applied, and any drops. This is invaluable for debugging 'why can't VM A talk to VM B' in a multi-project setup. Also, set up alerts for high NAT connection counts, dropped packets, and firewall rule changes. Use Cloud Monitoring dashboards to track subnet utilization and alert when IP space is below 20%.

resource "google_compute_subnetwork" "subnet_with_logs" {
  name             = "subnet-prod-us-central1-app"
  network          = google_compute_network.vpc.id
  region           = "us-central1"
  ip_cidr_range    = "10.0.0.0/20"
  log_config {
    aggregation_interval = "INTERVAL_5_SEC"
    flow_sampling        = 0.1
    metadata             = "INCLUDE_ALL_METADATA"
  }
}

# BigQuery export sink
export "google_logging_project_sink" "flow_logs_bq" {
  name        = "flow-logs-to-bq"
  destination = "bigquery.googleapis.com/projects/${var.log_project}/datasets/vpc_flow_logs"
  filter      = "resource.type=\"gce_subnetwork\" AND logName=\"projects/${var.host_project}/logs/compute.googleapis.com%2Fvpc_flows\""
}

Organizational Policy and Hierarchy: Enforcing Shared VPC at Scale

At the organization level, you can enforce Shared VPC usage via organizational policies. Use the compute.restrictSharedVpcHostProject constraint to limit which projects can be host projects. This prevents rogue teams from creating their own Shared VPCs. Also, use compute.restrictSharedVpcSubnetworks to restrict which subnets service projects can use. Combine with IAM conditions for defense in depth. For large organizations, use folder-level host projects: each folder (e.g., 'Production', 'Staging') has its own host project. This isolates environments. Use Terraform to manage the hierarchy: create host projects per folder, attach service projects, and apply firewall rules. Automate with CI/CD to prevent drift. Also, set up a centralized network CI/CD pipeline that deploys firewall rules and subnets from a single repository. This ensures all changes are reviewed and audited.

resource "google_organization_policy" "restrict_host_projects" {
  org_id     = var.org_id
  constraint = "compute.restrictSharedVpcHostProject"
  list_policy {
    allow {
      values = ["projects/network-host-prod", "projects/network-host-staging"]
    }
  }
}

resource "google_folder_organization_policy" "restrict_subnets" {
  folder     = google_folder.production.name
  constraint = "compute.restrictSharedVpcSubnetworks"
  list_policy {
    allow {
      values = ["projects/network-host-prod/regions/us-central1/subnetworks/subnet-prod-*"]
    }
  }
}

Migration from VPC Peering to Shared VPC

Migrating from a VPC peering mesh to Shared VPC is painful but necessary for scale. The key challenge: you cannot change the network of existing resources. You must recreate them in the Shared VPC. Strategy: create the Shared VPC host project and subnets, then gradually migrate workloads. For GCE instances, use instance templates with the new subnet and rolling update. For GKE, create a new cluster in the Shared VPC and migrate workloads using a blue-green deployment. For Cloud SQL, you must restore a backup into the new VPC. Use a migration project as a staging ground: attach it to the host project, deploy new resources, and cut over traffic. During migration, maintain peering between old and new VPCs for connectivity. Once all workloads are migrated, delete the old VPCs and peering connections. This process can take weeks — plan for downtime windows.

#!/bin/bash
# Create new instance in Shared VPC
OLD_INSTANCE="web-server-old"
NEW_INSTANCE="web-server-new"
ZONE="us-central1-a"
SUBNET="projects/network-host-prod/regions/us-central1/subnetworks/subnet-prod-us-central1-app"

gcloud compute instances create "$NEW_INSTANCE" \
    --zone "$ZONE" \
    --subnet "$SUBNET" \
    --source-instance-template "web-server-template" \
    --no-address

# After verifying new instance, delete old one
gcloud compute instances delete "$OLD_INSTANCE" --zone "$ZONE" --quiet

Common Pitfalls and How to Avoid Them

Even experienced teams hit these Shared VPC landmines. First: overlapping CIDRs. Always use a central IPAM tool to track allocations. Second: forgetting IAM conditions. Without them, a staging service account can accidentally use production subnets. Third: ignoring GKE service agent IAM. Cluster creation fails silently. Fourth: not planning for secondary ranges. You can't add them later without recreating the subnet. Fifth: assuming peering is transitive. It's not — you need explicit peering for each pair. Sixth: not enabling VPC Flow Logs from day one. You'll have no baseline for anomaly detection. Seventh: allowing service project firewall rules. They create a security blind spot. Eighth: not using organizational policies. Without them, teams can create their own host projects, defeating centralization. Mitigate each with automation: use Terraform to enforce standards, run policy-as-code checks in CI/CD, and conduct regular audits.

#!/bin/bash
# Check for CIDR overlap between two projects
PROJECT_A="prod-network-host"
PROJECT_B="staging-network-host"

gcloud compute networks subnets list --project $PROJECT_A --format='value(ipCidrRange)' | sort > /tmp/subnets_a.txt
gcloud compute networks subnets list --project $PROJECT_B --format='value(ipCidrRange)' | sort > /tmp/subnets_b.txt

# Use grep to find overlapping ranges (simplified)
while read cidr; do
  if grep -q "$cidr" /tmp/subnets_b.txt; then
    echo "Overlap found: $cidr"
  fi
done < /tmp/subnets_a.txt

Automation with Terraform and CI/CD

Manual Shared VPC management doesn't scale. Use Terraform to define the entire network as code. Store state in a remote backend with locking. Organize modules: one for host project, one for subnets, one for firewall rules, one for IAM. Use workspaces or folders for environments. CI/CD pipeline: run terraform plan on every PR, require approval for production changes, and apply automatically after merge. Use Terratest or OPA for policy-as-code: enforce that all subnets have flow logs enabled, no public IPs on VMs, and firewall rules are tagged. Also, use Google Cloud Build or Terraform Cloud for execution. This ensures consistency and auditability. A common mistake: using terraform import for existing resources without updating state. Always run terraform plan after import to detect drift.

module "host_project" {
  source = "./modules/host-project"
  project_id = "network-host-prod"
  org_id     = var.org_id
}

module "subnets" {
  source   = "./modules/subnets"
  network  = module.host_project.network_self_link
  subnets  = var.subnets
}

module "firewall" {
  source  = "./modules/firewall"
  network = module.host_project.network_name
  rules   = var.firewall_rules
}

module "iam" {
  source      = "./modules/iam"
  host_project = module.host_project.project_id
  service_projects = var.service_projects
}

# CI/CD pipeline config (simplified)
resource "google_cloudbuild_trigger" "network-cicd" {
  trigger_template {
    branch_name = "main"
    repo_name   = "gcp-network"
  }
  substitutions = {
    _ENV = "prod"
  }
  filename = "cloudbuild.yaml"
}

Subnet-Level IAM vs Project-Level: Least Privilege for Shared VPC

When granting compute.networkUser to service project teams, you have two approaches: project-level or subnet-level IAM. Project-level grants access to ALL subnets in the host project, including future ones. This is simpler but violates least privilege—a staging team could accidentally use production subnets. Subnet-level IAM binds the role directly on individual subnets, scoping access precisely. To do this, use gcloud compute networks subnets add-iam-policy-binding instead of gcloud projects add-iam-policy-binding. The trade-off: subnet-level requires more management but provides blast radius containment. For organizations with more than 5 service projects, manage subnet IAM with Terraform to avoid drift. A common pattern: create Google Groups per team (e.g., gcp-network-web-team@), grant subnet-level networkUser to the group, and manage group membership in your identity provider. Never use set-iam-policy on subnets—it replaces the entire policy and can accidentally revoke other teams' access. Always use add-iam-policy-binding.

resource "google_compute_subnetwork_iam_binding" "web_team" {
  project    = "network-host-prod"
  region     = "us-central1"
  subnetwork = "subnet-prod-web"
  role       = "roles/compute.networkUser"

  members = [
    "group:gcp-network-web-team@example.com",
    "serviceAccount:service-PROJECT_NUMBER@container-engine-robot.iam.gserviceaccount.com",
  ]
}

resource "google_compute_subnetwork_iam_binding" "data_team" {
  project    = "network-host-prod"
  region     = "us-east1"
  subnetwork = "subnet-prod-data"
  role       = "roles/compute.networkUser"

  members = [
    "group:gcp-network-data-team@example.com",
  ]
}

Service Account-Based Firewall Rules vs Network Tags

GCP firewall rules traditionally use network tags (targetTags) to determine which VMs a rule applies to. However, network tags can be set by anyone with compute.instanceAdmin role, creating a security gap: a developer can tag a VM as 'http-server' and circumvent intended restrictions. Service account-based firewall rules are more secure because they use IAM identity, which is harder to spoof. Instead of target_tags = ["web-server"], use target_service_accounts = ["web-sa@project.iam.gserviceaccount.com"]. Any VM running as that service account automatically gets the firewall rule. This provides better audit trails and prevents tag-based privilege escalation. For production, prefer service account-based rules for sensitive applications (databases, internal APIs) and use network tags only for coarse-grained controls like health check allowlists. Migrate existing tag-based rules gradually: audit which service accounts should have access, create the rules, then remove tag-based rules.

resource "google_compute_firewall" "allow-db-from-app" {
  name    = "fw-allow-db-from-app-sa"
  network = google_compute_network.vpc.name

  allow {
    protocol = "tcp"
    ports    = ["5432"]
  }

  source_service_accounts = ["app-sa@app-project.iam.gserviceaccount.com"]
  target_service_accounts = ["db-sa@db-project.iam.gserviceaccount.com"]
}

# Compare with tag-based (less secure)
resource "google_compute_firewall" "allow-db-from-app-tag" {
  name    = "fw-allow-db-from-app-tag"
  network = google_compute_network.vpc.name

  allow {
    protocol = "tcp"
    ports    = ["5432"]
  }

  source_tags = ["app-tier"]
  target_tags = ["db-tier"]
}