CIDR Explained: A Practical Guide to GCP VPCs, Subnets, and IP Address Planning

CIDR determines how many IP addresses belong to a network range. In Google Cloud, understanding CIDR helps you size subnets, plan regional deployments, allocate GKE address space, and avoid conflicts with connected networks.

A useful CIDR table must distinguish total addresses from usable addresses. A /24 contains 256 IPv4 addresses, but a GCP primary subnet range provides 252 usable addresses because Google reserves four.

What Does CIDR Mean?

CIDR stands for Classless Inter-Domain Routing. It describes an address range using an IP address followed by a prefix length:

10.10.1.0/24

IPv4 addresses contain 32 bits. In this example, 24 bits identify the network prefix, leaving eight bits for addresses within the range.

Total IPv4 addresses = 2^(32 − prefix length)

For a /24:

32 − 24 = 8 address bits
2^8 = 256 total addresses

The range runs from 10.10.1.0 through 10.10.1.255.

A smaller prefix number means a larger address range. A /16 is much larger than a /24; a /28 is much smaller.

Corrected IPv4 CIDR Conversion Table

The original table mixed historical Class A, B, and C terminology with subnet counts and inconsistent host calculations. CIDR does not require those class boundaries.

The table below gives the total address count for every prefix. Its final column applies the GCP four-address reservation to primary subnet ranges.

*Google Cloud accepts subnet prefix lengths from /4 through /29, subject to address-range validation. Most /4 ranges fail those validations; a mathematically correct size does not guarantee a valid subnet. The smallest primary or secondary range is /29. These are address capacities, not VM quotas. Source: Google Cloud subnet documentation.

The traditional “subtract two” convention would give a /24 254 usable host addresses. It does not describe GCP primary subnet capacity. Also, /31 has two addresses and can serve point-to-point links in other networking contexts; /32 identifies one address. Neither is a valid GCP subnet range.

GCP VPCs Are Global; Subnets Are Regional

A GCP VPC is global. Its subnets belong to individual regions, and each IPv4 subnet has its own CIDR range. There is no mandatory enclosing IPv4 CIDR assigned to the VPC. Source: VPC network overview.

For example, a custom-mode VPC called production-vpc could contain:

These ranges are an illustrative address plan. They need not come from one contiguous parent block.

A regional subnet can serve VMs in multiple zones of its region. For example, VMs in us-central1-a and us-central1-b can use app-us-central. A VM in us-east1-b needs a subnet in us-east1. Communication remains subject to firewall rules. Source: VPC network overview.

Which Four Addresses Does GCP Reserve?

For the primary range 10.10.1.0/24:

The assignable range is 10.10.1.2 through 10.10.1.253, giving 252 addresses. Google reserves the first two and last two addresses of each primary range. Source: Subnet address reservations.

For a smaller 10.10.2.0/28 example:

• Total range: 10.10.2.0–10.10.2.15.
• Reserved: .0, .1, .14, and .15.
• Assignable: 10.10.2.2–10.10.2.13.
• Usable capacity: 12 addresses.

How Many Subnets Fit Inside a Parent Range?

“Number of networks” has no fixed value for a prefix. You must identify both the parent range and the size of the smaller ranges.

Number of child ranges = 2^(child prefix − parent prefix)

For example, splitting 10.40.0.0/16 into /24 ranges gives:

2^(24 − 16) = 256 /24 ranges

The first is 10.40.0.0/24; the last is 10.40.255.0/24.

In GCP, the parent can simply be an allocation in your IP planning register. You would create the child subnets; you would not also create an overlapping parent subnet.

Splitting one primary /24 into four primary /26 subnets preserves 256 total addresses, but increases reservations: four subnets reserve 16 addresses altogether, leaving 240 usable addresses.

Example: Size a Subnet for an Application

Suppose an application needs:

• 180 VM network-interface addresses at peak load.
• 20 addresses for other planned resources and static reservations.
• 80 additional addresses as deployment and growth headroom.

That is 280 addresses.

An illustrative choice is 10.50.0.0/23. It spans 10.50.0.0–10.50.1.255, with assignable addresses from 10.50.0.2 through 10.50.1.253.

Size for peak demand, replacement instances during deployments, and growth—not just today's running VM count.

Example: Allocate a /20 Across Regional Subnets

Suppose your organization allocates 10.60.0.0/20 for an application platform. That planning block contains 4,096 addresses and spans 10.60.0.0–10.60.15.255.

It can be divided into four /22 subnets:

Each provides 1,020 usable primary addresses. Across all four, usable capacity is 4,080.

Notice the /22 boundaries: the third octet advances in steps of four. CIDR ranges must align with their prefix boundaries.

Example: Plan GKE Nodes and Pods Separately

VPC-native GKE uses the subnet primary range for nodes and secondary ranges for Pods. Services can use a separate secondary range or a GKE-managed range, depending on configuration. Source: GKE VPC-native clusters.

An illustrative configuration with explicitly assigned secondary ranges is:

The four-address reservation applies to primary ranges; Google makes all addresses in secondary ranges available at the subnet level. Workload allocation rules still determine actual capacity. Source: Subnet address reservations.

For example, if the cluster allocates one /24 Pod block per node:

/16 Pod range ÷ /24 per-node allocation
= 2^(24 − 16)
= 256 node allocations

Although the primary range has 1,020 usable addresses, the Pod range in this example supplies only 256 such allocations. GKE Pod block sizing depends on the maximum Pods per node; address totals alone do not establish cluster capacity. Source: GKE VPC-native clusters.

Avoid Overlap Before Connecting Networks

Suppose both your data center and a planned GCP subnet use 10.100.0.0/16. Connecting them creates overlapping address space: an address such as 10.100.10.20 no longer identifies one unambiguous destination.

For a new deployment, an illustrative plan could be:

Check these proposed blocks against your complete address inventory before creating subnets. Include other clouds, future acquisitions, and container address pools. Google requires non-overlapping subnet ranges within a VPC and across peered networks; hybrid connectivity also requires careful overlap planning. Source: Subnet range limitations.

Create the VPC and Subnet

The following commands illustrate creating a custom-mode VPC and a regional subnet in your selected project:

gcloud compute networks create production-vpc \
  --subnet-mode=custom

gcloud compute networks subnets create app-us-central \
  --network=production-vpc \
  --region=us-central1 \
  --range=10.10.1.0/24

The --range flag sets the subnet's primary IPv4 range. Source: gcloud subnet creation reference.

Leave Room for Growth

A primary subnet range can be expanded, subject to validation, but cannot be shrunk. Source: Subnet range limitations.

For example, expanding 10.10.0.0/24 to 10.10.0.0/23 would also consume 10.10.1.0/24. If that adjacent range already belongs to another subnet, the expansion conflicts.

Document each planned range, its owner, region, purpose, expected peak usage, and expansion space. Treat unallocated adjacent space as an explicit reservation in your address plan.

Good CIDR planning connects address arithmetic to workload demand. Choose ranges that accommodate peak usage and deployment headroom, keep node and Pod requirements separate, and check overlap before establishing connectivity.