Private Access & Service Connectivity

One of the most counterintuitive things about Google Cloud is that your VMs, by default, cannot reach Google APIs like Cloud Storage or BigQuery over a private path. If your VM calls storage.googleapis.com, the request leaves Google’s network, traverses the public internet, and comes back in through Google’s front door. The data stays within Google’s infrastructure physically, but the DNS resolution and routing path are public. For many enterprises—especially those in healthcare, finance, or government—this is unacceptable. They need private, non-internet connectivity to Google services.

Google Cloud solves this with three distinct mechanisms, and understanding when to use each one is one of the most heavily tested topics on the PCNE exam: Private Google Access (PGA), Private Service Access (PSA), and Private Service Connect (PSC).

Private Google Access (PGA): The Simple Switch

PGA is the easiest to understand. It is a single toggle on a subnet that allows VMs without external IP addresses to reach Google APIs (like storage.googleapis.com or bigquery.googleapis.com) through Google’s internal network.

How It Works
  1. You enable PGA on a subnet.
  2. VMs in that subnet resolve Google API endpoints to their standard public IPs (e.g., 142.250.x.x).
  3. But because PGA is enabled, the packets are routed internally within Google’s network instead of going out to the internet.
The VIP Addresses

For tighter control, Google provides special virtual IPs:

  • private.googleapis.com (199.36.153.8/30): Access to all Google APIs over a private path.
  • restricted.googleapis.com (199.36.153.4/30): Access only to APIs that are supported by VPC Service Controls—critical for compliance.

The exam trap: PGA only helps VMs without external IPs. If a VM has an external IP, it already reaches Google APIs via the internet, and PGA is irrelevant.

Private Service Access (PSA): Peering with Google

PSA is fundamentally different from PGA. Instead of routing to Google’s public API endpoints, PSA creates a VPC Peering connection between your VPC and Google’s internal service VPC.

Use Case

Managed services like Cloud SQL, Memorystore (Redis), and Cloud Filestore create their instances inside Google-managed VPCs. With PSA, you allocate an IP range from your VPC (e.g., 10.100.0.0/16), and Google creates the peering connection automatically. Your Cloud SQL instance gets an IP from that range, and your VMs can reach it directly over the peered connection.

The Limitation

Because PSA uses VPC Peering, it inherits peering’s limitations:

  1. Non-transitive: If VPC A peers with Google’s service VPC, and VPC B peers with VPC A, VPC B cannot reach the Cloud SQL instance.
  2. IP range management: You must carefully allocate ranges to avoid overlap.
Private Service Connect (PSC): The Modern Standard

PSC is the newest and most powerful option. It gives you a private endpoint (a forwarding rule with an internal IP in your VPC) that acts as a gateway to a Google service or a service published by another team.

How It Works
  1. Consumer Side: You create a PSC Endpoint in your VPC—a forwarding rule with an internal IP like 10.0.0.100.
  2. Producer Side: Google (or another team) publishes a Service Attachment.
  3. The consumer’s IP 10.0.0.100 maps to the producer’s service. Your application connects to 10.0.0.100, and the traffic is tunneled to the producer’s backend.
Why PSC is Better Than PSA
  1. No Peering Required: PSC does not use VPC Peering, so there are no transitivity issues.
  2. IP Control: You choose the IP address. There is no shared range allocation.
  3. Cross-Organization: You can connect to services in completely different Google Cloud organizations.
  4. DNS Integration: You can create DNS records that point your application’s service name to the PSC endpoint IP.

When the exam says “access a Google managed service from a different organization without VPC Peering,” the answer is PSC.

Putting it Together: A Pro-Engineer View

Imagine you are building a healthcare data platform. Patient data in Cloud SQL must never traverse the public internet. Researchers in a separate GCP organization need access to a FHIR API you publish. You enable PGA on all subnets so VMs reach Cloud Storage privately. You configure PSA so your Cloud SQL instances get private IPs within your VPC. And you publish your FHIR API as a PSC Service Attachment, allowing the research organization to create a PSC Endpoint in their own VPC—connecting to your service without any peering, VPN, or public IP. Three different mechanisms, each solving a different layer of the private connectivity problem.

Related Posts