Direct VPC egress with a VPC network

You can enable your Cloud Run service, job, or worker pool tosend traffic to a VPC network by using Direct VPC egress with noServerless VPC Access connector required.

Before you begin

Limitations

The following limitations apply to Cloud Run services, jobs, andworker pools:

  • You might experience connection establishment delays of a minute or more on instance startup when using Direct VPC egress. We recommend configuring aHTTP startup probe that tests a connection to an egress destination used by the application before the application accepts requests. This egress connectivity test should either implement retries or the startup probe should be set with appropriate period and threshold configurations to act as a retry.
  • Cloud Run supports throughput of up to 1 Gbps per individual instance. Exceeding this amount results in performance throttling.

  • ACloud Run usage quota limits the maximum number of instances you can configure to use Direct VPC egress. The maximum number is configured per Cloud Run revision or job execution. To increase the default limits, seehow to increase quotas.

  • Cloud Run services, jobs, and worker pools might experience connection breaks during networking infrastructure maintenance events. We recommend that you use client libraries that can handle occasional connection resets.

The following items are not supported by Direct VPC egress:

  • VPC Flow Logs doesn't provide the name of the Cloud Run revision.
  • Firewall Rules Logging
  • Packet Mirroring
  • Network Intelligence Center, except Connectivity Tests, forIPv6 subnet ranges.
  • Network tags orservice identity in ingress firewall rules.
  • Firewall rules cannot use Resource Manager tags attached to Cloud Run workloads.
  • Cloud Run jobs that run for more than 1 hour might experience connection breaks. These can occur duringmaintenance events that migrate the job from one machine to another. The container receives aSIGTSTP signal 10 seconds before the event and aSIGCONT signal after the event. After the container receives theSIGCONT signal, retry the connection.

IP address allocation

To place your Cloud Run service, job, or worker pool on a VPCnetwork, specify either a VPC network or a subnet, or both. Ifyou specify only a network, the subnet uses the same name as the network.Cloud Run allocates IP addresses from your subnet.

IP addresses are ephemeral, so don't create policies based on individual IPs.If you need to create a policy based on IPs, such as in firewall rules, you mustuse the IP address range of the entire subnet.

To change the network or subnet that your service, job, or worker pool uses, deploy a new revision or execute a new job task that uses the new network and subnetvalues.

Scale up and scale down

For faster scale up during a traffic surge, Cloud Run reserves IPaddresses in blocks of 16 (28 subnet mask) at a time.See which IP addresses Cloud Run has allocated.To ensure that you have enough IPv4 addresses available for use acrossCloud Run, your subnet's IPv4 address range must be/26 orlarger.

For IP allocation efficiency and ease of management, place multiple resources onthe same subnet. If your IPv4 address space is limited, seeSupported IPv4 ranges for more options.

To delete the subnet, you must first delete or redeploy your Cloud Runservices, jobs, or worker pools to stop using the subnet, and then wait 1-2 hours.

IP address consumption for services and worker pools

At steady state, Cloud Run uses 2 times (2X) as many IP addressesas the number of instances. When a revision scales down, Cloud Runretains its IP addresses for up to 20 minutes. In total, reserve at least 2X thenumber of IP addresses, plus a buffer to account for revision updates.

For example, if you upgrade revisions so thatrevision 1 scales from 100instances down to zero whilerevision 2 scales from zero up to 100,Cloud Run retains therevision 1 IP addresses for up to 20minutes after scaling down. During the 20-minute retention window, you mustreserve at least 400 IP addresses ((100 + 100) * 2).

IP consumption for jobs

For Cloud Run jobs, each task consumes 1 IP address for theduration of its execution plus 7 minutes after it completes. Ensure that yoursubnet is large enough to accommodate all concurrent job task executions, witha minimum reservation/26 subnet required.

For example:

  • A single-task job that runs daily and always completes at least 7 minutesbefore the next execution consumes a maximum of 1 IP address on the subnet.
  • A 10-task job running every 10 minutes, with each task running for 15 minutes,consumes 1 IP address for 22 minutes per task (3 executions consume IP addressesat the same time), as shown in the following example. The job therefore consumes30 IP addresses at steady state.
  • A single-task job that takes 1 minute to run and executes 100 times perminute requires roughly 800 IP addresses depending on the exact time of execution.

Supported IPv4 ranges

Cloud Run supports the following IPv4 ranges for your subnet:

  • RFC 1918
    • 10.0.0.0/8
    • 172.16.0.0/12
    • 192.168.0.0/16
  • RFC 6598
    • 100.64.0.0/10
  • Class E
    • 240.0.0.0/4
Note: Test non-RFC 1918 setups to identify possible compatibility issues withnon-Google Cloud resources or hardware. Learn more aboutcreating subnets with non-RFC 1918 IP ranges.

Set up IAM permissions

Ensure that Cloud Run has access to the VPC network byusing one of the following methods:

  • Cloud Run Service Agent role: By default, theCloud Run service agent has theCloud Run Service Agent role (roles/run.serviceAgent)that contains the necessary permissions.

  • Custom permissions: For more granular control, grant the Cloud Runservice agent with the following additional permissions on the project:

    • compute.networks.get
    • compute.subnetworks.get
    • compute.subnetworks.use on the project or the specific subnet
    • compute.addresses.get
    • compute.addresses.list
    • compute.addresses.create (required only fordual-stack subnets with external IPv6)
    • compute.addresses.delete (required only for dual-stack subnets with external IPv6)
    • compute.addresses.createInternal
    • compute.addresses.deleteInternal
    • compute.regionOperations.get

  • Compute Network User role: If you don't use the defaultCloud Run Service Agent role or the custom permissions, grant theCompute Network User role (roles/compute.networkUser)on the Cloud Run Service Agent service account. Subnets withexternal IPv6 also require theCompute Public IP Admin role (roles/compute.publicIpAdmin).

    For example, to grant the Compute Network User role, run the followingcommand:

    gcloudprojectsadd-iam-policy-bindingPROJECT_ID\--member"serviceAccount:service-PROJECT_NUMBER@serverless-robot-prod.iam.gserviceaccount.com"\--role"roles/compute.networkUser"

    Replace the following:

    • PROJECT_ID: the ID of your project.
    • PROJECT_NUMBER: the project number where youdeploy your Cloud Run service, job, or worker pool.

Deploy a Cloud Run resource

Depending on the Cloud Run resource that you have, see the instructionsin one of the following sections:

Deploy a service

Direct VPC egress allows your Cloud Run service to send trafficto a VPC network without a Serverless VPC Accessconnector. Network costs scale to zero just like the service itself. You canalsoadd network tags directly onCloud Run service revisions for more granular network security, such asapplyingVPC firewall rules.

You can configure Direct VPC egress with a service by using theGoogle Cloud console, Google Cloud CLI, YAML, or Terraform.

Console

  1. Go to Cloud Run

  2. ClickCreate Service if you are configuring anew service you are deploying to. If you are configuring and deploying anexisting service, click the service, then clickEdit and deploy new revision.

  3. If you are configuring a new service, fill out the initial servicesettings page as needed, then clickContainer(s), Volumes, Networking, Security toexpand the service configuration page.

  4. Click theNetworking tab.

  5. ClickConnect to a VPC for outbound traffic.

  6. ClickSend traffic directly to a VPC.

  7. In theNetwork field, select the VPCnetwork that you want to send traffic to.

  8. In theSubnet field, select the subnet where your service receives IPaddresses from. You can deploy multiple services on the same subnet.

  9. Optional: Enter the names of thenetwork tagsthat you want to associate with your service or services. Network tags arespecified at the revision-level. Each service revision can have differentnetwork tags, such asnetwork-tag-2.

  10. ForTraffic routing, select one of the following:

    • Route only requests to private IPs to the VPC to send onlytraffic to internal addresses through the VPC network.
    • Route all traffic to the VPC to send all outbound trafficthrough the VPC network.

  11. ClickCreate orDeploy.

  12. To verify that your service is on your VPC network, clickthe service, then click theNetworking tab. The network and subnetare listed in theVPC card.

    You can now send requests from your Cloud Run service to anyresource on the VPC network, as allowed by your firewallrules.

gcloud

To deploy a Cloud Run service without a connector from the Google Cloud CLI:

  1. Updategcloud components to the latest version:

    gcloudcomponentsupdate

  2. Ensure that the Compute Engine API is enabled for your project:

    gcloud services enable compute.googleapis.com

  3. Deploy your Cloud Run service with the following command:

    gcloudrundeploySERVICE_NAME\--image=IMAGE_URL\--network=NETWORK\--subnet=SUBNET\--network-tags=NETWORK_TAG_NAMES\--vpc-egress=EGRESS_SETTING\--region=REGION

    Replace:

    • SERVICE_NAME with the name of your Cloud Runservice.
    • IMAGE_URL: a reference to the container image, forexample,us-docker.pkg.dev/cloudrun/container/hello:latest. If you use Artifact Registry,therepositoryREPO_NAME mustalready be created. The URL follows the format ofLOCATION-docker.pkg.dev/PROJECT_ID/REPO_NAME/PATH:TAG
    • Optional:NETWORK with the name of your VPCnetwork. Specify either a VPC network or a subnet, orboth. If you specify only a network, the subnet uses the same name asthe network.
    • Optional:SUBNET with the name of your subnet. Specify either a VPCnetwork or a subnet, or both. If you specify only a network, the subnet usesthe same name as the network. You can deploy or execute multiple services, jobs,or worker pools on the same subnet.
    • Optional:NETWORK_TAG_NAMES with the comma-separated namesof thenetwork tagsyou want to associate with a service. For services, network tags arespecified at the revision-level. Each service revision can havedifferent network tags, such asnetwork-tag-2.
    • EGRESS_SETTING with anegress setting value:
      • all-traffic: Sends all outbound traffic through the VPCnetwork.
      • private-ranges-only: Sends only traffic to internal addressesthrough the VPC network.
    • REGION with a region for your service.

  4. To verify that your service is on your VPC network, runthe following command:

    gcloudrunservicesdescribeSERVICE_NAME\--region=REGION

    Replace:

    • SERVICE_NAME with the name of your service.
    • REGION with the region for your service that youspecified in the previous step.

    The output should contain the name of your network, subnet, and egresssetting, for example:

    VPC access:  Network:       default  Subnet:        subnet  Egress:        private-ranges-only

You can now send requests from your Cloud Run service to anyresource on the VPC network, as allowed by your firewallrules.

YAML

  1. If you are creating a new service, skip this step.If you are updating an existing service, download itsYAML configuration:

    gcloudrunservicesdescribeSERVICE--formatexport>service.yaml

  2. Update the following attributes:

    apiVersion:serving.knative.dev/v1kind:Servicemetadata:name:SERVICE_NAMElabels:cloud.googleapis.com/location:REGIONspec:template:metadata:annotations:run.googleapis.com/network-interfaces:'[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'run.googleapis.com/vpc-access-egress:EGRESS_SETTINGspec:containers:-image:IMAGE

    Replace:

    • SERVICE_NAME with the name of your Cloud Runservice. Service names must be 49 characters or less and must be uniqueper region and project.
    • REGION with the region for your Cloud Run service,which must match the region of your subnet.
    • Optional:NETWORK with the name of your VPCnetwork. Specify either a VPC network or a subnet, orboth. If you specify only a network, the subnet uses the same name asthe network.
    • Optional:SUBNET with the name of your subnet. Specify either a VPCnetwork or a subnet, or both. If you specify only a network, the subnet usesthe same name as the network. You can deploy or execute multiple services, jobs,or worker pools on the same subnet.
    • Optional:NETWORK_TAG_NAMES with the names of thenetwork tagsyou want to associate with a service. For services, network tags arespecified at the revision-level. Each service revision can havedifferent network tags, such asnetwork-tag-2.
    • EGRESS_SETTING with anegress setting value:
      • all-traffic: Sends all outbound traffic through the VPCnetwork.
      • private-ranges-only: Sends only traffic to internal addressesthrough the VPC network.
    • IMAGE with the URL of your service container image.

    You can alsospecify more configuration,such as environment variables or memory limits.

  3. Create or update the service using the following command:

    gcloudrunservicesreplaceservice.yaml

Terraform

To learn how to apply or remove a Terraform configuration, seeBasic Terraform commands.

  1. Add the following to yourmain.tf file:

    /** * Copyright 2024 Google LLC * * Licensed under the Apache License, Version 2.0 (the "License"); * you may not use this file except in compliance with the License. * You may obtain a copy of the License at * *      http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */# Example configuration of a Cloud Run service with direct VPCresource"google_cloud_run_v2_service""default"{name="cloudrun-service"location="us-central1"deletion_protection=false # set to "true" in productiontemplate{containers{image="us-docker.pkg.dev/cloudrun/container/hello"}vpc_access{network_interfaces{network="default"subnetwork="default"tags=["tag1", "tag2", "tag3"]}}}}
Note: Administrators can restrict the egress settings that developers can selectby setting therun.allowedVPCEgressorganization policy.

Optionally,make your service public if youwant to allow unauthenticated access to the service.

Create a job

Direct VPC egress allows your Cloud Run job to send traffic to aVPC network without a Serverless VPC Accessconnector. You can alsoadd network tagsdirectly on Cloud Run jobs for more granular network security, such asapplyingVPC firewall rules.

You can configure Direct VPC egress with a job by using theGoogle Cloud console, Google Cloud CLI, or YAML.

Console

  1. Go to Cloud Run

  2. If you are configuring a new job, click theJobs tab and fill outthe initial job settings page as needed. If you are configuring anexisting job, click the job, then clickEdit.

  3. ClickContainer, Variables & Secrets, Connections, Security toexpand the job properties page.

  4. Click theConnections tab.

  5. ClickConnect to a VPC for outbound traffic.

  6. ClickSend traffic directly to a VPC.

  7. In theNetwork field, select the VPC network that youwant to send traffic to.

  8. In theSubnet field, select the subnet where your job receives IPaddresses from. You can execute multiple jobs on the same subnet.

  9. ForTraffic routing, select one of the following:

    • Route only requests to private IPs to the VPC to send onlytraffic to internal addresses through the VPC network.
    • Route all traffic to the VPC to send all outbound trafficthrough the VPC network.

  10. Optional: Enter the names of thenetwork tagsthat you want to associate with your service or services. Network tags arespecified at the revision-level. Each service revision can have differentnetwork tags, such asnetwork-tag-2.

  11. Optional: Enter the names of thenetwork tagsthat you want to associate with your job or jobs. For jobs, network tags arespecified at the execution level. Each job execution can have differentnetwork tags, such asnetwork-tag-2.

  12. ClickCreate orUpdate.

  13. To verify that your job is on your VPC network, clickthe job, then click theConfiguration tab. The network and subnet arelisted in theVPC card.

    You can now execute your Cloud Run job and send requests from thejob to any resource on the VPC network, as allowed by yourfirewall rules.

gcloud

To create a Cloud Run job without a connector from the Google Cloud CLI:

  1. Updategcloud components to the latest version:

    gcloudcomponentsupdate

  2. Ensure that the Compute Engine API is enabled for your project:

    gcloud services enable compute.googleapis.com

  3. Create a Cloud Run job with the following command:

    gcloudrunjobscreateJOB_NAME\--image=IMAGE_URL\--network=NETWORK\--subnet=SUBNET\--network-tags=NETWORK_TAG_NAMES\--vpc-egress=EGRESS_SETTING\--region=REGION

    Replace:

    • JOB_NAME with the name of your Cloud Runjob.
    • IMAGE_URL: a reference to thecontainer image—forexample,us-docker.pkg.dev/cloudrun/container/job:latest
    • Optional:NETWORK with the name of your VPCnetwork. Specify either a VPC network or asubnet, or both. If you specify only a network, the subnet uses the samename as the network.
    • Optional:SUBNET with the name of your subnet. Specify either a VPCnetwork or a subnet, or both. If you specify only a network, the subnet usesthe same name as the network. You can deploy or execute multiple services, jobs,or worker pools on the same subnet.
    • Optional:NETWORK_TAG_NAMES with the names of thenetwork tagsyou want to associate with a job. For jobs, network tags are specifiedat the execution-level. Each job execution can have different networktags, such asnetwork-tag-2.
    • EGRESS_SETTING with anegress setting value:
      • all-traffic: Sends all outbound traffic through the VPCnetwork.
      • private-ranges-only: Sends only traffic to internal addressesthrough the VPC network.
    • REGION with a region for your job.

  4. To verify that the job is on your VPC network, run thefollowing command:

    gcloudrunjobsdescribeJOB_NAME\--region=REGION

    Replace:

    • JOB_NAME with the name of your job.
    • REGION with the region for your job that youspecified in the previous step.

    The output should contain the name of your network and subnet, forexample:

    VPC network:  Network:       default  Subnet:        default

You can now execute your Cloud Run job and send requests from thejob to any resource on the VPC network, as allowed by yourfirewall rules.

YAML

  1. If you are creating a new job, skip this step.If you are updating an existing job, download itsYAML configuration:

    gcloudrunjobsdescribeJOB_NAME--formatexport>job.yaml

  2. Update the following attributes:

    apiVersion:run.googleapis.com/v1kind:Jobmetadata:name:JOB_NAMElabels:cloud.googleapis.com/location:REGIONspec:template:metadata:annotations:run.googleapis.com/network-interfaces:'[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'run.googleapis.com/vpc-access-egress:EGRESS_SETTINGspec:containers:-image:IMAGE

    Replace:

    • JOB_NAME with the name of your Cloud Runjob. Job names must be 49 characters or less and must be unique perregion and project.
    • REGION with the region for your Cloud Run job,which must match the region of your subnet.
    • Optional:NETWORK with the name of your VPCnetwork. Specify either a VPC network or a subnet, orboth. If you specify only a network, the subnet uses the same name asthe network.
    • Optional:SUBNET with the name of your subnet. Specify either a VPCnetwork or a subnet, or both. If you specify only a network, the subnet usesthe same name as the network. You can deploy or execute multiple services, jobs,or worker pools on the same subnet.
    • Optional:NETWORK_TAG_NAMES with the names of thenetwork tagsyou want to associate with a job. For jobs, network tags are specifiedat the execution-level. Each job execution can have different networktags, such asnetwork-tag-2.
    • EGRESS_SETTING with anegress setting value:
      • all-traffic: Sends all outbound traffic through the VPCnetwork.
      • private-ranges-only: Sends only traffic to internal addressesthrough the VPC network.
    • IMAGE with the URL of your job container image.

  3. Create or update the job using the following command:

    gcloudrunjobsreplacejob.yaml
Note: Administrators can restrict the egress settings that developers can selectby setting therun.allowedVPCEgressorganization policy.

Deploy a worker pool

Direct VPC egress allows your Cloud Run worker pool to send trafficto a VPC network without a Serverless VPC Accessconnector. Network costs scale to zero just like the worker pool itself. You canalsoadd network tags directly onCloud Run worker pool revisions for more granular network security, such asapplyingVPC firewall rules.

You can configure Direct VPC egress with a worker pool by using theGoogle Cloud CLI.

gcloud

To deploy a Cloud Run worker pool without a connector from the Google Cloud CLI:

  1. Updategcloud components to the latest version:

    gcloudcomponentsupdate

  2. Ensure that the Compute Engine API is enabled for your project:

    gcloud services enable compute.googleapis.com

  3. Deploy your Cloud Run worker pool with the following command:

    gcloudbetarunworker-poolsdeployWORKER_POOL\--image=IMAGE_URL\--network=NETWORK\--subnet=SUBNET\--network-tags=NETWORK_TAG_NAMES\--vpc-egress=EGRESS_SETTING\--region=REGION

    Replace:

    • WORKER_POOL with the name of your Cloud Runworker pool. Worker pool names must be 49 characters or less, use a unique name per region and project, and must not share the same name as an existing service name from your project. If the worker pool does not exist yet, this command creates the worker pool during the deployment. You can omit this parameter entirely, but you will be prompted for the worker pool name if you omit it.
    • IMAGE_URL: a reference to the container image thatcontains the worker pool, such asus-docker.pkg.dev/cloudrun/container/worker-pool:latest
    • Optional:NETWORK with the name of your VPCnetwork. Specify either a VPC network or a subnet, orboth. If you specify only a network, the subnet uses the same name asthe network.
    • Optional:SUBNET with the name of your subnet. Specify either a VPCnetwork or a subnet, or both. If you specify only a network, the subnet usesthe same name as the network. You can deploy or execute multiple services, jobs,or worker pools on the same subnet.
    • Optional:NETWORK_TAG_NAMES with the comma-separated namesof thenetwork tagsyou want to associate with a worker pool. For services, network tags arespecified at the revision-level. Each worker pool revision can havedifferent network tags, such asnetwork-tag-2.
    • EGRESS_SETTING with anegress setting value:
      • all-traffic: Sends all outbound traffic through the VPCnetwork.
      • private-ranges-only: Sends only traffic to internal addressesthrough the VPC network.
    • REGION with a region for your worker pool.

  4. To verify that your worker pool is on your VPC network, runthe following command:

    gcloudbetarunworker-poolsdescribeWORKER_POOL\--region=REGION

    Replace:

    • WORKER_POOL with the name of your worker pool.
    • REGION with the region for your worker pool that youspecified in the previous step.

    The output should contain the name of your network, subnet, and egresssetting, for example:

    VPC access:  Network:       default  Subnet:        subnet  Egress:        private-ranges-only

You can now send requests from your Cloud Run worker pool to anyresource on the VPC network, as allowed by your firewallrules.

YAML

  1. If you are creating a new worker pool, skip this step.If you are updating an existing worker pool, download itsYAML configuration:

    gcloudbetarunworker-poolsdescribeWORKER_POOL--formatexport>workerpool.yaml

  2. Update the following attributes:

    apiVersion:run.googleapis.com/v1kind:WorkerPoolmetadata:name:WORKER_POOLlabels:cloud.googleapis.com/location:REGIONannotations:run.googleapis.com/launch-stage:BETAspec:template:metadata:annotations:run.googleapis.com/network-interfaces:'[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'run.googleapis.com/vpc-access-egress:EGRESS_SETTINGspec:containers:-image:IMAGE_URL

    Replace the following:

    • WORKER_POOL: the name of your Cloud Runworker pool.
    • REGION: the region for your Cloud Run worker pool,which must match the region of your subnet.
    • Optional.NETWORK: the name of your VPCnetwork. Specify either a VPC network or a subnet, orboth. If you specify only a network, the subnet uses the same name asthe network.
    • Optional.SUBNET with the name of your subnet. Specify either a VPCnetwork or a subnet, or both. If you specify only a network, the subnet usesthe same name as the network. You can deploy or execute multiple services, jobs,or worker pools on the same subnet.
    • Optional.NETWORK_TAG_NAMES: the names of thenetwork tagsyou want to associate with the worker pool. For worker pools, networktags are specified at the revision-level. Each worker pool revisioncan have different network tags, such asnetwork-tag-2.
    • EGRESS_SETTING: anegress setting value.
      • all-traffic: Sends all outbound traffic through the VPCnetwork.
      • private-ranges-only: Sends only traffic to internal addressesthrough the VPC network.
    • IMAGE_URL: a reference to the container image thatcontains the worker pool, such asus-docker.pkg.dev/cloudrun/container/worker-pool:latest.

    You can alsospecify more configuration,such as environment variables or memory limits.

  3. Create or update the worker pool using the following command:

    gcloudbetarunworker-poolsreplaceworkerpool.yaml
Note: Administrators can restrict the egress settings that developers can selectby setting therun.allowedVPCEgressorganization policy.

Set up dual-stack services and jobs

To add a dual-stack subnet with an IPv6 range on a Cloud Runresource, seeSet up dual-stack services and jobs.

Restrict access with firewall rules

Restrict access to resources in a VPC network by usingVPC firewall rules. Add these restrictionsby using one of the following strategies:

  • Create an ingress firewall rule that refers to yourservice orjob by using the subnet'sIP range.

  • Create an egress firewall rule that refers to yourservice orjob.

    In the egress firewall rule, refer to your service or job by using the linkedservice accountservice identity,the subnet's IP range, or the associatednetwork tags.

Network tags for egress

Add an additional layer of network security by using network tags in egressfirewall rules.

Console

To associatenetwork tagswith a service or job:

  1. In the Google Cloud console, go to theCloud Run page.

    Go to Cloud Run

  2. Click the service or job you want to associate network tags with, thenclickEdit and deploy new revision for services orEdit for jobs.

  3. Click theNetworking tab for services, or theConnections tabfor jobs.

  4. Ensure that you have selectedConnect to a VPC for outbound trafficandSend traffic directly to a VPC.

  5. In theSubnet field, select the subnet where your service receivesIP addresses from. You can deploy or execute multiple services or jobs onthe same subnet.

  6. In theNetwork tags field, enter the names of thenetwork tagsthat you want to associate with your service or job.

  7. ClickDeploy orUpdate.

For services, every service revision can have a different set of network tagsbecause network tags are specified at the revision level. For jobs, a jobexecution has the same network tags that the job had when the execution of thejob was created.

gcloud

To associatenetwork tagswith a service or job, use thegcloud run deploy command:

gcloudrundeploySERVICE_JOB_NAME\--image=IMAGE_URL\--network=NETWORK\--subnet=SUBNET\--network-tags=NETWORK_TAG_NAMES\--region=REGION

Replace the following:

  • SERVICE_JOB_NAME with the name of your service or job.
  • IMAGE_URL with the image URL of the service or job.
  • NETWORK with the name of your VPC network.
  • SUBNET with the name of your subnet. Specify either a VPCnetwork or a subnet, or both. If you specify only a network, the subnet usesthe same name as the network. You can deploy or execute multiple services, jobs,or worker pools on the same subnet.
  • NETWORK_TAG_NAMES with the name of your network tag or acomma-separated list of network tags.
  • REGION with the name of your region.

For services, every service revision can have a different set of network tagsbecause network tags are specified at the revision level. For jobs, a jobexecution has the same network tags that the job had when the execution of thejob was created.

Disconnect a Cloud Run resource

Depending on the Cloud Run resource that you have, see the instructionsin one of the following sections:

Disconnect a service

Console

  • To remove your service from the VPC network:

    1. Go to Cloud Run

    2. Click the service you want to remove, then clickEdit and deploy new revision.

    3. Click theNetworking tab.

    4. ClearConnect to a VPC for outbound traffic.

    5. ClickDeploy.

    6. To verify that your service is no longer on your VPCnetwork, click theNetworking tab. The network and subnet are nolonger listed in theVPC card.

  • To remove only the network tags while keeping the service connected to theVPC network:

    1. Click the service that contains the network tags you want to remove,then clickEdit and deploy new revision.

    2. Click theNetworking tab.

    3. Clear the names of thenetwork tagsthat you no longer want to associate with your service.

    4. ClickDeploy.

gcloud

  • To remove your service from the VPC network, run thefollowing command:

    gcloudrunservicesupdateSERVICE_NAME--region=REGION\--clear-network

  • To remove only the network tags while keeping the service connected to theVPC network, run the following command:

    gcloudrunservicesupdateSERVICE_NAME--region=REGION\--clear-network-tags

    Replace the following:

    • SERVICE_NAME: the name of your Cloud Runservice.
    • REGION: the region for your Cloud Run service.

YAML

  • To remove your service from the VPC network:

    1. Download the service'sYAML configuration:

      gcloudrunservicesdescribeSERVICE_NAME--formatexport>service.yaml

    2. Remove the following content from yourservice.yaml file:

      run.googleapis.com/network-interfaces:'[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'

      Where

      • NETWORK: the name of your VPC network.
      • SUBNET: the name of your subnet.
      • Optional:NETWORK_TAG_NAMES: the names of the networktags if you had associated them with a service.

    3. Deploy the service revision by running the following command:

      gcloud run services replace service.yaml

  • To remove only the network tags while keeping the service connected to theVPC network:

    1. Download the service'sYAML configuration:

      gcloudrunservicesdescribeSERVICE_NAME--formatexport>service.yaml

    2. Remove thetags variable from the content in yourservice.yamlfile, leaving thenetwork andsubnetwork variables in place, as shownin the following example:

      run.googleapis.com/network-interfaces:'[{"network":"NETWORK","subnetwork":"SUBNET"}]'

      Where

      • NETWORK: the name of your VPC network.
      • SUBNET: the name of your subnet.

    3. Deploy the service revision by running the following command:

      gcloud run services replace service.yaml

Disconnect a job

Console

  • To remove your job from the VPC network:

    1. Go to Cloud Run

    2. Click the job you want to remove, then clickEdit and deploy new revision.

    3. Click theConnections tab.

    4. ClearConnect to a VPC for outbound traffic.

    5. ClickUpdate.

    6. To verify that your job is no longer on your VPCnetwork, click theConfiguration tab. The network and subnet are nolonger listed in theVPC card.

  • To remove only the network tags while keeping the job connected to theVPC network:

    1. Click the job that contains the network tags you want to remove, thenclickEdit and deploy new revision.

    2. Click theConnections tab.

    3. Clear the names of thenetwork tagsthat you no longer want to associate with your job.

    4. ClickUpdate.

gcloud

  • To remove your job from the VPC network, run the followingcommand:

    gcloudrunjobsupdateJOB_NAME--region=REGION\--clear-network

  • To remove only the network tags while keeping the job connected to theVPC network, run the following command:

    gcloudrunjobsupdateJOB_NAME--region=REGION\--clear-network-tags

    Replace the following:

    • JOB_NAME: the name of your Cloud Run job.
    • REGION: the region for your Cloud Run job.

YAML

  • To remove your job from the VPC network:

    1. Download the job'sYAML configuration:

      gcloudrunjobsdescribeJOB_NAME--formatexport>job.yaml

    2. Remove the following content from yourjob.yaml file:

      run.googleapis.com/network-interfaces:'[{"network":"NETWORK","subnetwork":"SUBNET","tags":"NETWORK_TAG_NAMES"}]'

      Replace the following:

      • NETWORK: the name of your VPC network.
      • SUBNET: the name of your subnet.
      • Optional:NETWORK_TAG_NAMES with the names of the networktags if you had associated them with a job.

    3. Update the job by running the following command:

      gcloud run jobs replace job.yaml

  • To remove only the network tags while keeping the job connected to theVPC network:

    1. Download the job'sYAML configuration:

      gcloudrunjobsdescribeJOB_NAME--formatexport>job.yaml

    2. Remove thetags variable from the content in yourjob.yamlfile, leaving thenetwork andsubnetwork variables in place, as shownin the following example:

      run.googleapis.com/network-interfaces:'[{"network":"NETWORK","subnetwork":"SUBNET"}]'

      Replace the following:

      • NETWORK: the name of your VPC network.
      • SUBNET: the name of your subnet.

    3. Update the job by running the following command:

      gcloud run jobs replace job.yaml

Disconnect a worker pool

gcloud

  • To remove your worker pool from the VPC network, run thefollowing command:

    gcloudbetarunworker-poolsupdateWORKER_POOL--region=REGION\--clear-network

  • To remove only the network tags while keeping the worker pool connected to theVPC network, run the following command:

    gcloudbetarunworker-poolsupdateWORKER_POOL--region=REGION\--clear-network-tags

    Replace the following:

    • WORKER_POOL: the name of your Cloud Runworker pool.
    • REGION: the region for your Cloud Run worker pool.

Troubleshooting

Cannot delete subnet

To delete a subnet, you must first delete or redeploy all resources that useit. If Cloud Run is using a subnet, disconnect the Cloud Runservice orjobfrom the VPC network or move it to a different subnet beforedeleting the subnet.

Note: After you delete or move your Cloud Run resources, wait1-2 hours for Cloud Run to release the IP addresses before youdelete the subnet.

Direct VPC egress subnet runs out of IPv4 addresses

The following error occurs when you try to deploy:

Instance failed to start because of insufficient free IP addresses in thesubnetworkSUBNET_ID when attempting to create an address in thesubnetwork. Please consider moving to a subnetwork with more available IPaddresses.

If the subnet of the VPC network runs out of IPv4 addresses, itis logged by Cloud Logging. When this occurs, Cloud Run cannotstart any more service instances or job tasks until more IPv4 addresses becomeavailable.

To resolve this issue, follow theIP address exhaustion strategies.

View allocated IP addresses

To see which IP addresses Cloud Run has allocated, go to theIP addresses page in the Google Cloud consoleor run the following command from the Google Cloud CLI:

gcloudcomputeaddresseslist

Issues with custom MTU

If you experience issues with a custom MTU, ensure that youuse the default MTU setting for Cloud Run.

Except as otherwise noted, the content of this page is licensed under theCreative Commons Attribution 4.0 License, and code samples are licensed under theApache 2.0 License. For details, see theGoogle Developers Site Policies. Java is a registered trademark of Oracle and/or its affiliates.

Last updated 2025-12-15 UTC.