GCP Subnets: Global Networking on Google Cloud Platform
Google Cloud Platform takes a unique approach to virtual networking that sets it apart from AWS and Azure. At the heart of GCP networking is the global VPC, and within each VPC, subnets provide the regional address space for your cloud resources. Understanding how GCP subnets work is essential for designing cost-effective, scalable, and highly available architectures on Google Cloud.
What Is a GCP Subnet?
A GCP subnet is a regional IP address range within a Virtual Private Cloud (VPC). Unlike AWS where subnets are confined to a single Availability Zone, GCP subnets span all zones within a region. This means that when you create a subnet in us-central1, resources in us-central1-a, us-central1-b, and us-central1-c can all use IP addresses from the same subnet. This regional subnet model simplifies network planning significantly—you do not need to create separate subnets for each zone to achieve high availability across multiple failure domains.
GCP subnets have a unique advantage: they do not carry any reserved IP overhead. Unlike AWS and Azure which reserve 5 IP addresses per subnet, GCP does not reserve any addresses. Every IP in your subnet CIDR range is available for resources. A /24 subnet in GCP provides 256 usable addresses, not 251. This can save significant IP space in large deployments. The GCP subnet calculator on this page helps you plan your subnets by showing the exact usable range for any CIDR prefix.
Global VPCs and Subnet Modes
The most distinctive feature of GCP networking is the global VPC. While AWS VPCs are region-scoped, a GCP VPC spans all regions globally. This allows resources in different continents to communicate using private IPs without VPC peering or VPN tunnels. GCP VPCs operate in one of two subnet modes: auto-mode (default) or custom-mode. Auto-mode VPCs create subnets in every region automatically with predefined /20 CIDR ranges. Custom-mode VPCs give you full control over subnets and CIDR ranges, which is recommended for production environments.
In custom-mode VPCs, you can create up to 10 non-overlapping subnets per VPC. Unlike AWS where subnets within a VPC must be contiguous and derived from the VPC CIDR, GCP allows subnets to use any non-overlapping private IP range, regardless of the VPC's primary CIDR. This flexibility makes it easier to integrate with on-premises networks and other cloud providers. Each subnet must be at least /29 and supports both IPv4 and optionally IPv6. The GCP subnet calculator helps you design custom subnet plans across multiple regions.
Subnet Security and Connectivity
GCP provides firewall rules at the VPC level that apply to all subnets within the VPC. Unlike AWS where NACLs are applied per subnet and security groups per instance, GCP uses a unified firewall rule system that applies to all resources. Firewall rules are stateful and support ingress/egress filtering by IP, port, protocol, and target tags. VPC Flow Logs provide visibility into traffic patterns. Private Google Access allows resources in subnets without external IPs to access Google APIs and services, enhancing security.
GCP also supports VPC Network Peering for connecting VPCs within the same project or across projects, Cloud VPN for site-to-site connectivity, Cloud Interconnect for dedicated private connections to on-premises, and Cloud NAT for outbound internet access from private instances. The shared VPC feature allows you to have a central host project with subnets that are shared with multiple service projects—ideal for enterprise Landing Zone architectures.
When planning GCP subnets, best practices include: using custom-mode VPCs for production, allocating /24 or larger subnets to allow growth, using separate subnets for different tiers (web, app, db), enabling Private Google Access for security, and designing IP ranges that do not overlap with on-premises networks. The GCP subnet calculator makes this planning straightforward by generating CIDR blocks for any region, showing the full usable IP range, and helping you visualize your network topology before deployment.