architectGCP

You are setting up networking for a multi-team GCP organization with 50+ projects. How do you design Shared VPC with Private Google Access, and what are the IAM and routing considerations for ensuring services can reach GCP APIs without public IPs?

⚡

Quick Answer

Use a Shared VPC host project for centralized network management, with service projects attached for workloads. Enable Private Google Access on subnets, configure Cloud DNS for private.googleapis.com or restricted.googleapis.com, and set up Cloud NAT only for workloads requiring external internet access.

Detailed Answer

Shared VPC Architecture

Shared VPC allows a central network team to manage VPC networks, subnets, firewall rules, and routes in a host project, while service projects (owned by application teams) deploy compute resources into those shared subnets. This separation enables centralized network governance—IP address management, firewall policies, and VPN/Interconnect connectivity—without giving application teams access to modify network infrastructure. A single host project can support up to 1,000 service projects.

Subnet Design and IP Planning

Design subnets per region and environment: /20 for production workloads (4,094 IPs), /22 for staging (1,022 IPs), and /24 for dev (254 IPs). Use secondary ranges for GKE pods (/14 for pods, /20 for services per cluster). Enable Private Google Access on every subnet to ensure resources without external IPs can reach Google APIs. Plan IP ranges to avoid overlap with on-premises networks if using Cloud VPN or Interconnect.

Private Google Access Deep Dive

Private Google Access (PGA) allows VMs without external IPs to reach Google APIs (BigQuery, Cloud Storage, etc.) via internal routes. There are three domains to choose from: private.googleapis.com (199.36.153.8/30) for accessing all Google APIs, restricted.googleapis.com (199.36.153.4/30) for VPC-SC-supported APIs only, and the default *.googleapis.com which requires external IPs. Configure Cloud DNS to resolve *.googleapis.com to the chosen IP range, and add a custom route for that CIDR to the default internet gateway.

IAM for Shared VPC

The host project admin grants roles/compute.networkUser to service project teams on specific subnets, not the entire VPC. For GKE, grant roles/container.hostServiceAgentUser to the GKE service agent. Service project teams can create VMs, GKE clusters, and Cloud SQL instances in shared subnets but cannot modify firewall rules, routes, or subnet configurations. Use IAM Conditions to restrict network access by resource type or region.

Firewall and Routing Governance

Use hierarchical firewall policies at the organization or folder level for baseline rules (deny all ingress, allow health checks, allow IAP for SSH). VPC firewall rules in the host project handle workload-specific rules using network tags or service accounts. Cloud NAT in the host project provides outbound internet access for specific subnets when needed (e.g., pulling external dependencies). All configuration is managed via Terraform with a dedicated networking repository and PR-based review.

# Enable Shared VPC on host project gcloud compute shared-vpc enable network-host-project # Associate service projects gcloud compute shared-vpc associated-projects add app-team-a \ --host-project=network-host-project gcloud compute shared-vpc associated-projects add app-team-b \ --host-project=network-host-project # Create subnets with Private Google Access and secondary ranges for GKE gcloud compute networks subnets create prod-us-central1 \ --project=network-host-project \ --network=shared-vpc \ --region=us-central1 \ --range=10.0.0.0/20 \ --secondary-range pods=10.4.0.0/14,services=10.8.0.0/20 \ --enable-private-ip-google-access \ --enable-flow-logs \ --logging-flow-sampling=0.5 # Grant network access to service project team (subnet-level) gcloud compute networks subnets add-iam-policy-binding prod-us-central1 \ --project=network-host-project \ --region=us-central1 \ --member="group:[email protected]" \ --role="roles/compute.networkUser" # Configure Private Google Access DNS # Create DNS zone for googleapis.com gcloud dns managed-zones create googleapis \ --project=network-host-project \ --dns-name="googleapis.com." \ --visibility=private \ --networks=shared-vpc \ --description="Private Google Access DNS" # CNAME *.googleapis.com to restricted.googleapis.com gcloud dns record-sets create "*.googleapis.com." \ --project=network-host-project \ --zone=googleapis \ --type=CNAME \ --ttl=300 \ --rrdatas="restricted.googleapis.com." # A record for restricted.googleapis.com gcloud dns record-sets create "restricted.googleapis.com." \ --project=network-host-project \ --zone=googleapis \ --type=A \ --ttl=300 \ --rrdatas="199.36.153.4,199.36.153.5,199.36.153.6,199.36.153.7" # Custom route for restricted API range gcloud compute routes create restricted-googleapis \ --project=network-host-project \ --network=shared-vpc \ --destination-range=199.36.153.4/30 \ --next-hop-gateway=default-internet-gateway \ --priority=100 # Cloud NAT for outbound internet (only where needed) gcloud compute routers create nat-router \ --project=network-host-project \ --network=shared-vpc \ --region=us-central1 gcloud compute routers nats create prod-nat \ --project=network-host-project \ --router=nat-router \ --region=us-central1 \ --nat-custom-subnet-ip-ranges=prod-us-central1 \ --auto-allocate-nat-external-ips \ --min-ports-per-vm=1024 \ --log-config=ERRORS_ONLY

You are setting up networking for a multi-team GCP organization with 50+ projects. How do you design Shared VPC with Private Google Access, and what are the IAM and routing considerations for ensuring services can reach GCP APIs without public IPs?

More GCP questions