GCP VPC Networking

A Virtual Private Cloud (VPC) is a private, isolated network within GCP where all cloud resources communicate with each other securely. Every VM, database, and cloud service lives inside a VPC network. Understanding VPC is essential because it controls how resources connect, communicate, and stay secure.

Imagine a company office building. The VPC is the building itself — it has different floors (subnets), internal phone lines (internal IPs), locked doors (firewall rules), and a main entrance for visitors (external IPs and NAT). Resources inside the building can talk to each other privately, and only approved traffic enters or leaves.

Key VPC Concepts

VPC Network

A VPC network is a global resource in GCP. Unlike most cloud providers, a single GCP VPC spans all regions. There is no need to create a separate VPC per region — one VPC can have subnets in multiple regions.

VPC Network: "my-app-vpc" (Global)
├── Subnet: us-central1-subnet  (10.0.1.0/24) — Iowa
├── Subnet: europe-west1-subnet (10.0.2.0/24) — Belgium
└── Subnet: asia-south1-subnet  (10.0.3.0/24) — Mumbai

Subnet

A subnet (subnetwork) is a range of IP addresses within a region. Resources like VMs are created inside subnets. Each subnet has a primary IP range defined using CIDR notation.

CIDR example: 10.0.1.0/24 means the IP range is 10.0.1.0 to 10.0.1.255 — providing 256 addresses.

Default VPC

Every new GCP project automatically has a default VPC with subnets in every region. It is useful for quick testing, but production environments should use custom VPCs for better control.

Types of VPC Networks

Internal and External IP Addresses

Internal IP:
┌────────────────────────────────────────┐
│  VPC Network                           │
│                                        │
│  VM A ──────────────────── VM B        │
│  10.0.1.5              10.0.1.6        │
│  (Talk to each other using             │
│   internal IPs — free, fast)           │
└────────────────────────────────────────┘

External IP:
┌────────────────────────────────────────┐
│  VM A                                  │
│  External IP: 34.68.100.25             │
│  (Reachable from the internet)         │
│  (Billed per hour when attached)       │
└────────────────────────────────────────┘

VMs that only need to communicate internally should not have external IPs. This reduces the attack surface and saves cost.

Firewall Rules

Firewall rules control which traffic is allowed into and out of VMs inside a VPC. Firewall rules are applied at the network level and target VMs using network tags or service accounts.

Firewall Rule Components

Example: Allow HTTP and HTTPS traffic to web servers

gcloud compute firewall-rules create allow-web-traffic \
  --network=my-app-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web-server

VMs with the network tag web-server will receive this rule. All other VMs in the same VPC are unaffected.

Creating a Custom VPC

# Create a custom VPC network
gcloud compute networks create my-app-vpc \
  --subnet-mode=custom

# Create a subnet in us-central1
gcloud compute networks subnets create us-subnet \
  --network=my-app-vpc \
  --region=us-central1 \
  --range=10.0.1.0/24

# Create a subnet in asia-south1
gcloud compute networks subnets create asia-subnet \
  --network=my-app-vpc \
  --region=asia-south1 \
  --range=10.0.2.0/24

Cloud NAT – Outbound Internet for Private VMs

VMs without external IPs cannot access the internet by default (they cannot download updates or call external APIs). Cloud NAT (Network Address Translation) solves this — it routes outbound traffic from private VMs through a managed gateway without exposing them to inbound internet traffic.

Private VM (no external IP)
        │
        │ Outbound request (e.g., apt-get update)
        ▼
Cloud NAT Gateway
        │
        ▼
Internet
        │
        ▼ Response comes back through NAT
Private VM receives the response
(Internet cannot initiate connections to this VM)

VPC Peering

VPC Peering connects two separate VPC networks so resources in each can communicate using internal IPs. This is useful when two projects need to share data privately without routing traffic over the internet.

Project A: VPC "prod-vpc" (10.0.0.0/16)
        │
        │ VPC Peering
        │
Project B: VPC "data-vpc" (10.1.0.0/16)

VM in prod-vpc can reach VM in data-vpc via 10.1.0.5 (internal IP)
No internet traffic involved.

Key Takeaways

• A GCP VPC is a global resource — one VPC can have subnets across all regions.
• Subnets define IP address ranges within a specific region.
• Use Custom Mode VPCs for production environments.
• Firewall rules control traffic using direction, protocol, port, and network tags.
• Avoid assigning external IPs to VMs that do not need internet access.
• Cloud NAT allows private VMs to make outbound internet requests securely.
• VPC Peering connects two VPCs for private internal communication.