Private Google Access: Reaching Google APIs Without a Public IP
A VM with no external IP address is, from a security standpoint, exactly what you want for most backend workloads — nothing on the public internet can initiate a connection to it directly. But that same VM still needs to call Cloud Storage, BigQuery, Pub/Sub, or any other Google API to actually do its job, and those APIs live at public endpoints (storage.googleapis.com and similar). Without something solving this specific gap, a no-external-IP VM would be unable to reach the very Google services it needs, which would defeat a lot of the point of running on GCP in the first place. Private Google Access is that solution — it lets VMs without external IPs reach Google APIs and services over Google’s internal network, never touching the public internet at all.
This sounds like a small, obscure feature until you internalize how central it is to running a genuinely locked-down GCP environment — nearly every “no external IPs by default” security posture depends on it working correctly.
How It Actually Works
VM with no external IP (10.0.1.5) │ ▼ Enable Private Google Access on the subnet │ ▼DNS resolves storage.googleapis.com to aGoogle-owned IP range reachable via internal routing │ ▼ Request routes over Google's internal network, never touching the public internet │ ▼ Cloud Storage API respondsgcloud compute networks subnets update my-subnet \ --region=us-central1 \ --enable-private-ip-google-accessThis is a per-subnet setting, not a per-VM one — every VM in a subnet with Private Google Access enabled gets the capability automatically, without individual configuration. Once enabled, a VM with no external IP can call storage.googleapis.com, bigquery.googleapis.com, and other Google API endpoints exactly as if it had public internet access, but the traffic never actually leaves Google’s network.
Restricted vs Default API Access
There’s a meaningful distinction between the default Private Google Access behavior and a more locked-down variant using restricted VIPs:
┌────────────────────────┬────────────────────────────────────────┐│ Endpoint │ Behavior │├────────────────────────┼────────────────────────────────────────┤│ *.googleapis.com │ Reaches any Google API, including some ││ (default) │ services outside your VPC Service Controls ││ │ perimeter if one is configured ││ restricted.googleapis.com │ Reaches only APIs supported within a VPC ││ │ Service Controls perimeter — genuinely ││ │ restricts which services are reachable, ││ │ enforcing perimeter boundaries strictly │└────────────────────────┴────────────────────────────────────────┘For environments using VPC Service Controls to enforce a hard data-exfiltration boundary (covered more fully as its own topic), pointing DNS at restricted.googleapis.com instead of the default *.googleapis.com is what actually makes the perimeter enforcement meaningful for private-access traffic — using the default endpoint can, depending on configuration, allow some API traffic that bypasses the intended perimeter restriction, which defeats a real part of what VPC Service Controls is meant to guarantee.
Setting Up Restricted Access with Custom DNS
# Create a private DNS zone for the restricted VIPgcloud dns managed-zones create restricted-googleapis \ --dns-name="googleapis.com." \ --visibility=private \ --networks=my-vpc \ --description="Route Google API traffic through restricted VIP"
# Add a CNAME pointing to the restricted VIP rangegcloud dns record-sets create "*.googleapis.com." \ --zone=restricted-googleapis \ --type=CNAME \ --ttl=300 \ --rrdatas="restricted.googleapis.com."
gcloud dns record-sets create "restricted.googleapis.com." \ --zone=restricted-googleapis \ --type=A \ --ttl=300 \ --rrdatas="199.36.153.4,199.36.153.5,199.36.153.6,199.36.153.7"
# Route to the restricted rangegcloud compute routes create restricted-vip-route \ --network=my-vpc \ --destination-range=199.36.153.4/30 \ --next-hop-gateway=default-internet-gatewayThis combination — private DNS zone overriding the default *.googleapis.com resolution, plus a route to the restricted VIP range — is what actually enforces “this VPC can only reach Google APIs that are within our VPC Service Controls perimeter,” rather than relying on the default, broader access pattern.
This setup is worth testing explicitly after configuration, not just trusted to be correct — running a Connectivity Test or a direct API call from a representative VM and confirming the traffic actually resolves through the restricted VIP, rather than silently falling back to the default path, catches a misconfiguration before it becomes a false sense of security rather than after.
Private Google Access for On-Prem: A Different Direction
For on-prem systems (connected via VPN or Interconnect) that also need to reach Google APIs privately, without routing through the public internet, there’s a parallel capability using Private Google Access for on-premises hosts — same underlying restricted VIP mechanism, but reachable from outside GCP entirely through the hybrid connection:
On-prem server │ ▼ (via Cloud VPN / Interconnect)Cloud Router advertises restricted.googleapis.comrange (199.36.153.4/30) to on-prem │ ▼On-prem server routes Google API trafficthrough the hybrid connection, privately │ ▼Google API responds, still never touchingthe public internetThis is genuinely valuable for hybrid environments with a compliance requirement that certain API calls (say, encrypting data via Cloud KMS from an on-prem application) never traverse the public internet, even briefly, even encrypted.
Default Path vs Restricted Path, Traced Side by Side
Seeing both DNS resolution paths laid out together makes the practical difference concrete in a way the abstract description doesn’t quite capture.
The takeaway worth internalizing: enabling Private Google Access alone gets your no-external-IP VMs functional against Google APIs, but it doesn’t by itself give you the strict perimeter enforcement a compliance requirement might actually demand. That requires the deliberate additional step of overriding DNS resolution to the restricted VIP — two related but genuinely separate configuration decisions, easy to conflate as “we enabled private access, so we’re covered” when they’re not quite the same guarantee.
Private Google Access vs Private Service Connect: Two Related, Distinct Tools
Because these names get confused constantly, a direct comparison is worth having explicitly rather than leaving the distinction implicit.
┌───────────────────────┬───────────────────────────────────────┐│ Aspect │ Private Google Access vs Private Service Connect│├───────────────────────┼───────────────────────────────────────┤│ What it connects to │ PGA: Google's own public APIs only. ││ │ PSC: Google-managed services, third-party ││ │ published services, or your own services ││ │ published for private consumption ││ Setup mechanism │ PGA: subnet flag + optional DNS override. ││ │ PSC: explicit endpoint creation with an ││ │ allocated internal IP per connection ││ Typical use │ PGA: general-purpose "reach Google APIs ││ │ from a private VM." PSC: connecting to a ││ │ specific managed service or SaaS product ││ │ privately, often across organizational ││ │ boundaries │└───────────────────────┴───────────────────────────────────────┘In practice, most environments need Private Google Access simply because it’s a prerequisite for any no-external-IP VM to function at all — it’s closer to baseline infrastructure than an opt-in architectural choice. Private Service Connect is reached for more deliberately, for specific service-to-service private connectivity needs, particularly when connecting to a SaaS vendor’s product or exposing your own internal service to another team or organization without broader network exposure.
Real-World Use Case: Fully Locked-Down Data Processing Environment
A company processing regulated financial data wants every VM handling that data to have zero external IP addresses, zero direct internet exposure, while still needing those VMs to read source data from Cloud Storage, write results to BigQuery, and log to Cloud Logging — all genuine Google API dependencies. Private Google Access with the restricted VIP configuration, combined with VPC Service Controls defining exactly which projects and services are inside the trusted perimeter, gives this environment full functional API access with a technically enforced guarantee that data never has a path to the public internet, satisfying auditors who specifically ask “can you prove this data cannot leave through an API call” rather than just asserting a policy that says it won’t.
Best Practices
- Enable Private Google Access on every subnet hosting VMs without external IPs — it’s a required prerequisite, not an optional hardening step, for those VMs to function at all against Google APIs.
- Use the restricted VIP and custom DNS setup for any environment with a genuine data-exfiltration concern, not just the default
*.googleapis.compath, since only the restricted path actually enforces VPC Service Controls perimeter boundaries meaningfully. - Extend Private Google Access to on-prem systems via the hybrid connectivity pattern wherever a compliance requirement demands API traffic never touch the public internet, even from outside GCP.
- Test actual API reachability after enabling, using a Connectivity Test or a direct call from a representative VM, rather than assuming the subnet setting alone guarantees correct behavior across every API your workloads actually depend on.
Common Mistakes
Assuming a no-external-IP VM can reach Google APIs without Private Google Access enabled. Without it explicitly enabled on the subnet, such a VM genuinely cannot reach storage.googleapis.com or any other Google API — this is a common and confusing first encounter with the feature, since the error looks like a generic connectivity failure rather than a missing, specific configuration step.
Using the default *.googleapis.com endpoint while believing VPC Service Controls fully enforces the perimeter. Without the restricted VIP and DNS override, some traffic patterns can bypass the intended perimeter restriction — a gap that undermines a security control the team believes is fully in place.
Forgetting the on-prem side of hybrid Private Google Access when only configuring the GCP side. Both directions need explicit configuration — GCP-side restricted VIP setup doesn’t automatically extend to on-prem without the corresponding route advertisement over the hybrid connection.
Frequently Asked Questions
Does Private Google Access cost anything extra? No separate fee for the feature itself — traffic still incurs standard data processing charges where applicable, but there’s no additional charge specifically for using Private Google Access over having an external IP.
Can a VM with an external IP also use Private Google Access? The setting applies at the subnet level regardless of individual VM IP configuration, but it’s primarily meaningful for VMs without external IPs — a VM with a public IP can already reach Google APIs over the public internet without needing this feature.
Is Private Google Access the same as Private Service Connect? No — Private Google Access is specifically for reaching Google’s own public APIs privately. Private Service Connect is a broader capability for privately connecting to Google-managed services and even third-party or your own published services via private endpoints — related in spirit but a distinct, more general mechanism.
What happens if I forget to update DNS when switching from default to restricted API access? Without the DNS override, traffic continues resolving to the default *.googleapis.com addresses rather than the restricted VIP — the route and perimeter configuration alone aren’t sufficient without DNS actually directing traffic to the restricted endpoint.
Summary
Private Google Access is the unglamorous but structurally necessary piece that makes “no external IPs” a viable security posture rather than a self-defeating one — without it, locking down external IP access would also lock workloads out of the Google APIs they legitimately need. The distinction between default and restricted VIP access is worth taking seriously specifically because it’s the difference between a VPC Service Controls perimeter that’s actually enforced for API traffic and one that has a meaningful gap most teams don’t discover until an audit or a genuine incident tests it directly.