Serverless VPC Access connectors aren’t actually a bridge; they’re a proxy that sits in front of your Cloud Run service and routes traffic through a dedicated network interface within your VPC.
Let’s see it in action. Imagine you have a Cloud Run service that needs to access a private Cloud SQL instance.
First, you’d create a Serverless VPC Access connector. This connector lives in a specific region and subnet within your VPC.
gcloud compute networks vpc-access connectors create my-connector \
--region=us-central1 \
--network=my-vpc-network \
--subnet=projects/my-project/regions/us-central1/subnetworks/my-subnet \
--min-instances=2 \
--max-instances=10
Here, my-connector is the name of your connector, us-central1 is the region, my-vpc-network is the name of your VPC, and my-subnet is the specific subnet where the connector’s network interface will reside. We’re also setting the scaling parameters: min-instances=2 ensures at least two instances are always running for high availability, and max-instances=10 allows it to scale up to handle more traffic.
Next, you configure your Cloud Run service to use this connector. When deploying or updating your service:
gcloud run deploy my-service \
--image=gcr.io/my-project/my-app:latest \
--region=us-central1 \
--vpc-connector=projects/my-project/locations/us-central1/connectors/my-connector \
--vpc-egress=all
The crucial part here is --vpc-connector. This tells Cloud Run to direct all outbound traffic from my-service through the my-connector. Setting --vpc-egress=all means all outbound traffic from your Cloud Run service will go through the connector, including traffic to public IP addresses. If you only wanted to route traffic to private IPs within your VPC, you’d use --vpc-egress=private-ranges.
Now, when my-service tries to connect to your private Cloud SQL instance (e.g., at its private IP address 10.0.1.5), the request doesn’t go out to the public internet. Instead, it’s sent to the Serverless VPC Access connector. The connector, which has an IP address within your my-subnet, then forwards the request into your VPC. Your VPC’s routing rules handle the rest, sending the traffic to Cloud SQL. The response travels back through the connector to your Cloud Run service.
The problem this solves is the inherent isolation of serverless platforms. By default, Cloud Run and other serverless services operate in Google-managed environments without direct access to your private network resources. Serverless VPC Access bridges this gap, allowing your ephemeral workloads to interact with your static, private infrastructure like databases, internal APIs, or on-premises resources connected via Cloud VPN or Interconnect.
The connector itself is a managed fleet of VMs. When you specify --min-instances, you’re telling Google Cloud to keep at least that many VMs running for your connector. These VMs are provisioned within the subnet you specified and handle the network translation. Scaling occurs automatically based on the traffic volume hitting the connector, up to the --max-instances limit. Each instance provides a certain amount of network throughput, so scaling up increases your overall capacity to handle more requests concurrently.
A common misconception is that the connector is the subnet. It’s not. The connector uses a subnet. The connector’s instances get IP addresses from the allocated IP range of that subnet, which you define when creating the subnet itself. Make sure this range is large enough to accommodate the connector’s scaling needs and any other resources you might place in that subnet.
The real magic is how it handles egress. When you use --vpc-egress=all, the connector intercepts all outbound traffic from Cloud Run. If the destination IP is within your VPC’s CIDR range, it’s routed internally. If it’s a public IP, the connector uses its own egress IP (which is an IP from your VPC’s subnet) to access the internet. This means your Cloud Run service appears to be originating from an IP address within your VPC, which is crucial for firewall rules and IP allow-listing.
The next hurdle you’ll likely encounter is understanding egress IP translation and how it affects firewall rules.