Skip to main content

Serverless VPC Access

Exam guide§2.1

Serverless VPC Access connects a Cloud Run function directly to your VPC network, so it can reach Compute Engine VMs, Memorystore, and any other resource at its internal IP address. Requests and responses use internal DNS and internal IPs, so the traffic is never exposed to the internet. This page covers configuring a connector for a function, restricting what the connector can reach with firewall rules, and connecting to a Shared VPC.

The connector fundamentals (what a connector is, the /28 requirement, region matching) are shared with Cloud Run services - see Cloud Run access & networking. This page focuses on the function-specific pieces.

GotchaA function reaches public IPs by default - internal IPs it cannot

By default a Cloud Run function can call public external IPs and URLs, but it cannot reach a resource on its internal VPC IP. A request to an internal address just hangs and times out (the function returns an upstream request timeout). Attach a Serverless VPC Access connector and route egress through it, and the same internal IP becomes reachable. So a function that returns a VM's page instantly from the VM's external IP will time out on its internal IP - until it is redeployed with --vpc-connector.

Configuring a connector​

NumbersConfiguring Serverless VPC Access
  1. Enable the Serverless VPC Access API.
  2. Create a connector in your Google Cloud project.
  3. Attach the connector to a VPC network and region. The connector's region must match the region where your functions are deployed.

A Serverless VPC Access connector is the resource that handles traffic between the serverless functions environment and your VPC network. Configure it with an unused /28 subnet or a non-overlapping /28 CIDR range, used exclusively by the connector and no other resources. Once created, you use it by deploying each function with the connector name.

CommandsDeploy a function through a connector
gcloud functions deploy FUNCTION_NAME \
--vpc-connector CONNECTOR_NAME \
FLAGS...

Restricting connector access​

Restrict what a connector can reach in your VPC with firewall rules - either at the destination resource (ingress) or at the connector itself (egress).

Using ingress rules​

PRI: 1000Connector subnet/CIDR rangePRI: 990Source connector tag/CIDR rangePRI: 980Source connector tag/CIDR rangeTarget resource tag
Ingress rules apply at the destination. Priority 1000 is the implicit allow; a lower number (990) denies the connector; an even lower number (980) re-allows it to one target resource.
NumbersIngress rule layering
  • Connecting to a standalone VPC - or a Shared VPC with the connector in the host project - automatically creates an implicit firewall rule at priority 1000 that allows ingress from the connector's subnet/CIDR range to all resources in the VPC.
  • Override the default: create an ingress rule with priority lower than 1000 to deny ingress from the connector network tag or CIDR range.
  • Re-allow to a target: create another ingress rule with an even lower priority number, targeting the specific resource you want the connector to reach.
GotchaLower priority number = higher precedence

Firewall priority is inverted: the smaller the number, the higher the priority. 990 overrides the implicit 1000 allow, and 980 overrides the 990 deny. Get the ordering backwards and your override never takes effect.

Using egress rules​

PRI: 990Target connector tagPRI: 980Target connector tagDestination CIDR range
Egress rules apply at the connector. A higher-priority deny (990) stops the connector sending traffic; a lower number (980) re-allows egress to one destination CIDR range.
FactsEgress rule layering
  • Restrict a connector's outgoing traffic with egress rules on the connector in the VPC.
  • Deny first: create an egress rule targeting the connector tag to stop it from sending outgoing traffic.
  • Then allow to a destination: create another egress rule with a lower priority number, setting the destination range to the CIDR range of the resource you want the connector to reach.

Connecting to a Shared VPC network​

Cloud Run functions can connect directly to a Shared VPC network with Serverless VPC Access, reaching Compute Engine VMs and any other internal-IP resource in the shared network. A connector can live in one of two places:

  • One connector per service project - in each service project whose functions need access to the network.
  • One shared connector in the host project - reused across service projects.
NumbersConfiguring Serverless VPC Access for a Shared VPC
  1. Enable the Serverless VPC Access API.
  2. Create a connector in each service project or in the host project.
  3. Configure the connector and its subnet.
  4. Perform additional configuration depending on whether the connector is in the host or a service project (below).
  5. Configure your functions to use the connector to send traffic to the VPC network.

Connector in the host project​

StepsHost-project connector setup
  • Enable the Cloud Functions API for the service project - required to add IAM roles and for the service project to use Cloud Run functions.
  • Grant Serverless VPC Access User to the service project's Cloud Functions Service Agent on the host project - provides access to the connector.
  • Make it discoverable: grant Serverless VPC Access Viewer on the host project and Compute Network Viewer on the service project.

Connector in a service project​

FactsService-project connector setup
  • Create firewall rules to allow requests from NAT and health-check IP ranges to reach and be reached by the connector - these ranges are used by the Google infrastructure underlying Cloud Run functions.
  • Optionally limit the firewall rule scope to specific target resources in the network.
  • Grant Compute Network User in the host project to the service project's cloudservices and vpcaccess service accounts - required for each service project that uses the connector.

Host project vs service project​

Connector in each service projectIsolationEach connector has dedicated bandwidth, unaffectedby connectors in other service projects.ChargebacksCharges from a connector are billed to the serviceproject that contains it.SecurityLimit the access scope of services with firewallrules (principle of least privilege).Team independenceSeparate teams create and manage the connectors intheir own service project.Connector in the host projectCentralized network managementManage network resources centrally in the hostproject.IP address spacePreserves IP space, since each connector instancerequires an IP address.MaintenanceLess maintenance; one connector can serve multipleservices across service projects.Idle time and costFewer connectors can reduce connector idle time andcost when not serving traffic.
Two placements for a Shared VPC connector, with the advantages of each. Choose per-service-project for isolation and chargebacks; the host project for fewer connectors and central management.
DECISIONWhere should the Shared VPC connector live?
Isolate bandwidth and bill each team separately→Connector in each service project
Let separate teams own and manage their connector→Connector in each service project
Minimize connector count, IP use, and idle cost→Shared connector in the host project
Manage network resources centrally→Shared connector in the host project
Pick this when: per-service = isolation, chargebacks, team autonomy; host = fewer connectors, centralized management, less IP use and idle cost
0%0 of 147 pages studied