Send serverless traffic to a VPC network

We recommend that you enable your Cloud Run service or job to sendtraffic to a VPC network by usingDirect VPC egress—with no Serverless VPC Access connector required.

However, if Direct VPC egress isn't an option for you, you can useServerless VPC Access to connect directly toyour VPC network from serverless environments such asCloud Run and App Engine. ConfiguringServerless VPC Access lets your serverless environment sendrequests to your VPC network by using internal DNS and internalIP addresses (as defined byRFC1918 andRFC6598). The responses tothese 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 theinternet.
• Communication through Serverless VPC Access can have lesslatency compared to the internet.

Serverless VPC Access sends internal traffic from yourVPC network to your serverless environment only when that trafficis a response to a request that was sent from your serverless environmentthrough the Serverless VPC Access connector. To learn aboutsending other internal traffic, seePrivate Google Access.

To access resources across multiple VPC networks andGoogle Cloud projects, you must also configureShared VPC orVPC Network Peering.

How it works

Serverless VPC Access is based on a resource called aconnector. A connector handles traffic between your serverless environment andyour VPC network. When you create a connector in yourGoogle Cloud project, you attach it to a specific VPCnetwork and region. You can then configure your serverless services to use theconnector 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/28subnet ifthere are no resources that already use the subnet.
• CIDR range: You can specify an unused/28 CIDR range. When specifyingthis range, make sure that it doesn't overlap with any in-use CIDR ranges.

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

Firewall rules

Firewall rules are necessary for the operationof the connector and its communication with other resources, including resourcesin your network.

Firewall rules for connectors in standalone VPC networks or Shared VPC host projects

If you create a connector in a standalone VPC network or in thehost project of a Shared VPC network, Google Cloud creates allnecessary firewall rules. These firewall rules exist only as long as theassociated connector exists. They are visible in the Google Cloud console, but youcannot edit or delete them.

You can further restrict your connector's access to resources in its target VPCnetwork by using VPC firewall rules or rules in firewall policies. When addingfirewall rules, be sure they use a priority higher than 100 so that they don'tconflict with hidden firewall rules set by Google Cloud. For moreinformation, seeRestrict connector VM access VPC network resources.

Firewall rules for connectors in Shared VPC service projects

If you create a connector in a service project and the connector targets aShared VPC network in the host project, you need to add firewall rulesto allow necessary traffic for the connector's operation.

You can also restrict your connector's access to resources in its target VPCnetwork by using VPC firewall rules or rules in firewall policies.For more information, seeAccess to VPC resources.

Throughput and scaling

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

You can set the minimum and maximum number of connector instances allowed foryour 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 andmaximum number of instances for your connector, the default minimum of 2 anddefault maximum of 10 apply. A connector might temporarily exceed the value setfor maximum instances when Google performs biweekly maintenance, such assecurity updates. During maintenance, additional instances might be added toensure uninterrupted service. After maintenance, connectors return to thesame number of instances that they had before the maintenance period.Maintenance usually lasts for a few minutes. To reduce impact duringmaintenance, useconnection poolsand don't rely on connections lasting more than one minute. Instancesstop accepting requests one minute before shutdown.

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

Example

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

Throughput chart

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

You can monitor current throughput from the Connector details page in theGoogle Cloud console. TheThroughput chart on this page displays a detailed viewof the connector's throughput metrics.

Network tags

Serverless VPC Access network tags let you refer toVPC connectors infirewall rules androutes.

Every Serverless VPC Access connector automatically receivesthe following two network tags (sometimes calledinstance tags):

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

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

These network tags cannot be deleted. New network tags cannot be added. Usenetwork tags torestrict connector VM access to VPC resources.

Use cases

You can use Serverless VPC Access to access Compute Engine VMinstances, Memorystore instances, and any other resources with internalDNS 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 aCompute Engine VM.
• You run a backend service on a Managed Instance Group inCompute Engine and need your serverless environment to communicatewith this backend without exposure to the internet.
• Your serverless environment needs to access data from your on-premisesdatabase through Cloud VPN.

Example

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

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

There are two resources in the VPC network. One of the resourceshas the internal IP address10.0.0.4. The other resource has the internal IPaddress10.1.0.2, and is in a different region than theServerless VPC Access connector.

The connector handles sending and receiving both the requests and responsesdirectly from these internal IP addresses. When the connector sends requests tothe resource with internal IP address10.1.0.2,outbound data transfercosts apply because that resource is in adifferent region.

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

Requests sent to external IP addresses still travel through the internet anddon't use the Serverless VPC Access connector.

The following diagram shows this configuration.

Pricing

For Serverless VPC Access pricing, seeServerless VPC Access onthe VPC pricing page.

Supported services

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

The following table shows which serverless environments supportServerless VPC Access:

*If you want to use internal IP addresses when connecting fromKnative serving or the App Engine flexible environment, youdon't need to configure Serverless VPC Access. Just make sureyour service is deployed in a VPC network that has connectivityto the resources you want to reach.

Supported networking protocols

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

gcloud compute networks vpc-access locations list

• To configure Serverless VPC Access, seeConfigureServerless VPC Access.