GCP
Intermediate 16 min read GCP

GCP VPC and Networking

Global VPCs, firewalls and hybrid connectivity

GCP VPCs are global: one network with regional subnets, global routing, firewall rules, Cloud NAT and VPC peering. Interconnect/Cloud VPN link on-prem; private service connect keeps PaaS private.

VPCsubnetfirewall rulesCloud NATpeeringCloud VPNInterconnect
Prerequisites: GCP Service Catalog Cloud Networking
Before we start

What you will learn

  • Design a global VPC with regional subnets
  • Apply firewall rules and Cloud NAT
  • Connect VPCs and on-prem with peering/Cloud VPN/Interconnect
In 60 seconds

GCP VPC is a global virtual network: subnets live in regions, routing is global, firewall rules attach to networks/tags, Cloud NAT gives ephemeral egress, and peering/Cloud VPN/Interconnect stitch networks together.

Introduction

What is this?

A GCP VPC is a software-defined global network spanning regions: custom subnets per region, global route propagation, and firewall rules (allow/deny by IP, tags, service accounts). Cloud NAT provides managed outbound NAT for private instances. VPC peering connects VPCs transitively as hub-spoke with no route complexity; Cloud VPN (IPsec) and Dedicated/Partner Interconnect connect on-prem data centers. Private Service Connect (and the older network peering) reach Google-managed services privately.

Motivation

Why do you need it?

  • Global routing means two regions share one route graph — simpler than per-region VPCs.
  • Tagged firewall rules express 'web tier can talk to app tier' in one rule.
  • Cloud NAT removes public-IP-everywhere for egress-heavy workloads.
  • Peering avoids gateways; Interconnect provides SLA-bound dedicated bandwidth.
Think about it

Mental model

Imagine

A national highway authority

Think of

Global VPC

One authority (VPC) manages roads (subnets) across regions with one rulebook (firewall rules). Tolls for private roads (Cloud NAT) let citizens leave the county; agreements with neighboring countries (peering/interconnect) connect the whole map.

Mechanics

How it works

  • Create a VPC with regional subnets (auto or custom mode); routes are global.
  • Firewall rules: allow/deny by source/target (IP ranges, tags, service accounts), default deny inbound except allow listed.
  • Cloud NAT: a static set of egress IPs; instances with no public IP can still reach the internet.
  • VPC peering: direct private connectivity between two networks, no gateway, DNS config needed.
  • Hybrid: Cloud VPN over the internet, or Interconnect with dedicated circuits; BGP advertisements on both.

A global VPC with hybrid connectivity.

VPC (global)
Region subnet
Cloud NAT
Firewall rules
Peering / VPN / Interconnect
Real world

In production

  • A multi-region SaaS uses one global VPC: eu and us subnets, each app tier behind a global LB, egress via Cloud NAT.
  • An enterprise connects on-prem via two Cloud VPN tunnels + BGP for redundancy.
  • A platform team peering hub VPC to each team's VPC for shared services (monitoring, bastion).
Guidelines

Best practices

  • Use custom-mode VPCs and plan CIDRs; overlap breaks peering/interconnect.
  • Default-denied firewall: open only required ports via tags, not whole subnets.
  • Centralize egress with a single Cloud NAT per region and route default via it.
  • Prefer peering + Private Service Connect over creating VMs as proxies for PaaS access.
Watch out

Common mistakes

  • Overlapping CIDRs across peered networks — silent route failures.
  • Firewall everything-open 'for dev', promoting to prod.
  • Tunneling one Cloud VPN tunnel with no failover/BGP redundancy.
  • Using public IPs on instances when Cloud NAT would do egress cleanly.
Root cause analysis

Common issues

Error
Instance with no public IP can't reach the internet
Root cause

No default route via Cloud NAT in the subnet

Fix

Add a 0.0.0.0/0 route with next-hop Cloud NAT and create the NAT gateway.

Error
Peered VPC can't reach the other's services
Root cause

Overlapping prefixes or firewall rules missing

Fix

Ensure disjoint prefixes and allow the required ports between the two networks' tags.

Error
On-prem to GCP drops periodically
Root cause

Single VPN tunnel without BGP redundancy

Fix

Add a second tunnel/path and enable BGP failover routing.

When things break

Debugging tips

  • Traffic blocked? Read effective firewall rules for the instance (gcloud compute firewall-rules list).
  • Ping/port fails across peering? Check both sides' prefixes and rules; same-VPC wins over peering.
  • NAT issues: check Cloud NAT's SNAT IPs and whether the route to 0.0.0.0/0 exists in the subnet.
  • VPN flaps: review tunnel status and BGP session state (established) rather than pinging blindly.
Interviews

Interview checkpoint

Practice

Hands-on lab

Build a VPC with Instance Templates and a Firewall (Plan)
30 min · intermediate
In progress
Objectives
  • Create a custom VPC with a regional subnet
  • Attach firewall rules scoped by tags
  • Validate the topology with gcloud or a IaC plan

Build a VPC with Instance Templates and a Firewall (Plan)

30 min · intermediate

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

Quick quiz

0/1
1

What provides outbound internet access to instances without public IPs on GCP?

Go deeper

Official documentation

GCP — VPC overview
docs
GCP — Firewall rules
docs
GCP — Cloud NAT
docs