Migrate Shared VPC connector to Direct VPC egress

This page is for networking specialists who want to migrate Shared VPC network traffic from using Serverless VPC Access connectors to using Direct VPC egress when sending traffic to a Shared VPC network.

Direct VPC egress is faster and can handle more traffic than connectors, delivering lower latency and higher throughput because it uses a new, direct network path instead of connector instances.

Before migration, we recommend that you familiarize yourself with Direct VPC egress prerequisites, limitations, IP address allocation, and IAM permissions.

Migrate services to Direct VPC egress

Important: Connectors continue to incur charges even if they have no traffic and are disconnected. For details, see pricing. If you no longer need your connector, be sure to delete it to avoid continued billing.

Migrate services to Direct VPC egress gradually

When you migrate Cloud Run services from Serverless VPC Access connectors to Direct VPC egress, we recommend that you do so in a gradual transition.

To transition gradually:

1. Follow the instructions in this guide to to update your service or job to use Direct VPC egress.
2. Split a small percentage of traffic to test that the traffic works correctly.
3. Update the traffic split to send all traffic to the new revision using Direct VPC egress.

To migrate traffic with Direct VPC egress for a service, use the Google Cloud console or Google Cloud CLI:

Console

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

   Go to Cloud Run

2. Click the service that you want to migrate from a connector to Direct VPC egress, then click Edit and deploy new revision.

3. Click the Networking tab.

4. From Connect to a VPC for outbound traffic, click Send traffic directly to a VPC.

5. Select Networks shared with me.

6. In the Network field, select the Shared VPC network that you want to send traffic to.

7. In the Subnet field, select the subnet where your service receives IP addresses from. You can deploy multiple services on the same subnet.

8. Optional: Enter the names of the network tags that you want to associate with your service or services. Network tags are specified at the revision-level. Each service revision can have different network tags, such as network-tag-2.

9. For Traffic routing, select one of the following:

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

10. Click Deploy.

11. To verify that your service is on your Shared VPC network, click the service, then click the Networking tab. The network and subnet are listed in the VPC card.

    You can now send requests directly from your Cloud Run service to any resource on the Shared VPC network, as allowed by your firewall rules.

gcloud

To migrate a Cloud Run service from a connector to Direct VPC egress using the Google Cloud CLI:

1. Update your service on the shared subnet by specifying the fully qualified resource names for the Shared VPC network and subnet using the following command:

   gcloud beta run services update SERVICE_NAME \
     --clear-network \
     --network projects/HOST_PROJECT_ID/global/networks/VPC_NETWORK \
     --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME \
     --network-tags NETWORK_TAG_NAMES \
     --vpc-egress=EGRESS_SETTING \
     --region REGION \
     --max-instances MAX
     

   Replace the following:

   • SERVICE_NAME: the name of your Cloud Run service.
   • IMAGE_URL: the image URL of the service.
   • HOST_PROJECT_ID: the ID of your Shared VPC project.
   • VPC_NETWORK: the name of your Shared VPC network.
   • REGION: the region for your Cloud Run service, which must match the region of your subnet.
   • SUBNET_NAME: the name of your subnet.
   • Optional: NETWORK_TAG_NAMES with the comma-separated names of the network tags you want to associate with a service. For services, network tags are specified at the revision-level. Each service revision can have different network tags, such as network-tag-2.
   • EGRESS_SETTING with an egress setting value:
     • all-traffic: Sends all outbound traffic through the Shared VPC network.
     • private-ranges-only: Sends only traffic to internal addresses through the Shared VPC network.
   • MAX: the maximum number of instances to use for the Shared VPC network. The maximum number of instances allowed for services is 100.

   For more details and optional arguments, see the gcloud reference.

2. To verify that your service is on your Shared VPC network, run the following command:

   gcloud beta run services describe SERVICE_NAME \
   --region=REGION

   Replace:

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

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

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

You can now send requests from your Cloud Run service to any resource on the Shared VPC network, as allowed by your firewall rules.

Migrate jobs to Direct VPC egress

Important: Connectors continue to incur charges even if they have no traffic and are disconnected. For details, see pricing. If you no longer need your connector, be sure to delete it to avoid continued billing.

You can migrate traffic with Direct VPC egress for a job by using the Google Cloud console or Google Cloud CLI.

Console

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

   Go to Cloud Run

2. Click the job that you want to migrate from a connector to Direct VPC egress, then click Edit.

3. Click the Networking tab.

4. Click Container, Variables & Secrets, Connections, Security to expand the job properties page.

5. Click the Connections tab.

6. From Connect to a VPC for outbound traffic, click Send traffic directly to a VPC.

7. Select Networks shared with me.

8. In the Network field, select the Shared VPC network that you want to send traffic to.

9. In the Subnet field, select the subnet where your job receives IP addresses from. You can deploy multiple jobs on the same subnet.

10. Optional: Enter the names of the network tags that you want to associate with a job. For jobs, network tags are specified at the execution-level. Each job execution can have different network tags, such as network-tag-2.

11. For Traffic routing, select one of the following:

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

12. Click Update.

13. To verify that your job is on your Shared VPC network, click the job, then click the Configuration tab. The network and subnet are listed in the VPC card.

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

gcloud

To migrate a Cloud Run job from a connector to Direct VPC egress using the Google Cloud CLI:

1. Disconnect your job from the Shared VPC network by running the gcloud run jobs update command with the following flag:

   gcloud run jobs update JOB_NAME --region=REGION \
   --clear-network

   Replace the following:

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

2. Update your job on the shared subnet by specifying the fully qualified resource names for the Shared VPC network and subnet using the following command:

   gcloud beta run jobs create JOB_NAME \
     --clear-network \
     --image IMAGE_URL \
     --network projects/HOST_PROJECT_ID/global/networks/VPC_NETWORK \
     --subnet projects/HOST_PROJECT_ID/regions/REGION/subnetworks/SUBNET_NAME \
     --network-tags NETWORK_TAG_NAMES \
     --vpc-egress=EGRESS_SETTING \
     --region REGION \
     --max-instances MAX
     

   Replace the following:

   • JOB_NAME: the name of your Cloud Run job.
   • IMAGE_URL: the image URL of the job.
   • HOST_PROJECT_ID: the ID of your Shared VPC project.
   • VPC_NETWORK: the name of your Shared VPC network.
   • REGION: the region for your Cloud Run job, which must match the region of your subnet.
   • SUBNET_NAME: the name of your subnet.
   • Optional: NETWORK_TAG_NAMES with the comma-separated names of the network tags you want to associate with a job. Each job execution can have different network tags, such as network-tag-2.
   • EGRESS_SETTING with an egress setting value:
     • all-traffic: Sends all outbound traffic through the Shared VPC network.
     • private-ranges-only: Sends only traffic to internal addresses through the Shared VPC network.

   For more details and optional arguments, see the gcloud reference.

3. To verify that your job is on your Shared VPC network, run the following command:

   gcloud beta run jobs describe JOB_NAME \
   --region=REGION

   Replace:

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

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

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

You can now send requests from your Cloud Run job to any resource on the Shared VPC network, as allowed by your firewall rules.