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 for networking and platform services such as routing, DNS, and infrastructure management.
IP addresses reserved by Google Cloud
In every Google Cloud subnet, Google reserves four IP addresses:
- The first IP address – network address
- The second IP address – reserved for the default gateway
- The third IP address – reserved by Google Cloud
- The last IP address – broadcast address (not used in GCP, but still reserved)
These addresses cannot be assigned to virtual machines or other resources.
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.010.0.0.110.0.0.210.0.0.255
This leaves 252 usable IP addresses for virtual machines, load balancers, and other Google Cloud services.
Why Google Cloud reserves these addresses
Google Cloud uses the reserved IP addresses to provide core VPC functionality, including:
- VPC routing and gateway services
- Internal load balancing and forwarding
- Infrastructure and control plane operations
These addresses are managed by Google Cloud and cannot be repurposed for customer workloads.
Practical implications for subnet planning
Because Google Cloud reserves addresses in every subnet, small subnets can run out of usable IPs faster than expected.
This is particularly important when deploying:
- Internal and external load balancers
- Google Kubernetes Engine (GKE)
- Managed instance groups
- 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 for your workloads.
Internal-use addresses in Google Cloud
In addition to reserving IP addresses inside each subnet, Google Cloud also relies on well-known internal and link-local IP addresses that are required for platform services and instance functionality.
These addresses are not part of your subnet, but access to them is often required for virtual machines and managed services to function correctly.
Care should be taken when configuring firewall rules, routes, or network appliances to avoid unintentionally blocking access to these addresses.
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 information about the currently running virtual machine instance, including:
- Instance identity and project metadata
- Network configuration
- Service account credentials
- Instance attributes and custom metadata
Many Google Cloud services and automation tools rely on the metadata server. Blocking access to this address can break functionality related to identity, configuration, and automation.
Google Cloud DNS and internal services
Google Cloud provides internal DNS resolution and service connectivity through platform-managed addresses that are automatically available within the VPC.
These services are required for:
- Resolving internal hostnames
- Accessing managed Google Cloud services
- Standard VPC networking functionality
Unless you explicitly configure custom DNS or networking behavior, these services should remain reachable.
Practical guidance
- These addresses should not be used as destination IPs for customer workloads
- Access to metadata and internal DNS services is often required
- Avoid overly restrictive egress rules without explicit exceptions
- When using firewalls or custom routing, ensure required Google Cloud service addresses remain reachable
For official documentation, refer to Google Cloud VPC networking documentation:
https://cloud.google.com/vpc/docs/subnets
Special-purpose subnet considerations in Google Cloud
Google Cloud VPCs do not require named subnets for specific services in the same way as Azure. However, several Google Cloud services impose additional IP planning requirements that affect how subnets should be designed.
These requirements are service-specific and extend beyond simple usable IP calculations.
Google Kubernetes Engine (GKE) and IP aliasing
Google Kubernetes Engine (GKE) commonly uses VPC-native / IP aliasing mode.
Key considerations:
- Pods and services consume IP addresses from secondary IP ranges
- Each node reserves IPs for future pod scaling
- Incorrectly sized secondary ranges can prevent pod scheduling
While these IPs are not taken from the primary subnet range, they still require careful planning to avoid exhaustion.
Internal and external load balancers
Google Cloud load balancers rely on platform-managed networking resources.
Key considerations:
- Internal load balancers require IP space for forwarding rules
- Managed services may allocate additional IPs for scaling and health checks
- Load balancer behavior can vary depending on regional or global scope
These factors should be considered when designing subnets for shared infrastructure.
Private Service Access
Private Service Access allows managed Google Cloud services to connect into your VPC using private IPs.
Key considerations:
- Requires dedicated IP ranges
- Consumes addresses for managed services such as Cloud SQL
- These ranges should be planned separately from application subnets
Improper sizing can limit the number of private service instances that can be deployed.
Practical guidance
- Separate infrastructure, application, and service connectivity IP ranges
- Plan secondary IP ranges conservatively when using GKE
- Avoid tightly sized subnets for shared or managed services
- Re-addressing subnets later can be disruptive and time-consuming
The usable IP calculator focuses on primary subnet behavior. Google Cloud service requirements should be considered as part of a broader IP planning strategy.