Private Google Access and PSC

Introduction

In Google Cloud, Compute Engine VMs without external IP addresses, private GKE nodes, Cloud SQL clients, and Dataflow workers cannot reach the public internet by default. Yet most workloads still need to call Google-managed APIs such as storage.googleapis.com, bigquery.googleapis.com, pubsub.googleapis.com, dataflow.googleapis.com, or logging.googleapis.com to do useful work. Private Google Access (PGA) is the family of features that lets these otherwise air-gapped resources reach Google APIs over Google's internal backbone using only internal IP addresses, without traversing the public internet, without external NAT, and without giving up the security posture of a private subnet.

PGA is not a single feature but a layered system with four distinct flavours: PGA for VM instances (a subnet flag), PGA for on-premises hosts (a hybrid pattern over Cloud VPN or Interconnect), the Restricted VIP at 199.36.153.4/30 used to enforce VPC Service Controls (VPC-SC), and the newer Private Service Connect (PSC) endpoints for Google APIs which let you assign your own internal IP to the API surface. Each variant uses different VIP ranges, different DNS configurations, and different routing tricks. This study note walks through every variant, the exact 199.36.153.0/24 sub-prefixes Google publishes, the Cloud DNS managed zones you must create, the 0.0.0.0/0 deny plus narrow /30 allow routing pattern, BGP advertisement on Cloud Router for hybrid scenarios, and how PSC for Google APIs differs from classic PGA, with enough depth to pass any PCNE blueprint question on private connectivity to Google services.

PGA for VMs: The Subnet Enable Flag

What the Subnet Flag Actually Does

Private Google Access for VM instances is enabled with a single boolean on each subnet, set via gcloud compute networks subnets update SUBNET --region=REGION --enable-private-ip-google-access or in the Console as Private Google access: On. When the flag is on, VMs in that subnet whose primary or alias IP is internal-only can send packets to the public IP ranges of any Google API (such as storage.googleapis.com) and the Andromeda data plane on the host treats those packets as in-network: Google's edge accepts them despite the source being a private RFC1918 address, because Google can verify the packet originated from a PGA-enabled subnet in a real Google Cloud project.

Eligibility Rules

PGA only takes effect when the VM has no external IPv4 address on the relevant network interface. A dual-stack VM with an ephemeral external IP will egress via the external IP instead, ignoring the PGA flag, because the kernel routing table prefers the interface with a default route to the internet gateway. Alias IP ranges inherit the subnet's PGA setting, so GKE Pods on private nodes get PGA for free when the node subnet has the flag enabled. PGA is per-region per-VPC, scoped to the subnet primary CIDR and its alias ranges.

Cost and Limits

Enabling PGA is free; you pay only standard Google API egress charges and any service-side data processing fees. There is no PGA throughput cap separate from the underlying VM egress allowance, and PGA traffic does not consume Cloud NAT ports or count against NAT IP allocation. The feature is available in every Google Cloud region and in every VPC type, including legacy networks, custom-mode VPC, and Shared VPC service projects.

The Two Google API VIP Ranges

private.googleapis.com at 199.36.153.8/30

Google publishes a documented public VIP range 199.36.153.8/30 (four addresses) that resolves the hostname private.googleapis.com and serves all supported Google APIs. The range is announced only inside Google's private backbone; it is not reachable over the public internet despite being a public-IANA-allocated prefix. From a PGA-enabled subnet a VM can reach any Google API through these four IPs, and the same range is used in hybrid PGA when you route on-prem traffic to Google over Cloud VPN or Interconnect. Treat 199.36.153.8/30 as the canonical "private path to all Google APIs" target.

restricted.googleapis.com at 199.36.153.4/30

A second adjacent prefix 199.36.153.4/30 resolves the hostname restricted.googleapis.com and serves only those Google APIs that are integrated with VPC Service Controls as supported services. The Restricted VIP is what you use when an organization policy or a service perimeter forbids data exfiltration: any call that would land on the regular *.googleapis.com public IPs is denied, and only traffic that targets 199.36.153.4/30 is accepted, after which VPC-SC enforces the perimeter rules. The list of services callable via the Restricted VIP is a published subset (notably Cloud Storage, BigQuery, Pub/Sub, Spanner, Dataflow, AI Platform, KMS, Logging, Monitoring) and excludes some non-perimeterable services such as compute.googleapis.com admin endpoints.

Picking the Right VIP

For workloads that are not bound by a VPC-SC perimeter, use private.googleapis.com (199.36.153.8/30). For workloads inside a perimeter, or any architecture pursuing strict data-exfiltration controls, use restricted.googleapis.com (199.36.153.4/30) and pair it with a perimeter that lists the projects and services in scope. You can configure both ranges in the same VPC if different subnets or different on-prem segments require different policies, since they are distinct /30s and DNS resolution picks one or the other based on the hostname queried.

DNS Configuration with Cloud DNS Managed Zones

Why DNS Is the Crucial Piece

The PGA VIPs only work if your clients resolve *.googleapis.com hostnames to 199.36.153.8/30 or 199.36.153.4/30 instead of the regular public IPs. Public DNS resolves storage.googleapis.com to a normal global anycast public IP that has no special PGA semantics. To force the private path you create a Cloud DNS private managed zone that overrides resolution for googleapis.com and its key subdomains and returns the VIP addresses.

The Zone Layout for private.googleapis.com

The canonical pattern is one Cloud DNS private zone for googleapis.com. containing: an A record at the apex googleapis.com. pointing to the four IPs 199.36.153.8, 199.36.153.9, 199.36.153.10, 199.36.153.11; and a CNAME *.googleapis.com. pointing to private.googleapis.com. This forwards every Google API hostname (storage, bigquery, pubsub, and so on) to the apex which then resolves to the VIP /30. Create it with gcloud dns managed-zones create googleapis --visibility=private --networks=prod-vpc --dns-name=googleapis.com. followed by the record-set transactions for the A and CNAME entries.

The Zone Layout for restricted.googleapis.com

For VPC-SC the apex googleapis.com. A record points to 199.36.153.4, 199.36.153.5, 199.36.153.6, 199.36.153.7 and the wildcard CNAME *.googleapis.com. points to restricted.googleapis.com. The structure is identical; only the target VIP changes. Inside a VPC that hosts perimeterized workloads, prefer the restricted layout so every Google API call your VMs make is forced through VPC-SC.

Additional Hostnames

Beyond the apex zones, some services need extra entries. Container Registry and Artifact Registry need gcr.io, pkg.dev, *.gcr.io, and *.pkg.dev CNAMEd to the same VIP. Some legacy services need *.appspot.com. Always check the current Google documentation for the supported-domains list before assuming the apex googleapis.com zone is sufficient.

Routing: The 0.0.0.0/0 Deny Plus /30 Allow Pattern

Why the Default Route Matters

PGA for VMs requires a 0.0.0.0/0 route with next hop default-internet-gateway in the VPC; the route does not have to be usable (you can layer a deny firewall on top of it), but it has to exist for the host kernel to even attempt forwarding. Custom-mode VPCs ship with this route preinstalled. Auto-mode VPCs do too. The presence of the route is a precondition, not the data path, because the actual PGA forwarding happens inside Andromeda before the packet reaches any internet gateway.

Hardening with a Deny-All-Egress Firewall

In high-security designs you create an egress deny firewall rule for 0.0.0.0/0 at low priority (for example priority 65000) and then layer a higher-priority egress allow rule for the specific VIP /30 (199.36.153.4/30 or 199.36.153.8/30) plus your private RFC1918 ranges. This guarantees that even if DNS misconfiguration accidentally resolves to public IPs, the firewall blocks any escape to the public internet, and only the documented PGA VIPs are permitted.

Custom Static Routes for Hybrid PGA

For on-premises PGA, you cannot rely on default-internet-gateway because on-prem clients reach Google through Cloud VPN or Interconnect, not via internet egress. The pattern is a custom static route in the VPC for 199.36.153.4/30 (or .8/30) with next hop default-internet-gateway, so traffic arriving from on-prem and destined for the VIPs is handed off to Google's edge. The route is created with gcloud compute routes create private-googleapis --network=hub-vpc --destination-range=199.36.153.8/30 --next-hop-gateway=default-internet-gateway.

Private Google Access for On-Premises Hosts

The Hybrid Use Case

A data centre or branch office connected to Google Cloud over Cloud VPN or Cloud Interconnect frequently needs to call Google APIs directly from on-prem servers without those servers routing through a Google Cloud VM proxy. PGA for on-premises makes this work: the on-prem client resolves *.googleapis.com to 199.36.153.8/30 via its on-prem DNS (which forwards to Cloud DNS or has its own override zone), sends the packet across the VPN or Interconnect tunnel into Google Cloud, the VPC routes it to default-internet-gateway based on the custom static route, and Google's edge accepts it as a PGA-eligible flow because the source IP belongs to an on-prem range that the VPC has advertised as reachable.

DNS Forwarding from On-Prem to Cloud DNS

On-prem DNS must resolve googleapis.com and any related domains to the VIP /30. The cleanest pattern is to point on-prem DNS forwarders at a Cloud DNS inbound forwarding policy attached to the hub VPC: create the policy with gcloud dns policies create dns-policy --networks=hub-vpc --enable-inbound-forwarding, note the regional inbound forwarder IPs Cloud DNS allocates, then configure your on-prem resolvers to forward googleapis.com queries to those IPs. Cloud DNS then evaluates the private managed zone you created earlier and returns 199.36.153.8/30 (or .4/30) to the on-prem client.

Routing Across the Hybrid Link

The on-prem network must have a route for 199.36.153.8/30 (or .4/30) pointing at the Cloud VPN tunnel or VLAN attachment toward the Google Cloud VPC. On the GCP side, the static route in the hub VPC carries the traffic to default-internet-gateway as above. If using HA VPN with BGP, Cloud Router advertises the VIP range to the on-prem peer automatically once you configure the custom route advertisement (covered in the next section). If using static routing, you create both the on-prem static route and the GCP static route manually.

Source IP Considerations

The on-prem source IP must be inside a range that the VPC knows how to route back. With HA VPN + BGP, Cloud Router learns on-prem prefixes via BGP and installs return routes automatically. With Cloud Interconnect plus Partner Interconnect, the same BGP session over the VLAN attachment provides the return path. Without a return path, Google's edge accepts the inbound API call but the response packet cannot make it back to the on-prem client and the connection times out, manifesting as a particularly confusing failure mode.

BGP Advertisement on Cloud Router for Hybrid PGA

Custom Route Advertisements

Cloud Router can be told to advertise extra prefixes to its BGP peers beyond the subnets attached to its VPC. To make hybrid PGA work cleanly you advertise 199.36.153.8/30 (or .4/30) so that on-prem routers learn the VIP route dynamically and install it pointing to the VPN or Interconnect tunnel as next hop. Use gcloud compute routers update-bgp-peer PEER --router=ROUTER --region=REGION --advertised-route-priority=100 --custom-learned-route-priority=100 --advertisement-mode=custom --set-advertisement-ranges=199.36.153.8/30.

Default vs Custom Advertisement Mode

Cloud Router defaults to default advertisement mode, which announces all subnets in the VPC but not the VIP custom static route. Switching to custom mode requires you to enumerate everything you want advertised, including the VPC subnets you previously got for free. The trade-off is explicit control versus operational simplicity. For a production hub-and-spoke topology with PGA, custom mode is recommended because you typically want to advertise the VIP range plus only a subset of subnets, hiding internal-only ranges from on-prem.

Verifying BGP Health

Run gcloud compute routers get-status ROUTER --region=REGION and confirm under bgpPeerStatus that the BGP session is Established, the advertised routes include 199.36.153.8/30, and the learned routes include your on-prem ranges. If the session flaps or the advertisement is missing, the on-prem PGA path fails silently except for connection timeouts, which can be very hard to diagnose without checking BGP directly.

Per-Peer Advertisement Granularity

Cloud Router supports per-peer advertisement overrides, so a single Cloud Router with two BGP peers can advertise the PGA VIP to one peer (the production data centre) and withhold it from the other (a DMZ branch office). This is configured with --peer-advertisement-mode=custom on each peer separately. Use this when only a subset of the corporate footprint should be allowed to reach Google APIs privately.

Private Service Connect for Google APIs (The PGA Alternative)

What PSC for Google APIs Does

Private Service Connect for Google APIs is the modern successor to classic PGA. Instead of advertising a fixed public-looking VIP /30 over a private path, PSC lets you allocate your own internal IP inside your VPC and bind it as an endpoint for Google APIs. Clients call storage.googleapis.com (or a custom hostname you configure) and DNS resolves to the internal IP you chose, for example 10.10.0.100. Traffic never leaves the VPC subnet from the client's perspective.

When to Pick PSC Over Classic PGA

PSC is preferred when you want fully RFC1918 addressing end-to-end (no 199.36.153.x quasi-public range appearing in logs), when you operate across many VPCs that each need their own dedicated endpoint IPs, or when you need to apply more granular firewall or VPC-SC rules tied to a specific internal IP. Classic PGA is preferred when you want the simplest possible setup, when you do not want to manage extra endpoint resources, or when hybrid on-prem clients also need to share the same path.

Setting Up a PSC Endpoint for Google APIs

Reserve a regional internal address, then create a forwarding rule pointing at all-apis or vpc-sc bundles: gcloud compute addresses create psc-googleapis --region=REGION --subnet=SUBNET --addresses=10.10.0.100 then gcloud compute forwarding-rules create psc-googleapis --region=REGION --network=VPC --address=10.10.0.100 --target-google-apis-bundle=all-apis. The all-apis bundle is equivalent to private.googleapis.com; vpc-sc is equivalent to restricted.googleapis.com and enforces VPC-SC.

DNS for PSC

You still need a private DNS zone, but it points at your internal IP instead of the VIP /30. A typical zone has an A record googleapis.com. 10.10.0.100 and a CNAME *.googleapis.com. googleapis.com. Replace 10.10.0.100 with whatever address you reserved. The same on-prem DNS forwarding pattern works, and on-prem clients can reach the endpoint via VPN or Interconnect since 10.10.0.100 is just an internal IP in your VPC.

Common Failure Modes and Troubleshooting

Symptom: VM Cannot Reach Google API, No External IP

First check gcloud compute networks subnets describe SUBNET --region=REGION --format="value(privateIpGoogleAccess)". If false, the flag is off and the API call is being dropped by Google's edge despite DNS pointing to public IPs. Enable the flag and retest. If true but the call still fails, check whether the VM has an external IP (which overrides PGA) and whether the 0.0.0.0/0 default route still exists in the VPC.

Symptom: API Reachable but VPC-SC Denies Access

This usually means the client is hitting the public IPs of storage.googleapis.com instead of the Restricted VIP. The VPC-SC perimeter requires restricted.googleapis.com (199.36.153.4/30) for enforcement; a regular PGA path using 199.36.153.8/30 bypasses the perimeter. Fix the Cloud DNS private zone to point at the restricted /30 and confirm with dig +short storage.googleapis.com @169.254.169.254 from the VM.

Symptom: On-Prem Client Times Out

Check three things in order: (1) dig storage.googleapis.com on the on-prem host returns 199.36.153.x, (2) traceroute from on-prem stops at the Cloud VPN tunnel and not at a public internet hop, and (3) Cloud Router BGP status shows the VIP /30 advertised and on-prem prefixes learned. A failure in any one of these breaks the path.

Symptom: DNS Works But Firewall Blocks

A deny-all-egress firewall must explicitly allow egress to 199.36.153.4/30 or 199.36.153.8/30 on TCP 443. Confirm with gcloud compute firewall-rules list --filter="network=VPC" --format="table(name,direction,destinationRanges,sourceRanges,allowed)" and add a higher-priority allow rule if missing.

白話文解釋（Plain English Explanation）

Analogy 1: The Embassy Tunnel

Imagine your VM is a citizen of a private gated community (the VPC) with no public-facing door (no external IP). The citizen needs documents from a foreign embassy (Google APIs like Cloud Storage). Without Private Google Access, the only way to reach the embassy is to leave the community through the front gate (Cloud NAT) into the public street, which exposes the citizen's identity. With PGA, the community manager has built a private underground tunnel directly to the embassy's back door at address 199.36.153.8/30. The citizen walks through the tunnel using only an internal pass (internal IP), never appearing on the public street, and the embassy accepts the visit because the tunnel emerges from a recognised diplomatic compound (a PGA-enabled subnet).

Analogy 2: The Members-Only VIP Versus the Public Counter

Cloud Storage has two front doors. The public counter (storage.googleapis.com public IPs) is where anyone on the internet queues with a passport (API key or OAuth token). The VIP entrance at 199.36.153.8/30 (private.googleapis.com) requires a special card that says "I came from inside Google Cloud or via an approved tunnel." A second, even more exclusive VIP entrance at 199.36.153.4/30 (restricted.googleapis.com) is reserved for members of the VPC Service Controls club: it only admits those whose membership lists are pre-approved and bans them from carrying data out to non-member clubs. Picking the wrong door means either being seen by the public (PGA off), or being denied entry (VPC-SC perimeter expects restricted but you used regular).

Analogy 3: The Long-Distance Phone Routing Card

For on-prem hybrid PGA, think of an old company switchboard. Your branch office (on-premises) wants to call Google's API service. The corporate phone book (on-prem DNS) is updated so that whenever someone dials "storage.googleapis.com," it actually dials the internal extension 199.36.153.10. The switchboard (Cloud VPN tunnel) routes that call into Google Cloud's headquarters (the hub VPC). The headquarters operator has a custom routing card (static route to default-internet-gateway) that knows: "calls to 199.36.153.8/30 go through the diplomatic line, not the public street." The return call comes back via the same switchboard because Cloud Router advertised the route over BGP so the branch knows where to send replies. Skip the BGP step and replies vanish into the void.

Exam Pitfalls Specific to PCNE

Confusing PGA with Cloud NAT

PCNE questions love to test whether candidates know PGA and Cloud NAT solve different problems. PGA lets internal-only VMs reach Google APIs. Cloud NAT lets internal-only VMs reach the general internet. They are independent: a VM can have PGA enabled (subnet flag) and use Cloud NAT for non-Google traffic simultaneously. If the question is "VM has no external IP, needs to download a Linux package from apt.example.com," the answer is Cloud NAT, not PGA. If the question is "VM has no external IP, needs to write to a GCS bucket," the answer is PGA.

Confusing the Two VIP /30s

199.36.153.4/30 is restricted (4 IPs: .4, .5, .6, .7); 199.36.153.8/30 is private (4 IPs: .8, .9, .10, .11). The adjacency is deliberate but the semantics differ: restricted enforces VPC-SC, private does not. Memorize the lower range as restricted and the upper range as private. Some PCNE questions show only one of the two and expect you to know which feature it enables.

Forgetting Cloud DNS Inbound Forwarding for Hybrid

Many candidates correctly identify that on-prem PGA needs DNS overrides but forget that the override is delivered via a Cloud DNS inbound forwarding policy allocated forwarder IP, not a direct hand-edit of on-prem zones. The flow is: on-prem resolver -> Cloud DNS inbound forwarder IP (allocated by gcloud dns policies create --enable-inbound-forwarding) -> private managed zone for googleapis.com. Skipping the policy step is a common wrong answer.

PSC for Google APIs Versus Private Endpoints

PSC has two flavours: PSC for Google APIs (this study note) and PSC for published services (used to expose internal services). The PCNE blueprint asks about the first; the second is a peer-to-peer pattern between consumer VPC and producer VPC. Do not mix them. The --target-google-apis-bundle flag distinguishes the API flavour.

FAQs

Q: Does enabling PGA on a subnet cost anything? A: No. The subnet flag itself is free. You pay only the normal data egress charges and any per-service costs for the Google API you call. PGA does not consume Cloud NAT ports, does not require reserved IPs, and adds zero per-hour gateway fees, which is one of the reasons it is preferred over routing API traffic through Cloud NAT.

Q: Can I use PGA with Shared VPC? A: Yes. PGA is configured on the subnet in the Shared VPC host project. Service projects that consume that subnet via Shared VPC inherit the PGA setting automatically. The Cloud DNS private zone should be created in the host project and attached to the host-project VPC; service-project VMs see the zone transparently. This is the standard pattern for centralised connectivity teams.

Q: Does PGA work with GKE private clusters? A: Yes, and it is the recommended pattern. Private GKE nodes have only internal IPs by default; enabling PGA on the node subnet lets the nodes pull images from gcr.io and pkg.dev, push logs to logging.googleapis.com, and call any other Google API without needing Cloud NAT. Make sure the Cloud DNS private zone covers gcr.io, *.gcr.io, pkg.dev, and *.pkg.dev in addition to googleapis.com.

Q: If my VM has a public IP, does PGA still apply? A: No. The presence of any external IPv4 address on the network interface bypasses PGA: the host kernel routes via the external IP because that interface has direct internet egress, and Google's edge sees the call as a regular public-internet call. To force PGA you must remove the external IP, then ensure DNS resolves *.googleapis.com to the VIP /30, then confirm the egress firewall allows TCP 443 to that /30.

Q: Can on-prem hosts use PGA without a Cloud DNS inbound forwarder? A: Technically yes, if you hard-code the VIP /30 resolution into your on-prem DNS server's local zone files. But this is brittle: you must maintain the override on every on-prem resolver and you lose the centralised view Cloud DNS provides. The recommended path is always a Cloud DNS private zone plus an inbound forwarding policy, with on-prem resolvers forwarding googleapis.com (and friends) to the allocated Cloud DNS forwarder IPs.

Q: How is PGA different from Private Service Connect for Google APIs? A: Classic PGA uses the public-looking VIP /30s 199.36.153.4/30 and 199.36.153.8/30 and is enabled by a subnet flag plus a DNS override. PSC for Google APIs uses an internal IP you choose (for example 10.10.0.100) bound as a regional forwarding rule with --target-google-apis-bundle=all-apis or vpc-sc. PSC is the newer pattern; it gives you RFC1918 addressing end-to-end and one endpoint per VPC, which is cleaner for multi-VPC topologies. Both are valid PCNE answers depending on what the question asks for.

Q: Does PGA traverse the public internet at any point? A: No. PGA traffic stays inside Google's private backbone from the moment it leaves the host's Andromeda virtual switch until it reaches the Google API frontend. The use of public IP addresses in 199.36.153.0/24 is administrative: Google publishes those addresses globally so that PGA-aware clients (including on-prem clients over VPN or Interconnect) have an unambiguous DNS target, but the actual packets never appear on a public-internet path.