A Virtual Private Cloud (VPC) network in Google Cloud can be created in either auto mode or custom mode, and this choice determines how subnets are provisioned. An auto mode VPC automatically creates one subnet in each region using a predetermined set of IP ranges, which can cause IP overlap problems if connected to on-premises networks or other VPCs through peering. A custom mode VPC gives administrators full control to manually define subnets, their names, and their IP ranges only in the regions they choose, preventing automatic overlaps and allowing descriptive naming. Choose custom mode for most enterprise designs to maintain explicit control over IP address management and prevent conflicts in hybrid or multi-VPC architectures.
Subnets in Google Cloud are regional resources that contain a primary IP address range called a CIDR block. Since Google Cloud's software-defined networking provides full mesh connectivity between all VMs in a VPC, the number of subnets does not affect routing performance. A best practice is to group applications of the same type into fewer, larger subnets rather than creating many small subnets for isolation, because features like Cloud NAT, Private Google Access, VPC Flow Logs, and alias IP ranges are configured per subnet. For fine-grained security or routing control, use service accounts or network tags on resources instead of relying solely on subnet-based separation.
Effective IP address allocation requires planning CIDR ranges for subnets while considering service isolation, regional distribution, and future expansion to avoid exhaustion. Shared VPC centralizes IPAM in a host project, where subnets are created once and shared across multiple service projects. When allocating ranges, they must not overlap with ranges used in on-premises networks, other cloud providers, or peered VPCs. Supported IPv4 ranges include RFC 1918 addresses (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), RFC 6598 (Carrier-Grade NAT, 100.64.0.0/10), and Class E (240.0.0.0/4), though non-RFC 1918 addresses should be tested for compatibility.
Allocating IP addresses for managed services like Cloud Run or Google Kubernetes Engine (GKE) requires specific planning because these services consume addresses dynamically. Cloud Run reserves IP addresses in blocks of 16 and at steady state uses twice the number of active instances, requiring a subnet of at least /26 in size. Private Service Connect eliminates the need to allocate entire subnets for accessing managed services by allowing consumers to connect via private endpoints using IP addresses from their own VPC subnets, reducing IP address consumption compared to private services access which uses VPC Network Peering.
In hybrid designs connecting to on-premises environments, subnet IP ranges in Google Cloud must not conflict with on-premises networks. Cloud Router provides dynamic routing by automatically advertising VPC subnets to on-premises routers, either regionally or globally. Global dynamic routing advertises all subnets in the VPC but adds a metric penalty for cross-region paths to preserve symmetry, while regional routing only advertises subnets in the Cloud Router's region. This choice affects how on-premises systems view the cloud network and which paths they prefer for inbound traffic.
IPv6 addressing in Google Cloud provides expanded address spaces for dual-stack (IPV4_IPV6) and single-stack (IPV6_ONLY) configurations within custom mode VPC networks. Subnets configured with IPv6 receive a fixed /64 CIDR block from Google Cloud, and connected Compute Engine instances receive a /96 address range assigned to their virtual network interface cards. When creating an IPv6-enabled subnet, administrators choose between external IPv6 (allocated from Google's globally routable pool or BYOIP ranges, publicly routable across the internet in Premium Network Service Tier) and internal IPv6 (allocated from private unique local address blocks using fd20::/20 prefix at the VPC level for VM-to-VM communication without internet routability).
Bring Your Own IP (BYOIP) allows organizations to import their own publicly routable IPv4 or IPv6 prefixes into Google Cloud, enabling regional external BYOIP IPv4 addresses to be bound to VM instances, Cloud NAT gateways, Cloud VPN gateways, and external load balancers while preserving existing IP reputation. Privately Used Public IP (PUPI) allows public IPv4 addresses to be assigned as primary or secondary internal subnet ranges rather than using RFC 1918 ranges, functioning entirely as internal IP addresses where traffic remains within Google's private network and is not advertised to the public internet. A single subnet CIDR block cannot bridge RFC ranges and public ranges simultaneously.
Automated IP Address Management uses internal range resources via the Network Connectivity API to manage, delegate, and reserve non-overlapping IPv4 and IPv6 blocks across VPC networks. When requesting automatic IPv4 allocation by defining a prefix length and target ranges, Google Cloud assigns an available CIDR block based on one of four allocation strategies: RANDOM (selects any available block, the default), FIRST_AVAILABLE (allocates the free block with the numerically lowest starting IP), RANDOM_FIRST_N_AVAILABLE (balances contiguous space preservation with reduced contention), and FIRST_SMALLEST_FITTING (minimizes address fragmentation). Subnets can be created by referencing the reserved internal range resource URL, associating either the full CIDR allocation or a specific sub-range.
Private services access enables VPC networks to communicate privately with managed service producer networks through VPC Network Peering. The consumer network administrator creates a global internal IP range reservation with the purpose set to VPC_PEERING, typically recommending a minimum size of /16 with a hard minimum of /24. Once allocated, establishing the private connection creates a VPC Network Peering link, and consumer networks must avoid configuring routes whose destinations match or overlap the allocated range to prevent IP allocation errors.
Every primary IPv4 subnet range in Google Cloud reserves four IP addresses for internal infrastructure: the first address (.0) is the subnet network address, the second address (.1) is the default gateway, the second-to-last address (.254) is reserved for future infrastructure use, and the last address (.255) is the broadcast address. Subnet ranges must not overlap with restricted link-local ranges (169.254.0.0/16), multicast ranges (224.0.0.0/4), or internal guest OS ranges such as the default Docker bridge (172.17.0.0/16). Auto mode VPC networks are constrained to 10.128.0.0/9, which prevents custom IPv6 enablement and blocks direct VPC Network Peering or Cloud VPN connections between two auto mode networks.
Google Cloud supports several IP address ranges for VPC subnets, including RFC 1918 address space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), RFC 6598 (100.64.0.0/10), and Class E addresses (240.0.0.0/4). When allocating IP addresses, consider the specific needs of the resource type—for example, Cloud Run services require subnets with a minimum of /26 to accommodate IP address blocks reserved during scale-up events, reserving addresses in blocks of 16 during traffic surges. IP addresses in Google Cloud are ephemeral, so policies based on individual IP addresses must reference the entire subnet range rather than specific addresses.
Grouping applications into fewer subnets with larger address ranges simplifies management and aligns with Google Cloud's software-defined networking approach, where the number of subnets does not affect routing behavior. Some VPC features are configured per subnet, so additional subnets may be necessary when fine-grained control over Cloud NAT, Private Google Access, VPC Flow Logs, or alias IP ranges is required. Custom mode VPC networks allow unique, descriptive names for subnets, making networks more understandable compared to auto mode networks which use identical primary IP ranges. When a new Google Cloud region is introduced, auto mode VPC networks automatically receive new subnets while custom mode networks only get new subnets if explicitly specified.
Shared VPC provides an effective architecture for centralizing IP address management across multiple teams and projects. In this model, a host project contains the VPC network with defined subnets while service projects attach to this shared network and consume IP addresses from the allocated subnet ranges. Granting the network user role at the subnet level rather than the project level provides more granular control over which teams can provision resources in specific address ranges, enabling better IP space governance and preventing unintended address consumption in critical subnets.
Private Service Connect enables consumers to access services privately from inside their VPC network without requiring subnet allocation for private service access, eliminating the need for VPC Network Peering in many scenarios. The service offers a security model with no shared dependencies, explicit authorization, and line-rate performance. Private Service Connect supports endpoints deployed via forwarding rules that map consumer IP addresses to services, backends using network endpoint groups that direct traffic to load balancers before reaching the service, and interfaces that enable bidirectional communication between consumer and producer.
Blueprint architectures typically allocate IP address space subdivided by purpose, region, and environment—for example, dividing primary subnet ranges, private services access ranges, Private Service Connect endpoints, proxy-only subnets, and secondary ranges across development, non-production, and production environments. Some resources are global and do not require regional subdivisions while regional resources typically deploy across multiple regions with unused address ranges reserved for future expansion. This structured approach ensures IP address space can be tracked and audited across the organization's Google Cloud footprint, supporting compliance requirements and preventing address conflicts as workloads scale.
Terraform and similar infrastructure-as-code tools enable automated provisioning and management of VPC networks, subnets, and IP address allocations. When deploying Managed Microsoft AD with Shared VPC, the domain must be created in the host project and the IP address range reserved for the managed AD subnet is specified during domain creation. Automation scripts can also manage firewall rules that control access to subnets, enabling audit trails of who modified network configurations and when those changes occurred.
Auto mode VPC automatically creates one subnet per region using predetermined IP ranges, which can cause conflicts in hybrid environments. Custom mode requires manual subnet creation but gives full control over IP ranges and prevents automatic overlaps.
Use Private Service Connect when you want to access managed services without allocating large IP ranges for private services access, when you need explicit authorization controls, or when you want to avoid the shared dependencies that come with VPC Network Peering.
Cloud Run reserves IP addresses in blocks of 16 (/28) during traffic surges to enable faster scaling and uses twice as many IP addresses as the number of running instances at steady state, making a /26 the minimum viable subnet size.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts