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.
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.
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.
Mental model
A gated campus with roadways and a central dispatch
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.
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.
Key commands
gcloud compute networks create my-vpc --subnet-mode=customCreate a VPC with manual subnet control.
gcloud compute networks subnets create web-subnet --network=my-vpc --region=us-central1 --range=10.0.1.0/24Add 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-serverAllow HTTP and HTTPS traffic to tagged instances.
gcloud compute forwarding-rules listList the load balancer forwarding rules.
gcloud dns record-sets list --zone=my-zoneList the DNS records in a managed zone.
gcloud compute networks listList all VPC networks in the project.
Examples
Create a VPC, subnet and DNS zone
$ gcloud compute networks create my-vpc --subnet-mode=customCreated [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/24Created [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.
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.
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.
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.
Common issues
VM cannot reach the internetNo public IP and no Cloud NAT, or an egress firewall rule blocks outbound traffic.
Add Cloud NAT for the subnet or assign an external IP, and verify egress firewall rules allow the traffic.
Firewall rule is not applying to an instanceThe rule targets a tag the instance does not have.
Verify with gcloud compute instances describe, then set the tag on the instance or retarget the rule.
DNS record is not resolvingThe managed zone exists but the domain's nameservers are not pointing at Cloud DNS.
Check the zone's assigned NS records with gcloud dns managed-zones describe and update the domain registrar.
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.
Interview checkpoint
Hands-on lab
- 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
Quick quiz
Which component routes outbound traffic for private instances without assigning them public IPs?
GCP firewall rules are stateful: return traffic for an allowed connection is handled automatically.
A VM in a private subnet can call Google APIs but cannot download packages from the public internet. What is missing?
Cheat sheet
VPCGlobal isolated networkSubnetRegional CIDR rangeFirewall ruleStateful filter by tag, IP and portCloud NATOutbound-only internet for private subnetsRouteNext-hop mapping for a destination rangeGlobal HTTP(S) LBOne anycast IP, cross-region failoverCloud DNSManaged zones and recordsetsCloud CDNEdge cache for HTTP(S) contentPrivate Google accessReach Google APIs from private subnets