What Is a VPC in GCP? Networks, Subnets, and How They Work

Every VM, private database, and network-attached service in Google Cloud lives inside a VPC. Before you create your first resource or connect two services together, you need to understand what a VPC actually is, how subnets and firewall rules fit into it, and why GCP’s approach to networking is different from what you might expect.

Simple explanation: what is a VPC?

A VPC (Virtual Private Cloud) is your private, isolated slice of Google’s global network. Every resource that needs to communicate over a network — virtual machines, private database instances, Kubernetes nodes — lives inside one. The VPC gives those resources private IP addresses, controls which traffic is allowed to reach them, and determines how packets are routed between them.

Analogy

Think of a VPC as the private network inside a company office. Devices inside the office reach each other easily. Visitors from outside only get through the front desk if they’re expected and cleared. The office is completely separate from every other company’s office, even if they share the same building. In GCP, the front desk is your firewall. The building is Google’s physical infrastructure. Your office is your VPC.

One thing that surprises most people coming from AWS: a GCP VPC is a global resource. It does not belong to one region. You can have subnets in us-central1, europe-west1, and asia-east1 all inside the same VPC, communicating privately over Google’s backbone. Subnets are regional. The VPC itself is not.

GCP creates a default VPC in every new project so resources can be deployed immediately. That default VPC works for quick experiments, but it ships with permissive firewall rules that are not safe for production. For anything beyond a demo, you want a custom VPC you control entirely.

What a VPC network actually is

A VPC is a software-defined network. There is no physical hardware assigned to it — GCP manages everything at the software layer. Inside your VPC, you decide which IP address ranges are used, which resources can talk to each other, and what traffic is allowed in or out. GCP enforces all of that at the network level, before packets ever reach your VMs.

A GCP project can have multiple VPC networks. Each is completely isolated from every other VPC by default — traffic cannot cross VPC boundaries unless you explicitly connect them with VPC Peering or Shared VPC.

Two things are always true about GCP VPCs that differ from other cloud providers:

A VPC is global. It exists across all regions simultaneously. You do not create separate VPCs per region.
Subnets are regional. Each subnet lives in one region and provides IP addresses for resources there. All subnets in a VPC can communicate over private IPs by default.

Coming from AWS?

In AWS, a VPC is regional and you typically create one per region. In GCP, one VPC spans all regions automatically. A VM in us-central1 and a VM in europe-west1 can share the same VPC and communicate privately — no VPN, peering, or extra configuration needed.

How a GCP VPC works

Mental model

Think of your VPC as a country, your subnets as cities inside it, and your VMs as buildings in those cities. Every building has a street address (private IP) within its city’s numbering scheme (subnet CIDR). Firewall rules are the border checkpoints: they decide which traffic crosses in or out. Routes are the road signs: they tell packets which direction to travel. You have to deliberately build a road to the outside world — and unless you do, nothing reaches in from there either.

Here is the step-by-step picture of how the pieces connect:

You create a VPC. It is a global resource with a name and a subnet mode (custom or auto). No subnets or IP ranges exist yet.
You create subnets in specific regions. Each subnet has a CIDR range — for example, 10.0.1.0/24 in us-central1. A VM placed in that subnet gets a private IP from that range.
You create resources inside subnets. A VM in us-central1 gets a private IP like 10.0.1.5. A VM in europe-west1 in a different subnet gets 10.0.2.7. Both are in the same VPC and reach each other privately.
Firewall rules control what traffic is allowed. The VPC starts with an implicit rule that denies all inbound traffic. You create explicit rules to open what you need — for example, allow TCP 443 from anywhere, or allow port 5432 only from your application servers. See Firewall Rules Explained.
Routes determine where packets go. Every VPC gets system-generated routes: one lets all subnets reach each other, and a default route sends internet-bound traffic to the internet gateway. Custom routes handle more complex topologies. See Routes in GCP.
External access is optional and explicit. A VM with only a private IP cannot be reached from the internet, and cannot initiate outbound internet connections either. For outbound-only internet access without a public IP, use Cloud NAT. For inbound access, assign an external IP and create matching firewall rules.

Nothing gets in or out unless you decide it should. And because the VPC is global, resources in different regions participate in the same private network without any special setup.

Key components of a GCP VPC

Subnets

Subnets divide your VPC into regional IP ranges. Each subnet covers one region and all zones within it — unlike AWS, where subnets are zonal. When you create a VM, you choose a subnet and the VM gets a private IP from that range. Plan CIDR ranges before you start — overlapping ranges block you from connecting VPCs via peering later. See Subnets in GCP for planning guidance and how secondary ranges work for GKE.

Firewall rules

Firewall rules are the access control layer. They specify which traffic is allowed in (ingress) or out (egress) of your VMs, and they are stateful: if inbound traffic is permitted, return packets are automatically allowed. Rules can target all VMs in the network, or specific VMs via network tags or service accounts. See Firewall Rules Explained.

Routes

Routes tell the VPC where to forward packets. GCP generates default routes at VPC creation: one lets all subnets reach each other, and a default route handles internet-bound traffic. Custom routes direct traffic to a VPN gateway, a network appliance, or other destinations. See Routes in GCP.

IP addresses

Every VM gets a private (internal) IP from its subnet. External (public) IPs are optional and explicitly assigned. Private IPs are stable for the life of a VM; external IPs are ephemeral by default and change on restart unless you reserve a static one. See Private vs Public IP Addresses.

When to use a custom VPC

Every GCP project running compute or database resources needs a VPC. The question is whether to use the default one or create your own. In almost every real workload, you want a custom VPC. Here are the common scenarios:

Running VMs with no public internet exposure. Create subnets with no external IPs on instances. Use firewall rules to allow only the internal traffic you need. Everything stays off the public internet.
Separating environments. Many teams run separate VPCs for dev, staging, and production so a misconfiguration in dev cannot reach production databases. You can also use isolated subnets with strict firewall rules within a single VPC.
Building a multi-region application. Because a GCP VPC is global, you can deploy frontend servers in us-central1 and database replicas in europe-west1 inside the same VPC, communicating privately over Google’s backbone.
Sharing a network across multiple projects. Use Shared VPC to centralise networking in one host project while other teams deploy into its subnets. This is the standard pattern for organisations with multiple GCP projects.
Deploying GKE clusters or private Cloud SQL instances. Both require a VPC with properly planned subnets. GKE in particular needs careful CIDR planning — pod and service IP ranges consume large blocks of address space.

VPC vs subnet: what is the difference?

Analogy

A VPC is the whole country. A subnet is a city within that country. When a VM is created, it moves into a specific city (subnet) and gets an address on a specific street (private IP from the subnet’s range). The country sets the outer boundary — anything outside it is unreachable by default. The cities organise the address space within.

A VPC is the container. It is a global network boundary that defines isolation. Everything inside can potentially communicate with everything else in the VPC, subject to firewall rules. Everything outside is unreachable by default. One project can have multiple VPCs, and each is entirely separate.

A subnet is a regional IP range inside the VPC. You do not place a VM directly in a VPC — you place it in a subnet. The subnet determines the region and the IP address range the VM draws from. A single VPC can have subnets across every GCP region.

The chain in plain terms: VPC contains subnets, subnets contain resources, resources get private IPs from their subnet’s range, firewall rules and routes apply at the VPC level and affect everything inside it.

Note

GCP subnets are regional — one subnet covers all zones within a region. AWS subnets are zonal. Moving from AWS to GCP, you will create far fewer subnets: one per region per tier, rather than one per availability zone per tier.

Default VPC vs custom VPC

Every new GCP project gets a default VPC created automatically, with subnets pre-built in every region. This makes it easy to spin up resources immediately, but there are real reasons not to use it in production.

The default VPC

Uses auto mode — subnets created automatically in all regions with fixed, predefined IP ranges
Ships with firewall rules allowing SSH (port 22) and RDP (port 3389) from any IP address on the internet
IP ranges per region are fixed and cannot be changed
Cannot be peered with other auto mode VPCs because their ranges overlap across projects
Convenient for experiments and learning; not safe for production

A custom VPC

You create subnets manually, choosing region and CIDR range for each
Starts with no firewall rules except the implicit deny-all-ingress — you add only what you need
You control CIDR ranges, so you can design non-overlapping spaces for peering
Required for any production workload, any security-sensitive environment, and any setup involving Cloud VPN, Cloud Interconnect, or VPC Peering

See Default vs Custom Networks for the full comparison, including how to safely delete the default VPC and block its creation via org policy.

Warning

The default VPC ships with firewall rules that allow SSH and RDP from any IP address (0.0.0.0/0). Every VM you create with an external IP is immediately exposed to brute-force bots and internet scanners. If you use the default VPC for anything beyond a throwaway demo, delete or disable those permissive rules and replace them with targeted, restricted ones.

Connecting VPCs: Peering and Shared VPC

VPCs are isolated by default. When resources in two separate VPCs need to communicate, you have two options:

VPC Peering

VPC Peering connects two VPCs so resources in each can reach the other using private IPs. It works across projects and across organisations. Two constraints: peering is non-transitive (if A peers with B and B peers with C, A still cannot reach C without a direct peering), and peered VPCs must have non-overlapping CIDR ranges. This is why CIDR planning matters before you create anything.

Shared VPC

Shared VPC is the right model when multiple projects in the same organisation share one network. One project (the host) owns the VPC and subnets. Other projects (service projects) deploy resources into the host VPC’s subnets. Network management is centralised while application teams manage their own workloads independently. For organisations with more than a couple of GCP projects, Shared VPC is usually the better choice over peering for same-org connectivity.

Which one should you use?

Use VPC Peering when connecting VPCs across different organisations, or when the teams involved cannot share a host project. Use Shared VPC when all projects belong to the same GCP organisation and centralised network management is acceptable — it is simpler to operate at scale because there is one network to manage rather than many bilateral peerings.

Practical example: a production VPC setup

Here is what a typical production VPC looks like for a web application serving users in two regions. Three tiers: web frontend, application layer, database.

# Create a custom mode VPC
gcloud compute networks create production-vpc \
  --subnet-mode=custom \
  --description="Production application network"

# Subnets in us-central1, one per tier
gcloud compute networks subnets create web-us \
  --network=production-vpc \
  --region=us-central1 \
  --range=10.0.1.0/24

gcloud compute networks subnets create app-us \
  --network=production-vpc \
  --region=us-central1 \
  --range=10.0.2.0/24

gcloud compute networks subnets create db-us \
  --network=production-vpc \
  --region=us-central1 \
  --range=10.0.3.0/24

# Mirror subnets in europe-west1 for redundancy
gcloud compute networks subnets create web-eu \
  --network=production-vpc \
  --region=europe-west1 \
  --range=10.1.1.0/24

gcloud compute networks subnets create app-eu \
  --network=production-vpc \
  --region=europe-west1 \
  --range=10.1.2.0/24

All five subnets are in the same VPC. Web servers in us-central1 talk privately to app servers in the same region. App servers in the US can reach a database replica in europe-west1 over Google’s private backbone, without touching the public internet. Cross-region traffic within a VPC is private — but GCP charges egress fees for data crossing region boundaries, so architect accordingly.

The firewall rules for this setup allow only:

HTTPS (443) inbound to web-tagged VMs from the internet
Application traffic from web-tagged VMs to app-tagged VMs on the app port
Database traffic (e.g. port 5432) from app-tagged VMs to database-tagged VMs only
SSH from a restricted CIDR range to management-tagged VMs

For VMs that need to call Google APIs without external IPs, enable Private Google Access on each subnet. For Cloud Run or Cloud Functions that need to reach resources inside your VPC, use Serverless VPC Access. To see how a VPC fits into the actual VM creation flow, start with Creating Your First VM.

Common beginner mistakes

Assuming VPCs are regional, like in AWS. GCP VPCs are global. A single VPC spans every region. When AWS tutorials show separate VPCs per region, that is the AWS model — do not carry it into GCP. Create one VPC with subnets in multiple regions rather than a separate VPC per region.
Using the default VPC for production. Every GCP project starts with a default auto-mode VPC that has SSH and RDP open to the entire internet. It is built for convenience in demos and learning, not for real workloads. Create a custom VPC with explicit, minimal firewall rules from the start and consider deleting the default VPC so it cannot be accidentally used.
Not planning CIDR ranges before creating subnets. If you use 10.0.0.0/8 in every VPC without thinking about it, you will be unable to peer them later — peering requires non-overlapping address spaces. Decide on your IP addressing scheme before creating any subnets, especially if Cloud VPN, Cloud Interconnect, or VPC Peering is in the plan.
Confusing VPC firewall rules with OS-level firewalls. GCP firewall rules operate at the network level before a packet reaches your VM. An OS firewall (iptables, ufw, Windows Firewall) can also be running inside the VM. Both apply in sequence — if you open port 80 in GCP but iptables is blocking it, traffic still will not get through. Check both layers when diagnosing connectivity issues. See Troubleshooting Network Issues.
Assigning external IPs to VMs that do not need them. Every VM with an external IP is exposed to internet scanning and brute-force bots. VMs serving only internal traffic should use private IPs only. Use Cloud NAT for outbound internet access. Only assign an external IP when you genuinely need inbound traffic from the internet.

Frequently asked questions

What is a VPC network in GCP?

A VPC (Virtual Private Cloud) is a private, logically isolated network inside Google Cloud. Every resource that needs network access — VMs, private database instances, GKE clusters — must belong to a VPC. The VPC controls IP addressing through subnets, traffic permissions through firewall rules, and packet routing through a managed route table.

Is a GCP VPC global or regional?

A GCP VPC is global. It spans all Google Cloud regions automatically. Subnets are regional — each subnet covers one region and provides IP addresses for resources placed there. A VM in us-central1 and a VM in europe-west1 can be in the same VPC and communicate privately over Google's backbone without any extra configuration.

What is the difference between a VPC and a subnet in GCP?

A VPC is the top-level private network boundary — global, and the container for all your subnets and resources. A subnet is a regional IP address range within that VPC. When you create a VM, you place it in a subnet and it gets a private IP from the subnet's CIDR range. One VPC can have many subnets across many regions.

Do I need a VPC to create resources in Google Cloud?

Yes. Any GCP resource that requires network access must belong to a VPC. GCP provides a default VPC in every new project so you can create resources immediately, but the default VPC has permissive firewall rules and should not be used for production workloads. Create a custom VPC with explicit, least-privilege rules for anything serious.

Can two VPCs communicate with each other?

Not by default — VPCs are isolated from each other. You can connect them with VPC Peering (works across projects and organisations, requires non-overlapping CIDRs) or Shared VPC (shares one network across multiple projects in the same organisation). Peering is non-transitive: if A peers with B and B peers with C, A cannot reach C through B without a direct peering between A and C.

Last verified: 24 March 2026 Cloud services change frequently. Verify details against official documentation before making infrastructure decisions.