Private Service Connect and Private Access

Private Service Connect is a Google Cloud networking capability that allows consumers (your VPC) to privately access managed services (producers) using internal IP addresses. It was introduced in 2021 as an evolution of Private Google Access and VPC Service Controls. PSC is built on the concept of a *service attachment* (on the producer side) and an *endpoint* (on the consumer side). The consumer creates a PSC endpoint in their VPC, which gets an internal IP address from a subnet. Traffic to that IP is forwarded over Google's internal network directly to the producer's service attachment, bypassing the public internet entirely.

Before PSC, accessing Google APIs or managed services from a VPC required either: - Public internet: Unsecure, high latency, and incurs egress costs. - Private Google Access: Allows VMs without external IPs to reach Google APIs, but traffic still traverses Google's external network (though not the public internet). It does not provide a private IP address for the service; the destination IP is still a public IP (like 172.217.x.x). - VPC Peering: Only works for services that support it (e.g., Cloud SQL), and requires the service to be in a different project/VPC.

PSC solves these by giving the service a private RFC 1918 IP address within your VPC. This means:

PSC uses a producer/consumer model: - Producer: The service provider (e.g., Google Cloud SQL, or a third-party SaaS) creates a *service attachment* in their VPC. This is a resource that exposes the service to consumers. The service attachment is associated with a *service project* and a *service name* (a URN like projects/PROJECT_ID/regions/REGION/serviceAttachments/NAME). - Consumer: The customer creates a *Private Service Connect endpoint* (also called a *forwarding rule* of type private-service-connect) in their VPC. The endpoint is assigned an internal IP from a subnet. The consumer then publishes a DNS zone (e.g., googleapis.com) that resolves the service's DNS name to this internal IP.

When a VM sends a packet to the endpoint's IP, the following happens: 1. The packet reaches the VPC's subnet where the endpoint resides. 2. The forwarding rule (which is a regional resource) intercepts the packet because it matches the endpoint IP. 3. The packet is encapsulated and forwarded over Google's internal backbone to the producer's service attachment. 4. The producer's service attachment decapsulates the packet and delivers it to the actual service (e.g., Cloud SQL instance). 5. Return traffic follows the reverse path.

This process is transparent to the VM – it sees a normal internal IP connection.

To create a PSC endpoint using gcloud:

gcloud compute forwarding-rules create PSC_ENDPOINT_NAME \
    --region=us-central1 \
    --network=my-vpc \
    --subnet=my-subnet \
    --ip-version=IPV4 \
    --target-service-attachment=projects/PROJECT_ID/regions/us-central1/serviceAttachments/SA_NAME

To verify the endpoint:

gcloud compute forwarding-rules describe PSC_ENDPOINT_NAME --region=us-central1

Look for pscServiceAttachmentId and pscConnectionStatus which should be ACCEPTED.

Private Google Access is a VPC subnet-level setting that allows VMs without external IPs to reach Google APIs and services (like Cloud Storage, BigQuery) using Google's private network. When enabled, traffic from VMs to Google API public IPs (e.g., 172.217.x.x) is routed through Google's internal infrastructure rather than the public internet. However, the destination IP is still a public IP – it's not a private IP within your VPC. PGA is simpler than PSC but does not give you a private IP for the service.

Private Services Access is used for Google-managed services that support VPC peering (e.g., Cloud SQL, Memorystore). You allocate an IP range in your VPC and peer it with the service's VPC. This gives the service a private IP from your range. PSA is different from PSC in that it requires VPC peering and is limited to services that explicitly support it. PSC is more flexible as it works with any producer that creates a service attachment.

PSC uses Google's global network with low latency. Each endpoint can handle up to 10 Gbps of throughput (default). For higher throughput, you can create multiple endpoints and use load balancing. The producer service attachment also has its own capacity limits (e.g., a single Cloud SQL instance can handle up to 60,000 connections).

A large financial services company requires all traffic to Google APIs (e.g., BigQuery, Cloud Storage) to remain within Google's network and not traverse the public internet. They have thousands of VMs in a shared VPC across multiple regions. Previously, they used Private Google Access, but that still resolved APIs to public IPs (e.g., 172.217.x.x). With PSC, they create endpoints in each region for the googleapis.com service attachment (published by Google). They configure private DNS zones to resolve *.googleapis.com to the endpoint IPs. This ensures all API calls use private IPs, reducing attack surface and eliminating egress costs. The network team monitors endpoint utilization via Cloud Monitoring. A common issue is forgetting to update DNS when an endpoint IP changes (if ephemeral), so they use static internal IPs for endpoints.

A retail company uses a third-party inventory management SaaS that runs on Google Cloud. The SaaS provider creates a service attachment in their project and shares the service name URN with the retailer. The retailer creates a PSC endpoint in their VPC and configures DNS. This allows the retailer's applications to connect to the SaaS using a private IP, ensuring low latency and security. The retailer can control access via firewall rules on the endpoint IP. Performance considerations: if the SaaS is in a different region, latency increases; they should create endpoints in the same region as the SaaS. A misconfiguration occurs if the retailer's VPC subnet for the endpoint is in a different region than the service attachment – the endpoint creation will fail.

A healthcare organization has an on-premises data center connected to Google Cloud via Cloud Interconnect (VLAN attachment). They want on-premises servers to access a Google-managed Cloud SQL database privately. They create a PSC endpoint in their VPC and configure Cloud Router to advertise the endpoint's IP range to on-premises via BGP. On-premises servers can then connect to the Cloud SQL instance using the endpoint IP (which resolves via DNS). This eliminates the need for a public IP on Cloud SQL. A common mistake is not advertising the endpoint IP range, causing on-premises traffic to be dropped. They also need to ensure firewall rules on-premises allow traffic to the endpoint IP.