NetworkingNetworking

Part of the Cloud knowledge base — GCP deep dive. Complements DevOps Roadmap.

Overview

Networking is where GCP diverges most sharply from AWS, and the difference is architectural, not cosmetic. In GCP a VPC network is a global resource: one VPC spans every region, and you add regional subnets to it as you expand. There is no per-region VPC and no need for peering just to connect two regions of your own network — Google’s private backbone already carries that traffic.

On top of that global fabric sit the pieces you assemble daily: subnets (IP space), routes (where packets go), firewall rules (what is allowed), Cloud Load Balancing (from a single global anycast IP down to internal L4), Cloud NAT (egress for private VMs), Cloud DNS, and Cloud CDN. This page maps them, calls out where GCP behaves differently from AWS, and shows worked gcloud and Terraform examples.

Fundamentals

VPC network — global, with regional subnets

A VPC network is a virtual, software-defined network that is global. Its subnets are regional and carve out IP ranges (CIDR blocks). Because the VPC is global, a VM in us-central1 and a VM in europe-west1 on the same VPC communicate over Google’s backbone using internal IPs — no peering, no gateway.

Subnet modes:

• Auto mode — Google auto-creates one subnet per region from a fixed 10.128.0.0/9 range. Convenient for demos, but the ranges are fixed and can collide on interconnect. Avoid in production.
• Custom mode — you define every subnet and its CIDR explicitly. Always use custom mode for production.

Each subnet also has secondary IP ranges used for alias IPs — the mechanism GKE uses to give Pods and Services their own routable ranges (“VPC-native” clusters).

Routes

Routes tell packets where to go. Every VPC has:

• A default route to the internet (0.0.0.0/0 → default internet gateway), which only takes effect for VMs that have an external IP or go through Cloud NAT.
• Subnet routes — automatically created for each subnet’s range.
• Custom static routes — e.g. send 10.8.0.0/16 to a VPN tunnel or a NAT appliance instance (next hop = instance, IP, VPN tunnel, or ILB).
• Dynamic routes — learned via Cloud Router over BGP (for Cloud VPN / Interconnect).

Routes are global VPC resources but can be scoped by instance network tags.

Firewall rules (and how they differ from AWS)

GCP firewall rules operate at the VPC level, not per-instance like AWS Security Groups. Key differences:

Two implied rules always exist at priority 65535: deny all ingress, allow all egress. You layer higher-priority (lower-number) rules on top. Because both allow and deny exist with priorities, you can express “allow the range but deny one noisy IP inside it” — impossible with AWS SGs alone.

Targeting by tag or service account is idiomatic GCP: instead of listing IPs, you say “allow tcp:443 ingress to instances tagged https-server”, or “…to instances running as serviceAccount:web@…”. SA-based targeting is stronger because tags are freely settable by anyone who can edit an instance.

Shared VPC vs VPC Peering

Two ways to connect networks — pick based on org structure:

Shared VPC is the standard enterprise landing-zone pattern: a network/security team owns the host project’s subnets and firewall rules, and application teams deploy workloads into those subnets from their own service projects without touching networking.

Key Concepts

Cloud NAT & Cloud Router

VMs without external IPs still often need outbound internet (package updates, calling external APIs). Cloud NAT provides managed, regional egress NAT with no NAT-instance to run or scale. It is a software-defined service (not a bottleneck instance) and integrates with Cloud Router, which manages the control plane and also runs BGP for dynamic routes over Cloud VPN / Interconnect.

# Regional Cloud Router + Cloud NAT so private VMs can reach the internet outbound
gcloud compute routers create nat-router \
  --network=prod-vpc --region=us-central1

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

Cloud NAT is egress-only — it does not allow unsolicited inbound. Inbound to private VMs comes via a load balancer or IAP.

Cloud Load Balancing

Google’s load balancers are a family; the first split is global vs regional, the second is external vs internal, the third is L7 (HTTP/S) vs L4 (TCP/UDP).

The global external Application Load Balancer is a signature GCP feature: a single anycast IP advertised worldwide sends each user to the nearest healthy backend over Google’s backbone, with built-in Cloud CDN and Cloud Armor (WAF/DDoS). This is the AWS “CloudFront + global accelerator + ALB” combination in one product. Its building blocks: forwarding rule → target proxy → URL map → backend service → backend (MIG/NEG) → health check.

Cloud DNS

Cloud DNS is Google’s managed, authoritative DNS with a 100% uptime SLA.

• Public zones serve records to the internet.
• Private zones resolve names only inside chosen VPCs (split-horizon).
• DNS peering and forwarding integrate with on-prem/other VPC resolvers.
• DNSSEC signs public zones.

gcloud dns managed-zones create app-zone \
  --dns-name="app.example.com." --description="app zone" --visibility=public

gcloud dns record-sets create www.app.example.com. \
  --zone=app-zone --type=A --ttl=300 --rrdatas="203.0.113.10"

Cloud CDN

Cloud CDN caches content at Google’s edge POPs, fronting a backend service on the global external Application Load Balancer. Enabling it is a flag on the backend service; it uses cache keys, TTLs, and signed URLs/cookies for private content. Because it rides the same LB, you get global anycast + CDN + WAF as one stack.

Private connectivity: Private Google Access & Private Service Connect

Reaching Google APIs (Cloud Storage, BigQuery) and managed services without traversing the public internet:

• Private Google Access — lets VMs with only internal IPs reach Google APIs and services via internal routing. Enabled per-subnet.
• Private Service Connect (PSC) — exposes a service (a Google API, a managed service like Cloud SQL, or a partner/your own service) behind a private IP in your VPC. You consume it as if it lived in your network; traffic never touches the internet. The modern replacement for many private-access patterns.
• VPC Service Controls — a separate control that draws a service perimeter around resources (e.g. buckets) to stop data exfiltration even by valid credentials.

VPC Flow Logs

VPC Flow Logs sample the network flows (5-tuple, bytes, packets, latency, allow/deny decision) for a subnet and export them to Cloud Logging (and onward to BigQuery). Enabled per-subnet. Use them for network forensics, security analysis, cost/traffic-pattern insight, and troubleshooting connectivity — GCP’s analog to AWS VPC Flow Logs.

Hierarchical firewall policies

Beyond per-VPC firewall rules, hierarchical firewall policies attach at the Organization or Folder level and are inherited down to all VPCs beneath. They let a central security team enforce mandatory allow/deny (e.g. always allow health-check ranges, always deny a known-bad CIDR) that project teams cannot override. This is the firewall analog of hierarchical org policies. Network firewall policies (global/regional) are the newer VPC-level grouping that complements or replaces the classic per-rule model.

Worked example: VPC + subnet + firewall rule

gcloud:

# 1. Custom-mode global VPC
gcloud compute networks create prod-vpc --subnet-mode=custom

# 2. Regional subnet (primary + secondary range for GKE pods)
gcloud compute networks subnets create prod-usc1 \
  --network=prod-vpc --region=us-central1 \
  --range=10.10.0.0/20 \
  --secondary-range=pods=10.20.0.0/16,services=10.30.0.0/20 \
  --enable-private-ip-google-access \
  --enable-flow-logs

# 3. Allow HTTPS ingress only to instances tagged https-server
gcloud compute firewall-rules create allow-https \
  --network=prod-vpc --direction=INGRESS --action=ALLOW \
  --rules=tcp:443 --source-ranges=0.0.0.0/0 \
  --target-tags=https-server --priority=1000

# 4. Allow SSH only from the corporate range via IAP
gcloud compute firewall-rules create allow-ssh-iap \
  --network=prod-vpc --direction=INGRESS --action=ALLOW \
  --rules=tcp:22 --source-ranges=35.235.240.0/20 \
  --target-tags=ssh-allowed --priority=1000

(35.235.240.0/20 is Google’s IAP TCP-forwarding range — SSH via IAP means no public IP on the VM at all.)

Terraform equivalent:

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

resource "google_compute_subnetwork" "usc1" {
  name          = "prod-usc1"
  network       = google_compute_network.prod.id
  region        = "us-central1"
  ip_cidr_range = "10.10.0.0/20"

  secondary_ip_range {
    range_name    = "pods"
    ip_cidr_range = "10.20.0.0/16"
  }
  secondary_ip_range {
    range_name    = "services"
    ip_cidr_range = "10.30.0.0/20"
  }

  private_ip_google_access = true
  log_config { aggregation_interval = "INTERVAL_5_SEC" }
}

resource "google_compute_firewall" "allow_https" {
  name          = "allow-https"
  network       = google_compute_network.prod.id
  direction     = "INGRESS"
  priority      = 1000
  source_ranges = ["0.0.0.0/0"]
  target_tags   = ["https-server"]

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

Best Practices

1. Always use custom-mode VPCs in production. Auto mode’s fixed ranges cause collisions on peering/VPN and hand you subnets you never planned.
2. Plan non-overlapping CIDRs across all VPCs, on-prem, and other clouds. Overlaps make peering, VPN, and future mergers painful or impossible.
3. Target firewall rules by service account, not just network tags. Tags are editable by anyone who can modify an instance; SA-based targeting is tied to identity and far harder to spoof.
4. Default-deny and grant narrowly. Rely on the implied deny-all-ingress and open only the specific ports/sources you need; use deny rules for exceptions inside allowed ranges.
5. Use Shared VPC for multi-team orgs. Centralize subnets and firewalls in a host project owned by the network team; app teams get compute-only access.
6. Give VMs no external IP; use Cloud NAT for egress and IAP for admin access. Shrinks the attack surface dramatically — nothing is reachable inbound from the internet.
7. Enable Private Google Access on private subnets. Lets internal-only VMs reach Google APIs without an external IP or NAT hairpin.
8. Prefer Private Service Connect for consuming managed/partner services. Keeps traffic on private IPs and off the public internet.
9. Front public web apps with the global external Application LB + Cloud Armor + Cloud CDN. One stack gives you global anycast, WAF/DDoS, and edge caching.
10. Attach health checks to every backend service and remember to allow Google’s health-check ranges (35.191.0.0/16, 130.211.0.0/22) in your firewall.
11. Enable VPC Flow Logs on production subnets. Essential for security forensics and connectivity debugging; sample-rate-tune to control cost.
12. Use hierarchical firewall policies for org-wide guardrails. Enforce mandatory allow/deny at org/folder level that project teams cannot override.
13. Use Cloud DNS private zones for internal names, DNSSEC on public zones, and keep TTLs sensible for failover speed vs query cost.
14. Use Cloud Router + BGP for hybrid connectivity (Cloud VPN / Interconnect) so routes propagate dynamically instead of brittle static routes.
15. Add VPC Service Controls perimeters around sensitive data (buckets, BigQuery) to prevent exfiltration even with valid credentials.
16. Manage all networking as code (Terraform). Firewall and routing mistakes are high-blast-radius; reviewed, version-controlled changes are essential.

References

• VPC network overview
• Subnets
• Routes overview
• VPC firewall rules
• Firewall policies (hierarchical/network)
• Shared VPC
• VPC Network Peering
• Cloud NAT
• Cloud Router
• Cloud Load Balancing overview
• Application Load Balancer overview
• Cloud DNS
• Cloud CDN
• Private Google Access
• Private Service Connect
• VPC Flow Logs
• VPC Service Controls