This page discusses configuration options for includingCloud Run resources in your private network.

To get the most out of this content, you should have some familiarity with thefollowing concepts:

• Basic networking
• Google CloudVirtual Private Cloud (VPC)networks

To secure network traffic for their services and applications, manyorganizations use a private network on Google Cloud with perimetercontrols to prevent data exfiltration. Your private network might have thefollowing properties:

• You might have a number of resources, such as VMs, sitting on one or moreVPC networks.
• These VMs might belong to many different projects, and they might beconnected together with aShared VPC.
• You might have on-premises workloads or workloads on other cloudsconnected to this environment usingCloud VPNorCloud Interconnect.
• You might have enabled aVPC Service Controls perimeter to reducethe risk of data exfiltration.
• You might have multiple private networks, one for each of severaldifferent environments, such as one for production, one for staging, andone for development.

Unlike VMs, Cloud Run resources are not associated with anyparticular VPC network by default. This page explains how toincorporate Cloud Run resources into your private network.

Serverless networking narrative

To explore a range of common enterprise configurations for public and privatenetworking, read ourServerless networking narrative.

This starting point introduces the following basic-to-advancedCloud Run scenarios:

• Safely deploy a "Hello, World!" app that uses a custom domain
• Develop enterprise applications and microservices
• Access databases and file systems publicly or privately
• Connect with SaaS providers
• Apply security controls

See the list of correspondingTerraform modules.

Receive requests from your private network

Receiving requests from your private network requires configuration based on thefollowing conditions:

• Where the request comes from.
• Whether the Cloud Run resource only allows requests from yourprivate network.

For example,receiving requests from VPC networksmight require different configuration thanreceiving requests from on-premises resources and other clouds.

Receive requests from other Cloud Run resources or App Engine

When yourdestination Cloud Run resource receives traffic fromother Cloud Run resources or App Engine,and it uses the "internal" or "internal and load balancing" ingress setting,the traffic must use the VPC network to be consideredinternal.

To receive requests from other Cloud Run resources or App Engine,perform the following steps:

1. Configure thesource resource to use either Direct VPC egress or aconnector.

2. Make sure traffic to Cloud Run routes through the VPCnetwork by using one of the following options:

   • Configure thesource resource toroute all traffic through theVPC network and enablePrivate Google Accesson the subnet associated with Direct VPC egress or the connector.
   • Set upPrivate Service Connector an internal Application Load Balancer to front your destination Cloud Runresource. With this configuration, you access Cloud Run by usinginternal IP addresses, so requests are routed through the VPCnetwork.
   • Enable Private Google Access on the subnet associated with thesourceresource andconfigure DNSto resolverun.app URLs to theprivate.googleapis.com (199.36.153.8/30)orrestricted.googleapis.com (199.36.153.4/30) ranges. Requests to theseranges are routed through the VPC network.

Receive requests from VPC networks

By default, only resources that have external IP addresses or useCloud NAT can directly access the internet andGoogle Cloud services such as Pub/Sub and Cloud Run.For other resources, there are a few options to enable the traffic path toCloud Run:

• The most direct path is to enablePrivate Google Accesson the subnets that host your resources. When Private Google Access isenabled, resources on the subnets can access your Cloud Runresources at the defaultrun.app URL. Traffic from your VPCnetwork to Cloud Run stays in Google's network. In that case, theIP range for requests sent to the Cloud Run resource is0.0.0.0/32. This means that in request log entries, theremoteIpattribute of theHttpRequest willbe0.0.0.0.
• If you need your Cloud Run resource (together with other GoogleAPIs) to be accessible through an internal IP address in yourVPC network, consider creating aPrivate Service Connect endpointandconfiguring a private DNS zoneforrun.app. With this configuration, resources in the VPCnetwork can access Cloud Run resources at the defaultrun.app URLthrough the Private Service Connect endpoint IP address.
• If you need load balancing capabilities and controls, consider using aninternal Application Load Balancer.With this approach, resources in the VPC network access yourCloud Run resources by using the URL associated with theinternal Application Load Balancer.
• If you want to expose your service to internal clients as a managedservice and be able to control which projects can access it, you can hostit with an internal Application Load Balancer andpublish the service by using Private Service Connect.Projects that need to consume the service can access it by using aPrivate Service Connect endpointor aPrivate Service Connect backend.

Responses are returned by using the same path that the request went through.

Special considerations for Shared VPC

When using theinternal setting with Cloud Runingress controlsto enforce that all traffic must come from your private network,Shared VPC traffic is only recognized as "internal" in the followingsituations:

• The Cloud Run resource is running in the Shared VPC hostproject.

• Shared VPC ingress: the Cloud Run resource is attached to a Shared VPCnetwork. In this scenario, note the following considerations:

  • Only service revisions that have configuredDirect VPC egress or thathave configured aServerless VPC Access connectorto send traffic to the Shared VPC network will also accept trafficfrom that same Shared VPC network.

    Note: We recommend that all active Cloud Run servicerevisions use the same Direct VPC egress or connector configuration tomake sure that all traffic from the Shared VPC network is allowed.

  • Requests use different paths based on the traffic direction. Requests sentfrom Cloud Run to the Shared VPC network are routedby Direct VPC egress or the connector. However, requests sent from theShared VPC network to Cloud Run use the standardingress path.

  • To detach a Cloud Run resource from the Shared VPCnetwork, redeploy without VPC network access, or with theresource configured to send traffic to a different VPCnetwork.

• You are using an internal Application Load Balancer to proxy traffic.

• You have placed the Shared VPC host and all service projectsinside the sameVPC Service Controlsperimeter. To set up VPC Service Controls, seeUsing VPC Service Controls (VPC SC).

Special considerations for other VPC networks outside your project

When using theinternal setting with Cloud Runingress controlsto enforce that all traffic must come from your private network,traffic from other VPC networks outside your project is notrecognized as "internal" except in the following situations:

• VPC Service Controls is configured to allow the traffic withrun.googleapis.comas a restricted service, and Private Google Access is enabled for the source subnet.
• Your Cloud Run resource ispublishedas a managed service by using Private Service Connect (requiresan internal Application Load Balancer), and it isaccessedfrom the other VPC network.

Peering with a VPC network that is outside of your project doesn'tallow traffic to be recognized as "internal."

Receive requests from other Google Cloud services

Requests to Cloud Run from Google Cloud services such asPub/Sub stay within Google's network.

There are a few special considerations if you have configuredCloud Run ingress controls to only allow "internal" traffic:

• Requests from BigQuery, Cloud Scheduler, Cloud Tasks,Dialogflow CX, Eventarc, Pub/Sub,synthetic monitors (including uptime checks),and Workflows in the sameproject or VPC Service Controls perimeter are recognized as "internal."
• Requests from Cloud Run or App Engine that are sentfrom within the same project orVPC Service Controls perimeter all require additional configuration before theyare recognized as "internal." For details, see theReceive requests from other Cloud Run services or App Enginesection.
• If your chosen Google Cloud service is not able to accessCloud Run resources that have ingress set tointernal, notethat many services support authenticating to Cloud Run, such asPub/Sub(supports bothinternal and authentication),API Gateway,andDialogflow CX(supports bothinternal and authentication).Depending on your security needs, it might be sufficient for the destinationCloud Run resource to require authentication instead of"internal" ingress.
• Requests from Google Cloud services not mentioned previously are notrecognized as internal and cannot be received by Cloud Runresources that have ingress set tointernal orinternal-and-cloud-load-balancing.

Receive requests from on-premises resources or other clouds

There are multiple ways to privately receive requests from on-premisesresources and other clouds.

• Basic configuration: To have requests from on-premises resourcesand other clouds traverse your private network, configurePrivate Google Access for on-premises hosts.
• Make the Cloud Run resource accessible through an internal IPaddress: To call Cloud Run resources using an internal IP address,create aPrivate Service Connect endpoint to access Google APIs,configure a private DNS zoneforrun.app, andconfigure your on-premises network to access the endpoint.With this configuration, on-premises hosts can access Cloud Runresources at the defaultrun.app URL through thePrivate Service Connect endpoint IP address.
• With load balancing capabilities: If you need load balancingcapabilities and controls, use aninternal Application Load Balancer.For information about accessing internal Application Load Balancer from on-premises networks,seeUse Cloud VPN and Cloud Interconnect.
• Across administrative boundaries: If you want to expose your service tointernal clients as a managed service and be able to control which projectscan access it, you canpublish the service by using Private Service Connect(requires an internal Application Load Balancer). To access the service from on-premises hosts,create a Private Service Connect endpoint and configure theon-premises network to access the endpoint. For more information, seeAccess endpoints from hybrid networks.Alternatively, you can use aPrivate Service Connect backendwith a load balancer. For information about accessing load balancers fromon-premises networks, see the documentation for the load balancer that you're using--for example,for internal Application Load Balancers, seeUse Cloud VPN and Cloud Interconnect.

Require requests to come from your private network

To prevent incoming traffic (ingress) from external sources, you specify arestrictiveingress setting.The most restrictive ingress setting isinternal. With ingress set tointernal, your service only allows requests from your project,Shared VPC networks your project is attached to, and your VPC Service Controlsperimeter. There are some limitations with this setting depending on where therequests come from. To learn about these limitations and how to navigate them,see the sectionReceive requests from your private network.

You can specify the ingress setting for each Cloud Run resource,or enforce the use of your preferred ingress setting for allCloud Run resources in your organization.

• To specify the ingress setting for each Cloud Run resource: SeeSetting ingress.
• To enforce a particular ingress setting for allCloud Run resources in your project, folder, ororganization: Configure therun.allowedIngress organization policyconstraint. To learn how, seeCustomizing policies for list constraints.

Send requests to your private network

If your Cloud Run resource needs to access a resource on yourprivate network, you configure a path for private requests to your network.The configuration depends on the final destination of the request.

Send requests to your VPC network

To send requests to a VPC network, you must configure Direct VPCegress or a Serverless VPC Access connector.Compare Direct VPC egress and VPC connectors.Reviewpricing to understand costs.

When Direct VPC egress or connectors areconfigured, the following considerations apply by default:

• All DNS queries are sent to the DNS server configured for the VPCnetwork associated with your VPC network egress setup.

• Requests to internal IP addresses are routed to the VPC networkby using either Direct VPC egress or a connector. Requests to publicdestinations continue to be routed directly to the internet, unless youregress setting is configuredotherwise.

With requests routed using Direct VPC egress orconnectors, responses return using the path that the request went through.Requestsfrom your VPC network to Cloud Run are enabledby using other technologies and are not routed through Direct VPC egress orconnectors, and responses to those requests are returned using thesame path. To learn more about sending requests from your VPCnetwork to Cloud Run, seeReceive requests from VPC networks.

Sending requests to a VPC network outside of your project

To send requests to a VPC network outside of your project:

1. For Shared VPC users, seeConnect to a Shared VPCnetwork.
2. For other VPC networks, configure Direct VPC egress or aconnector to connect to a VPC in your project.
   • Peered VPC networks: To send to a VPCthat is peered to a VPC that uses VPCnetwork egress, no additional configuration is required. However, theVMs in the subnet hosting VPC network egress must be ableto reach the target VPC network.
   • Other VPC networks: For VPC networksoutside of your project that are not part of the same Shared VPCenvironment or peered to your project VPC network,configurePrivate Service Connectafter setting up VPC network egress.

Send requests to other Cloud Run resources and Google Cloud services

Requests from one Cloud Run resource to another or to otherGoogle Cloud services stay within Google's internal network and aresubject to VPC Service Controls.

For requests to Cloud Run resources with restrictive ingresssettings, additional configuration is required. SeeReceive requests from other Cloud Run resources or App Engine.

Send requests to on-premises resources and other clouds

To send requests to on-premises resources and other clouds through your privatenetwork, you must do the following:

1. Make sure your VPC network is configured to privately routeyour traffic to the destination, such as through a VPN tunnel.
2. Configure your service tosend requests to your VPC network.
3. Require that all requests go to your VPCnetwork.

Require that all requests go to your VPC network

To require that all requests from your Cloud Run resource go toyour VPC network, specify theall-trafficVPC networkegress setting.You can specify the egress setting for each Cloud Run resourcethat uses VPC network egress, or you can enforce the use of yourpreferred egress setting for all Cloud Run resources in yourproject, folder, or organization.

This is useful in the following situations:

1. You want to set up astatic outbound IP addressfor your Cloud Run resource.
2. You want to apply firewall rules for all egress from aCloud Run resource.
3. You want to send requests to on-premises resources and other cloudsthrough your private network.

If your Cloud Run resource makes requests to final destinationsoutside of your VPC network, requiring that all requests go toyour VPC network increases bandwidth use on configuredServerless VPC Access connectors and might increasecosts accordingly. Connectors automatically scaleout when traffic increases, but don't scale in if traffic decreases. Reviewpricing to understand costs.

• To specify the egress setting for individual Cloud Runresources: seeControl egress service traffic.
• To enforce a particular egress setting for allCloud Run resources in your project, folder, ororganization: configure therun.allowedVPCEgress organization policyconstraint. To learn how, seeCustomizing policies for list constraints.

Additional controls

• Perimeter controls: To reduce the risk of data exfiltration for agroup of resources, place them within a context-aware perimeter usingVPC Service Controls.
  • To understand VPC Service Controls, seeOverview of VPC Service Controls.
  • To get started, see the Cloud Run guideUsing VPC Service Controls (VPC SC).
  • To understand costs, reviewpricing.
• Granular controls: To control access for traffic from a specificresource within your private network, such as a specificCloud Run resource or Compute Engine virtual machine, useservice accounts to control permissions and authentication.
  • To understand service accounts, seeWhat are service accounts?
  • To get started, see the Cloud Runauthentication guides.

What's next

To learn more about delivering low latency and high throughput using a directnetwork path, seeDirect VPC egress with a VPC network.