Professional Cloud Network Engineer
Expanding a VPC subnet's CIDR range after creation allows a network to grow its available IP addresses without redesigning the entire architecture. This is done by reducing the subnet mask's prefix length, which makes the address block larger and must fully contain the original range. The process is non-disruptive to active traffic but is permanent; you cannot shrink a subnet's primary range after expanding it.
The primary IPv4 range of a subnet is expanded by changing its subnet mask to a smaller prefix number. For example, changing from /24 to /20 creates a broader block with more addresses. In auto mode VPC networks, the broadest prefix allowed is /16 to avoid conflicts with other automatically created subnets. Subnets used exclusively for proxy-only load balancers cannot be expanded at all. After expansion, you must update configurations that reference the old IP range, such as VPC firewall rules or the control plane authorized networks list for a Google Kubernetes Engine (GKE) cluster.
Expanding a subnet range risks IP address collisions if the new range overlaps with IP spaces in connected environments. VPC Network Peering fails if the expanded range overlaps with a peered VPC's IP addresses. For hybrid connections using Cloud VPN or Cloud Interconnect, the expanded range must not conflict with on-premises network ranges, or routing will fail. In a Shared VPC, expanding a subnet in the host project affects all attached service projects, so you must ensure the new range doesn't overlap with any service project's allocations.
The key operational constraint is that subnet expansion is irreversible. Best practice is to expand conservatively, starting with the smallest necessary increase, as you can expand again later if needed. Planning must verify the new range won't conflict with existing subnets, peered networks, or on-premises ranges. While the expansion itself doesn't interrupt traffic, the required follow-up tasks—like updating firewall rules and GKE authorized networks—must be completed to maintain security and access.
Modifying primary and secondary IP ranges after subnet creation allows a Virtual Private Cloud (VPC) network to scale without stopping active virtual machine (VM) instances or GKE workloads. This involves expanding the primary IPv4 range or adding/editing secondary ranges used for purposes like GKE pod IPs.
You expand a subnet's primary range through the Google Cloud console, gcloud CLI, or Compute Engine API by specifying a new, broader CIDR block. The operation takes several minutes, and traffic within the subnet is not interrupted. However, this change is permanent; a primary range cannot be shrunk afterward. Before expanding, the new range must follow VPC rules and not overlap with any other IP ranges in the subnet. After expansion, you may need to update firewall rules and GKE cluster authorized networks.
Secondary IP ranges are address pools added to a subnet for uses like GKE pod IPs. Unlike primary ranges, you can add new secondary ranges or edit existing ones after subnet creation. In a Shared VPC, secondary ranges cannot be managed by GKE; a Network Admin in the host project must create them before a cluster can use them. Modifying secondary ranges is generally less disruptive than changing the primary range. When a GKE cluster uses a subnet, if you expand its primary range, you must also add the new range to the cluster's control plane authorized networks.
You cannot expand subnets used for proxy-only load balancers. For GKE, the primary range size limits the maximum number of nodes, and formulas help calculate the required netmask based on node count. Secondary ranges for pods must be calculated based on maximum pods per node. Architecturally, the VPC control plane manages range expansion without affecting the data plane of existing VMs. In a Shared VPC, the host project owns the subnet and its ranges, while service projects consume them, requiring specific IAM permissions for cross-project operations.
Changing a subnet's IP boundaries by expanding its range requires updates to dynamic routing, peering connections, and security policies to maintain network reachability and protection. The expansion itself is non-disruptive, but the surrounding configuration must be realigned.
Dynamic route propagation depends on Cloud Router sessions advertising local network ranges. When a subnet expands, Cloud Router automatically learns the updated boundaries if configured to advertise all subnets. If the BGP session uses custom route advertisements, an administrator must manually update the advertised IP list to include the new address space. To prevent conflicts across hybrid connections like Cloud Interconnect or Cloud VPN, destination subnets in the local VPC take precedence over remote dynamic routes unless specific overlap capabilities are enabled.
VPC Network Peering automatically exchanges local subnet routes between connected VPCs. The newly expanded CIDR prefix propagates across the peering boundary through these default exchanges. However, custom routes do not propagate automatically. If workloads must reach destinations via static routes or hybrid connections, the peering configuration must explicitly enable custom route exports on the local VPC and imports on the remote VPC. Proper planning is essential to prevent overlapping IP ranges, which would cause peering to fail or drop traffic.
Security policies must adapt to the new IP boundaries. If Cloud Next Generation Firewall (Cloud NGFW) policies or standard VPC firewall rules specify source or destination IP ranges, administrators must add or modify rules to cover the expanded CIDR block. For Google Kubernetes Engine (GKE) clusters on the expanded subnet, the new address space must be added to the control plane authorized networks list to maintain cluster access. Environments using Private Service Connect or private access must also ensure that health check IP ranges and proxy-only subnets remain accessible after any rule updates.
StudyCerts
StudyCerts/24 to /20), which increases available IP addresses and cannot be undone./16 prefix.The main risk is IP address collision, where the new, larger range overlaps with IP space in a peered VPC, a connected on-premises network, or another subnet in a Shared VPC environment. This overlap causes routing failures and breaks connectivity.
No, expanding a subnet's primary IPv4 range is a permanent, one-way operation. Once you increase the range by reducing the prefix length, you cannot shrink it back to a smaller size.
If a GKE cluster uses a subnet whose primary range you expand, you must add the new, expanded IP range to the cluster's control plane authorized networks list. This update is required to maintain administrative access to the cluster.
Prepare and test your skills
Prepare and test your skills