Connect Cloud Functions to a VPC with Serverless VPC Access (2026)

Serverless VPC Access lets your Cloud Functions talk to resources inside your Virtual Private Cloud (VPC) network.

Let’s see it in action. Imagine a Cloud Function that needs to query a private Cloud SQL instance. Normally, Cloud Functions run in Google’s managed environment, isolated from your VPC. To bridge this gap, Serverless VPC Access creates a "connector" that acts as a gateway.

resource "google_vpc_access_connector" "connector" {
  name          = "my-vpc-connector"
  region        = "us-central1"
  network       = "projects/my-project/global/networks/my-vpc-network"
  ip_cidr_range = "10.8.0.0/28"
  min_throughput_mbps = 200
  max_throughput_mbps = 300
}

resource "google_cloudfunctions_function" "function" {
  name                  = "my-sql-query-function"
  runtime               = "nodejs18"
  region                = "us-central1"
  entry_point           = "queryDatabase"
  source_archive_bucket = "my-source-bucket"
  source_archive_object = "my-function.zip"

  vpc_connector = google_vpc_access_connector.connector.id

  environment_variables = {
    DB_HOST = "10.0.1.5" # Private IP of Cloud SQL instance
    DB_USER = "myuser"
    DB_PASS = "mypassword"
  }
}

In this Terraform configuration:

• google_vpc_access_connector.connector defines the connector itself.

  • name: A unique identifier for your connector.
  • region: Must be the same region as your Cloud Functions.
  • network: The self-link of the VPC network you want to connect to.
  • ip_cidr_range: A /28 CIDR block within your VPC’s address space that the connector will use. This block must not overlap with any other IP ranges in your VPC. A /28 gives you 16 IP addresses, sufficient for the connector instances.
  • min_throughput_mbps and max_throughput_mbps: Control the scaling of the connector. These values determine the minimum and maximum network egress bandwidth (in Mbps) that the connector can provide. Higher throughput allows for more concurrent connections and faster data transfer but incurs higher costs.

• google_cloudfunctions_function.function defines the Cloud Function.

  • vpc_connector: This is the crucial part. It’s set to the ID of the connector we defined, telling the function to route its VPC-bound traffic through this connector.
  • environment_variables: Here, we provide the private IP address of our Cloud SQL instance. The function code will use this IP to establish a connection.

When the my-sql-query-function is invoked, any outbound network requests it makes to the private IP address 10.0.1.5 will be routed through the my-vpc-connector. The connector then forwards these requests into your VPC network, allowing the function to reach the Cloud SQL instance as if it were running within the VPC itself. The response travels back through the connector.

The primary problem this solves is enabling serverless functions to access resources that are not exposed to the public internet. This includes databases (Cloud SQL, Memorystore), internal load balancers, and other services running on Compute Engine VMs within your VPC. Without Serverless VPC Access, you’d typically need to deploy your compute within the VPC (e.g., on GKE or Compute Engine) or use more complex proxying mechanisms.

The connector is essentially a managed fleet of VMs that live within the specified ip_cidr_range in your VPC. When you configure a function to use a connector, Google automatically deploys instances of these connector VMs into your VPC and routes the function’s traffic through them. This provides a secure, private connection without requiring you to manage the underlying infrastructure for these gateway VMs.

The scaling of the connector is automatic based on the configured min_throughput_mbps and max_throughput_mbps. If your function experiences a surge in traffic requiring more bandwidth, the connector will scale up its instances to meet the demand, up to the max_throughput_mbps limit. Conversely, it will scale down during periods of low activity. You are billed based on the amount of traffic that flows through the connector, not just for the connector’s existence, and also for the provisioned throughput.

A detail often overlooked is the IP CIDR range for the connector. It’s not just about avoiding conflicts with your existing VPC subnets; it’s also about ensuring the connector has enough IPs to scale. A /28 is the minimum, but if you anticipate very high concurrency or large data transfers, you might consider a larger range if your VPC topology allows, though the absolute maximum IPs the connector can utilize is capped. The connector itself uses a small subset of these IPs for its internal operations.

The next challenge you’ll likely face is managing the firewall rules to allow traffic from the connector’s IP range to your target resources within the VPC.