Serverless VPC Access in GCP Explained | Cloud Run, Connectors, and Private IPs

Simple explanation

Your Cloud Run service and your private database both live in Google Cloud, but they are not in the same part of Google’s network. Cloud Run runs on shared managed infrastructure that is not inside any VPC. Your private database lives inside your VPC: a private network you control, where resources only have private IP addresses.

Without a connector, traffic from Cloud Run cannot find a route to private IP addresses inside your VPC. Think of it as two offices in different buildings with no connecting corridor.

A Serverless VPC Access connector is that corridor. It is a small set of VM instances that Google manages for you, placed inside a dedicated /28 subnet in your VPC. When your Cloud Run service needs to talk to a private resource, traffic flows to the connector VMs, which forward it into your VPC as normal network traffic. Resources inside the VPC see that traffic as coming from the connector’s IP range, not from some unknown external address.

Why this matters

Many production architectures keep backend services off the public internet. A Cloud SQL instance configured with private connectivity has no public IP at all. It is only reachable via a private IP inside the VPC. Memorystore Redis instances always have private IPs. Internal APIs running on Compute Engine VMs are often placed on private subnets intentionally.

This is sound security practice. Keeping data stores and internal services off the internet reduces attack surface significantly. But it creates a real problem when the services consuming those resources are serverless, because serverless services live outside your VPC by default.

A Serverless VPC Access connector resolves this tension. You keep your database and internal services private, and you give your Cloud Run or Cloud Functions workloads a controlled path into the VPC to reach them. The connector is the mechanism that makes both true at once.

Common scenarios where this is directly necessary:

• Cloud Run connecting to Cloud SQL over a private IP
• Cloud Functions reading from or writing to a Memorystore Redis or Memcache instance
• Cloud Run calling an internal microservice on Compute Engine with no external IP
• Any serverless workload that must route all internet egress through a specific Cloud NAT IP for third-party allowlisting
• Cloud Run calling an internal service exposed only through an internal load balancer

How it works

A connector is a set of VM instances that Google creates and manages inside your VPC. You specify a /28 CIDR range when you create the connector, and Google provisions a dedicated subnet in that range. The connector VMs live in that subnet.

When your Cloud Run service sends a request to a private IP address, the traffic is routed to the connector. The connector VMs forward it into the VPC as ordinary network traffic. From the perspective of the destination resource (a database, a cache, or a VM), the traffic appears to originate from the connector’s /28 range. This means standard firewall rules apply: if you have ingress rules protecting your private resources, you need to explicitly allow traffic from the connector’s CIDR range.

A few properties of connectors to keep in mind:

• Regional: a connector is tied to a specific region. Your Cloud Run service and connector must be in the same region.
• Dedicated subnet: the /28 range must not overlap with any existing subnet in the VPC or any peered VPCs.
• Google-managed VMs: you do not patch or manage the connector instances yourself, but they count against your VM quota and are billed at Compute Engine rates.
• Scalable: you set minimum and maximum instance counts. The connector scales within those bounds based on traffic throughput.
• Egress modes: you control whether only traffic to private IP ranges goes through the connector (private-ranges-only), or whether all outbound traffic from the service does (all-traffic).

Each connector instance handles approximately 100 Mbps of throughput. For high-traffic workloads, raise the maximum instance count and consider a larger machine type such as e2-standard-4.

When to use this

Use a Serverless VPC Access connector when a serverless service needs to reach a resource that is only reachable via a private IP inside your VPC.

• Cloud Run to Cloud SQL private IP: your Cloud SQL instance is configured with private connectivity and has no public IP; the connector gives Cloud Run a path to reach it
• Cloud Run or Cloud Functions to Memorystore: Memorystore Redis and Memcache instances always have private IPs; a connector is required
• Cloud Run to an internal microservice: a backend service running on a VM or GKE node with no external IP, only accessible within the VPC
• Routing all internet egress through a fixed IP: when an external partner requires you to connect from a known IP address, set vpc-egress=all-traffic and route through a Cloud NAT gateway with a reserved static IP
• Keeping backend services fully private: the connector lets your serverless frontend reach internal services without those services needing public exposure

When not to use this

A connector is not always the right answer. In several cases you either do not need one or there is a better-fitting solution.

• The target service has a public endpoint: if your Cloud SQL instance has a public IP, Cloud Run can reach it directly without a connector (though this is not recommended for production security reasons).
• You only need to reach Google APIs: Serverless VPC Access is not the mechanism for reaching Cloud Storage, BigQuery, or other Google APIs. Cloud Run already has built-in access to Google APIs without a connector. For private VMs that need this, use Private Google Access instead.
• The added cost is not justified: connector VMs run continuously and incur Compute Engine costs even when no traffic flows. For very-low-traffic or intermittent workloads, evaluate whether the cost is proportionate to the benefit.
• Cloud Run 2nd gen is in use and direct VPC egress fits better: Cloud Run 2nd gen services support direct VPC egress, which connects the service directly into the VPC without needing to manage connector instances. Worth evaluating if you want lower overhead.
• Public access is the intended design: if both your Cloud Run service and its dependencies are designed to be publicly accessible, adding a connector for private routing introduces unnecessary complexity.

Serverless VPC Access vs related networking options

Several GCP networking features solve adjacent problems, and it is easy to confuse them when you are building on GCP for the first time. This table covers the most common points of confusion.

The most common confusion is between Serverless VPC Access and Private Google Access. They are not interchangeable. Private Google Access is a subnet-level flag that gives private VMs access to Google-managed APIs. It does nothing for serverless services that need to reach VPC resources with private IPs. If you are trying to reach Cloud Storage or BigQuery from Cloud Run, you do not need a connector at all.

Creating a connector

Before creating a connector, verify that the /28 CIDR range you plan to use is not already in use. Check your existing subnets and any peered VPC ranges first. The region must match the region of the services that will use the connector. The machine type and instance counts control throughput: each instance handles approximately 100 Mbps, and the connector scales between the specified minimum and maximum.

# Enable the Serverless VPC Access API
gcloud services enable vpcaccess.googleapis.com

# Create a connector
gcloud compute networks vpc-access connectors create my-vpc-connector \
  --network=my-vpc \
  --region=europe-west1 \
  --range=10.8.0.0/28 \
  --min-instances=2 \
  --max-instances=10 \
  --machine-type=e2-micro

# Confirm the connector is READY before attaching it to any service
gcloud compute networks vpc-access connectors describe my-vpc-connector \
  --region=europe-west1

Wait for the connector to reach READY state before deploying services that reference it. This typically takes one to two minutes.

Attaching a connector to Cloud Run

Attach the connector when deploying or updating a Cloud Run service. The egress mode controls which traffic routes through the connector.

# private-ranges-only: only traffic to RFC 1918 private addresses goes through the connector
# Public internet traffic still leaves directly from Cloud Run
gcloud run deploy my-service \
  --image=gcr.io/my-project/my-image:latest \
  --region=europe-west1 \
  --vpc-connector=my-vpc-connector \
  --vpc-egress=private-ranges-only

# all-traffic: every outbound connection from Cloud Run goes through the connector
# Use this when you want internet traffic to appear from a fixed Cloud NAT IP
gcloud run deploy my-service \
  --image=gcr.io/my-project/my-image:latest \
  --region=europe-west1 \
  --vpc-connector=my-vpc-connector \
  --vpc-egress=all-traffic

private-ranges-only is the right choice for most setups. Traffic to private IP addresses (RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) flows through the connector, while internet traffic still leaves Cloud Run directly. This avoids routing unnecessary traffic through the connector.

Using connectors with Cloud Functions

Cloud Functions — both 1st and 2nd generation — support Serverless VPC Access connectors. The connector must be in the same region as the function. Specify it at deploy time with the —vpc-connector flag.

# Deploy a Cloud Function with a VPC connector attached
gcloud functions deploy my-function \
  --runtime=python311 \
  --trigger-http \
  --region=europe-west1 \
  --vpc-connector=my-vpc-connector \
  --vpc-connector-egress-settings=private-ranges-only \
  --source=.

The —vpc-connector-egress-settings flag corresponds to the egress mode in Cloud Run. Use private-ranges-only for private VPC access without rerouting internet traffic, or all-traffic to route everything through the connector.

Firewall rules for connectors

When traffic from Cloud Run or Cloud Functions passes through the connector and enters your VPC, it appears to originate from the connector’s /28 CIDR range. It does not appear to come from a Google IP range, and it does not carry any identity from the Cloud Run service itself. Standard firewall rules apply based on that source range.

A correctly configured connector with no matching ingress firewall rule results in connections timing out silently. There is no helpful error message from Cloud Run. This is the single most common cause of failure when setting up Serverless VPC Access for the first time.

# Allow traffic from the connector's /28 range to reach a PostgreSQL database
gcloud compute firewall-rules create allow-connector-to-sql \
  --network=my-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:5432 \
  --source-ranges=10.8.0.0/28 \
  --description="Allow Serverless VPC connector to reach PostgreSQL"

Troubleshooting checklist

If Cloud Run or Cloud Functions cannot reach a private resource after adding a connector, work through these checks in order. Most failures are caused by one of the first four items.

1. Connector state is READY. Run gcloud compute networks vpc-access connectors describe my-vpc-connector —region=REGION and confirm the state shows READY. A connector in a degraded state will not forward traffic reliably.
2. Connector and service are in the same region. Confirm the connector region matches the Cloud Run service or Cloud Functions region exactly. Even a minor mismatch (europe-west1 vs europe-west2) causes a deployment configuration error.
3. Firewall rule allows the connector’s source range. Check that an ingress allow rule exists for the connector’s /28 CIDR on the correct port. Use gcloud compute firewall-rules list —filter=“network=my-vpc” to review all rules in the VPC.
4. The deployment includes the connector. Verify the deployed service or function has the connector configured. For Cloud Run: gcloud run services describe my-service —region=REGION and look for the VPC connector fields in the output.
5. Egress mode matches the use case. If you need internet traffic routed through the connector, confirm vpc-egress=all-traffic is set and that Cloud NAT is active in the VPC. If only private IPs need the connector, confirm private-ranges-only is set.
6. The target resource is actually reachable. Confirm the Cloud SQL instance, Memorystore instance, or VM is running and correctly configured. Test connectivity from a VM inside the same VPC to rule out connector-specific issues.
7. Cloud NAT is configured when using all-traffic egress. If Cloud Run needs to reach internet destinations through the connector, your VPC must have a Cloud NAT gateway in the same region. See Cloud NAT for setup steps.
8. Routes exist for the destination. Private resources must be reachable via existing VPC routes. If the destination subnet has a missing or broken route, the connector will forward the packet into the VPC but it will not reach its destination.

For deeper packet-level diagnostics, see Troubleshooting Network Issues.