Serve traffic from multiple regions

You return faster responses to your users around the world by deployingservices in multiple regions and routing your users to the nearest region.Deploying across multiple regions delivers low latency and higher availabilityin case of regional outages.

Because Cloud Run services deploy into individual regions,you mustdeploy your service to multiple regionsand thenconfigure global load balancing for the service.

You can automate cross-regional failover usingCloud Run service health.

Before you begin

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.
  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.create permission.Learn how to grant roles.
    Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains theresourcemanager.projects.create permission.Learn how to grant roles.
    Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

    Go to project selector

  5. Verify that billing is enabled for your Google Cloud project.

  6. Set up your Cloud Run development environmentin your Google Cloud project.
  7. Install and initialize the gcloud CLI.
  8. Ensure your account has the following IAM roles:
  9. Grant the roles

    Console

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

      Go to IAM
    2. Select the project.
    3. ClickGrant access.
    4. In theNew principals field, enter your user identifier. This is typically the Google Account email address used to deploy the Cloud Run service.

    5. In theSelect a role list, select a role.
    6. To grant additional roles, clickAdd another role and select each additional role.
    7. ClickSave.

    gcloud

    To grant the required IAM roles to your account on your project:

    gcloudprojectsadd-iam-policy-bindingPROJECT_ID\--member=PRINCIPAL\--role=ROLE

    Replace:

    • PROJECT_NUMBER with your Google Cloud project number.
    • PROJECT_ID with your Google Cloud project ID.
    • PRINCIPAL with the account you are adding the binding for. This is typically the Google Account email address that is used to deploy the Cloud Run service.
    • ROLE with the role you are adding to the deployer account.
  10. Review theCloud Run pricing page. To generate a cost estimate based on your projected usage, use thepricing calculator.
  11. Enable the Artifact Registry, Cloud Build, Cloud Run Admin API, Compute Engine,and Network Services API APIs by running the following command:
  12. gcloudservicesenableartifactregistry.googleapis.com\cloudbuild.googleapis.com\run.googleapis.com\compute.googleapis.com\networkservices.googleapis.com

Deploy the service to multiple regions

Scaling parameters that you configure apply across multiple regions. In amulti-region deployment, for example, the minimum instances value applies foreach of the multiple regions.

You deploy the same service to multiple regions using one of the followingmethods:

Deploy a multi-region service

This section shows you how to deploy and configure a multi-region service froma single gcloud CLI command or using a YAML or Terraform file.

gcloud

  • To create and deploy a multi-region service, run thegcloud run deploy command using the--regions flag:

    gcloudrundeploySERVICE_NAME\--image=IMAGE_URL\--regions=REGIONS

    Replace the following:

    • SERVICE_NAME: The name of the multi-region servicethat you want to deploy.
    • IMAGE_URL: A reference to the container image, forexample,us-docker.pkg.dev/cloudrun/container/hello:latest.
    • REGIONS: The list of multiple regions that youwant to deploy to. For example,europe-west1,asia-east1.

YAML

  1. Create theYAML file for your service, usingtherun.googleapis.com/regions attribute to set the multiple regions thatyou want to deploy your service to:

    apiVersion:serving.knative.dev/v1kind:Servicemetadata:name:SERVICE_NAMEannotations:run.googleapis.com/regions:REGIONSspec:template:spec:containers:-image:IMAGE_URL

    Replace the following:

    • SERVICE_NAME: The name of the multi-regionservice that you want to deploy to.
    • REGIONS: The list of multiple regions that youwant to update. For example,europe-west1,asia-east1.
    • IMAGE_URL: A reference to the container image, forexample,us-docker.pkg.dev/cloudrun/container/hello:latest.
  2. Create the service using the following command:

    gcloudrunmulti-region-servicesreplaceservice.yaml

Terraform

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

Add the following to agoogle_cloud_run_v2_serviceresource in your Terraform configuration.

resource"google_cloud_run_v2_service""default"{name="cloudrun-service-multi-region"regions=["REGION_1","REGION_2",]template{containers{image="us-docker.pkg.dev/cloudrun/container/hello"}}}

Replace"REGION_1" and"REGION_2" with each of the neededGoogle Cloud regions. For example,europe-west1andus-central1.

Update a multi-region service

Note: You cannot modify individual regional services after deployment. They areread-only resources.

This section shows you how to add or remove regions from a multi-region servicefrom a single gcloud CLI command or a YAML file.

gcloud

To add or remove regions from a multi-region service, run thegcloud run multi-region-services update command.

  • To add the multi-region service to an additional region or regions, use the--add-regions flag:

    gcloudrunmulti-region-servicesupdateSERVICE_NAME\--add-regions=REGIONS
  • To remove the multi-region service from a region or regions, use the--remove-regions flag:

    gcloudrunmulti-region-servicesupdateSERVICE_NAME\--remove-regions=REGIONS

    Replace the following:

    • SERVICE_NAME: The name of the multi-region servicethat you want to update.
    • REGIONS: The region or regions that you want toadd your service to or remove your service from. For example,us-central1,asia-east1.

YAML

  1. To update an existing multi-region service, download itsYAML configuration:

    gcloudrunmulti-region-servicesdescribeSERVICE_NAME--formatexport>service.yaml
  2. Update therun.googleapis.com/regions attribute to add or remove the listof regions that you want the service to deploy to:

    apiVersion:serving.knative.dev/v1kind:Servicemetadata:name:SERVICE_NAMEannotations:run.googleapis.com/regions:REGIONS

    Replace the following:

    • SERVICE_NAME: The name of the multi-regionservice that you want to deploy to.
    • REGIONS: The new list of multiple regions thatyou want the service revision to deploy to.
  3. Update the service using the following command:

    gcloudrunmulti-region-servicesreplaceservice.yaml

Delete a multi-region service

Note: You cannot modify individual regional services after deployment. They areread-only resources.
  • To delete a multi-region service, run thegcloud run multi-region-services delete command:

    gcloudrunmulti-region-servicesdeleteSERVICE_NAME

    ReplaceSERVICE_NAME with the name of the multi-region servicethat you want to delete.

Configure a global external Application Load Balancer

This section shows you how to configure aglobal external Application Load Balancerwith a domain secured with a managed TLS certificatepointing to a global anycast IP address, which routes users to the nearestGoogle data center that deploys your service.

The architecture described in the following sections does not automaticallyroute requests to a different region when a regional Cloud Run servicebecomes unresponsive or returns errors.

To increase the availability of your multi-regional service:

Create a global external Application Load Balancer

Creating a global external Application Load Balancer involves creatingvarious networkingresources and connecting themtogether:

gcloud

  1. Reserve a static IP address so you don't have to update your DNS recordswhen you recreate your load balancer.
    gcloudcomputeaddressescreate--globalSERVICE_IP
    In the command above, replaceSERVICE_IP with a name for the IPaddress resource (e.g.myservice-ip).

    This IP address is a global anycast IPv4 address that routes to the Google datacenter or point of presence closest to your visitors.

  2. Create a backend service.
    gcloudcomputebackend-servicescreate\--globalBACKEND_NAME\--load-balancing-scheme=EXTERNAL_MANAGED

    ReplaceBACKEND_NAME with a name you want to give to the backend service. For example,myservice-backend.

  3. Create a URL map.
    gcloudcomputeurl-mapscreateURLMAP_NAME--default-service=BACKEND_NAME

    ReplaceURLMAP_NAME with a name you want to give to the URL map (e.g.myservice-urlmap).

  4. Create a managed TLS certificate for your domain to serve HTTPStraffic. (Replaceexample.com with your domain name.)
    gcloudcomputessl-certificatescreateCERT_NAME\--domains=example.com

    ReplaceCERT_NAME with the name you want the managed SSL certificate to have (e.g.myservice-cert).

  5. Create a target HTTPS proxy.
    gcloudcomputetarget-https-proxiescreateHTTPS_PROXY_NAME\--ssl-certificates=CERT_NAME\--url-map=URLMAP_NAME

    ReplaceHTTPS_PROXY_NAME with the name you want to give to the target HTTPS proxy (e.g.myservice-https).

  6. Create a forwarding rule connecting the networking resources you createdto the IP address.
    gcloudcomputeforwarding-rulescreate--globalFORWARDING_RULE_NAME\--target-https-proxy=HTTPS_PROXY_NAME\--address=SERVICE_IP\--ports=443\--load-balancing-scheme=EXTERNAL_MANAGED

    ReplaceFORWARDING_RULE_NAME with the name of the forwarding rule resource you want to create. For example,myservice-lb.

Terraform

Alternatively to the steps described in this section, you can use theGlobal HTTP Load Balancer Terraform Module.

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

  1. Configure the IP address:

    resource"google_compute_global_address""lb_default"{provider=google-betaname="myservice-service-ip"  # Use an explicit depends_on clause to wait until API is enableddepends_on=[google_project_service.compute_api]}output"load_balancer_ip_addr"{value=google_compute_global_address.lb_default.address}

    Configures your IP address resource name to bemyservice-service-ip. You can change this to your own value. This IP address is a global anycast IPv4 address that routes to the Google data center or point of presence closest to your visitors.

  2. Create and configure the backend service:

    resource"google_compute_backend_service""lb_default"{provider=google-betaname="myservice-backend"load_balancing_scheme="EXTERNAL_MANAGED"backend{group=google_compute_region_network_endpoint_group.lb_default[0].id}backend{group=google_compute_region_network_endpoint_group.lb_default[1].id}  # Use an explicit depends_on clause to wait until API is enableddepends_on=[google_project_service.compute_api,]}

    This resource configures the backend service to be namedmyservice-backend. You can change this to your own value.

  3. Configure the URL map:

    resource"google_compute_url_map""lb_default"{provider=google-betaname="myservice-lb-urlmap"default_service=google_compute_backend_service.lb_default.idpath_matcher{name="allpaths"default_service=google_compute_backend_service.lb_default.idroute_rules{priority=1url_redirect{https_redirect=trueredirect_response_code="MOVED_PERMANENTLY_DEFAULT"}}}}

    Connects the backend service resource (myservice-backend) to the new URL map resource (myservice-lb-urlmap). You can change these to your own values.

  4. Create a managed TLS certificate for your domain to serve HTTPS traffic. Replaceexample.com with your domain name in thegoogle_compute_managed_ssl_certificate resource:

    resource"google_compute_managed_ssl_certificate""lb_default"{provider=google-betaname="myservice-ssl-cert"managed{domains=["example.com"]}}
  5. Configure the HTTPS proxy:

    resource"google_compute_target_https_proxy""lb_default"{provider=google-betaname="myservice-https-proxy"url_map=google_compute_url_map.lb_default.idssl_certificates=[google_compute_managed_ssl_certificate.lb_default.name]depends_on=[google_compute_managed_ssl_certificate.lb_default]}

    Createsgoogle_compute_target_https_proxy resource with target namemyservice-https-proxy and connects previously created TLS certificate (myservice-ssl-cert) and URL mapping resources (myservice-lb-urlmap). You can change these to your own values.

  6. Configure the forwarding rule:

    resource"google_compute_global_forwarding_rule""lb_default"{provider=google-betaname="myservice-lb-fr"load_balancing_scheme="EXTERNAL_MANAGED"target=google_compute_target_https_proxy.lb_default.idip_address=google_compute_global_address.lb_default.idport_range="443"depends_on=[google_compute_target_https_proxy.lb_default]}

    Createsgoogle_compute_global_forwarding_rule resource with target namemyservice-https-proxy and connects previously created HTTPS proxy target (myservice-https-proxy) and IP address resource (myservice-service-ip). You can change these to your own values.

  7. Apply this config:

    To apply your Terraform configuration in a Google Cloud project, complete the steps in the following sections.

    Prepare Cloud Shell

    1. LaunchCloud Shell.
    2. Set the default Google Cloud project where you want to apply your Terraform configurations.

      You only need to run this command once per project, and you can run it in any directory.

      export GOOGLE_CLOUD_PROJECT=PROJECT_ID

      Environment variables are overridden if you set explicit values in the Terraform configuration file.

    Prepare the directory

    Each Terraform configuration file must have its own directory (alsocalled aroot module).

    1. InCloud Shell, create a directory and a new file within that directory. The filename must have the.tf extension—for examplemain.tf. In this tutorial, the file is referred to asmain.tf.
      mkdirDIRECTORY && cdDIRECTORY && touch main.tf
    2. If you are following a tutorial, you can copy the sample code in each section or step.

      Copy the sample code into the newly createdmain.tf.

      Optionally, copy the code from GitHub. This is recommended when the Terraform snippet is part of an end-to-end solution.

    3. Review and modify the sample parameters to apply to your environment.
    4. Save your changes.
    5. Initialize Terraform. You only need to do this once per directory.
      terraform init

      Optionally, to use the latest Google provider version, include the-upgrade option:

      terraform init -upgrade

    Apply the changes

    1. Review the configuration and verify that the resources that Terraform is going to create or update match your expectations:
      terraform plan

      Make corrections to the configuration as necessary.

    2. Apply the Terraform configuration by running the following command and enteringyes at the prompt:
      terraform apply

      Wait until Terraform displays the "Apply complete!" message.

    3. Open your Google Cloud project to view the results. In the Google Cloud console, navigate to your resources in the UI to make sure that Terraform has created or updated them.
    Note: Terraform samples typically assume that the required APIs are enabled in your Google Cloud project.

Configure regional network endpoint groups

For each region you deployed to in the previous step, you must createserverless network endpoint groups (NEGs) and add them to the backendservice using the following instructions:

gcloud CLI

  1. Create a network endpoint group for the Cloud Run service inREGION:

    gcloudcomputenetwork-endpoint-groupscreateNEG_NAME\--region=REGION\--network-endpoint-type=serverless\--cloud-run-service=SERVICE_NAME

    Replace the following:

    • NEG_NAME with the name of the network endpoint group resource. (for example,myservice-neg-uscentral1)
    • REGION with the region your service is deployed in.
    • SERVICE_NAME with the name of your service.
  2. Add the network endpoint group to the backend service:

    gcloudcomputebackend-servicesadd-backend--globalBACKEND_NAME\--network-endpoint-group-region=REGION\--network-endpoint-group=NEG_NAME

    Specify theNEG_NAME you created in the previous step for the region.

  3. Repeat the preceding steps for each region.

Terraform

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

  1. Configure a network endpoint group with namemyservice-neg for the Cloud Run service for each region specified inrun_regions variable:

    resource"google_compute_region_network_endpoint_group""lb_default"{provider=google-betacount=length(local.run_regions)name="myservice-neg"network_endpoint_type="SERVERLESS"region=local.run_regions[count.index]cloud_run{service=google_cloud_run_v2_service.run_default[count.index].name}}
  2. Configure a backend service to attach the network endpoint group (myservice-neg):

    resource"google_compute_backend_service""lb_default"{provider=google-betaname="myservice-backend"load_balancing_scheme="EXTERNAL_MANAGED"backend{group=google_compute_region_network_endpoint_group.lb_default[0].id}backend{group=google_compute_region_network_endpoint_group.lb_default[1].id}  # Use an explicit depends_on clause to wait until API is enableddepends_on=[google_project_service.compute_api,]}

Configure DNS records on your domain

To point your domain name to the forwarding rule you created, updateits DNS records with the IP address that you created.

  1. Find the reserved IP address of the load balancer by running the followingcommand:

    gcloudcomputeaddressesdescribeSERVICE_IP\--global\--format='value(address)'

    ReplaceSERVICE_IP with the name of the IP address you created previously. This command prints the IP address to the output.

  2. Update your domain's DNS records by adding anA record with thisIP address.

Configure custom audience if using authenticated services

Authenticated services areprotected by IAM.Such Cloud Run services require client authentication thatdeclares the intended recipient of a request at credential generation time (theaudience).

Audience is usually the full URL of the target service, which by default for Cloud Runservices is a generated URL ending inrun.app. However, in a multi-region deployment,a client cannot know in advance which regional service a request will be routed to.So, for a multi-region deployment, configure your service to usecustom audiences.

Wait for load balancer to provision

After configuring the domain with the load balancer IP address, waitfor DNS records to propagate. Similarly, wait for themanaged TLS certificate to be issued for your domain and to be ready tostart serving HTTPS traffic globally.

It might take up to 30 minutes for your load balancer to start serving traffic.

After it is ready, visit your website's URL withhttps:// prefix to try it out.

Verify status

  1. To check the status of your DNS record propagation, use thedigcommand-line utility:

    digA+shortexample.com

    The output shows the IP address that you configured in your DNS records.

  2. Check the status of your managed certificate issuance by running the followingcommand:

    gcloudcomputessl-certificatesdescribeCERT_NAME

    ReplaceCERT_NAME with the name you previously chose forthe SSL certificate resource.

    The output shows a line containingstatus: ACTIVE.

Set up HTTP-to-HTTPS redirect

Note: Creating additional forwarding rules are subject to charges. Seeloadbalancer pricing.

By default, a forwarding rule only handles a single protocol and thereforerequests to yourhttp:// endpoints respond with "404 Not Found". If youneed requests to yourhttp:// URLs to redirect to thehttps://protocol, create an additional URL map and a forwarding rule using the following instructions:

gcloud CLI

  1. Create a URL map with a redirect rule.

    gcloudcomputeurl-mapsimportHTTP_URLMAP_NAME\--global\--source/dev/stdin<<EOFname:HTTP_URLMAP_NAMEdefaultUrlRedirect:redirectResponseCode:MOVED_PERMANENTLY_DEFAULThttpsRedirect:TrueEOF

    Replace theHTTP_URLMAP_NAME with the name of the URL map resource you will create (for example,myservice-httpredirect).

  2. Create a target HTTP proxy with the URL map.

    gcloudcomputetarget-http-proxiescreateHTTP_PROXY_NAME\--url-map=HTTP_URLMAP_NAME

    ReplaceHTTP_PROXY_NAME with the name of the target HTTP proxy you will create (for example,myservice-http).

  3. Create a forwarding rule on port80 with the same reserved IP address.

    gcloudcomputeforwarding-rulescreate--globalHTTP_FORWARDING_RULE_NAME\--target-http-proxy=HTTP_PROXY_NAME\--address=SERVICE_IP\--ports=80

    ReplaceHTTP_FORWARDING_RULE_NAME with the name of the new forwarding rule you will create (for example,myservice-httplb).

Terraform

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

  1. Create a URL map resource with a redirect rule:

    resource"google_compute_url_map""https_default"{provider=google-betaname="myservice-https-urlmap"default_url_redirect{redirect_response_code="MOVED_PERMANENTLY_DEFAULT"https_redirect=truestrip_query=false}}
  2. Create a target HTTP proxy with the newly created URL map resource (myservice-https-urlmap):

    resource"google_compute_target_http_proxy""https_default"{provider=google-betaname="myservice-http-proxy"url_map=google_compute_url_map.https_default.iddepends_on=[google_compute_url_map.https_default]}
  3. Create a forwarding rule on port80 with the same reserved IP address resource (myservice-http-proxy):

    resource"google_compute_global_forwarding_rule""https_default"{provider=google-betaname="myservice-https-fr"target=google_compute_target_http_proxy.https_default.idip_address=google_compute_global_address.lb_default.idport_range="80"depends_on=[google_compute_target_http_proxy.https_default]}
Note: Similar to the HTTPS forwarding rule to be created, creating the additionalforwarding rule might take some time. After it is ready, your application isaccessible overhttp:// and redirects tohttps:// URL with a "301 MovedPermanently" status code.

For additional configuration options, seeSet up a global external Application Load Balancer with Cloud Run.

Automate cross-regional failover with Cloud Run service health

Preview — Cloud Run service health

This feature is subject to the "Pre-GA Offerings Terms" in the General Service Terms section of theService Specific Terms. Pre-GA features are available "as is" and might have limited support. For more information, see thelaunch stage descriptions.

Cloud Run service health minimizes service disruptions and automatescross-region failover and failback. Set up a multi-region, high availabilityCloud Run service with automated failover and failbackcapabilities forinternaltraffic.

Limitations

The following limitations apply to Cloud Run service health:

  • You must configure at least one service-level or revision-levelminimum instance per region to calculatehealth. You can also use theContainer instance countmetric in Cloud Monitoring to estimate the required minimum instances foryour regions.
  • Failovers require at least two services from different regions. Otherwise, ifone service fails, the error messageno healthy upstream is displayed.
  • Cloud Run service health doesn't support cross-region internal Application Load Balancerswith more than 5 serverless NEG backends.
  • You can't configure a URL mask or tags in serverless NEGs.
  • You can't enable IAP from a backend service or load balancer.Enable IAP directly from Cloud Run.
  • If a Cloud Run service is deleted, Cloud Rundoesn't report an unhealthy status to the load balancer.
  • Starting a new instance won't count the first readiness probe, so a requestmight briefly route to a newly started service before becoming unhealthy.
  • Cloud Run service health is computed across all instances.Revisions without probes are treated as unknown. The load balancer treatsunknown instances as healthy.

Report regional health status

To aggregate regional Cloud Run service health and report ahealthy or unhealthy status to the load balancer, perform the following steps:

  1. Deploy a Cloud Run service revision in multiple regions withone or moreminimum instances. Run thefollowing command to use the readiness probe that you configured in the previousstep:

    gcloudbetarundeploySERVICE_NAME\--regions=REGION_A,REGION_B\--min=MIN_INSTANCES

    Replace the following:

    • SERVICE_NAME: the name of the service.
    • REGION_A,REGION_B: different regions foryour service revision. For example, setREGION_A tous-central1andREGION_B toeurope-west1.
    • MIN_INSTANCES: the number of container instances to be kept warm,ready to receive requests. You must set the minimum value to 1 or more.
  2. Configure agRPC or HTTP readiness probeset up on each container instance.

  3. Configure across-region internal Application Load Balancerto shift traffic away from unhealthy regions.

  4. Set upServerless NEGsfor each Cloud Run service in each region.

  5. Configure a backend service to connect with serverless NEGs.

Best practices

You can use a combination of readiness probes, traffic splitting, and minimuminstances to perform safe, gradual rollouts. This lets you verify the health ofa new revision in a single "canary" region before promoting it, ensuring thatthe load balancer only sends traffic to healthy regional backends.

Recommended rollout process

You can roll out a service revision on an existing Cloud Runservice that's not using a readiness probe or Cloud Run servicehealth. Follow this process one region at a time to safely deploy a newrevision:

  1. Deploy the new revision in a single "canary" region with a readiness probeconfigured.

  2. Send a small amount of traffic (for example, 1%) to the new revision.

  3. Use non-zero minimum instances at the service level, rather than at therevision level.

  4. Check the readiness probe metric (run.googleapis.com/container/instance_count_with_readiness)to ensure that new instances are healthy.

  5. In incremental steps, increase the traffic percentage to the new revision. As you rampup, monitor the regional Cloud Run service health metric(run.googleapis.com/service_health_count), which is used by the load balancer.Cloud Run service health reportsUNKNOWN until enough traffic isrouted to the new revision.

  6. Once the revision receives 100% of traffic and the regional Cloud Runservice health is stable and healthy, repeat this process for all other regions.

Monitor health checks

After you set up Cloud Run service health, serverless NEGscollect the Cloud Monitoring service health metric. You can view the healthstatus for the existing regional services. The following diagram shows how theseCloud Run service health components respond to requests to yourservice:

Illustration of Cloud Run service health components

If a service in a region is unhealthy, the load balancer diverts trafficfrom the unhealthy region to a healthy region. Traffic recovers after the regionbecomes healthy again.

Use authenticated Pub/Sub push subscriptions with multi-region deployment

A Pub/Sub service by default delivers messages to push endpointsin the same Google Cloud region where the Pub/Sub service stores themessages. For a workaround to this behavior, refer toUsing an authenticated Pub/Sub push subscription with a multi-region Cloud Run deployment.

Configure a manual failover

To manually configure traffic to fail over to a healthy region, modify theglobal external Application Load Balancer URL map.

  1. To update the global external Application Load Balancer URL map, remove the NEG from the backendservice, using the--global flag:

    gcloud compute backend-services remove-backendBACKEND_NAME \--network-endpoint-group=NEG_NAME \--network-endpoint-group-region=REGION \--global

    Replace the following:

    • BACKEND_NAME: The name of the backend service.
    • NEG_NAME: The name of the network endpoint groupresource, for example,myservice-neg-uscentral1.
    • REGION: The region where the NEG was createdand where you want to remove your service from. For example,us-central1,asia-east1.
  2. To confirm that a healthy region is now serving traffic, navigate tohttps://<domain-name>.

What's next

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 2026-02-19 UTC.