Serverless VPC Access

Serverless VPC Access makes it possible for you to connect directly to your Virtual Private Cloud (VPC) network from serverless environments such as Cloud Run, App Engine, or Cloud Functions. Configuring Serverless VPC Access allows your serverless environment to send requests to your VPC network by using internal DNS and internal IP addresses (as defined by RFC 1918 and RFC 6598). The responses to these requests also use your internal network.

There are two main benefits to using Serverless VPC Access:

  • Requests sent to your VPC network are never exposed to the internet.
  • Communication through Serverless VPC Access can have less latency compared to the internet.

Serverless VPC Access sends internal traffic from your VPC network to your serverless environment only when that traffic is a response to a request that was sent from your serverless environment through the Serverless VPC Access connector. To learn about sending other internal traffic to your serverless environment, see Private Google Access.

To access resources across multiple VPC networks and Google Cloud projects, you must also configure Shared VPC or VPC Network Peering.

How it works

Serverless VPC Access is based on a resource called a connector. A connector handles traffic between your serverless environment and your VPC network. When you create a connector in your Google Cloud project, you attach it to a specific VPC network and region. You can then configure your serverless services to use the connector for outbound network traffic.

IP address ranges

There are two options for setting the IP address range for a connector:

  • Subnet: You can specify an existing /28 subnet if there are no resources that already use the subnet.
  • CIDR range: You can specify an unused /28 CIDR range. When specifying this range, make sure that it doesn't overlap with any in-use CIDR ranges.

Traffic sent through the connector into your VPC network originates from the subnet or CIDR range that you specify.

Firewall rules

If the subnet is not a shared subnet, an implicit firewall rule with priority 1000 is created on your VPC network to allow ingress from the connector's subnet or custom IP range to all destinations in the network. The implicit firewall rule is not visible in the Google Cloud console and exists only as long as the associated connector exists.

Throughput and scaling

A Serverless VPC Access connector consists of connector instances. Connector instances can use one of several machine types. Larger machine types provide more throughput. You can view the estimated throughput and cost for each machine type in the Google Cloud console and in the following table.

Machine type Estimated throughput range in Mbps* Price
(connector instance plus network outbound data transfer costs)
f1-micro 100-500 f1-micro pricing
e2-micro 200-1000 e2-micro pricing
e2-standard-4 3200-16000 e2 standard pricing

* Maximum throughput ranges are estimates based on regular operation. Actual throughput depends on many factors. See VM network bandwidth.

You can set the minimum and maximum number of connector instances allowed for your connector. The minimum must be at least 2. The maximum can be at most 10, and must be larger than the minimum. If you don't specify the minimum and maximum number of instances for your connector, the default minimum of 2 and default maximum of 10 apply. A connector may temporarily exceed the value set for maximum number of instances when Google does maintenance such as security updates. During maintenance, additional instances may be added to ensure uninterrupted service. After maintenance, connectors are returned to the same number of instances as they had before the maintenance period. Maintenance usually lasts for a few minutes. To reduce impact during maintenance, don't rely on connections lasting more than one minute. Instances don't accept requests one minute before they are taken down.

Serverless VPC Access automatically scales out the number of instances in your connector as traffic increases. The instances added are of the type you specified for your connector. Connectors cannot mix machine types. Connectors don't scale in. To prevent connectors from scaling out more than you want, set the maximum number of instances to a low number. If your connector has scaled out and you prefer to have fewer instances, recreate the connector with the necessary number of instances.


If you choose f1-micro for your machine type, and you use the default values for minimum and maximum number of instances (2 and 10 respectively), the estimated throughput for your connector is 100 Mbps at the default minimum number of instances and 500 Mbps at the default maximum number of instances.

Throughput chart

You can monitor current throughput from the Connector details page in the Google Cloud console. The Throughput chart on this page displays a detailed view of the connector's throughput metrics.

Network tags

Serverless VPC Access network tags let you refer to VPC connectors in firewall rules and routes.

Every Serverless VPC Access connector automatically receives the following two network tags (sometimes called instance tags):

  • Universal network tag (vpc-connector): Applies to all existing connectors and any connectors made in the future.

  • Unique network tag (vpc-connector-REGION-CONNECTOR_NAME): Applies to the connector CONNECTOR_NAME in the region REGION.

These network tags cannot be deleted. New network tags cannot be added.

Use cases

You can use Serverless VPC Access to access Compute Engine VM instances, Memorystore instances, and any other resources with internal DNS or internal IP address. Some examples are:

  • You use Memorystore to store data for a serverless service.
  • Your serverless workloads use third-party software that you run on a Compute Engine VM.
  • You run a backend service on a Managed Instance Group in Compute Engine and need your serverless environment to communicate with this backend without exposure to the internet.
  • Your serverless environment needs to access data from your on-premises database through Cloud VPN.


In this example, a Google Cloud project is running multiple services across the following serverless environments: App Engine, Cloud Functions, and Cloud Run.

A Serverless VPC Access connector was created and assigned the IP range Therefore, the source IP address for any request sent from the connector is in this range.

There are two resources in the VPC network. One of the resources has the internal IP address The other resource has the internal IP address, and is in a different region than the Serverless VPC Access connector.

The connector handles sending and receiving both the requests and responses directly from these internal IP addresses. When the connector sends requests to the resource with internal IP address, outbound data transfer costs apply because that resource is in a different region.

All requests and responses between the serverless environments and the resources in the VPC network travel internally.

Requests sent to external IP addresses still travel through the internet and do not use the Serverless VPC Access connector.

The following diagram shows this configuration.

Serverless VPC Access example (click to enlarge)
Serverless VPC Access example (click to enlarge)


For Serverless VPC Access pricing, see Serverless VPC Access on the VPC pricing page.

Supported services

The following table shows which types of networks you can reach using Serverless VPC Access:

Connectivity service Serverless VPC Access support
Shared VPC
Legacy networks
Networks connected to Cloud Interconnect
Networks connected to Cloud VPN
Networks connected to VPC Network Peering

The following table shows which serverless environments support Serverless VPC Access:

Serverless environment Serverless VPC Access support
Cloud Run
Knative serving*
Cloud Functions
App Engine standard environment All runtimes except PHP 5
App Engine flexible environment*

*If you want to use internal IP addresses when connecting from Knative serving or the App Engine flexible environment, you don't need to configure Serverless VPC Access. Just make sure your service is deployed in a VPC network that has connectivity to the resources you want to reach.

Supported networking protocols

The following table describes the networking protocols supported by Serverless VPC Access connectors.

Protocol Route only requests to private IPs through the VPC connector Route all traffic through the VPC connector
ICMP Supported only for external IP addresses

Supported regions

Serverless VPC Access connectors are supported in every region that supports Cloud Run, Cloud Functions, or App Engine standard environment.

To view available regions:

gcloud compute networks vpc-access locations list

What's next