Global VPC and Regional Subnets

On GCP a VPC is a global resource and its subnets are regional — the exact inverse of what an AWS engineer expects, where the VPC is regional and subnets are pinned to an availability zone. One google_compute_network for Hatch spans every region on Earth; you carve a google_compute_subnetwork in us-central1 out of it, and a VM in any zone of that region attaches to the same subnet with no AZ-to-subnet mapping to design around.

This single inversion is the source of most AWS-brain mistakes on GCP networking. If you replicate the one-subnet-per-AZ habit, you fragment your address space for no redundancy benefit and build a design that fights the platform. Internalize that the network is global and the subnet is regional, and the rest of GCP networking — Shared VPC, firewalls, private connectivity — falls into place.

The Network Is Global

A google_compute_network has no region. It is one routing domain that reaches every GCP region, so a VM in us-central1 and one in europe-west1 attached to the same VPC talk over Google's backbone using internal IPs, with no peering and no transit gateway between them. The VPC is the boundary; the regions are just where you place subnets inside it.

For Hatch, that means hatch-net-host holds exactly one global VPC. You do not create a VPC per region and stitch them together — there is one network object, and you add a regional subnet wherever you want to place workloads. The configuration below declares the host network in custom mode, which the next section explains.

resource "google_compute_network" "hatch" {
  project                 = "hatch-net-host"
  name                    = "hatch-vpc"
  auto_create_subnetworks = false   # declare every subnet explicitly
  routing_mode            = "GLOBAL"  # dynamic routes propagate across regions
}

Subnets Are Regional, Not Zonal

A google_compute_subnetwork belongs to exactly one region and carries a primary CIDR — say 10.10.0.0/20 for the Hatch app subnet in us-central1. Every zone in that region draws addresses from that one subnet. There is no per-AZ subnet to replicate, and no "which subnet do I use for zone -a versus -c" decision, because the zones share the regional subnet.

This is exactly where the AWS habit hurts. In AWS you build a subnet per availability zone and spread instances across them for resilience. On GCP that resilience is automatic within a regional resource — a regional managed instance group already spans the zones of us-central1 on the single subnet — so three hand-made "zonal" subnets just chop your /20 into fragments with no benefit.

resource "google_compute_subnetwork" "app" {
  project       = "hatch-net-host"
  name          = "app-uc1"
  region        = "us-central1"     # regional, not zonal
  network       = google_compute_network.hatch.id
  ip_cidr_range = "10.10.0.0/20"     # every zone of us-central1 shares this
}

Auto Mode vs Custom Mode

Setting auto_create_subnetworks = true creates an auto-mode VPC: Google spawns a /20 subnet in every region automatically, from a fixed default address plan. That is fine for a throwaway sandbox where you never peer or connect to on-prem. It is wrong for anything real, because those default ranges are prone to collide the moment you peer two VPCs or attach a VPN to a corporate network — and you cannot renumber an auto-mode VPC without recreating it.

For hatch-net-host you set auto_create_subnetworks = false and declare each subnet explicitly. Custom mode is the only sane choice for a network you intend to govern: you own the address plan, you place subnets only where you need them, and nothing collides because nothing was auto-generated behind your back.

Secondary IP Ranges

A subnet can carry named secondary_ip_range blocks beyond its primary CIDR. This is how GKE gets alias-IP ranges: a pods range and a services range so containers receive real, routable VPC addresses instead of being hidden behind NAT. The pods get genuine internal IPs, which is what makes GKE networking on GCP feel native rather than bolted on.

Size these up front, because a secondary range is effectively fixed once a cluster consumes it. A too-small /24 pods range caps the cluster's original node pools at a few hundred pods, and lifting that ceiling means adding a second pod range to the cluster and migrating the workloads onto new node pools, because a node pool's range is immutable. Plan a generous /16-class pods range and a smaller services range before the cluster exists, not after it hits the ceiling.

resource "google_compute_subnetwork" "gke" {
  project       = "hatch-net-host"
  name          = "gke-uc1"
  region        = "us-central1"
  network       = google_compute_network.hatch.id
  ip_cidr_range = "10.20.0.0/20"     # nodes

  secondary_ip_range {
    range_name    = "pods"
    ip_cidr_range = "10.96.0.0/14"   # sized for pod density, fixed once used
  }
  secondary_ip_range {
    range_name    = "services"
    ip_cidr_range = "10.100.0.0/20"
  }
}

Internal Ranges and Routing

The VPC has implied routes between all of its subnets, so subnets in different regions reach each other internally with no configuration. You size the primary range for the VMs you expect and the secondary ranges for the pod and service density you plan, and the routing between them is handled for you.

The discipline that matters is address planning. Overlapping the primary and a secondary range, or two subnets' ranges, breaks alias IPs or peering silently — the VPC accepts the config and the failure only surfaces when GKE or a peer tries to use the colliding range. Lay out non-overlapping CIDRs deliberately and write them down next to the code, because the cost of getting it wrong is a renumber or a rebuild.