Global VPC, Subnets, Firewall Rules & Shared VPC Architecture

GCP Virtual Private Clouds (VPC) differ fundamentally from AWS VPCs. While an AWS VPC is bound to a single AWS Region, a GCP VPC is a GLOBAL resource.

A single GCP VPC can contain subnets in every Google Cloud region around the world, connected across Google’s private global fiber backbone without needing inter-region VPC peering or transit gateways.

Topic 1: Custom Mode vs. Auto Mode VPCs

When creating a VPC network in GCP, you choose between two modes:

1. Auto Mode VPC (Non-Production / Sandbox):

   • Automatically creates one subnet in every GCP region using predefined CIDR ranges (10.128.0.0/20, 10.132.0.0/20, etc.).
   • Default firewall rules are auto-created.
   • Production Risk: CIDR ranges overlap with other standard networks, making VPN or hybrid interconnect impossible.

2. Custom Mode VPC (Enterprise Production Standard):

   • No subnets are created automatically.
   • Network engineers explicitly define subnets, regions, and non-overlapping CIDR blocks.
   • Required for Shared VPCs, VPNs, and Dedicated Interconnects.

# Create an enterprise Custom Mode Global VPC
gcloud compute networks create prod-vpc \
  --subnet-mode=custom \
  --bgp-routing-mode=global

# Add a regional subnet in us-central1 with a primary range and secondary pod ranges
gcloud compute networks subnets create prod-subnet-us-central1 \
  --network=prod-vpc \
  --region=us-central1 \
  --range=10.100.0.0/20 \
  --secondary-range=gke-pods=10.200.0.0/14,gke-services=10.204.0.0/20

Topic 2: VPC Firewall Rules & Network Tag Targeting

GCP VPC firewalls are global, stateful inspection filters.

• Default State: Ingress is denied by default; Egress is allowed by default.
• Stateful Behavior: If ingress traffic is allowed, return egress response traffic is automatically allowed regardless of egress rules.
• Rule Priorities: Evaluated numerically from 0 (highest priority) to 65535 (lowest priority default rules).

Targeting Firewall Rules: Instead of attaching security groups to network interfaces, GCP applies firewall rules to VM instances using:

1. Network Tags (e.g., target-web-server)
2. Service Accounts (e.g., sa-frontend@project.iam.gserviceaccount.com — more secure than tags because tags can be edited by anyone with Compute Instance Admin permissions).

# Ingress rule targeting VMs with network tag 'target-web-server'
gcloud compute firewall-rules create allow-http-web-tags \
  --network=prod-vpc \
  --direction=INGRESS \
  --priority=1000 \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=target-web-server

Topic 3: Shared VPC Architecture (Host vs. Service Projects)

In large organizations, placing compute workloads and networking into a single shared GCP project causes operational chaos. GCP solves this with Shared VPC:

• Host Project: A central project owned by the Network/SecOps team that contains the Shared VPC network, subnets, VPN gateways, Cloud Routers, and central firewall rules.
• Service Projects: Application projects owned by service teams (e.g., checkout-service, analytics-service) attached to the Host Project.
• Mechanism: The Host Project admin grants the roles/compute.networkUser role on specific subnets to the Service Project service accounts. Developers in Service Projects can launch GCE VMs or GKE nodes attached to the Host subnets, but cannot edit subnets, routes, or firewall rules.

Topic 4: Connecting Networks: Shared VPC vs. VPC Peering vs. Cloud Interconnect

Common mistake: Building on the auto-mode default VPC because it is already there. It creates a subnet in every region with predictable ranges and permissive default firewall rules, which is both a security surface and a guarantee of a CIDR collision the first time you peer with anything. Create a custom-mode VPC and allocate ranges deliberately.