You can route Cloud Run egress traffic directly to a VPC network without using a Serverless VPC Access connector if your Cloud Run service is configured to use a VPC Network.
This is how it looks when it’s running:
Let’s say you have a Cloud Run service named my-app in the us-central1 region. It needs to access a private database instance running on Compute Engine within your VPC network.
First, you’d deploy your Cloud Run service, ensuring it’s associated with your VPC network:
gcloud run deploy my-app \
--image gcr.io/my-project/my-image \
--region us-central1 \
--vpc-connector projects/my-project/locations/us-central1/connectors/my-connector \
--vpc-egress all \
--platform managed
Wait, that’s the old way! The new way, the one that bypasses the connector for direct egress, looks like this:
gcloud run deploy my-app \
--image gcr.io/my-project/my-image \
--region us-central1 \
--network my-vpc-network \
--subnet my-subnet \
--vpc-egress all \
--platform managed
Notice the absence of --vpc-connector. Instead, we’re specifying --network and --subnet. This tells Cloud Run to carve out IP addresses from your specified subnet and use them for the outbound traffic of your service.
When my-app needs to connect to 10.10.1.5 (your private database IP), the request originates from an IP address within my-subnet. The VPC network’s routing tables then handle directing this traffic to the database instance, just as if the request had come from any other VM in that subnet. No proxying through a connector.
The core problem this solves is avoiding the latency and potential bottleneck introduced by the Serverless VPC Access connector. Connectors, while useful for many scenarios, involve an extra hop. Traffic from Cloud Run goes to the connector’s instances, and then from those instances into your VPC. By routing egress directly, you eliminate that hop.
Internally, when you specify --network and --subnet, Google Cloud provisions a range of IP addresses from your chosen subnet for your Cloud Run service. This is often referred to as "VPC Network Peering" or "Private Service Connect" for Cloud Run, though the underlying mechanism is about IP address allocation and routing. Your service’s outbound traffic is then NAT’d using one of these allocated IPs before it leaves the Cloud Run environment and enters your VPC. The beauty is that this NAT happens within the VPC infrastructure, not on separate connector VMs.
The key levers you control are:
--network: The name of your VPC network.--subnet: The name of the subnet within that VPC network from which IP addresses will be allocated for your Cloud Run service’s egress.--vpc-egress: This can beall(all outbound traffic goes through the VPC) orprivate-ranges-only(only traffic to RFC 1918 private IP ranges goes through the VPC; public internet traffic goes through Google’s public egress).
When you use --vpc-egress all, all outbound traffic from your Cloud Run service, including requests to public internet endpoints, will be routed through your VPC network. This means you’ll need appropriate firewall rules and NAT gateways (if necessary for internet access) configured in your VPC. If you use private-ranges-only, only traffic destined for private IP addresses within your VPC (or peered networks) will use the VPC egress. Public internet traffic will still egress via Google’s standard public IPs, bypassing your VPC entirely for those requests.
The most surprising true thing is that your Cloud Run service, in this configuration, effectively becomes a resource within your VPC, capable of being assigned an IP from your subnet and leveraging your VPC’s routing and firewall rules directly for its outbound connections, without needing a separate, explicitly managed connector infrastructure. It’s like having a mini-VM in your VPC, but managed by Cloud Run.
The next thing you’ll likely grapple with is how to handle inbound requests to your Cloud Run service from within the VPC, especially if you want to avoid public IP exposure.