Private Service Access vs. Google Private Access
Private Google Access vs. Private Service Connect: A GCP Q&A
Google Cloud provides several ways to access services privately, and the similar terminology can make the choices confusing.
Two technologies that are particularly easy to mix up are:
- Private Google Access (PGA)
- Private Service Connect (PSC)
They can both allow workloads to reach services without requiring the workload itself to have a public IP address, but they solve different architectural problems.
Here is a practical Q&A explaining the difference.
Q: What is Private Google Access?
Private Google Access allows resources without external IP addresses to reach supported Google APIs and services.
It is enabled at the subnet level.
Consider a VPC containing two subnets:
GCP VPC
|
+---------+---------+
| |
v v
DEV Subnet PROD Subnet
|
Private Google Access
ENABLED
|
v
PROD VM
No External IP
|
v
Google APIs
|
+----------+----------+
| | |
v v v
Cloud Storage BigQuery Other APIs
The important point is that Private Google Access is enabled for the PROD subnet, not necessarily for the entire VPC.
Q: What problem does Private Google Access solve?
Imagine your company's security policy states:
Production VMs must not have external IP addresses.
That is a good security policy, but those VMs might still need to access services such as Cloud Storage or BigQuery.
For example:
PROD VM
10.10.10.25
No External IP
|
| Need access
v
Cloud Storage
Enabling Private Google Access on the PROD subnet allows eligible VMs in that subnet to reach supported Google APIs and services without assigning those VMs external IP addresses.
A simple way to remember it is:
Private Google Access = private workloads accessing Google APIs and services.
Q: Is Private Google Access configured at the VPC level?
No.
Private Google Access for VM instances is a subnet-level setting.
For example:
VPC: production-vpc
DEV Subnet
10.10.1.0/24
PGA = Disabled
PROD Subnet
10.10.2.0/24
PGA = Enabled
That means you can enable Private Google Access for PROD while leaving it disabled for DEV.
This gives architects more granular control over which subnets can use this access mechanism.
Q: What is Private Service Connect?
Private Service Connect is a service-oriented private connectivity technology.
Instead of broadly connecting one network to another network, PSC allows a consumer to privately connect to a specific service.
The consumer creates an endpoint using an internal IP address within its own VPC.
Conceptually:
Consumer VPC
Application
10.20.1.10
|
v
PSC Endpoint
10.20.1.50
|
|
===== Private Service Connect =====
|
v
Google API
or
Published Service
The application communicates with an IP address that exists within its own VPC while PSC provides connectivity to the target service.
Q: What is the easiest way to differentiate PGA and PSC?
Ask:
What am I trying to reach?
If your requirement is:
"This VM doesn't have an external IP but needs to access Google APIs."
Think:
Private Google Access.
If your requirement is:
"I want an internal endpoint in my VPC that represents a particular service."
Think:
Private Service Connect.
In simplified form:
PRIVATE GOOGLE ACCESS
Private VM
|
v
Google APIs
PRIVATE SERVICE CONNECT
Consumer
|
v
Private Endpoint
|
v
Specific Service
Q: Does the client need an external IP address?
This is another useful distinction.
Private Google Access
For the standard VM use case, PGA is specifically useful for Google Cloud resources that do not have external IP addresses.
VM
Private IP: YES
External IP: NO
|
v
Private Google Access
|
v
Google APIs
Private Service Connect
PSC consumers can include Google Cloud resources with or without external IP addresses, depending on the PSC configuration and service being consumed.
The external IP isn't what establishes the PSC connection.
The workload communicates with the PSC endpoint.
Q: Can Private Service Connect be used for Google APIs?
Yes.
PSC can create endpoints for supported Google APIs and services.
For example:
Application
|
v
Private DNS
storage.example.internal
|
v
PSC Endpoint
10.10.20.50
|
v
Google APIs
This provides a service endpoint inside the consumer's VPC.
Q: Can PSC be used to access APIs that my company hosts?
Yes, and this is one of PSC's most interesting enterprise use cases.
Suppose Company B operates an application that Company A needs to consume privately.
Company B can publish the service using PSC.
COMPANY A
Application
|
v
PSC Endpoint
10.20.10.50
|
|
==== PRIVATE SERVICE CONNECT ====
|
|
COMPANY B
Service Attachment
|
v
Load Balancer
|
v
Application / API
Company A doesn't need general network access to Company B's VPC.
It receives connectivity to the specific published service.
This makes PSC particularly useful for:
- shared enterprise services
- partner integrations
- cross-organization integrations
- acquisitions
- SaaS services
- centrally hosted APIs
Q: How does Private Service Connect actually work?
At a high level, PSC creates an endpoint represented by an internal IP address within the consumer's VPC.
For example:
Consumer VPC
10.20.0.0/16
Application
10.20.1.10
|
v
PSC Endpoint
10.20.1.50
|
v
Private Service Connect
|
v
Published Service
The application sends traffic to:
10.20.1.50
PSC then connects that traffic to the appropriate service.
From the application's perspective, it is simply communicating with an internal endpoint.
Q: Do applications have to use the PSC endpoint's IP address?
Not necessarily.
You can use Cloud DNS so applications communicate using a meaningful hostname.
For example:
orders.partner.internal
|
v
Private DNS
|
v
10.20.1.50
|
v
PSC Endpoint
|
v
Partner Service
Applications can therefore call:
https://orders.partner.internal
rather than hard-coding an IP address.
This also separates application configuration from the underlying networking implementation.
Q: Why not just use VPC Peering?
Because VPC Peering and Private Service Connect solve fundamentally different problems.
VPC Peering connects networks:
VPC A
|
| VPC Peering
|
v
VPC B
PSC connects a consumer to a service:
VPC A
Application
|
v
PSC Endpoint
|
v
Published Service
|
v
VPC B
This distinction is important.
With PSC, you don't necessarily need to provide the consumer broad network-level connectivity to the producer VPC.
Instead, you expose only the required service.
Q: Does PSC help when the two VPCs have overlapping IP ranges?
This can be one of PSC's major architectural advantages.
Consider two companies:
Company A VPC
10.0.0.0/16
Company B VPC
10.0.0.0/16
Traditional routed network integration becomes problematic because the IP address spaces overlap.
PSC uses a service-oriented model where the consumer accesses an endpoint within its own VPC.
This can avoid many of the routing problems associated with directly connecting overlapping networks.
This becomes particularly useful during mergers and acquisitions where both organizations may have independently built large RFC1918 address spaces.
Q: What about Private Services Access?
This is where Google Cloud terminology gets particularly confusing.
There are actually three concepts:
Private Google Access
≠
Private Service Connect
≠
Private Services Access
Private Services Access is another private connectivity mechanism used by certain Google-managed services.
It typically involves allocating an IP range and establishing private connectivity with a Google service producer network.
Conceptually:
Your VPC
10.10.0.0/16
|
v
Allocated IP Range
|
v
Private Services Access
|
v
Google Service
Producer Network
So don't confuse Private Service Connect with Private Services Access simply because their names sound similar.
Q: How do I choose between the three?
A useful decision tree is:
What are you trying to access?
|
|
+-------+-------+
| |
v v
Google APIs Specific Service
| |
v v
Private VM Want endpoint
needs access inside VPC?
| |
v v
Private Google Private Service
Access Connect
Managed service requires
private producer-network
connectivity?
|
v
Private Services Access
Or remember them this way:
| Technology | Think |
|---|---|
| Private Google Access | My private workload needs Google APIs |
| Private Service Connect | I want a private endpoint to a specific service |
| Private Services Access | A managed service needs private service-producer connectivity |
Q: What does the real-world PROD example look like?
Suppose you have:
Corporate GCP VPC
+---------------------------+
| |
| DEV Subnet |
| 10.10.1.0/24 |
| |
+---------------------------+
+---------------------------+
| |
| PROD Subnet |
| 10.10.2.0/24 |
| |
| No VM External IPs |
| |
+---------------------------+
Security policy states:
No production VM may have an external IP address.
However, your production application needs Cloud Storage.
You could enable Private Google Access on the PROD subnet.
PROD VM
10.10.2.25
No External IP
|
v
Private Google Access
|
v
Cloud Storage
That is a classic Private Google Access use case.
Q: What would a PSC use case look like instead?
Suppose the same application needs an API operated by another business unit or another company.
Instead of connecting their entire VPC to yours:
PROD Application
|
v
PSC Endpoint
10.10.2.50
|
v
=========================
PRIVATE SERVICE CONNECT
=========================
|
v
Partner API
Now the application has private connectivity to the required service without turning the two VPCs into one broadly interconnected network.
Q: What is the architectural takeaway?
The biggest difference isn't simply subnet versus VPC configuration.
It is the problem each technology is designed to solve.
Private Google Access answers:
How can a workload without an external IP access Google APIs and services?
Private Service Connect answers:
How can a consumer privately access a specific service through an endpoint?
And Private Services Access answers a third question:
How can my VPC establish private connectivity with supported Google-managed service producer networks?
For architects, PSC is especially interesting because it represents a shift away from traditional network-centric thinking:
OLD MODEL
Network A <=========> Network B
toward service-centric connectivity:
SERVICE-ORIENTED MODEL
Workload
|
v
Private Endpoint
|
v
Authorized Service
That model is particularly powerful for multi-VPC, cross-organization, partner, shared-services, and merger/acquisition architectures.
This is a good explanation. If we can add a diagram of both side by side, will make the difference more explicit.
sorry but copy paste
Did you even read the differentiator in the intro? Most people are confused between the two – and I don’t know of any other blog post or GCP article that clearly explains how they differ.