How to Configure Google Cloud Private Service Connect (PSC) for Secure API Access

In traditional cloud architectures, if a virtual machine residing in a private Virtual Private Cloud (VPC) needs to access a managed service (like Google Cloud Storage or BigQuery), the traffic must traverse the public internet. Even if the traffic doesn’t literally leave Google’s physical fiber backbone, the API endpoints (e.g., storage.googleapis.com) resolve to public IP addresses, requiring the VPC to have a Cloud NAT, an Internet Gateway, or complex firewall egress rules.

Exposing highly sensitive internal workloads to the public internet solely to reach a cloud API is a massive violation of Zero Trust architecture.

Google Cloud solved this with Private Service Connect (PSC). PSC allows you to consume Google APIs, third-party SaaS services (like MongoDB Atlas or Snowflake), and even your own internal microservices across different VPCs, entirely using internal IP addresses within your own VPC subnet.

This guide explains how to deploy Google Cloud Private Service Connect to achieve completely isolated, private API access without requiring Cloud NAT or VPC Peering.

Understanding the PSC Architecture

PSC fundamentally alters how DNS and IP routing work for managed services.

1. The PSC Endpoint: You create an endpoint (an internal IP address, like 10.0.0.50) inside your specific VPC subnet.
2. The Service Attachment: This endpoint is cryptographically tethered to the target service (e.g., Google Cloud APIs, or a published third-party service).
3. The DNS Override: You configure a private Cloud DNS zone. When a VM asks for storage.googleapis.com, Cloud DNS intercepts the request and returns the internal PSC IP address (10.0.0.50) instead of Google’s public IP block.
4. The Data Path: The VM sends the packet to 10.0.0.50. Google’s software-defined networking (Andromeda) intercepts the packet at the hypervisor level and forwards it directly to the Cloud Storage API backend. The packet never touches a router, never traverses a NAT, and is completely invisible to the public internet.

Step 1: Reserving the Internal IP Address

First, you must allocate a static internal IP address within your VPC subnet to act as the PSC endpoint.

Using the gcloud CLI, reserve the IP address (ensure the IP is within the CIDR block of your target subnet, e.g., my-internal-subnet):

gcloud compute addresses create psc-google-apis-ip \
    --global \
    --purpose=PRIVATE_SERVICE_CONNECT \
    --addresses=10.0.0.50 \
    --network=my-secure-vpc

Step 2: Creating the PSC Endpoint

Next, you bind the reserved internal IP address to the Google APIs bundle. Google offers two primary bundles: vpc-sc (for VPC Service Controls) and all-apis.

Create the forwarding rule (the endpoint) targeting all Google APIs:

gcloud compute forwarding-rules create psc-google-apis-endpoint \
    --global \
    --network=my-secure-vpc \
    --address=psc-google-apis-ip \
    --target-google-apis-bundle=all-apis

At this moment, the IP 10.0.0.50 is actively listening inside your VPC and routing traffic directly to the Google API backend.

Step 3: Configuring the Private DNS Zone

If you execute a Python script that uploads a file to Cloud Storage, the Google Cloud SDK will automatically attempt to connect to storage.googleapis.com. The SDK does not know that it should connect to 10.0.0.50.

You must intercept the DNS resolution using Google Cloud DNS.

First, create a private managed DNS zone for googleapis.com, binding it exclusively to your VPC:

gcloud dns managed-zones create psc-googleapis-zone \
    --description="Private DNS for PSC" \
    --dns-name="googleapis.com." \
    --visibility=private \
    --networks=my-secure-vpc

Step 4: Creating the DNS Records

You must route the traffic to your PSC IP address.

Create an A record pointing the base domain to the PSC IP:

gcloud dns record-sets create googleapis.com. \
    --zone=psc-googleapis-zone \
    --type=A \
    --ttl=300 \
    --rrdatas=10.0.0.50

Create a CNAME record using a wildcard so that all subdomains (e.g., storage.googleapis.com, bigquery.googleapis.com, pubsub.googleapis.com) resolve to the A record you just created:

gcloud dns record-sets create *.googleapis.com. \
    --zone=psc-googleapis-zone \
    --type=CNAME \
    --ttl=300 \
    --rrdatas=googleapis.com.

Step 5: Verifying the Private Data Path

To prove the architecture is working, SSH into a VM located inside my-secure-vpc. Ensure this VM does not have an external IP address and does not have a Cloud NAT configured.

Run a DNS lookup against the Cloud Storage API:

nslookup storage.googleapis.com

The output must show that it resolves to your internal PSC IP (10.0.0.50).

Now, attempt to upload a file to a bucket or query BigQuery using the standard CLI tools:

gsutil cp test_file.txt gs://my-secure-bucket/

The command will succeed instantly. The VM has absolutely no internet access, yet it is securely interacting with Google’s public cloud services entirely over the private, software-defined backend fabric.

Conclusion

Relying on Cloud NAT or public IP addresses for internal microservices to reach cloud APIs introduces unnecessary latency, egress costs, and a massive attack surface. By deploying Google Cloud Private Service Connect, cloud architects can forcefully drag all API traffic into the private VPC subnet, achieving strict compliance isolation and mathematically guaranteeing that sensitive data never touches the public internet.