Private Google Access in GCP Explained | Reach Google APIs Without External IPs

Simple explanation

Private Google Access is a setting you enable on a subnet. When it is on, VMs in that subnet can reach Google Cloud APIs — Cloud Storage, BigQuery, Pub/Sub, and similar — even if those VMs have no external IP address. The traffic travels over Google’s internal network, not the public internet.

Why Private Google Access exists

A solid security baseline for GCP VMs is to remove external IP addresses. Every public IP is a potential target: it can be scanned, probed, and subjected to brute-force attempts. The network security best practices page covers this in more detail.

But removing external IPs creates an immediate problem. A VM processing data might need to read from Cloud Storage, write results to BigQuery, or publish messages to Pub/Sub. Without an external IP, and without Private Google Access, those API calls fail — the VM has no route to the internet and no other way to reach Google’s API endpoints.

Private Google Access solves this with a dedicated internal route. Your VMs stay off the internet entirely, and Google API traffic stays on Google’s network. You get the security benefit without sacrificing the ability to use the services.

How it works

Private Google Access is configured at the subnet level, not the VPC level. Enabling it on a subnet makes two virtual IP ranges reachable from VMs in that subnet:

• 199.36.153.8/30 — private.googleapis.com: standard private access to Google APIs
• 199.36.153.4/30 — restricted.googleapis.com: for VPC Service Controls-protected access

When a VM in that subnet calls a Google API, the traffic is routed to one of these virtual IPs. Google’s infrastructure receives the request and forwards it to the appropriate service. The VM never needs a public IP, and the traffic does not leave Google’s network.

Key boundaries to understand:

• Subnet-level, not VPC-level. Enabling it on one subnet does not enable it on others. Each subnet you want to use must be configured individually.
• Outbound only. This feature controls outbound API calls from your VMs. It has no effect on inbound traffic.
• Google APIs only. Private Google Access covers Google Cloud services. It does not cover Google Workspace APIs (Gmail, Drive, etc.) or any non-Google internet destinations.

When to use Private Google Access

Enable Private Google Access whenever private VMs need to reach Google APIs. Common scenarios:

• Compute Engine VMs with no external IP that read from Cloud Storage, write to BigQuery, or publish to Pub/Sub
• Hardened subnets where external IPs have been removed as a baseline security measure
• VPC Service Controls environments — required when you want API traffic to stay within your service perimeters (use restricted.googleapis.com in this case)
• Data processing workloads in isolated subnets that should not have general internet access but still need to call managed Google services
• Architectures that enforce no external IPs by default via an organisation policy

Private Google Access vs Cloud NAT

These two are often confused because both deal with private VMs that lack external IPs. They solve different problems and are not interchangeable.

Many production architectures use both. Private Google Access covers Google API calls. Cloud NAT covers everything else outbound. They work independently — enabling one does not affect the other.

Private Google Access vs Private Service Connect

Private Google Access and Private Service Connect are frequently confused because both involve private connectivity to Google services. They are distinct features with different scopes.

Private Google Access is a subnet-level flag. Enable it and all VMs in that subnet can reach any Google-managed API through well-known virtual IP ranges. There are no individual endpoints to create and no extra resources to manage. It works uniformly across all Google Cloud APIs.

Private Service Connect is a more granular endpoint model. You create a specific private endpoint — with its own internal IP — that forwards traffic to a particular service. That service might be a Google API, or it might be a service published by another team or organisation inside your network. Each endpoint is a distinct resource and can be controlled independently with its own firewall rules and access policies.

In practice:

• Private Google Access is simpler to set up and sufficient for most workloads that need to call Google APIs privately
• Private Service Connect gives finer control — useful when you need to pin traffic to a specific endpoint, apply per-endpoint policies, or access third-party services published inside your network
• The two can coexist — some subnets use Private Google Access broadly, while specific services use Private Service Connect endpoints alongside it

DNS and restricted access

For most workloads, Private Google Access works without any DNS changes. VMs resolve API hostnames (like storage.googleapis.com) to public Google IPs by default, but the traffic is still routed internally because of how the virtual IP ranges are handled at the VPC edge.

When you use VPC Service Controls, DNS configuration becomes critical. Your VMs must resolve API hostnames to the restricted.googleapis.com range (199.36.153.4/30), not to public Google IPs. If they resolve to a public IP, that traffic bypasses your service perimeters entirely — defeating their data exfiltration protection.

The fix is a private DNS zone in Cloud DNS that overrides googleapis.com resolution inside the VPC:

# Create a private DNS zone to override googleapis.com resolution
gcloud dns managed-zones create googleapis-private \
  --dns-name=googleapis.com. \
  --description="Redirect googleapis.com to restricted VIPs" \
  --visibility=private \
  --networks=my-vpc

# Point *.googleapis.com to restricted.googleapis.com
gcloud dns record-sets create "*.googleapis.com." \
  --zone=googleapis-private \
  --type=CNAME \
  --ttl=300 \
  --rrdatas=restricted.googleapis.com.

# Add A records for restricted.googleapis.com (199.36.153.4/30)
gcloud dns record-sets create "restricted.googleapis.com." \
  --zone=googleapis-private \
  --type=A \
  --ttl=300 \
  --rrdatas="199.36.153.4,199.36.153.5,199.36.153.6,199.36.153.7"

The CNAME causes all *.googleapis.com queries inside the VPC to resolve to restricted.googleapis.com, which then resolves to the VIP A records. VMs outside this private zone are unaffected — the override is VPC-scoped.

Firewall and routing considerations

In most VPCs, enabling the subnet flag is sufficient. GCP’s default VPC allows all egress traffic, so no additional firewall rule is needed.

If your VPC has a deny-all egress rule as a hardening baseline — which is a sensible practice for sensitive workloads — you must also add an explicit allow rule for the Google API VIP ranges. Without it, the subnet setting has no practical effect: the egress firewall drops the traffic before it can reach the VIP.

# Allow egress to both Google API VIP ranges on HTTPS
gcloud compute firewall-rules create allow-egress-private-google-access \
  --network=my-vpc \
  --direction=EGRESS \
  --action=ALLOW \
  --rules=tcp:443 \
  --destination-ranges=199.36.153.8/30,199.36.153.4/30 \
  --priority=100 \
  --description="Allow egress to Google APIs via Private Google Access"

How to enable Private Google Access

You can enable Private Google Access on an existing subnet or at creation time. The change takes effect immediately for all VMs in that subnet.

# Enable on an existing subnet
gcloud compute networks subnets update my-subnet \
  --region=europe-west1 \
  --enable-private-ip-google-access

# Verify the setting
gcloud compute networks subnets describe my-subnet \
  --region=europe-west1 \
  --format="get(privateIpGoogleAccess)"

# Create a new subnet with Private Google Access already enabled
gcloud compute networks subnets create my-new-subnet \
  --network=my-vpc \
  --region=europe-west1 \
  --range=10.10.20.0/24 \
  --enable-private-ip-google-access

The verify command returns True when enabled and False when disabled. If you see False on a subnet where you expected it enabled, confirm you are using the correct region — subnet names are not globally unique across regions.

How to verify it is working

SSH into a VM that has no external IP — use Identity-Aware Proxy or a bastion to access it — and test connectivity to a Google API directly:

# SSH to a private VM using IAP tunnel
gcloud compute ssh my-private-vm \
  --zone=europe-west1-b \
  --tunnel-through-iap

# From inside the VM: test API reachability
curl -o /dev/null -s -w "%{http_code}\n" \
  https://storage.googleapis.com/storage/v1/b?project=my-project

# A 200 or 401 both confirm the network path is working
# 200 = authenticated and succeeded
# 401 = auth failed, but the VM reached the API endpoint

# Alternatively, test with the VM's attached service account
gsutil ls gs://my-bucket/

A 401 response is still good news for network testing — it means the VM reached the Storage API and received an HTTP response, which confirms the internal path is open. A connection timeout or Could not connect error indicates a network-level failure: Private Google Access may not be enabled on the subnet, the egress firewall may be blocking the traffic, or the DNS resolution is returning an unreachable IP.

For a systematic approach to diagnosing why a private VM cannot reach Google APIs, see Troubleshooting Network Issues.