Subnetting and CIDR Planning in Google Cloud

CIDR stands for Classless Inter-Domain Routing. It is the notation you use to describe an IP network and its prefix length, such as 10.20.30.0/24.

The part before the slash is the network address. The part after the slash is the number of bits reserved for the network. The remaining bits are available for hosts or sub-allocation.

In practical cloud networking, CIDR answers three questions:

• How big is this subnet?
• Which IPs belong to it?
• How much room do I have left before I need another subnet?

In Google Cloud, a primary subnet range loses four addresses, not two. Google reserves the first two and last two IPs in each primary IPv4 subnet range. That matters when you are doing tight capacity planning for node pools, bastion subnets, and small management networks.

For most production Google Cloud environments, your default choice should be RFC1918 private space. These ranges are non-routable on the public internet and are the safest default when you expect VPN, Interconnect, peering, or hybrid growth.

Google Cloud documentation for VPC subnets lists these RFC1918 ranges as valid private IPv4 subnet ranges, and it also allows some additional internal ranges. Even so, RFC1918 should remain your production default unless you have a clear reason to use something else.

One practical rule keeps many teams out of trouble: pick one RFC1918 strategy for the whole company. If networking, platform, and Kubernetes teams all improvise independently, overlap becomes almost guaranteed.

A subnet mask and a CIDR prefix describe the same boundary in two different formats. For example, /24 is the same as 255.255.255.0.

CIDR math is easier if you remember one formula:

• Total IPs = 2^(32 - prefix)
• GCP primary subnet usable IPs = 2^(32 - prefix) - 4

Visualizing the split helps:

If you cannot do the math quickly in your head, that is normal. The engineering requirement is not mental speed. It is consistency. You need a plan that teams can extend without guessing.

Subnet sizing is a capacity exercise, not a trivia exercise. Start from workload growth, not from a random /24 habit.

A production planner should always ask:

1. How many workloads exist today?
2. What is the 12 to 24 month growth target?
3. Will I add GKE, private services, PSC endpoints, or more regions later?
4. Does this subnet need room for blue-green or migration overlap?

IP exhaustion happens when the subnet still exists, but no new IPs can be allocated. In Google Cloud that blocks new VMs, forwarding rules, node scale-out, or load balancer growth depending on what uses the range.

The cleanest production estates separate dev, staging, and prod at the address-planning layer, not just with IAM and labels. If you do not reserve environment blocks early, teams eventually collide.

A straightforward enterprise pattern inside 10.0.0.0/8 is:

Inside each environment, you can repeat the same region and subnet pattern:

This repeatable pattern lowers cognitive load. When an engineer sees 10.2.16.0/20, they can infer both the environment and the region without opening a spreadsheet.

Google Cloud VPC networks are global, but subnets are regional. That means your IP plan should reserve regional blocks inside an environment, then subdivide those blocks by workload.

A common production mistake is to allocate subnets consecutively without reserving gaps. That feels efficient on day one and painful on year two.

Kubernetes changes IP planning because you are no longer sizing only for nodes. In a VPC-native GKE cluster, you must think about:

• The primary subnet range for nodes and internal load balancers
• A secondary range for Pods
• A secondary range for Services

Google Cloud guidance matters here:

• GKE Pod secondary ranges are immutable after cluster creation, so undersizing them causes future scaling pain.
• Google Cloud documentation notes that all IPs in secondary ranges are usable for Pods, while primary ranges still lose four addresses.
• For Standard clusters, the default maximum of 110 Pods per node maps to a /24 Pod CIDR per node.

The planning tradeoff is direct:

Practical example from Google Cloud sizing logic:

That is why a cluster can run out of Pod IPs even when the node subnet still has room. The node subnet and the Pod secondary range are different exhaustion domains.

The most expensive subnetting problems are usually not syntax mistakes. They are planning mistakes that surface only when you add regions, clusters, or hybrid links.

Overlapping subnets are especially painful. They create ambiguous routing and often block:

• Cloud VPN or Interconnect attachments
• VPC Network Peering
• Shared services migration
• Mergers between teams or projects
• Shared VPC adoption later

IP exhaustion and overlap often combine. Teams squeeze small ranges to save space, then later reuse neighboring space without a central plan.

Production IP planning should be opinionated. Ambiguity is what turns networking into archaeology six months later.

For Shared VPC, the strongest pattern is:

Google Cloud Shared VPC documentation emphasizes that the host project can share selected subnets, including secondary ranges, with service projects, and that subnet-level permissions help preserve least privilege. That should shape your IP plan: design the host project like a platform, not like a single app team’s network.