Prepare and test your skills
Prepare and test your skills
Private IP address allocation in Google Cloud controls which workloads can reach each other without using the public internet. A Virtual Private Cloud (VPC) (opens in a new tab) network is a fully virtual, isolated private partition with its own IP address space, subnets, routes, and firewall rules. Traffic stays internal when both the source and destination are inside the same VPC network and firewall rules permit it, so address planning directly defines the internal security boundary.
A VPC network is a global resource that connects subnets in different regions and zones over Google's private backbone. Virtual machines (VMs) in any region communicate privately with each other by using local VPC routes, because the trust boundary sits at the VPC edge. Enterprises create separate VPC networks to enforce default-deny separation between environments, to support overlapping IP ranges after acquisitions or multi-cloud deployments, and to delegate full administrative control to part of the enterprise.
Common isolation patterns use separate VPC networks to segregate development, staging, and production copies of an application and to give each autonomous business unit its own network and administrators. The tradeoff for this strong separation is higher administrative overhead for any service that must span multiple networks. The recommended design from best practices for VPC design (opens in a new tab) is to make each VPC as broad as the administrative and security boundary allows, then add finer isolation inside the same VPC with firewall rules.
A subnet allocates internal IPv4 addresses to resources from its primary and secondary ranges. Standard private ranges follow RFC 1918, while organizations short on private space can also use privately used public IP addresses (PUPIs), which are public address blocks used only internally inside a VPC network. Internal IPv6 subnets provide a third category for VM-to-VM communication that is not publicly routable.
Because each VPC is fully virtual, the same private IP address can exist in multiple VPC networks without conflict. Reuse conserves scarce RFC 1918 space, especially when on-premises networks already consume large portions of it. Reuse is safe only while those VPC networks are neither connected through hybrid connectivity nor peered, because once routes are exchanged, overlapping ranges create routing conflicts and unpredictable behavior.
Exam tip: The same private address can be reused in disconnected VPC networks, but do not reuse or overlap ranges between a VPC and any on-premises or peered network where routes will be exchanged.
IPv6 subnet ranges in a custom mode VPC network are either internal or external. Internal IPv6 ranges are used for VM-to-VM communication within VPC networks, cannot be reached from the internet, and are not publicly routable. External IPv6 ranges support VM-to-VM communication and are also publicly routable.
Subnets with IPv6 ranges are supported only in custom mode VPC networks. Auto mode VPC networks, including the default network, and legacy networks do not support them. To add IPv6 to an auto mode network, first convert the network to custom mode, then create new dual-stack or IPv6-only subnets or convert existing IPv4-only subnets to dual-stack.
Alias IP ranges give multiple internal IP addresses to a single VM network interface so each service on that VM has its own address. The VPC network forwards packets destined to a particular service address to the corresponding VM. This separates workloads at the IP layer without creating additional VMs or interfaces.
Google Kubernetes Engine (GKE) (opens in a new tab) uses the same capability for VPC-native clusters. In a VPC-native cluster, Kubernetes configures Pod IP addresses as alias IP ranges on the node's virtual network interface, which makes every Pod IP natively routable within the entire VPC network. Direct routability lets Pods communicate with each other and with Compute Engine instances and Cloud SQL instances without Network Address Translation (NAT). VPC-native addressing simplifies design and lowers latency, conserves route quota by avoiding a custom static route per node, and lets VPC firewall rules apply directly to Pod traffic.
When PUPIs are used for Pods, the cluster must configure the IP masquerade agent to perform Source NAT (SNAT) on outbound traffic. Traffic flows from the Pod with its PUPI source to the agent, which rewrites the source to the node's internal IP before the packet leaves. Without SNAT, return traffic to that PUPI would be routed over the public internet and fail.
GKE IP address management assigns each component from a different VPC range to prevent exhaustion and overlap. Planning node, Pod, and Service ranges up front ensures the cluster can scale without disruptive rearchitecture and avoids conflicts with on-premises networks reached over Cloud VPN or Cloud Interconnect.
| Component | Source of internal address |
|---|---|
| Node | Primary IP range of the subnet for the node pool |
| Pod | Pod CIDR range allocated to its node, delivered as alias IP ranges |
| Service ClusterIP | Dedicated secondary range in the cluster VPC network |
| Control plane | Internal range in a Google-managed tenant project connected to the VPC, typically by Private Service Connect |
| Load balancer | Internal load balancers use the primary range of the cluster subnet; external load balancers use public addresses |
The table above establishes the subject for address planning: overlapping the Pod, Service, or node ranges with another connected network causes routing conflicts and service disruption. Effective management also strengthens security because Kubernetes Network Policies control Pod-to-Pod flow while VPC firewall rules isolate workloads at the network level.
Multiple network interfaces attach one VM to several subnets, often in different VPC networks within the same project. The VM acts as a network virtual appliance (NVA) gateway that bridges or inspects traffic between VPC networks or between a VPC and the internet. Routes with the same priority distribute traffic across appliances with a 5-tuple hash, while routes with different priorities create a redundant path. Scale introduces two limits when an appliance sits in the data path: quotas apply at the project level across all bridged VPC networks, and a single VM chokepoint works against the horizontal scalability of the VPC fabric.
Routes define egress paths for packets leaving instances, including subnet routes among subnets and internet routes for eligible instances. Forwarding rules direct arriving traffic to a destination based on IP address, protocol, and port, including target instances, load balancer targets, and Classic VPN gateways. A VPC network advertises three categories of internal addresses to connected networks: regional internal IPv4 addresses for primary and secondary subnet ranges, regional internal and external IPv6 addresses for IPv6 subnet ranges, and global internal IPv4 addresses for Private Service Connect endpoints for Google APIs.
VPC Network Peering and Network Connectivity Center (NCC) enforce which of those categories cross the boundary. Peered networks always exchange subnet routes for private IPv4 ranges, but exchange of privately reused public IPv4 ranges and of internal and external IPv6 ranges is configurable. Global internal IPv4 addresses for Google API endpoints are never exchanged over peering. When hybrid connectivity advertises VPC ranges to on-premises routers, take extra care with PUPIs, as described in private connectivity with VPC Service Controls (opens in a new tab): VMs in a VPC that uses a public block internally cannot reach external resources that use those same public addresses, and advertising those blocks onward can leak them toward the internet.
Controlling public IP exposure means keeping VPC workloads on private internal IP addresses by default and placing only managed edge services on the public internet. In Google Cloud, a Virtual Private Cloud (VPC) (opens in a new tab) assigns each resource an internal IP address from its subnet range, and resources with only that private address can still reach Google APIs through private paths while remaining isolated from inbound internet traffic. Public attack surface is then minimized by denying direct external IPs with policy, using Cloud NAT for controlled outbound access, and fronting any required inbound traffic with external load balancers, Google Cloud Armor, and Identity-Aware Proxy (IAP).
Private and public addressing in a VPC determines whether a resource is directly reachable from the internet. A resource created in a VPC network and subnet receives an internal IP address from the subnet range, and resources can communicate with each other over those internal addresses when firewall rules permit. A public external IP address adds both outbound and inbound internet connectivity to that VM or forwarding rule, which expands the perimeter to that individual resource and exposes it to scanning, exploitation, and misconfigured firewall rules.
The secure pattern is to limit internet access to only resources that need it and keep all other VMs private-only. Private-only VMs can still interact with many Google and Google Cloud services through Private Service Connect or Private Google Access, so isolation from the public internet does not mean isolation from needed platform services. When private VMs must reach the public internet for updates or downloads, that outbound traffic flows from the private VM to a shared gateway such as Cloud NAT rather than from a per-VM external address.
Organization policies in Resource Manager enforce perimeter control by preventing users from creating public forwarding resources even when they have Compute permissions. The Restrict Protocol Forwarding Based on type of IP Address constraint blocks creation of forwarding rules with external IP addresses across the organization, because protocol forwarding creates a forwarding rule that directs traffic to a VM. It is configured with enforcement set to Replace, policy values set to Custom, policy type set to Deny, and custom value set to IS:EXTERNAL, and it can then be relaxed at the folder or project level only for projects explicitly authorized to publish external services.
A companion constraint defines allowed external IPs for VM instances, since by default an individual VM can acquire an external IP address for direct inbound and outbound internet access. Together these policies shift ownership of the perimeter from individual developers to the organization, so exceptions require an explicit policy change rather than a per-VM setting. Private Google Access is enabled at the subnet level to preserve usability under these denies, letting isolated resources reach key Google services without a public address.
Cloud NAT provides outbound internet access for private VMs without assigning an external IP address to each VM. Traffic flows from the private VM subnet to the Cloud NAT gateway in the same region, the gateway translates the private source to one of a small set of shared regional NAT IP addresses, and the response returns to the gateway and then to the originating VM. This consolidation also supports a fixed outbound identity when a third party allows requests only from specific external addresses, because many VMs can share the same few NAT addresses per region.
Cloud NAT depends on stateful firewall behavior and initiates only outbound sessions. Google Cloud firewall rules are stateful, so once a connection from a private VM to a target is allowed, all subsequent traffic in either direction is allowed as long as the session stays active. Only connections initiated from workloads in Google Cloud toward external networks are translated, which means Cloud NAT cannot be used to create unsolicited inbound access to a private VM. For overlapping address space, Hybrid NAT enables translation toward external networks, and for VPCs connected with Network Connectivity Center VPC spokes, Inter-VPC Cloud NAT allows address reuse across VPCs.
| Outbound option | How traffic flows | Choose when |
|---|---|---|
| Direct external IP on VM | Traffic flows directly from the VM to the internet and the internet can initiate inbound to the VM | Only for resources that must accept direct inbound internet connections |
| Cloud NAT | Traffic flows from the private VM to the regional Cloud NAT gateway, then to the internet using shared NAT IPs | Private VMs need general outbound internet without per-VM public addresses or need a small set of fixed egress IPs |
| Secure Web Proxy | Traffic flows from the private VM through the proxy to HTTP(S) destinations with identity controls applied | Outbound traffic can be downloaded over HTTP(S) and requires user or workload identity policy |
The table above establishes the subject for outbound choice: direct external IPs maximize exposure, Cloud NAT consolidates egress identity, and Secure Web Proxy adds identity controls for web traffic. Cloud NAT gateways are scoped by region and can be further limited to specific subnets when only some workloads need egress. At a minimum, enable Cloud NAT logging for ERRORS_ONLY, and configure logging to ALL when translation logs are needed for investigation.
Exam tip: Cloud NAT allows outbound-initiated sessions from private VMs and permits stateful return traffic, but it does not assign an inbound public address — unsolicited traffic from the internet cannot reach a VM through Cloud NAT alone.
Required inbound traffic should terminate at managed edge services rather than at per-VM external addresses. A global external HTTP(S) Load Balancing frontend provides high availability and protocol normalization in front of backends, so malformed or inconsistent client behavior is normalized at the edge before it reaches VPC workloads. Google Cloud Armor integrates with that load balancer to provide distributed denial-of-service (DDoS) protection and to block or allow IP addresses at the network edge, which filters volumetric and known-bad sources before they consume backend capacity.
Identity-Aware Proxy (IAP) adds identity and context checks after network filtering, verifying user identity and request context to decide whether access to the app should be granted. Hierarchical firewall policies must then permit the edge control-plane traffic that these services depend on: allow ingress from 35.235.240.0/20 for TCP ports 22 and 3389 for IAP for TCP forwarding, and allow health-check ingress from 35.191.0.0/16 and 130.211.0.0/22 for ports 80 and 443 for most load balancers. For Network Load Balancing legacy health checks, also allow 209.85.152.0/22 and 209.85.204.0/22. Security Command Center (opens in a new tab) provides the single interface for security insights, anomaly detection, and vulnerability detection across these edge and workload layers.
Google API access from a VPC follows the default internet gateway next-hop, but despite that name the traffic path from instances to Google APIs remains within Google's network. By default only VMs with an external IP address can reach Google APIs and services, so private-only subnets must enable Private Google Access per subnet or use Private Service Connect endpoints for API access without performance penalty. Google Kubernetes Engine (GKE) automatically enables Private Google Access on subnets where nodes are deployed, so nodes without external addresses can still reach managed services.
Cloud DNS private zones keep name resolution inside the perimeter by resolving services to internal IP addresses within the VPC without exposing that mapping externally. Split-horizon DNS extends that control by mapping the same DNS name to different addresses by source: the same service can resolve to an external load balancer address from the public internet and to an internal load balancer address from inside the VPC. This lets internal traffic flow from internal clients to the internal load balancer while external clients flow to the network load balancer, even though both use the same name.
Private connectivity for Google APIs lets workloads with only private internal IP addresses consume Cloud Storage, BigQuery, and other managed services without using public internet paths. Private Google Access (PGA) provides subnet-level private access inside a Virtual Private Cloud (VPC), while Private Service Connect (PSC) provides dedicated internal endpoints with bundle-level and firewall-level control. Together with routing, DNS, and perimeter controls, they form a secure egress architecture where private instances initiate outbound API calls and no inbound path from the internet exists.
Private Google Access (opens in a new tab) is a per-subnet setting that allows virtual machine (VM) instances with only internal IP addresses to reach Google APIs and services. A VM qualifies only when it has no external IP address and resides in a subnet with Private Google Access enabled. By default, only VMs with an external IP address can reach Google APIs, so Private Google Access is the mechanism that removes that public-IP dependency without slowing API communication.
Traffic from the VPC network to Google APIs follows the default-internet-gateway next hop. Despite the gateway name, traffic from instances to Google APIs remains within Google's network and does not traverse the public internet. Google Kubernetes Engine (GKE) automatically enables Private Google Access on subnets where nodes are deployed, so private GKE nodes can reach managed services without external addresses. For operational simplicity, instances that require Google APIs should be grouped on the same subnet where Private Google Access is enabled, or served by a Private Service Connect endpoint.
If the default route 0.0.0.0/0 is changed to send traffic elsewhere, such as to an on-premises inspection device, explicit routes for Google API destination ranges must be added with the default-internet-gateway as next hop. This preserves private API reachability while all other egress follows the custom path. Deploying without these explicit routes breaks private API access when the default internet route is removed.
Private Service Connect for Google APIs creates a consumer endpoint inside the VPC network that exposes Google APIs through an internal IP address and forwarding rule. The endpoint is created from an internal address with purpose PRIVATE_SERVICE_CONNECT and a forwarding rule that targets a Google APIs bundle, such as the vpc-sc bundle for Virtual Private Cloud Service Controls-supported APIs or the all-apis bundle for broader access. A private Cloud DNS zone for googleapis.com. attached to the VPC network then maps *.googleapis.com queries to the endpoint address, so API traffic flows from the workload to the endpoint to Google's service front end.
A Private Service Connect endpoint depends on VPC firewall rules or firewall policies that control which sources can reach the endpoint address. This provides finer-grained connectivity control than subnet-wide Private Google Access, avoids shared scaling dependencies, and reduces IP coordination between producers and consumers. An endpoint can be made accessible from other regions with Private Service Connect global access, which supports failover and multi-region consumption, but traffic from other regions to the endpoint incurs inter-regional outbound charges.
Setting up private API connectivity in a restricted VPC follows an ordered flow:
googleapis.com. visible to the VPC network so API names resolve to the endpoint.Private access from on-premises hosts extends the same private-IP model across Cloud VPN or Cloud Interconnect into a connected VPC network. On-premises requests to restricted services must travel through the VPC network over the hybrid connection, either by configuring a static route on the on-premises router or by announcing the restricted API range from Cloud Router with Border Gateway Protocol (BGP). All environments in this design use overlap-free RFC 1918 address space so internal addresses remain routable without address translation.
Two hybrid options differ in scope and DNS needs. Private Google Access for on-premises hosts reaches selected services over private ranges but supports only a subset of services, so unsupported APIs become unreachable and extra DNS configuration such as DNS views may be required. Private Service Connect endpoints reached from on-premises hosts support the configured API bundle through the endpoint IP over the hybrid connection, which is the preferred path when broader or bundle-controlled API access is needed. In both cases, the on-premises network must be connected to the consumer VPC network that hosts the private path.
Exam tip: Use restricted.googleapis.com at 199.36.153.4/30 and 2600:2d00:0002:1000::/56 to deny APIs not supported by VPC Service Controls; use private.googleapis.com or an all-apis endpoint only with service patterns to limit exfiltration risk.
A gated egress architecture exposes only selected remote APIs to Google Cloud workloads while blocking direct reachability in both directions. The VPC network in Google Cloud is extended to the other environment over private hybrid connectivity, and communication meets strict boundary rules where workloads in Google Cloud can communicate with the API gateway, load balancer, or Private Service Connect endpoint by internal IP address. Other systems in the private environment cannot be reached directly from Google Cloud, communication from the private environment to Google Cloud workloads is not allowed, and traffic to private APIs in other environments is initiated only from within Google Cloud.
Return traffic for allowed outbound sessions is permitted because Google Cloud firewall rules are stateful, so an established session allows response packets without a separate inbound rule. To limit egress to only allowed sources and destinations, apply IP allowlist filtering with firewall rules or firewall policies, next-generation firewall (NGFW) network virtual appliances in the path, or Cloud Next Generation Firewall Enterprise with intrusion prevention service (IPS) for deep packet inspection. VPC Service Controls (opens in a new tab) extends this boundary around projects and the connected on-premises network, so a VPC network and protected resources such as Cloud Storage buckets in the same service perimeter can communicate over the private VIP while external API paths are denied.
| Mechanism | Connectivity unit | Choose when |
|---|---|---|
| Private Google Access | Subnet setting using default-internet-gateway path | Private-IP-only VMs in the same VPC need simple private API access without an extra endpoint IP |
| Private Service Connect endpoint | Internal forwarding-rule endpoint with API bundle and DNS zone | Private-IP-only or on-premises clients need bundle selection, per-endpoint firewall control, or cross-region access |
The table above establishes the subject for choosing a private mechanism: Private Google Access is simpler for same-VPC access, while Private Service Connect adds bundle and firewall control. Limit external access further by preventing unnecessary public addresses. Use organization policies to restrict which projects can create external IP addresses, use Cloud NAT to allow outbound internet without assigning external IPs to VMs, and use Secure Web Proxy for outbound HTTP(S) web traffic where identity controls are desired.
restricted.googleapis.com uses 199.36.153.4/30 and 2600:2d00:0002:1000::/56 to deny APIs not supported by VPC Service Controls.A resource with only an internal IP address from its subnet range can communicate internally when firewall rules permit and can still reach Google APIs through Private Service Connect or Private Google Access without inbound internet exposure. Adding a public external IP address adds both outbound and inbound internet connectivity, which expands the perimeter to that resource and exposes it to scanning, exploitation, and misconfigured firewall rules.
Use Cloud NAT when private virtual machines need general outbound internet access without per-VM public addresses or need a small set of fixed egress addresses. Cloud NAT translates private sources to shared regional addresses for outbound-initiated sessions only, and stateful return traffic is allowed but unsolicited traffic from the internet cannot reach a virtual machine through Cloud NAT alone.
Private Google Access is a per-subnet setting that lets virtual machine instances with only internal IP addresses reach Google APIs over the default-internet-gateway path without an extra endpoint IP. A Private Service Connect endpoint is an internal forwarding-rule address that targets a Google APIs bundle with a private Cloud DNS zone for googleapis.com, providing bundle selection and per-endpoint firewall control.
Reuse is safe only while those Virtual Private Cloud networks are neither connected through hybrid connectivity nor peered. Once routes are exchanged, overlapping ranges create routing conflicts and unpredictable behavior, so do not overlap ranges between a Virtual Private Cloud network and any on-premises or peered network where routes will be exchanged.
A financial enterprise is securing its Google Cloud environment to minimize perimeter attack surfaces and prevent unintended internet exposure. The security architect establishes the following requirements:
Which combination of architectural controls and services should the security architect deploy?
Enforce the Define allowed external IPs for VM instances organization policy constraint to Deny All, deploy Cloud NAT gateways in the VPC, configure Identity-Aware Proxy (IAP) for TCP forwarding with a firewall rule permitting 35.235.240.0/20 for ports 22 and 3389, and use external Application Load Balancers with reserved external IP addresses.
Enforce the Skip default network creation constraint to True, configure Cloud NAT to handle both inbound and outbound traffic, permit 0.0.0.0/0 on firewall ports 22 and 3389, and use Cloud DNS routing policies for external web ingestion.
Enforce the Disable VPC External IPv6 usage constraint, create an internal Application Load Balancer with an INTERNET_IP_PORT backend, and use VPC Network Peering with Exchange subnet routes with public IP enabled for external communication.
Enforce the Restrict Protocol Forwarding Based on type of IP Address constraint set to IS:EXTERNAL, deploy Internet NEGs pointing to private RFC 1918 VM addresses, and allow health check ranges 35.191.0.0/16 and 130.211.0.0/22 for SSH management.
Last updated