Regional building block inside a global VPC
Google Cloud lets one VPC network span multiple regions, but each subnet belongs to one region.
That means subnet planning is where geography and IP design meet.
Subnet and subnetwork mean the same thing
In Google Cloud documentation, APIs, CLI commands, and the console, the words subnet and subnetwork are used interchangeably.
Where workloads actually land
Even though engineers often talk about “the VPC,” it is the subnet that usually determines placement, available IP space, and regional location for workloads.
Simple mental model: the VPC is your Google Cloud network boundary, while subnets are the regional lanes inside that network where actual workloads are placed.
Subnet lives in one region
If you create a subnet in europe-west1, that subnet belongs to europe-west1.
A workload in us-central1 cannot be placed into that subnet because subnet scope is regional.
One VPC can contain many subnets
A single VPC can have subnets in multiple regions, which makes Google Cloud VPC design flexible for multi-region applications and global organizations.
Each subnet has an IP range
The subnet’s CIDR range determines how many private addresses are available for the resources that use it.
Routes move traffic
Subnets do not route traffic by themselves. Routing decisions are made using system-generated and custom routes attached to the VPC environment.
Firewall rules filter traffic
Subnets are often discussed together with firewall rules, but these are different concepts.
Subnets provide addressing and placement, while firewall rules control allowed and denied traffic.
Subnet choice affects future growth
Poor subnet planning creates pain later when teams want Shared VPC, VPC Peering, VPN, Interconnect, GKE secondary ranges, or expansion into more regions.
Traffic placement flow
Global VPC Network
→
Regional Subnet
→
VM / GKE / Service
Environment-based subnets
Many teams separate development, test, and production environments with dedicated subnet ranges so each environment is easier to manage and secure.
Region-based subnets
Multi-region applications commonly use one subnet per region or multiple subnets per region, depending on workload density and isolation needs.
Application-tier subnets
Some architectures use subnet separation for web tiers, application tiers, batch workloads, or internal service groups.
Private-first subnet strategy
Modern designs often place workloads into private subnet ranges and avoid external IP addresses where possible, using load balancers and Cloud NAT instead.
Shared VPC subnet delegation
In enterprise environments, network admins create subnets centrally and service projects consume those subnets without owning the network itself.
Growth-oriented IP planning
Good subnet design leaves room for future workload growth, GKE adoption, peering, hybrid networking, and private service consumption.
Good subnet planning answer: not “how many subnets can I create,” but “what future traffic, scaling, region expansion, and private connectivity needs will this design have to support?”
Primary subnet range
The primary IP range is the main CIDR block associated with the subnet. VM instances and many standard workloads typically consume addresses from this range.
Secondary subnet ranges
Secondary ranges are additional CIDR blocks attached to a subnet. They are commonly used by GKE for pod IPs and service IPs so that cluster networking stays cleaner and more scalable.
| Range Type |
What it is used for |
Why it matters |
| Primary range |
Main subnet address space for resources such as VM instances. |
Defines the core private IP capacity of that subnet. |
| Secondary range |
Additional address space, often used for GKE pods and services. |
Prevents Kubernetes networking from colliding with the main workload address plan. |
Common platform mistake: teams sometimes create a subnet without thinking about future Kubernetes use, then later discover they did not leave enough clean address space for pod and service ranges.
Single-region application subnet
A smaller application may use one regional subnet for the web and app workload, backed by firewall rules and a load balancer for controlled access.
Multi-region customer platform
One global VPC can contain separate subnets in us-central1, europe-west1, and asia-south1, giving each region its own IP space while remaining in the same VPC design.
Private compute with Cloud NAT
VM instances live in a subnet with private IPs only, while Cloud NAT gives them outbound internet access for updates, package downloads, or external API calls.
Shared VPC enterprise model
Central network teams create and govern subnets, while application teams deploy resources into those subnets from service projects.
GKE-ready subnet model
The subnet includes a primary range for nodes and secondary ranges for pods and services, making future Kubernetes deployment cleaner.
Hybrid-connected subnet model
On-premises environments connect through Cloud VPN or Interconnect, so subnet ranges must be planned carefully to avoid overlaps and route conflicts.
Example architecture flow
Internet / Users
→
Load Balancer
→
App VMs in Regional Subnet
→
Private DB / Service
| Feature |
Google Cloud |
AWS |
Azure |
| Top-level network scope |
VPC network is global |
VPC is regional |
VNet is regional |
| Subnet scope |
Regional |
AZ-linked within a region |
Regional within a VNet |
| Subnet terminology |
Subnet / subnetwork |
Subnet |
Subnet |
| Kubernetes secondary ranges |
Common and important with GKE |
Different model in EKS/VPC CNI |
Different model in AKS |
| Key learning challenge |
Global VPC + regional subnets |
Regional VPC + AZ placement |
Regional VNet + subnet delegation patterns |
Main takeaway: Google Cloud subnet design often feels different because the VPC spans regions while subnets stay regional. That creates a design pattern that many AWS and Azure engineers need time to adjust to.
Plan CIDR ranges before deployment
Choose ranges with room for growth and with enough distance from on-premises, peered, or partner networks to avoid overlap problems later.
Leave room for Kubernetes
Even if you are not using GKE now, future platform adoption is common. Leave space for clean primary and secondary range planning.
Keep subnets purposeful
Subnets should have clear reasons for existing, such as region, environment, workload class, or governance model.
Design private-first where possible
Minimize unnecessary public exposure. Use load balancers, Cloud NAT, Private Google Access, and other controlled paths.
Document ownership clearly
In larger organizations, be explicit about who owns subnet design, who consumes subnets, and how changes are approved.
Think beyond today’s workload
Subnets are not just for the first deployment. They affect tomorrow’s routing, VPN, Interconnect, service networking, and security boundaries too.
Choosing subnet ranges that overlap
Overlapping ranges become a serious blocker when you later need peering, hybrid networking, or private service connectivity.
Creating subnets too small
Small subnet ranges limit workload growth and can force redesign when a platform scales faster than expected.
Mixing too many workload types
When one subnet is used for unrelated environments or services, network governance and troubleshooting become less clean.
Ignoring future secondary ranges
Teams often regret not planning for GKE or service IP separation when clusters are introduced later.
Confusing firewall problems with subnet problems
Engineers sometimes blame subnets for blocked traffic when the real issue is a firewall rule, route, or missing connectivity service.
No naming or governance standard
In enterprise environments, weak naming and ownership standards make subnet growth messy and hard to audit.
Workload cannot reach another private workload
- Check whether both workloads are in reachable subnets inside the expected VPC design.
- Verify firewall rules before assuming the subnet itself is the issue.
- Check for routing assumptions in hybrid or peered scenarios.
Private VM cannot reach the internet
- Check if the VM is intentionally private-only.
- Confirm whether Cloud NAT or another egress design exists.
- Validate route and firewall behavior for outbound traffic.
GKE cluster IP exhaustion
- Review primary and secondary subnet range sizing.
- Check pod and service address planning assumptions.
- Look at growth patterns rather than current usage only.
Peering or hybrid route conflict
- Check for overlapping subnet CIDR ranges.
- Review route advertisements and route expectations.
- Confirm that original subnet planning considered future connectivity.
Troubleshooting tip: when subnet traffic fails, verify the full chain in order: subnet placement, route path, firewall rules, NAT or internet egress design, private service path, and hybrid route advertisement assumptions.
GCP VPC
Start from the broader network model and how subnets fit into a global VPC network.
Open GCP VPC page →
Routes
Understand how Google Cloud decides where packets go after they leave a subnet-attached resource.
Open Routes page →
Firewall Rules
Learn how access is controlled so subnet communication is actually allowed or denied in practice.
Open Firewall Rules page →
Cloud NAT
See how private workloads in subnets can get outbound internet access without public IP addresses.
Open Cloud NAT page →
Cloud Router
Understand dynamic routing for VPN and Interconnect scenarios that depend on clean subnet planning.
Open Cloud Router page →
Shared VPC
Important for enterprises where subnets are centrally owned and consumed from service projects.
Open Shared VPC page →