Google Cloud VPC Subnet Calculator

Google Cloud VPC networks are global, but subnets are regional — each subnet you create lives in one region and has its own CIDR range. Planning these ranges carefully before deployment matters because GCP does not allow you to resize a subnet's primary range while VMs are running in it. This calculator uses VLSM to allocate exactly the right block size for each subnet, then shows all remaining free space as ready-to-use CIDR blocks.

Enter the IP address block you want to divide across your GCP regions. This becomes the total pool all subnets are carved from.

1. 1Enter a VPC Base IP — use a private RFC 1918 address such as 10.0.0.0, 172.16.0.0, or 192.168.0.0.
2. 2Drag the CIDR slider or type a Subnet Mask. GCP subnets support /8 to /29. A /16 is the most common starting point — it gives 65,536 addresses across all your planned regional subnets.

Type how many subnets you need into the No. of Subnets box and click Generate Rows. One blank row appears for each subnet — fill in the four fields for each one:

1. →Subnet Name — a label you will recognise in the Google Cloud console, for example web-private-us-central1 or proxy-only-europe-west1. GCP subnet names must be lowercase letters, numbers, and hyphens only.
2. →Region — type the GCP region this subnet belongs to, for example us-central1, europe-west1, or asia-southeast1. Each GCP subnet is tied to exactly one region.
3. →Type — type private, public, proxy, or psc. Private subnets host VMs and GKE nodes with internal IPs only. Public subnets hold resources with external IPs such as load balancer frontends. Proxy subnets are dedicated proxy-only subnets required by Google Cloud regional Application Load Balancers and regional proxies. PSC subnets are used exclusively for Private Service Connect producer endpoints.
4. →Hosts Needed — the number of resources you expect in this subnet. Size generously — GCP does not allow you to shrink a primary subnet range, and expanding it requires the new range to be larger and non-overlapping. The calculator rounds up to the nearest power-of-2 block and subtracts the 4 GCP-reserved addresses automatically.

Click Generate Plan. The calculator allocates subnets from largest to smallest (VLSM order) to minimise gaps, then shows you the complete IP layout. Here is what each column means:

1. →Subnet Name / Type — your label and a colour-coded type badge (green = Private, blue = Public, amber = Proxy-only, red = PSC).
2. →Region — the GCP region you entered for this subnet.
3. →Network (CIDR) — the exact IP range to enter in the Google Cloud console when creating this subnet.
4. →Total IPs — the full block size including GCP-reserved addresses.
5. →GCP Reserved — always 4. Shown separately so you can see exactly what Google takes from every subnet.
6. →Usable IPs — addresses available to assign to resources. This is Total IPs minus 4.
7. →Netmask — the subnet mask in dotted-decimal format for reference.

Key rules from the Google Cloud architecture framework and GCP networking documentation when sizing subnets:

1. 1Size up generously for GKE. GKE clusters consume IPs rapidly in VPC-native mode — each node gets a /24 alias IP block by default, consuming 256 addresses per node regardless of actual pod count. Plan your GKE node subnet with a /20 or larger.
2. 2Proxy-only subnets need a minimum /26. Regional Application Load Balancers and regional proxies require a dedicated proxy-only subnet per region. Google recommends at least a /26 (60 usable IPs) per region; use a /23 for high-traffic environments.
3. 3PSC subnets can be small. Private Service Connect producer subnets only need one IP per forwarding rule. A /29 (4 usable IPs) is sufficient for most PSC producer configurations.
4. 4Use secondary ranges for pods and services. In GKE VPC-native clusters, pods and services use secondary IP ranges on the subnet — not the primary range. Plan primary and secondary ranges separately; this tool handles primary ranges only.
5. 5Reserve space for growth. GCP allows you to expand a subnet's primary range to a larger prefix, but the new range must be a supernet of the current one. Leave enough room in your overall VPC block so expanding a regional subnet does not conflict with neighbouring subnets.

GCP reserves the first two and the last two addresses in every subnet. The network address (.0) and the default gateway (.1) are reserved at the start. At the end, the second-to-last address is reserved by Google for future use, and the broadcast address is the final IP in the block. This means a /29 with 8 total addresses only gives you 4 usable IPs — a noticeably better ratio than cloud providers that reserve 5, but still significant for very small subnets.

Use a private RFC 1918 range — 10.0.0.0/8, 172.16.0.0/12, or 192.168.0.0/16. Because GCP VPCs are global, a single VPC can span all regions with no additional configuration. Starting with a /16 from the 10.x space is the most common choice — it gives 65,536 addresses to divide into regional subnets. If you plan to peer with other VPCs or connect on-premises via Cloud VPN or Cloud Interconnect, ensure no ranges overlap across all connected networks.

Private subnets are the standard type — they host VMs, GKE nodes, and internal services with no external IP required. Public subnets hold resources that need external IP addresses, such as bastion hosts or internet-facing load balancer backends. Proxy-only subnets are a GCP-specific requirement — regional Application Load Balancers and regional TCP/SSL proxies allocate IPs from a dedicated proxy-only subnet in each region, separate from your workload subnets. PSC subnets are reserved exclusively for Private Service Connect producer-side forwarding rules, allowing you to publish services to other VPCs.

You can expand a subnet's primary range to a larger prefix, but you cannot shrink it. The expanded range must be a supernet of the existing range — for example, you can grow a /24 to a /23 as long as no other subnet already occupies the adjacent block. You cannot change the starting address of the subnet at all. Secondary ranges (used by GKE pods and services) can be added or removed more freely, but the primary range is effectively permanent once VMs are deployed.

The most significant difference is that GCP VPCs are global — a single VPC spans all regions automatically, and you create regional subnets within it. AWS and Azure VPCs and VNets are regional resources. This means one GCP VPC can replace dozens of regionally isolated networks in other clouds. GCP also uses a flat routing model — all subnets in a VPC can communicate by default without explicit route tables, unlike AWS where route tables must be configured per subnet.

After all your subnets are placed, the remaining address space inside your VPC CIDR is decomposed into boundary-aligned CIDR blocks and displayed in the free table. These are real, assignable ranges — not gaps or unusable space. You can use any of these blocks for a new regional subnet in the Google Cloud console at any time without affecting existing subnets. Blocks are listed in sequential address order, smallest first, so the first entry immediately follows your last allocated subnet.

The minimum subnet size in GCP is a /29, which has 8 total IP addresses. After the 4 GCP-reserved addresses, you have 4 usable IPs. This is tighter than AWS (/28, 11 usable) or Azure (/29, 3 usable) and is only suitable for very constrained subnets such as PSC producer endpoints or small management subnets. For any subnet that may receive VMs or GKE pods, use at minimum a /26 (60 usable) to leave room for growth and GCP's alias IP behaviour.