Prepare and test your skills
Prepare and test your skills
Designing private connectivity for hybrid and on-premises environments means allowing hosts outside Google Cloud to reach Google APIs and Google Cloud workloads without crossing the public internet. Traffic flows from the on-premises network over Cloud Interconnect or Cloud VPN into a Virtual Private Cloud (VPC) network, and then over Google's internal infrastructure to the API or service. Private Service Connect (opens in a new tab) endpoints and internal load balancers provide private IP entry points inside the VPC network with more isolation and control than the basic path.
Private Google Access for on-premises hosts is the basic configuration that lets on-premises and other-cloud hosts reach Google APIs over a private hybrid network. The on-premises host sends API traffic through an existing Cloud Interconnect connection or Cloud VPN IPsec tunnel into the VPC network, and the VPC network forwards the traffic to Google APIs over Google's network. Cloud Interconnect extends the external network to Google through a high-availability, low-latency connection, while Cloud VPN securely extends the peer network through an IPsec tunnel. Cloud Router exchanges Border Gateway Protocol (BGP) routes with Cloud Interconnect, Cloud VPN, and Router appliances to create dynamic routes, so return traffic stays on the private path.
A Private Service Connect endpoint for hybrid API access is a private IP address inside the consumer VPC network that forwards traffic to Google APIs over Google's internal infrastructure. To serve hybrid clients, the endpoint is created in a routing VPC network, a private DNS zone is configured for the API name such as run.app, and the on-premises network is configured to reach the endpoint IP. Traffic flows from the on-premises host over Cloud Interconnect or Cloud VPN to the endpoint IP in the routing VPC network, then over Google's internal infrastructure to the destination such as a Cloud Storage bucket in a service project. This pattern supports private input where uploaded data never travels over the internet, because engineers copy data over the hybrid connection to the endpoint using only private IP addresses.
Within the service project, data travels between systems by using one of the following methods, depending on where the systems are hosted:
Exam tip: Use Private Google Access for on-premises hosts for the basic private path to Google APIs, and use a Private Service Connect endpoint when hybrid clients must call the API through an internal IP address in your VPC network.
An internal Application Load Balancer for hybrid clients adds load-balancing controls in front of a workload or managed service without internet exposure. The load balancer endpoint is an IP address in the application VPC network, and on-premises networks reach it over Cloud VPN and Cloud Interconnect. When the routing VPC network, the application VPC network, and the hybrid connections are all spokes of the same Network Connectivity Center hub, Network Connectivity Center exports all spoke subranges to the hub, which then re-exports those subranges to the other spoke networks. End users in the external network can then reach the load-balanced service from the external network over private connectivity.
The inference flow shows the ordered path from an external client to the backend:
If the service must be shared across administrative boundaries, it can be published by using Private Service Connect behind an internal Application Load Balancer. To access the published service from on-premises hosts, a Private Service Connect endpoint is created in the consumer network and the on-premises network is configured to access that endpoint.
| Hybrid access option | Consumer entry point | Choose when |
|---|---|---|
| Private Google Access for on-premises hosts | Hybrid tunnel into VPC, then Google network to APIs | Basic private API access over existing Interconnect or VPN is sufficient |
| Private Service Connect endpoint | Internal IP address in routing VPC with private DNS | Clients must call Google APIs at default URLs through a VPC-internal address |
| Internal Application Load Balancer | Load balancer IP address reachable from on-premises | Load-balancing controls, customer-owned domains, centralized security, or failover between regions is required |
Gated egress (opens in a new tab) is a pattern that exposes select APIs from the on-premises environment or another cloud to workloads in Google Cloud without exposing the private environment to the internet. Exposure is provided through an API gateway or proxy, a load balancer that serves as a facade, or a Private Service Connect endpoint, deployed in an isolated perimeter network segment. The pattern enforces one-way initiation where traffic to the private APIs in other environments is only initiated from within the Google Cloud environment.
The gated egress pattern depends on VPC networks in Google Cloud being extended to the other environments through hybrid connectivity so communication uses internal IP addresses. All environments share overlap-free RFC 1918 IP address space. Workloads in Google Cloud can communicate with the gateway, load balancer, or Private Service Connect endpoint by using internal IP addresses, other systems in the private environment cannot be reached directly from Google Cloud, and communication from the private environment to Google Cloud workloads is not allowed. To limit traffic from specific VPC IP addresses to remote gateways, IP allowlist filtering is used, and return traffic is allowed by stateful firewall rules. Filtering and inspection can combine firewall rules or firewall policies, a network virtual appliance (NVA) with next-generation firewall inspection in the path, and Cloud Next Generation Firewall Enterprise with intrusion prevention for deep packet inspection.
Restricted Google Access and Private Service Connect endpoints are two private paths for reaching Google APIs and services that run on Google's production infrastructure. Restricted Google Access (opens in a new tab) limits API reachability to a VPC Service Controls-compliant subset through the restricted.googleapis.com virtual IP (VIP). Private Service Connect exposes Google APIs through an internal IP address inside the VPC network. Both paths keep traffic within Google's private network and avoid the public internet.
Restricted Google Access is the use of Private Google Access with the restricted.googleapis.com domain to allow only VPC Service Controls (opens in a new tab)-supported APIs. Requests from virtual machine (VM) instances to *.googleapis.com are resolved by Cloud DNS to restricted.googleapis.com, which maps to IPv4 range 199.36.153.4/30 and IPv6 range 2600:2d00:0002:1000::/56. Those VIP ranges are not announced to the internet, so traffic sent to the VIP stays within Google Cloud's network only. Using restricted.googleapis.com denies access to Google APIs and services that are not supported by VPC Service Controls, which reduces data exfiltration risk.
Restricted Google Access depends on Private Google Access networking controls in the VPC network. VM instances must have only a private IP address with no public IP address and must sit in a subnet with Private Google Access enabled. A custom static route directs destination 199.36.153.4/30 to the default-internet-gateway as the next hop, and despite the gateway name the traffic is routed privately through Google's network to the appropriate API. Firewall rules must allow egress to the restricted VIP range, and DNS must map API names to the restricted VIP.
For on-premises hosts, Restricted Google Access flows from the on-premises network through a VPC network over a Cloud VPN tunnel or Cloud Interconnect VLAN attachment. The on-premises DNS configuration maps *.googleapis.com to restricted.googleapis.com, and the 199.36.153.4/30 range is made reachable by a static route in the on-premises router or by advertisement through BGP from Cloud Router. The connected VPC network must be inside the same VPC Service Controls service perimeter as the protected resource, or connected by a perimeter bridge, for on-premises hosts to gain the same access as VPC VMs. Setting up the path completes in three parts:
199.36.153.4/30 to default-internet-gateway and advertise the range to on-premises when hybrid access is needed.*.googleapis.com to restricted.googleapis.com so all API traffic uses the restricted VIP.Private Service Connect (opens in a new tab) endpoints for Google APIs provide private consumption of Google-managed services through an internal IP address inside the consumer VPC network. An administrator reserves an internal address with purpose PRIVATE_SERVICE_CONNECT and creates a global forwarding rule with --target-google-apis-bundle that forwards requests from the endpoint to Google APIs and services. The endpoint supports all Google Cloud APIs and most other Google APIs, and it serves Google Cloud resources or on-premises systems with or without external IP addresses when hybrid connectivity exists. On-premises hosts reach the endpoint over Cloud VPN or Cloud Interconnect using the endpoint IP address advertised by Cloud Router.
Private Service Connect endpoints make the network path explicit and auditable because each endpoint maps directly to a specific service or API bundle. A private Cloud DNS zone for googleapis.com. in the VPC network maps googleapis.com with an A record to the endpoint IP, such as 10.0.1.1, and maps *.googleapis.com with a CNAME record to googleapis.com.. Firewall policy then controls access at the endpoint IP rather than at shared VIPs, so an egress rule can allow TCP port 443 only to 10.0.1.1 while a low-priority rule denies all other egress to 0.0.0.0/0. The bundle choice controls scope, where the vpc-sc bundle aligns with VPC Service Controls-supported APIs and the all-apis bundle provides broader access that should be paired with VPC Service Controls service patterns to limit which unsupported APIs remain reachable.
The comparison between Restricted Google Access and Private Service Connect endpoints turns on filtering behavior, granularity, and operational control. Restricted Google Access enforces allowlisting by domain, while Private Service Connect enforces isolation by dedicated internal endpoint and firewall scope.
| Approach | Connection mechanism | Service filtering |
|---|---|---|
| Restricted Google Access | Traffic flows from private VMs or on-premises hosts through the VPC default internet gateway to the shared restricted VIP 199.36.153.4/30 | Allows only VPC Service Controls-supported APIs; denies unsupported APIs by default |
| Private Service Connect endpoints | Traffic flows from private or public-IP clients to an internal endpoint IP in the VPC network, then the forwarding rule forwards requests to Google APIs | Bundle selection controls scope; vpc-sc aligns with perimeter services while all-apis needs service patterns to restrict unsupported APIs |
Choose Restricted Google Access when the goal is simple subnet-level enforcement that no workload can reach non-compliant APIs on the private path. Choose Private Service Connect endpoints when workloads need per-service network isolation, per-endpoint firewall rules, and explicit audit of which internal IP reaches Cloud Storage or BigQuery without sharing a path with other API traffic. The two approaches can combine with a deny-all-egress baseline, where only the restricted VIP or only the endpoint IP is allowed, to mitigate internet exfiltration paths inside a VPC Service Controls perimeter.
Exam tip: Use restricted.googleapis.com when workloads do not require unsupported APIs, because it denies them; use private.googleapis.com or an all-apis Private Service Connect endpoint with service patterns when unsupported APIs are required but must be selectively limited.
Private Google Access (opens in a new tab) for VPC resources is a subnet-level setting in a VPC network that lets VM interfaces without an external IP address reach Google APIs and services. Traffic from those VMs is sent through the VPC network's default-internet-gateway as the next hop, but the path stays inside Google's network and does not traverse the public internet. Enable Private Google Access when isolated VMs must use Google APIs while keeping no public IP addresses for network isolation.
By default, a VM without an external IP address can send packets only to other internal IP destinations and cannot reach anything outside its VPC network, including Google APIs. Private Google Access removes that limitation for the subnet where it is enabled, without assigning external addresses to the VMs. Google Kubernetes Engine (GKE) automatically enables Private Google Access on subnets where nodes are deployed, so private nodes can reach Google-managed services.
When to enable Private Google Access depends on whether VMs with only private IP addresses must call services that run on Google's production infrastructure. Those services include Google APIs with *.googleapis.com endpoints, web applications such as Gmail and Google Maps, serverless resources served from *.appspot.com, *.run.app, or *.cloudfunctions.net, and files served from *.gstatic.com. Private Google Access also allows access to the external IP addresses used by App Engine, including third-party App Engine-based services.
A VM interface with an external IPv4 or IPv6 address does not need Private Google Access to reach Google APIs and services. Choose Private Google Access when the goal is isolation plus API access: keep the VM without an external address and turn on the feature on its subnet. When VMs need to reach VPC-hosted services such as Cloud SQL, Filestore, or Memorystore for Redis through private addresses, use Private Service Connect or private services access instead of, or in addition to, Private Google Access.
The requirements for a Private Google Access connection must all be met at the same time for a VM interface to reach Google APIs privately. The VPC network must meet the requirements for Google APIs, the subnet must have the feature on, the interface must have no external address, and the packet source must be a valid internal address.
The network requirements add two practical checks. If the workload calls a Google API service endpoint, enable that API in the project, such as enabling the Cloud Storage API before creating buckets through storage.googleapis.com. If the workload uses IPv6, the VM must be configured with a /96 IPv6 address range and the software on the VM must send packets from an address in that range.
Routing for Private Google Access uses the default-internet-gateway next hop to reach Google API destination ranges, even though the traffic remains private inside Google's network. In a normal VPC network the default route 0.0.0.0/0 already points to that gateway, so no extra route is needed for the standard Google API addresses. This default path does not slow down communication with Google APIs.
When the default route is changed, explicit routes preserve private API access while keeping isolation. A common example is a network that sends 0.0.0.0/0 to an on-premises inspection device instead of the internet gateway. The following comparison summarizes the two routing choices supported by the documentation.
| Routing choice | When to use it | Destination and next hop |
|---|---|---|
| Default routing | The 0.0.0.0/0 route still uses the default-internet-gateway | Default route carries API traffic to the default-internet-gateway, which forwards it privately to Google APIs |
| Custom explicit routing | The 0.0.0.0/0 route was changed to a different next hop | Explicit routes for Google API destination ranges point to the default-internet-gateway as the next hop |
For hardened perimeters, point DNS and routing at the restricted.googleapis.com VIP ranges instead of the standard addresses. The IPv4 range is 199.36.153.4/30 and the IPv6 range is 2600:2d00:0002:1000::/56, and neither range is announced to the internet. A custom static route sends destination 199.36.153.4/30 to the default-internet-gateway, and traffic then flows privately through Google's network to the appropriate API or service.
Exam tip: A next hop of default-internet-gateway for Google API ranges still keeps traffic inside Google's network; the gateway name does not mean the traffic leaves for the public internet.
Firewall rules and DNS for Private Google Access complete the deployment by allowing only the intended API traffic and directing names to the intended VIP. Egress firewall rules must permit traffic to the Google API addresses or to the endpoint, and the default VPC implied allow egress rule already permits it unless a higher-priority egress rule blocks it. DNS is configured so queries for *.googleapis.com resolve to restricted.googleapis.com, which resolves to 199.36.153.4/30, when the restricted path is required.
The restricted path enforces a security boundary for VPC Service Controls (opens in a new tab). Using restricted.googleapis.com denies access to Google APIs and services that are not supported by VPC Service Controls. Using private.googleapis.com or a Private Service Connect endpoint with the all-apis bundle allows unsupported APIs, so combine that choice with VPC Service Controls service patterns to control which unsupported APIs are reachable and reduce data exfiltration risk.
Some Google APIs also support direct connectivity from Compute Engine VMs that bypasses Google Front Ends (GFEs) for better performance. To establish that path, routes and firewall rules must allow IPv4 traffic to 34.126.0.0/18 and IPv6 traffic to 2001:4860:8040::/42. Those addresses support VPC Service Controls and do not require DNS records.
Enabling Private Google Access on a subnet is a per-subnet operation, so VMs that need Google API access should be placed on the same subnet where the setting is on. If a VM has more than one interface, connect the interface with the default route, usually nic0, to the enabled subnet. Principals who create or update subnets need Project Owner, Editor, or Network Admin rights.
To enable the setting with gcloud, identify the subnet and region and then update and verify the subnet:
gcloud compute networks subnets list --filter=NETWORK_NAME to find the subnet name and region for the target VPC network.gcloud compute networks subnets update SUBNET_NAME --region=REGION --enable-private-ip-google-access to turn on Private Google Access.gcloud compute networks subnets describe SUBNET_NAME --region=REGION --format="get(privateIpGoogleAccess)" to confirm the setting is enabled.After the subnet setting is on, confirm that routes point API destinations to the default-internet-gateway, that egress firewall rules allow the API ranges, and that DNS resolves API names to the selected VIP. Together those three checks ensure that VMs without external IP addresses can reach the required Google APIs while all other internet egress remains blocked.
default-internet-gateway next hop while staying inside Google's network.restricted.googleapis.com at 199.36.153.4/30 and 2600:2d00:0002:1000::/56 to allow only VPC Service Controls-supported APIs and deny unsupported APIs.--target-google-apis-bundle and private DNS records for googleapis.com.Use Private Google Access for on-premises hosts for the basic private path to Google APIs over an existing Cloud Interconnect connection or Cloud VPN tunnel into the VPC network. Use a Private Service Connect endpoint when hybrid clients must call the API through an internal IP address in your VPC network with private DNS. The endpoint forwards traffic from that internal address over Google’s internal infrastructure to the destination without traveling over the internet.
Restricted Google Access uses Private Google Access with the restricted.googleapis.com domain at 199.36.153.4/30 and 2600:2d00:0002:1000::/56 to allow only VPC Service Controls-supported APIs and deny unsupported APIs. Private Service Connect endpoints expose Google APIs through an internal IP address in the VPC network with a forwarding rule that targets a Google APIs bundle and private DNS records for googleapis.com. Choose Restricted Google Access for simple subnet-level enforcement that blocks non-compliant APIs and choose Private Service Connect endpoints for per-service isolation with per-endpoint firewall rules and explicit audit of which internal IP reaches each service.
A virtual machine interface without an external IP address needs to be connected to a subnet where Private Google Access is enabled, a VPC network that meets the network requirements for Google APIs, and a packet source that matches its primary internal IPv4 address, internal IPv6 address, or an alias IP range address. Routing must send Google API destinations to the default-internet-gateway next hop so traffic stays inside Google’s network, and egress firewall rules and DNS must permit and direct the intended API traffic.
A financial enterprise is securing communications between its Google Cloud VPC network and Google APIs to prevent data exfiltration. The security architect has established the following requirements:
Which combination of private connectivity architectures should the architect implement?
Configure Cloud DNS response policies to map *.googleapis.com to restricted.googleapis.com (199.36.153.4/30) for VPC-wide egress, and deploy a Private Service Connect (PSC) endpoint for Google APIs with an allocated internal IP in the analytics subnet.
Configure Cloud DNS to resolve *.googleapis.com to private.googleapis.com (199.36.153.8/30) for the entire VPC, and create a Private Services Access (PSA) connection for the analytics subnet.
Configure Cloud DNS to resolve *.googleapis.com to restricted.googleapis.com (199.36.153.4/30) across the VPC, and configure Serverless VPC Access connectors for the analytics tier.
Enable standard Private Google Access on all subnets, and deploy an internal Application Load Balancer with a Private Service Connect backend pointing to all-apis for the analytics tier.
Last updated