Google Cloud Platform
Intermediate 16 min read Google Cloud Platform

VPC & Networking

A VPC is your isolated network inside Google Cloud, built from regional subnets rather than a single CIDR. Learn firewall rules, Cloud NAT and routing, plus the global Cloud Load Balancing, Cloud DNS and Cloud CDN that sit in front of your services.

VPCsubnetfirewall rulerouteCloud NATCloud Load Balancingforwarding ruleCloud DNSCloud CDNanycast IP
Introduction

What is this?

A VPC (Virtual Private Cloud) is your isolated network inside Google Cloud. GCP VPCs are global, divided into regional subnets with their own CIDR ranges. You control traffic with firewall rules (stateful, applied per network and target tag) and routes. Cloud NAT gives private instances outbound internet access without public IPs. Cloud Load Balancing fronts your backends behind a single global anycast IP, Cloud DNS is the managed DNS service, and Cloud CDN caches content at Google's edge points.

Motivation

Why do you need it?

  • Every resource you deploy — VMs, GKE clusters, Cloud SQL — lands in a subnet of a VPC, so networking mistakes take down entire environments.
  • Firewall rules are the first security layer for GCP workloads; misconfigurations cause both breaches and outages.
  • A global anycast IP simplifies failover and lets one DNS name serve backends across regions.
  • Cloud NAT and private Google access let private workloads reach the outside without exposing them.
  • Understanding subnets, routes, peering and load balancing is required for production architectures.
Think about it

Mental model

Imagine

A gated campus with roadways and a central dispatch

Think of

A VPC and its services

The campus fence is the VPC boundary. Roads (subnets) are regional streets with assigned address ranges. The mailroom (Cloud NAT) lets private buildings make outbound calls without opening inbound doors. Security desks (firewall rules) check everyone entering a building. The dispatch office (Cloud Load Balancing) receives all visitor requests at one address and sends each to whichever building is free — even one in another wing (region). The phonebook (Cloud DNS) tells visitors which number maps to which building.

Mechanics

How it works

  • You create a VPC and define regional subnets; in custom mode you control each subnet's range, while auto mode creates ranges automatically.
  • Firewall rules filter traffic by source, target tags, ports and protocols; VPC firewall rules are stateful, so return traffic for an allowed connection is handled automatically.
  • An external HTTP(S) load balancer uses a single global anycast IP and routes to backend services by URL, with health checks deciding which backends receive traffic.
  • Cloud NAT gives private instances outbound internet access without public IPs, while private Google access lets them reach Google APIs privately.
  • Cloud DNS maps names to IPs with managed zones and recordsets; Cloud CDN caches origin responses at edge locations.

Traffic paths inside a GCP VPC with load balancing and NAT.

VPC with regional subnets
Firewall rules
Private instances
Global load balancer
Health checks
Cloud DNS + Cloud CDN
Reference

Key commands

gcloud compute networks create my-vpc --subnet-mode=custom

Create a VPC with manual subnet control.

gcloud compute networks subnets create web-subnet --network=my-vpc --region=us-central1 --range=10.0.1.0/24

Add a regional subnet with a specific CIDR range.

gcloud compute firewall-rules create allow-http --network=my-vpc --allow=tcp:80,tcp:443 --target-tags=http-server

Allow HTTP and HTTPS traffic to tagged instances.

gcloud compute forwarding-rules list

List the load balancer forwarding rules.

gcloud dns record-sets list --zone=my-zone

List the DNS records in a managed zone.

gcloud compute networks list

List all VPC networks in the project.

Hands-on

Examples

Create a VPC, subnet and DNS zone

Create a VPC, subnet and DNS zone
$ gcloud compute networks create my-vpc --subnet-mode=custom
Created [https://www.googleapis.com/compute/v1/projects/my-project/global/networks/my-vpc].
$ gcloud compute networks subnets create web-subnet \
--network=my-vpc --region=us-central1 --range=10.0.1.0/24
Created [https://www.googleapis.com/compute/v1/projects/my-project/regions/us-central1/subnetworks/web-subnet].
$ gcloud dns managed-zones create my-zone \
--dns-name="example.com." --description="Production zone"
Created [https://dns.googleapis.com/.../managedZones/my-zone].

The VPC is created in custom mode so you own every subnet range. The subnet carves 10.0.1.0/24 out of us-central1, giving instances there a stable private range. The Cloud DNS managed zone takes ownership of example.com and becomes the source of truth for its records.

Real world

In production

  • Run web tiers behind a global external HTTP(S) load balancer so one anycast IP works across regions.
  • Use Cloud NAT for private instances that need outbound updates and APIs without public IPs.
  • Peer VPCs (or use Shared VPC) to connect environments without exposing them to the internet.
  • Use private Google access to reach GCS, BigQuery and other APIs from private subnets.
  • Place Cloud CDN in front of HTTP(S) backends to cut latency and egress for repeatable content.
Guidelines

Best practices

  • Prefer custom-mode VPCs so you control ranges and avoid overlap with peered networks.
  • Use network tags to apply firewall rules to groups of instances rather than raw IP ranges.
  • Keep public-facing resources in subnets with a route to the internet and private workloads in isolated subnets.
  • Use IAP (Identity-Aware Proxy) for admin access instead of opening ports to the world.
  • Design subnets with room to grow — expanding ranges later is painful.
Watch out

Common mistakes

  • Using auto-mode VPCs and then hitting overlapping ranges when peering.
  • Opening firewall rules to 0.0.0.0/0 for admin ports and calling it temporary.
  • Placing databases in public subnets so developers can connect from home.
  • Forgetting that firewall rules must still explicitly allow inbound traffic, even though they are stateful.
  • Putting every environment in one VPC and losing blast-radius isolation.
Root cause analysis

Common issues

Error
VM cannot reach the internet
Root cause

No public IP and no Cloud NAT, or an egress firewall rule blocks outbound traffic.

Fix

Add Cloud NAT for the subnet or assign an external IP, and verify egress firewall rules allow the traffic.

Error
Firewall rule is not applying to an instance
Root cause

The rule targets a tag the instance does not have.

Fix

Verify with gcloud compute instances describe, then set the tag on the instance or retarget the rule.

Error
DNS record is not resolving
Root cause

The managed zone exists but the domain's nameservers are not pointing at Cloud DNS.

Fix

Check the zone's assigned NS records with gcloud dns managed-zones describe and update the domain registrar.

When things break

Debugging tips

  • Trace the path: check the subnet range, the firewall rule, then the VM's tags.
  • Use gcloud compute firewall-rules list and gcloud compute instances describe to confirm tags and rules align.
  • Test TCP on the real port, not just ICMP — many firewalls allow ping but block the service.
  • Remember a VM without a public IP cannot be reached from the internet, period.
  • Check gcloud dns record-sets list when DNS fails before blaming the application.
Interviews

Interview checkpoint

Practice

Hands-on lab

Trace Local Network Paths Like a Network Engineer
25 min · intermediate
In progress
Objectives
  • Confirm the local interface and routing configuration
  • Test loopback, local and remote connectivity
  • Resolve hostnames with dig and nslookup
  • Inspect HTTP reachability and headers with curl

Trace Local Network Paths Like a Network Engineer

25 min · intermediate

0/6 steps
0%
sandbox · Linux sandbox
$
Try these commands
Test yourself

Quick quiz

0/3
1

Which component routes outbound traffic for private instances without assigning them public IPs?

2

GCP firewall rules are stateful: return traffic for an allowed connection is handled automatically.

3

A VM in a private subnet can call Google APIs but cannot download packages from the public internet. What is missing?

Quick reference

Cheat sheet

VPC building blocks
VPCGlobal isolated network
SubnetRegional CIDR range
Firewall ruleStateful filter by tag, IP and port
Cloud NATOutbound-only internet for private subnets
RouteNext-hop mapping for a destination range
Edge services
Global HTTP(S) LBOne anycast IP, cross-region failover
Cloud DNSManaged zones and recordsets
Cloud CDNEdge cache for HTTP(S) content
Private Google accessReach Google APIs from private subnets
Go deeper

Official documentation