In the expansive world of Google Cloud Platform (GCP), networking is the nervous system that keeps your applications alive. Yet, for many architects and engineers, navigating the acronym-heavy landscape of connectivity options can feel like deciphering a secret code. Three terms, in particular, cause the most confusion: Private Service Access (PSA), Private Service Connect (PSC), and Private Google Access (PGA).
If you have ever found yourself staring at a VPC architecture diagram wondering which “Private” solution to use to connect your GKE cluster to Cloud SQL, or how to reach a storage bucket without a public IP, you are not alone. While they sound similar, these three technologies solve fundamentally different problems regarding how traffic moves between your Virtual Private Cloud (VPC), Google’s managed services, and the public internet.
This comprehensive guide will strip away the complexity. We will dissect each technology using real-world analogies and deep technical dives, ensuring you never confuse them again.
What to Remember
- PGA (Private Google Access): It is for accessing public Google APIs (like GCS, Pub/Sub, BigQuery) from VMs that do not have external IP addresses. It keeps traffic on Google’s backbone.
- PSA (Private Service Access): It relies on VPC Peering. It connects your VPC to a Google-managed VPC (for services like Cloud SQL or Redis). It requires reserving a global IP range and can have transitive routing limitations.
- PSC (Private Service Connect): It is service-centric, not network-centric. It uses endpoints (internal IPs) in your VPC to access services. It eliminates IP overlap issues and is the modern standard for accessing both Google services and third-party SaaS.
- The “VPC Peering” Limit: If you use PSA, you are peering. If you use PSC, you are tunneling to an endpoint. This distinction is crucial for network scalability and transitivity.
1. Private Service Access (PSA): The Peering Bridge
Private Service Access is the “classic” way to connect your infrastructure to managed Google services that run inside Google’s own tenant projects, such as Cloud SQL, Memorystore (Redis), and AI Platform Training.
The Technical Mechanics: VPC Network Peering
At its core, PSA is an abstraction over VPC Network Peering. When you provision a managed service like Cloud SQL with a private IP, that database doesn’t actually live inside your VPC. It lives in a “Service Producer VPC” managed by Google.
To allow your VMs to talk to that database, PSA builds a bridge (peering) between your network and Google’s network.
How it works:
- IP Allocation: You must reserve a specific range of IP addresses (CIDR block) within your VPC (e.g.,
10.50.0.0/16) specifically for this connection. - Service Networking API: You use this API to create a private connection. Google takes your reserved range and assigns it to the managed services in the Producer VPC.
- Route Exchange: Through the magic of peering, routes are exchanged. Your VPC learns how to reach the Service Producer VPC, and vice-versa.
The Analogy: The Shared Amenities Floor
Imagine your VPC is a high-security apartment building. You want your tenants (VMs) to use a Gym (Cloud SQL). However, the Gym is managed by the building owner (Google) and isn’t technically inside your apartment unit.
PSA is like the building manager creating a shared hallway that connects your apartment directly to the Gym. To make this work, you have to reserve a specific “floor” (IP Range) in your building plans so the Gym fits. Once built, anyone in your apartment can walk down the hallway to the Gym.
The Limitations (Why we need more)
While PSA is powerful, it comes with the inherent baggage of VPC Peering:
- Non-Transitive: If VPC A is peered with VPC B (the service), and VPC A is also peered with VPC C, VPC C cannot reach VPC B. You can’t chain connections easily.
- IP Overlaps: Since you are peering networks, you cannot have overlapping IP ranges. If your organization acquires another company with the same IP scheme, PSA can become a nightmare to integrate.
- Broad Access: Peering opens a network path. While firewall rules help, from a networking perspective, you are connecting two broad networks rather than exposing a single specific service.
2. Private Service Connect (PSC): The Surgical Link
Private Service Connect is the modern evolution of private connectivity. It moves away from the “network-centric” model of peering and embraces a “service-centric” model. It allows you to access Google APIs, managed services, and even third-party SaaS applications privately, without the headaches of peering.
The Technical Mechanics: Endpoints and Attachments
PSC does not peer networks. Instead, it places a specific Endpoint (a forwarding rule with an internal IP address) directly inside your subnet.
How it works:
- No Reserved Ranges: You don’t need to reserve a massive
/16block. You just pick a single IP address from your existing subnet. - Service Attachment: The Service Producer (Google or a SaaS vendor) creates a “Service Attachment” that exposes their service behind a load balancer.
- Unilateral Connection: You create a PSC Endpoint in your VPC that points to that Service Attachment. Traffic sent to that local IP is encapsulated and tunneled over Google’s backbone directly to the service.
The Analogy: The Private Delivery Chute
Let’s go back to the apartment building. Instead of building a hallway (peering) to the Gym, PSC is like installing a teleporter or a dedicated delivery chute inside your living room.
You press a button (send traffic to the PSC IP), and your request is instantly transported to the service. You don’t care where the service is located, or if the service provider uses the same floor plan (IP range) as you. It creates a private, secure, one-way door specifically for that service.
Why PSC is often superior
- Solves IP Overlap: Since there is no peering, the Producer VPC can use the exact same IP ranges as your Consumer VPC without conflict.
- Granular Security: You aren’t connecting networks; you are connecting to a specific service.
- Transitivity: PSC enables scenarios that peering prevents. For example, through PSC Interfaces, traffic can be routed in ways that traditional peering blocks, enabling hub-and-spoke topologies.
- Multi-Team/SaaS: It is the standard way to consume software from partners (like MongoDB Atlas or Snowflake) securely over GCP.
3. Private Google Access (PGA): The Hidden Tunnel to Public APIs
Private Google Access is the most distinct of the three because it deals with Public Google APIs.
Many Google services, like Cloud Storage (GCS), BigQuery, and Pub/Sub, are technically “public” services—they are accessed via public endpoints (e.g., storage.googleapis.com). Typically, to reach them, a VM needs an external (public) IP address and internet access.
But what if you have a secure, private VM with no external IP? How does it dump logs to Cloud Storage? This is where PGA comes in.
The Technical Mechanics: The Subnet Flag
PGA is a setting you enable on a Subnet level.
How it works:
- No External IP Needed: Your VM has only a private IP (e.g.,
10.0.0.5). - Internal Routing: When the VM tries to reach
storage.googleapis.com, usually, that traffic would be dropped because the VM has no route to the internet. - The Magic: With PGA enabled, Google’s software-defined network recognizes the destination is a Google API. It intercepts that traffic and routes it internally across Google’s backbone to the service, bypassing the public internet entirely.
The Analogy: The Secure Mailbox
PGA is like having a secure mailbox inside your apartment building lobby. Even if you are grounded and not allowed to leave the building (no public IP/internet access), you can still drop a letter in this mailbox. The building manager (Google) guarantees that this letter will get to the Post Office (Google APIs) without ever traveling on the public streets (Public Internet).
Crucial Distinction: PGA allows you to reach public IP addresses of Google services using private VM instances. It does not give the Google service a private IP (that’s what PSC is for).
Comparison Summary: Which One Do I Choose?
Here is the decision matrix to simplify your architecture planning:
| Feature | Private Service Access (PSA) | Private Service Connect (PSC) | Private Google Access (PGA) |
|---|---|---|---|
| Primary Use Case | Native managed services (Cloud SQL, Memorystore). | Accessing services (Google, SaaS, or internal) via a local private IP. | Accessing Public Google APIs (GCS, BigQuery) from private VMs. |
| Mechanism | VPC Network Peering. | Forwarding Rules & Service Attachments. | Subnet-level routing feature. |
| IP Requirements | Requires reserving a dedicated IP Range (e.g., /16 or /24). | Uses a single IP from your existing subnet. | No specific IP reqs; uses Google’s public ranges internally. |
| Transitivity | No (Peering is non-transitive). | Yes (via PSC Interfaces/Endpoints). | N/A (One-way access to APIs). |
| IP Overlap | Critical Issue: Ranges cannot overlap. | Solved: Overlapping IPs are allowed. | N/A. |
| Implementation | ”Heavy” (Connecting networks). | ”Light” (Connecting endpoints). | ”Toggle” (Enable on subnet). |
Real-World Scenario: Putting it all together
Imagine a complex enterprise application:
- The Database: You have a Cloud SQL instance. You use PSA to connect your VPC to it because it’s the standard, native integration for Cloud SQL (though Cloud SQL now supports PSC, PSA remains common for legacy reasons).
- The SaaS Vendor: Your app needs to send data to a third-party fraud detection SaaS running on GCP. You use PSC to create an endpoint in your VPC so you can securely send data to them without peering networks.
- The Archive: Your private app servers need to archive logs to a Google Cloud Storage bucket. Since these servers have no public IPs for security, you enable PGA on their subnet so they can upload files securely.
Conclusion
Cloud networking is about choosing the right tool for the specific communication path.
- Use PSA when you need broad, peered access to managed services like Cloud SQL, provided you have the IP space.
- Use PSC for a more modern, secure, and flexible connection to services (including Google’s) that avoids IP conflicts and peering headaches.
- Use PGA simply to let your private VMs talk to the vast world of Google’s public APIs without exposing them to the internet.
By mastering these three concepts, you move from “making it work” to designing architectures that are robust, secure, and scalable.
To further enhance your cloud security and implement Zero Trust, contact me on LinkedIn Profile or [email protected].
Frequently Asked Questions (FAQ)
Can I use Private Service Connect (PSC) to access Cloud SQL instead of Private Service Access (PSA)?
Yes, Cloud SQL now supports PSC. This is often preferred for new deployments because it avoids the need to reserve large IP ranges and prevents IP overlap issues, which are common with the traditional PSA peering method.
Does Private Google Access (PGA) give my VM a public IP address?
No. PGA allows VMs with only private IP addresses to reach the public IP addresses of Google APIs and services. The traffic remains on Google's private network backbone and never traverses the public internet.
What happens if my PSA IP range overlaps with a new VPC I need to peer with?
This will cause a routing conflict, and the peering will fail or routing will break. This is the main limitation of PSA. To fix it, you would typically have to migrate your infrastructure to a non-overlapping range or switch to using Private Service Connect (PSC), which handles overlaps gracefully.
Is Private Service Connect (PSC) transitive?
Standard VPC peering is not transitive. However, PSC can enable transitive-like behaviors. For example, using PSC Interfaces allows a Producer VPC to initiate connections to a Consumer VPC, and PSC Endpoints can be accessed from peered networks if configured correctly with custom routes.
Do I need to enable PGA if I have Cloud NAT?
Technically, if you have Cloud NAT, your private VMs can reach Google APIs via the NAT gateway. However, enabling PGA is still recommended because it routes traffic directly to Google services without passing through the NAT gateway, reducing latency, complexity, and potentially cost.
Resources
- Google Cloud Documentation - Private Service Access: https://docs.cloud.google.com/vpc/docs/private-services-access
- Google Cloud Documentation - Private Service Connect: https://docs.cloud.google.com/vpc/docs/private-service-connect
- Google Cloud Documentation - Private Google Access: https://docs.cloud.google.com/vpc/docs/private-google-access
- Medium Article Reference: Private Service Access (PSA) vs Private Service Connect (PSC) vs Private Google Access (PGA) — Made simple by Rohan Singh.
