Reserved and internal-use IP addresses in Google Cloud (GCP)
When you create a subnet in a Google Cloud Virtual Private Cloud (VPC), not all IP addresses in the CIDR range are available for your workloads. Google Cloud reserves several addresses in each subnet’s primary IPv4 range for networking and platform services.
IP addresses reserved by Google Cloud
In every Google Cloud subnet (primary IPv4 range), Google reserves four IP addresses:
- The first IP address – network address
- The second IP address – default gateway
- The second-to-last IP address – reserved by Google Cloud for potential future use
- The last IP address – broadcast address
These four addresses are unusable and cannot be assigned to virtual machines or other resources.
Google Cloud effectively uses:
Total IPs – 4 = usable IPs
Example: /24 subnet in Google Cloud
A subnet with CIDR 10.0.0.0/24 contains 256 total IP addresses.
Google Cloud reserves:
10.0.0.0(network)10.0.0.1(default gateway)10.0.0.254(reserved by Google)10.0.0.255(broadcast)
This leaves:
252 usable IP addresses
Usable range:
10.0.0.2 – 10.0.0.253
Why Google Cloud reserves these addresses
These reserved addresses support core VPC functionality, including:
- Default routing and gateway services
- Software-defined networking infrastructure
- Platform-level network management
The default gateway in GCP is implemented in the virtual networking layer and typically does not respond to traditional ICMP behavior like a physical router would.
Practical implications for subnet planning
Because four addresses are reserved in every primary subnet range, very small subnets can exhaust usable IP space quickly.
This is particularly important when deploying:
- Google Kubernetes Engine (GKE)
- Managed instance groups
- Internal load balancers
- Private Service Access
As with other cloud providers, it is generally safer to size subnets larger than the theoretical minimum.
The usable IP calculator above accounts for Google Cloud’s reserved addresses and shows how many IPs are actually available.
Internal-use addresses in Google Cloud
In addition to reserved addresses inside each subnet, Google Cloud relies on well-known link-local and platform-managed IP addresses required for instance and service functionality.
These addresses are not part of your subnet, but access to them is often required.
Care should be taken when configuring firewall rules, custom routes, or network appliances to avoid unintentionally blocking them.
169.254.169.254 — Google Cloud metadata server
The IP address 169.254.169.254 is used by the Google Cloud metadata server.
The metadata server provides:
- Instance identity and project metadata
- Network configuration
- Service account credentials
- Instance attributes and custom metadata
Blocking access to this address can break:
- Workload identity
- Automation tools
- Instance initialization scripts
- Service account authentication
Internal DNS in Google Cloud
Google Cloud provides internal DNS resolution automatically within each VPC.
Key details:
- On Linux instances, the default DNS resolver is typically
169.254.169.254 - On Windows instances, DNS resolution behavior differs and integrates with the VPC gateway
- Internal hostnames (e.g., instance-name.c.project.internal) rely on this service
Blocking metadata server access may also disrupt DNS resolution on Linux systems.
Special-purpose subnet considerations in Google Cloud
Google Cloud does not require dedicated named subnets for infrastructure components (unlike Azure). However, several services introduce additional IP planning considerations.
Google Kubernetes Engine (GKE) and IP aliasing
GKE commonly uses VPC-native (alias IP) mode.
Key considerations:
- Pods and services use secondary IP ranges
- Each node reserves a block of IPs for pod scaling
- Primary subnet usable IPs are still reduced by four
- Secondary ranges must be sized correctly to avoid pod scheduling failures
Improper secondary range sizing is a common cause of GKE IP exhaustion issues.
Internal and external load balancers
Internal load balancers allocate a frontend IP address from the subnet you select.
Key planning considerations:
- One IP is consumed per internal load balancer frontend
- Some load balancer types (e.g., Envoy-based internal HTTP(S) load balancers) require a dedicated proxy-only subnet
- Subnet planning should account for expected growth in frontend IP usage
Health checks and scaling mechanisms do not consume additional primary subnet IPs.
Private Service Access
Private Service Access allows managed Google Cloud services (such as Cloud SQL) to connect to your VPC using private IPs.
Key considerations:
- Requires dedicated allocated IP ranges
- Uses separate reserved ranges for service networking
- These ranges should be planned independently of primary application subnets
Improper sizing can limit the number of managed service instances you can deploy.
Practical guidance
- Primary subnet usable IPs = total – 4
- Plan secondary IP ranges conservatively when using GKE
- Account for internal load balancer frontend IP consumption
- Keep metadata server and internal DNS reachable
- Avoid tightly sized subnets for shared infrastructure
Re-addressing subnets later can be disruptive and operationally complex.
For official documentation, refer to: