How to Deploy Google Cloud Run Services with VPC Serverless Connector for Private Database Access

Google Cloud Run is a highly scalable, fully managed serverless compute platform that allows developers to run containerized applications without worrying about infrastructure provisioning. By default, services deployed on Cloud Run are accessible via the public internet and operate entirely outside of your Virtual Private Cloud (VPC) network. However, enterprise architectures frequently require backend microservices to communicate with private, internal resources, such as Cloud SQL databases, Redis Memorystore instances, or legacy on-premises virtual machines. Because these resources reside securely on private IP addresses within a VPC, a standard Cloud Run service cannot route traffic to them. To bridge this isolation gap, infrastructure engineers must deploy a Serverless VPC Access Connector.

The Architecture of Serverless VPC Access

A Serverless VPC Access Connector acts as an elastic network bridge between the serverless execution environment of Cloud Run and your designated VPC network. It consists of a pool of Compute Engine virtual machine instances (provisioned and managed entirely by Google Cloud) that sit within a dedicated /28 subnet inside your VPC.

When a Cloud Run service is configured to use the connector, Google’s internal networking stack routes the outbound egress traffic from the container directly into the connector’s subnet. From there, the traffic inherits a private IP address from the subnet and flows natively through the VPC routing tables, allowing seamless connectivity to any private IP resource in the region.

Provisioning the VPC Subnet and Connector

Before deploying the connector, you must allocate a dedicated subnet. This subnet must have a CIDR block of exactly /28 (providing 16 IP addresses) and cannot be utilized by any other Google Cloud resources, such as Compute Engine instances or Kubernetes clusters.

Execute the following gcloud command to create the dedicated subnet in your target region (e.g., us-central1):

gcloud compute networks subnets create serverless-connector-subnet \
    --network=my-enterprise-vpc \
    --region=us-central1 \
    --range=10.0.10.0/28

Once the subnet is established, you can instantiate the Serverless VPC Access Connector. You must specify the minimum and maximum throughput instances depending on your expected backend load:

gcloud compute networks vpc-access connectors create my-vpc-connector \
    --network=my-enterprise-vpc \
    --region=us-central1 \
    --subnet=serverless-connector-subnet \
    --min-instances=2 \
    --max-instances=10 \
    --machine-type=e2-micro

Deploying Cloud Run with the Connector

With the networking bridge established, you can deploy your containerized application to Cloud Run and instruct it to route egress traffic through the connector. Crucially, you must decide on the Egress routing policy.

• Private ranges only: Only traffic destined for RFC 1918 private IP addresses (your internal databases) is routed through the VPC. Traffic to the public internet exits directly from the Cloud Run environment.
• All traffic: Every outbound packet, including external internet requests, is routed through the VPC. This is essential if you need to route outbound internet traffic through a static Cloud NAT IP address or a centralized third-party firewall appliance (e.g., Palo Alto Networks).

To deploy the service and attach the connector with the “Private ranges only” routing policy, utilize the following gcloud run deploy syntax:

gcloud run deploy my-secure-backend \
    --image=gcr.io/my-project/backend-api:v1.0 \
    --region=us-central1 \
    --vpc-connector=my-vpc-connector \
    --vpc-egress=private-ranges-only \
    --allow-unauthenticated

Configuring Cloud SQL Connectivity

Once deployed, your Cloud Run container can interact with internal resources exactly as if it were a standard virtual machine residing on the network. For example, if you are attempting to connect to a private Cloud SQL instance, you no longer need to configure the complex Cloud SQL Auth Proxy or manage external SSL certificates.

You can simply configure your application’s database connection string (e.g., in Node.js, Python, or Java) to point directly to the private IPv4 address of the Cloud SQL instance, using standard port 5432 for PostgreSQL or 3306 for MySQL. The VPC Connector will flawlessly route the packets across the internal network boundaries.