GCP VPC Design: Custom VPCs, Subnets, and IP Allocation

You just deployed a new microservice, and suddenly half your production traffic is timing out. The root cause? Your VPC subnet ran out of IP addresses, forcing GCP to auto-allocate from a range that overlaps with your on-premises VPN. That's the cost of ignoring VPC design. Most teams treat VPCs as an afterthought—click 'default' and move on. But in GCP, a VPC is a global resource, and subnets are regional. Get the CIDR blocks wrong, and you're rebuilding from scratch. This article walks you through designing custom VPCs that survive production: from IP allocation strategies to hybrid connectivity, with real-world failure modes you'll face at scale.

Why Default VPCs Are a Trap

GCP creates a default VPC in every project with auto-mode subnets in each region. This sounds convenient, but it's a ticking time bomb. Auto-mode uses a /20 per region, which is fine for prototypes but disastrous for production. You can't control IP ranges, so you'll inevitably collide with on-premises networks or peered VPCs. Worse, you can't delete the default VPC without breaking existing resources. The first step in any production deployment is to create a custom VPC with manually planned CIDR blocks. This gives you full control over IP allocation, routing, and firewall rules. Don't let convenience cost you a production outage.

gcloud compute networks create prod-vpc \
  --subnet-mode=custom \
  --bgp-routing-mode=regional \
  --mtu=1460

IP Allocation Strategy: CIDR Planning for Growth

IP allocation is the foundation of VPC design. Start by reserving a large CIDR block for your entire VPC—typically a /16 or /8 depending on scale. Then carve out subnets per region and tier. For example, use 10.0.0.0/16 for the whole VPC, then assign 10.0.1.0/24 for us-central1 web tier, 10.0.2.0/24 for us-central1 app tier, and so on. Always leave room for expansion: never allocate more than 50% of your block upfront. Use RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) and avoid overlapping with on-premises or other cloud networks. Document your plan in a central IPAM tool.

gcloud compute networks subnets create prod-us-central1-web \
  --network=prod-vpc \
  --region=us-central1 \
  --range=10.0.1.0/24 \
  --enable-private-ip-google-access \
  --secondary-range=services=10.0.101.0/24,pods=10.0.201.0/24

Regional vs. Global VPC: Choosing the Right Scope

GCP VPCs are global, meaning a single VPC spans all regions. This is a superpower: you can have subnets in us-central1, europe-west1, and asia-east1 all within the same VPC. Global VPCs simplify routing and firewall management because resources can communicate across regions using internal IPs. However, global VPCs also mean a misconfiguration can affect all regions. For most production workloads, a single global VPC per environment (prod, staging, dev) is the right choice. Avoid creating separate VPCs per region—that's a legacy mindset from on-premises networking.

gcloud compute networks subnets list --network=prod-vpc

Subnet Design: Tiers, Regions, and High Availability

Subnets are the atomic unit of network segmentation. Design them around tiers (web, app, db) and regions. Each tier should have its own subnet to enforce firewall rules and routing policies. For high availability, create subnets in at least two regions. For example, us-central1 and us-east1 each have web, app, and db subnets. Use consistent naming: {env}-{region}-{tier}. This makes firewall rules and monitoring easier. Each subnet should have a /24 or larger to accommodate growth. For GKE, use secondary ranges for pods and services to avoid IP exhaustion.

for region in us-central1 us-east1; do
  for tier in web app db; do
    gcloud compute networks subnets create prod-${region}-${tier} \
      --network=prod-vpc \
      --region=${region} \
      --range=10.0.${RANDOM:0:2}.0/24
  done
done

Private Google Access: Enabling Internal API Calls

Private Google Access allows VM instances without external IPs to reach Google APIs and services (Cloud Storage, BigQuery, etc.) through Google's internal network. This is critical for security: you don't want your database servers talking to the internet. Enable it per subnet. Without it, your private instances will fail to pull container images or write logs. Always enable it on subnets that host backend services. It's a checkbox in the console or a flag in gcloud. Don't forget it—it's a common cause of 'works on my machine' failures.

gcloud compute networks subnets update prod-us-central1-web \
  --enable-private-ip-google-access

Firewall Rules: Least Privilege at Scale

Firewall rules in GCP are stateful and evaluated in order of priority (lower number = higher priority). Default rules allow all internal traffic and deny all ingress from outside. For production, you need to lock down inter-tier traffic. For example, only allow web tier to talk to app tier on port 8080, and app tier to db tier on port 3306. Use service accounts and tags to group instances. Avoid using source IP ranges for dynamic workloads—use tags instead. Always log denied traffic to detect misconfigurations. Remember: firewall rules are global, so a rule applies to all regions unless you specify source and destination tags.

gcloud compute firewall-rules create allow-web-to-app \
  --network=prod-vpc \
  --priority=1000 \
  --direction=INGRESS \
  --source-tags=web \
  --target-tags=app \
  --allow=tcp:8080 \
  --log-config=enable=true

VPC Peering: Connecting VPCs Across Projects

VPC peering allows you to connect two VPCs so they can communicate using internal IPs. This is useful for multi-project architectures (e.g., shared services VPC with monitoring tools). Peering is not transitive: if VPC A is peered with VPC B, and VPC B with VPC C, A cannot talk to C. Plan your peering topology as a hub-and-spoke model. Use a shared VPC for most cases instead of multiple peerings. Also, beware of overlapping IP ranges—peering fails if CIDRs overlap. Always check for conflicts before creating a peering.

gcloud compute networks peerings create prod-to-shared \
  --network=prod-vpc \
  --peer-project=shared-project \
  --peer-network=shared-vpc \
  --auto-create-routes

Cloud NAT: Outbound Connectivity for Private Instances

Private instances (no external IP) need Cloud NAT to access the internet for updates, package downloads, or external APIs. Cloud NAT is a regional managed service that provides outbound NAT. You configure it per region and associate it with a Cloud Router. Without Cloud NAT, private instances can't reach the internet. This is a common oversight when migrating from on-premises. Cloud NAT also supports static IP addresses for whitelisting. Always enable logging to debug connectivity issues.

gcloud compute routers create nat-router \
  --network=prod-vpc \
  --region=us-central1

gcloud compute routers nats create nat-config \
  --router=nat-router \
  --region=us-central1 \
  --nat-all-subnet-ip-ranges \
  --auto-allocate-nat-external-ips \
  --enable-logging

Hybrid Connectivity: VPN and Interconnect

Connecting on-premises networks to GCP requires either Cloud VPN (IPsec) or Dedicated Interconnect. Cloud VPN is simpler but limited to 3 Gbps per tunnel. Use it for low-bandwidth or test environments. For production, use Dedicated Interconnect for 10 Gbps or higher with SLA. Both require a Cloud Router for dynamic routing (BGP). Always use BGP over static routes to handle failover automatically. Plan your IP ranges to avoid overlap with on-premises. Test failover regularly—we've seen VPN tunnels drop without triggering alerts.

gcloud compute vpn-tunnels create onprem-tunnel \
  --region=us-central1 \
  --peer-address=203.0.113.1 \
  --shared-secret=mySecretKey \
  --ike-version=2 \
  --local-traffic-selector=10.0.0.0/16 \
  --remote-traffic-selector=192.168.0.0/16

Shared VPC: Centralized Network Management

Shared VPC allows you to host a VPC in a central project (host project) and share its subnets with other projects (service projects). This is the recommended pattern for multi-team organizations. The host project owns the network resources (VPC, subnets, firewall rules), while service projects deploy their workloads into those subnets. This centralizes control and avoids IP fragmentation. However, it requires careful IAM: grant compute.networkUser role to service project teams. Also, be aware that Shared VPC is not transitive—you can't share a shared VPC further.

gcloud compute shared-vpc enable shared-host-project

gcloud compute shared-vpc associated-projects add service-project-1 \
  --host-project=shared-host-project

Monitoring and Logging: VPC Flow Logs and Firewall Insights

You can't fix what you can't see. Enable VPC Flow Logs on subnets to capture metadata about IP traffic. This helps with troubleshooting, capacity planning, and security analysis. Flow Logs are sampled (default 1 per 10 packets) and cost money, so enable them selectively on critical subnets. Also, enable Firewall Insights to see which firewall rules are being hit and identify unused rules. Set up alerts for denied traffic spikes—they often indicate misconfigurations or attacks. Use Cloud Logging to export logs to BigQuery for long-term analysis.

gcloud compute networks subnets update prod-us-central1-web \
  --enable-flow-logs \
  --logging-aggregation-interval=INTERVAL_5_SEC \
  --logging-flow-sampling=0.5 \
  --logging-metadata=INCLUDE_ALL_METADATA

IPv6 Support in VPC: Dual-Stack and IPv6-Only Subnets

GCP VPCs support IPv4-only (single-stack), dual-stack (IPv4 + IPv6), and IPv6-only subnets. Internal IPv6 addresses (ULAs from fd20::/20) are private and not internet-routable. External IPv6 addresses (GUAs) are publicly routable and available only in Premium Tier. When you enable IPv6 on a subnet, a /64 range is assigned. The first and last /96 of internal /64 ranges are reserved for system use. For dual-stack subnets, VM interfaces get both IPv4 and IPv6 /96 addresses. Production insight: plan your IPv6 allocation upfront. The VPC network gets a /48 ULA range, and each subnet gets a /64 from that. You can provide a custom /48 ULA to avoid conflicts with on-premises networks. We migrated a legacy app to IPv6-only subnets and discovered that some monitoring tools didn't support IPv6. Always test application compatibility before migrating.

# Create a subnet with internal IPv6
gcloud compute networks subnets create prod-us-central1-ipv6 \
  --network=prod-vpc \
  --region=us-central1 \
  --range=10.0.10.0/24 \
  --stack-type=IPV4_IPV6 \
  --ipv6-access-type=INTERNAL

# Create a VM with IPv6 on this subnet
gcloud compute instances create ipv6-vm \
  --zone=us-central1-a \
  --subnet=prod-us-central1-ipv6 \
  --stack-type=IPV4_IPV6

Packet Mirroring: Deep Traffic Inspection

Packet Mirroring clones traffic from a mirrored source (VM instance or tag) and forwards it to a collector destination (internal load balancer or another VM). This is used for intrusion detection systems, application performance monitoring, and compliance logging. It captures all traffic (ingress and egress) on the source's network interfaces, including metadata. Packet Mirroring is a regional resource—source and collector must be in the same region. Important: Packet Mirroring doubles the traffic cost for the mirrored VMs because mirrored traffic is billed separately. Production insight: use Packet Mirroring selectively on sensitive workloads (e.g., database servers), not on all VMs. We saw a client mirroring all traffic in a 500-VM fleet, doubling their network bill. Focus on high-value targets and use sampling.

gcloud compute packet-mirrorings create prod-db-mirror \
  --region=us-central1 \
  --collector-ilb=mirror-collector \
  --network=prod-vpc \
  --filter-cidr-ranges=10.0.2.0/24 \
  --mirrored-tags=db-server

VPC Service Controls: Prevent Data Exfiltration

VPC Service Controls (VPC SC) define a security perimeter around Google Cloud services like Cloud Storage, BigQuery, and Cloud Bigtable. Within the perimeter, data can flow freely. Outside the perimeter, data exfiltration is blocked. You can configure perimeters per project or across multiple projects. VPC SC also allows you to define ingress and egress rules for specific identities or VPCs. This is critical for compliance frameworks that require data residency and exfiltration prevention. Production insight: VPC SC can break legitimate cross-service integrations. For example, a Cloud Function in a non-perimeter project can't access a Cloud Storage bucket in a perimeter project unless you configure an egress rule. We had a client enable VPC SC and immediately break their CI/CD pipeline because the CI service account was outside the perimeter. Test in a staging environment first.

# Create a VPC Service Controls perimeter (via Access Context Manager)
gcloud access-context-manager perimeters create prod-perimeter \
  --title="Production Perimeter" \
  --resources=projects/123456789,projects/987654321 \
  --restricted-services=storage.googleapis.com,bigquery.googleapis.com \
  --access-levels=accessPolicies/123/accessLevels/corporate_network

# Add ingress rule (allow CI/CD access)
gcloud access-context-manager perimeters update prod-perimeter \
  --add-ingress-policies="sourceIdentities=serviceAccount:ci-sa@project.iam.gserviceaccount.com,resources=projects/123456789"

Common Pitfalls and How to Avoid Them

Even experienced teams make mistakes. Here are the top pitfalls: (1) IP overlap with on-premises or peered VPCs—always document and use an IPAM tool. (2) Forgetting to enable Private Google Access on subnets—add it to your subnet creation script. (3) Using default VPC in production—just don't. (4) Overly permissive firewall rules—use tags and least privilege. (5) Not planning for GKE secondary ranges—you'll have to recreate the cluster. (6) Ignoring Cloud NAT for private instances. (7) Assuming VPC peering is transitive. Avoid these by using Infrastructure as Code (Terraform) and peer reviews for network changes.

resource "google_compute_network" "vpc" {
  name                    = "prod-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "subnet" {
  name          = "prod-us-central1-web"
  network       = google_compute_network.vpc.id
  region        = "us-central1"
  ip_cidr_range = "10.0.1.0/24"
  private_ip_google_access = true
}