Serverless VPC Access

Serverless VPC Access makes it possible for you to connect directly to your 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 using internal DNS and internal IP addresses

Potential 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.

How it works under the hood

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. A /28 CIDR range (or "block") is a group of IP addresses. For example, the CIDR range 10.8.0.0/28 has a 32-bit IP address (10.8.0.0 in decimal or 00001010.00001000.00000000.00000000 in binary).
• The CIDR range also has a mask, /28, which indicates how many bits belong to the network identifier (the first part of the IP address) and how many belong to the host identifier (the second part). A mask of /28 means that the first 28 bits belong to the network, and the last 4 bits belong to the host identifier. With 4 binary bits, you can count to 16 (0000, 0001, 0010, ... 1000).
• Therefore, a /28 CIDR range is a range of 16 host IP addresses, where the first address (10.8.0.0) and the last address (10.8.0.15) are reserved, leaving 14 usable IP addresses: 10.8.0.1 to 10.8.0.14. 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.

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.

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.

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 do not scale in. To prevent connectors from scaling out more than you want, set the maximum number of instances to a low number.

Cloud Run Serverless VPC Access Configuration

Connect to a Standalone VPC network

You can use Serverless VPC Access connect a Cloud Run service or job directly to your VPC network, allowing access to Compute Engine VM instances, Memorystore instances, and any other resources with an internal IP address.

Create a Serverless VPC Access connector

1. Ensure the Serverless VPC Access API is enabled for your project:

gcloud services enable vpcaccess.googleapis.com

2. If you are using Shared VPC, which requires you to use your own subnet, create a connector with the following command:

gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
--region REGION \
--subnet SUBNET \
# If you are not using Shared VPC, omit the following line.
--subnet-project HOST_PROJECT_ID \
# Optional: specify minimum and maximum instance values between 2 and
10, default is 2 min, 10 max.
--min-instances MIN \
--max-instances MAX \
# Optional: specify machine type, default is e2-micro
--machine-type MACHINE_TYPE

Subnets must be used exclusively by the connector. They cannot be used by other resources such as VMs, Private Service Connect, or Internal HTTP(S) Load Balancing.

3. If you are not using Shared VPC and want to supply a custom IP range instead of using a subnet, create a connector with the following command:

gcloud compute networks vpc-access connectors create CONNECTOR_NAME \
--network VPC_NETWORK \
--region REGION \
--range IP_RANGE

4. Verify that your connector is in the READY state before using it:

gcloud compute networks vpc-access connectors describe CONNECTOR_NAME \
--region REGION

Configure your service to use a connector

To specify a connector during deployment, use the --vpc-connector flag:

gcloud run deploy SERVICE --image IMAGE_URL --vpc-connector CONNECTOR_NAME

Configure your job to use a connector

To specify a connector during the job deployment, use the --vpc-connector flag:

gcloud beta run jobs create JOB --image IMAGE_URL --vpc-connector CONNECTOR_NAME

Restrict access to VPC resources

When connecting to a standalone VPC network or a Shared VPC network that has the connector in the host project, an implicit firewall rule with priority 1000 is automatically created on your VPC network to allow ingress from the connector’s subnet or custom IP range to all destinations in the VPC network. The implicit firewall rule is not visible in the Google Cloud console and exists only as long as the associated connector exists.

Connecting to a Shared VPC network

For Shared VPC, Serverless VPC Access connectors can be configured in two different ways. You can either set up connectors in each service project that has Cloud Run resources that need access to your network, or you can set up shared connectors in the host project. There are advantages to each method.

Service Projects

Advantages of creating connectors in the service projects:

• Isolation: Each connector has dedicated bandwidth and is unaffected by bandwidth use of connectors in other service projects. This is good if you have a service that experiences spikes in traffic, or if you need to ensure that each service project is unaffected by connector use of other service projects.
• Chargebacks: Charges incurred by connectors are associated with the service project containing the connector. This enables easier chargebacks.
• Security: Allows you to follow the “principle of least privilege.” Connectors must be granted access to the resources in your Shared VPC network that they need to reach. By creating a connector in the service project, you can limit what the services in the project can access by using firewall rules.
• Team independence: Reduces dependency on the host project administrator. Teams can create and manage the connectors associated with their service project. A user with the Compute Engine Security Admin role or a custom Identity and Access Management (IAM) role with the compute.firewalls.create permission enabled for the host project must still manage firewall rules for the connector.

Host Projects

Advantages of creating connectors in the host project:

• Centralized network management: Aligns with the Shared VPC model of centralizing network configuration resources in the host project.
• IP address space: Preserves more of your IP address space. Connectors require an IP address for each instance, so having fewer connectors (and fewer instances in each connector) uses fewer IP addresses. This is good if you are concerned about running out of IP addresses.
• Maintenance: Reduces maintenance, because each connector you create may be used by multiple service projects. This is good if you are concerned about maintenance overhead.
• Cost for idle time: Can reduce the amount of connector idle time and associated cost. Connectors incur costs even when they are not serving traffic. Having fewer connectors may reduce the amount of resource you pay for when not serving traffic, depending on your connector type and number of instances. This is often cost effective if your use case involves a large number of services, and the services are used infrequently.