Plan GCP VPC subnet allocation across regions with GKE-aware sizing.
Last verified: April 2026
Output will appear here...The planner models GCP's unique VPC structure where the VPC is global but subnets are regional with independently assigned primary and secondary IP ranges. It validates that primary ranges don't overlap across subnets, that secondary ranges (for GKE pods/services) don't conflict with primary ranges or each other, and that all ranges are compatible with VPC peering requirements. For GKE-aware planning, it calculates the minimum secondary range size based on max-pods-per-node and max-nodes configuration.
The GCP VPC CIDR Planner helps you design subnet allocation across regions for Google Cloud VPC networks with GKE-aware sizing. Unlike AWS where VPCs have CIDR blocks, GCP VPCs are global and subnets are regional with their own IP ranges. This tool accounts for GKE secondary ranges (pods and services), alias IP ranges, and Private Google Access requirements.
Your platform team is rolling out a Shared VPC for 6 service project teams, each running GKE clusters across 3 regions. Using the planner, you allocate non-overlapping primary subnets (/22 per team per region) and GKE secondary ranges (/16 for pods, /20 for services). The planner flags that team-4's pod range in us-central1 overlaps with team-2's primary range in europe-west1, which would break cross-region pod communication. You catch this before any clusters are created, avoiding a multi-team outage and cluster rebuild.
Avoid auto-mode VPCs in production. Auto-mode creates a /20 subnet in every region automatically using the 10.128.0.0/9 range, which frequently conflicts with other VPCs, on-premises networks, or AWS/Azure address spaces. Always use custom-mode VPCs where you control every subnet range.
GKE secondary ranges for pods and services cannot be changed after cluster creation. If you under-size the pod range, your only option is to create a new cluster. Use /14 for pods and /20 for services as generous defaults — the unused IPs cost nothing.
In Shared VPC architectures, the host project owns all subnets and secondary ranges. Service projects reference them but can't create their own. Plan subnet allocation centrally and include all current and future service projects in the design. Adding a new subnet later requires host project admin access.
GCP VPCs are global resources and subnets are regional (not zonal). Subnets define their own primary and optional secondary IP ranges independently, rather than carving from a VPC-level CIDR. This gives more flexibility in address allocation but requires careful planning to avoid overlaps during VPC peering.
Secondary ranges are used for GKE VPC-native clusters to provide separate IP spaces for pods and services. A GKE cluster needs one secondary range for pod IPs and another for service IPs. These ranges are not used for VM primary IPs and enable alias IP networking.
For GKE, the pod secondary range should accommodate maximum-pods-per-node times maximum-nodes. The default is 110 pods/node, so a 100-node cluster needs at least 11,000 pod IPs (a /18). The service range needs one IP per Kubernetes Service, typically a /20 is sufficient. Over-provision rather than under-provision since ranges cannot be expanded.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.