Serve traffic from multiple regions

Stay organized with collections Save and categorize content based on your preferences.

To return faster responses to your users around the world, you need to deploy services in multiple regions and route your users to the nearest region.

Because Cloud Run services are deployed into individual regions, you need to configure external HTTP(S) Load Balancing to route your users to different regions of your service.

This guide shows you how to configure external HTTP(S) Load Balancing with a domain secured with a managed TLS certificate pointing to a global anycast IP address, which routes users to the nearest Google data center that has your service deployed.

Create a load balancer

Creating an external load balancer involves creating various networking resources and connecting them together:

Command line

  1. Reserve a static IP address so you don't have to update your DNS records when you recreate your load balancer.
    gcloud compute addresses create --global SERVICE_IP
    In the command above, replace SERVICE_IP with a name for the IP address 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.
    gcloud compute backend-services create --global BACKEND_NAME

    In the command above, replace BACKEND_NAME with a name you want to give to the backend service (e.g. myservice-backend).

  3. Create a URL map.
    gcloud compute url-maps create URLMAP_NAME --default-service=BACKEND_NAME

    Replace URLMAP_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 HTTPS traffic. (Replace example.com with your domain name.)
    gcloud compute ssl-certificates create CERT_NAME \
      --domains=example.com

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

  5. Create a target HTTPS proxy.
    gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
      --ssl-certificates=CERT_NAME \
      --url-map=URLMAP_NAME

    Replace HTTPS_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 created to the IP address.
    gcloud compute forwarding-rules create --global FORWARDING_RULE_NAME \
      --target-https-proxy=HTTPS_PROXY_NAME \
      --address=SERVICE_IP \
      --ports=443

    Replace FORWARDING_RULE_NAME with the name of the forwarding rule resource you want to create (e.g. myservice-lb).

Terraform

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

Add the following to your terraform file (for example main.tf):

  1. Configure the IP address:

    resource "google_compute_global_address" "lb_default" {
      provider = google-beta
      name     = "myservice-service-ip"
    
      # Use an explicit depends_on clause to wait until API is enabled
      depends_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 be myservice-service-ip. You can change this to your own value. 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 and configure the backend service:

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

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

  3. Configure the url map:

    resource "google_compute_url_map" "lb_default" {
      provider        = google-beta
      name            = "myservice-lb-urlmap"
      default_service = google_compute_backend_service.lb_default.id
    
      path_matcher {
        name            = "allpaths"
        default_service = google_compute_backend_service.lb_default.id
        route_rules {
          priority = 1
          url_redirect {
            https_redirect         = true
            redirect_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:

    1. Replace example.com with your domain name:

      variable "domain_name" {
        type    = string
        default = "example.com"
      }
      
      variable "run_regions" {
        type    = list(string)
        default = ["us-central1", "europe-west1"]
      }
    2. Add your domain name to a new google_compute_managed_ssl_certificate resource:

      resource "google_compute_managed_ssl_certificate" "lb_default" {
        provider = google-beta
        name     = "myservice-ssl-cert"
      
        managed {
          domains = [var.domain_name]
        }
      }
  5. Configure the HTTPS proxy:

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

    Creates google_compute_target_https_proxy resource with target name myservice-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-beta
      name                  = "myservice-lb-fr"
      load_balancing_scheme = "EXTERNAL_MANAGED"
      target                = google_compute_target_https_proxy.lb_default.id
      ip_address            = google_compute_global_address.lb_default.id
      port_range            = "443"
      depends_on            = [google_compute_target_https_proxy.lb_default]
    }

    Creates google_compute_global_forwarding_rule resource with target name myservice-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 following steps:

    1. Launch Cloud Shell.
    2. Set the Google Cloud project where you want to apply the Terraform configuration:
      export GOOGLE_CLOUD_PROJECT=PROJECT_ID
      
    3. Create a directory and open a new file in that directory. The filename must have the .tf extension, for example main.tf:
      mkdir DIRECTORY && cd DIRECTORY && nano main.tf
      
    4. Copy the sample into main.tf.
    5. Review and modify the sample parameters to apply to your environment.
    6. Save your changes by pressing Ctrl-x and then y.
    7. Initialize Terraform:
      terraform init
    8. 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.

    9. Apply the Terraform configuration by running the following command and entering yes at the prompt:
      terraform apply

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

    10. 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.

Deploy to multiple regions

Deploy your Service to available Cloud Run regions. For ease of management, you can use the same service name across multiple regions.

Command line

  1. Choose regions where you want to make your service available.
  2. Deploy your Cloud Run service to individual regions.
  3. gcloud run deploy SERVICE_NAME \
    --allow-unauthenticated \
    --image=IMAGE_URL \
    --region=REGION

    Replace the following variables:

    • REGION with one of the regions you want to deploy to.
    • SERVICE_NAME with the name of your service. Using the same service name across multiple region makes it easier to keep track of your multi-region deployments.
    • IMAGE_URL with a reference to the container image, for example, us-docker.pkg.dev/cloudrun/container/hello:latest
  4. Repeat the previous step for each region.

Terraform

Configures a service for each region specified in run_regions variable.

resource "google_cloud_run_service" "run_default" {
  provider = google-beta
  count    = length(var.run_regions)
  name     = "myservice-run-app-${var.run_regions[count.index]}"
  location = var.run_regions[count.index]

  template {
    spec {
      containers {
        image = "us-docker.pkg.dev/cloudrun/container/hello"
      }
    }
  }

  traffic {
    percent         = 100
    latest_revision = true
  }

  # Use an explicit depends_on clause to wait until API is enabled
  depends_on = [
    google_project_service.run_api
  ]
}

Loops through all regions specified in run_regions variable and names each new service like so: myservice-run-app-${var.run_regions[count.index]}. Defining service location is similarly applied. Replace default image us-docker.pkg.dev/cloudrun/container/hello" with your own image.

Cloud Run locations

Cloud Run is regional, which means the infrastructure that runs your Cloud Run services is located in a specific region and is managed by Google to be redundantly available across all the zones within that region.

Meeting your latency, availability, or durability requirements are primary factors for selecting the region where your Cloud Run services are run. You can generally select the region nearest to your users but you should consider the location of the other Google Cloud products that are used by your Cloud Run service. Using Google Cloud products together across multiple locations can affect your service's latency as well as cost.

Cloud Run is available in the following regions:

Subject to Tier 1 pricing

  • asia-east1 (Taiwan)
  • asia-northeast1 (Tokyo)
  • asia-northeast2 (Osaka)
  • europe-north1 (Finland) leaf icon Low CO2
  • europe-southwest1 (Madrid) leaf icon Low CO2
  • europe-west1 (Belgium) leaf icon Low CO2
  • europe-west4 (Netherlands)
  • europe-west8 (Milan)
  • europe-west9 (Paris) leaf icon Low CO2
  • me-west1 (Tel Aviv)
  • us-central1 (Iowa) leaf icon Low CO2
  • us-east1 (South Carolina)
  • us-east4 (Northern Virginia)
  • us-east5 (Columbus)
  • us-south1 (Dallas)
  • us-west1 (Oregon) leaf icon Low CO2

Subject to Tier 2 pricing

  • asia-east2 (Hong Kong)
  • asia-northeast3 (Seoul, South Korea)
  • asia-southeast1 (Singapore)
  • asia-southeast2 (Jakarta)
  • asia-south1 (Mumbai, India)
  • asia-south2 (Delhi, India)
  • australia-southeast1 (Sydney)
  • australia-southeast2 (Melbourne)
  • europe-central2 (Warsaw, Poland)
  • europe-west2 (London, UK)
  • europe-west3 (Frankfurt, Germany)
  • europe-west6 (Zurich, Switzerland) leaf icon Low CO2
  • northamerica-northeast1 (Montreal) leaf icon Low CO2
  • northamerica-northeast2 (Toronto) leaf icon Low CO2
  • southamerica-east1 (Sao Paulo, Brazil) leaf icon Low CO2
  • southamerica-west1 (Santiago, Chile)
  • us-west2 (Los Angeles)
  • us-west3 (Salt Lake City)
  • us-west4 (Las Vegas)

If you already created a Cloud Run service, you can view the region in the Cloud Run dashboard in the Google Cloud console.

Configure regional backends

For each region you deployed to in the previous step, you need to create serverless network endpoint groups (NEGs) and add them to the backend service, using the following instructions:

Command line

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

    gcloud compute network-endpoint-groups create NEG_NAME \
                --region=REGION \
                --network-endpoint-type=SERVERLESS \
                --cloud-run-service=SERVICE_NAME

    In the command above, replace:

    • NEG_NAME with the name of the network endpoint group resource. (e.g. `myservice-neg-uscentral1`)
    • REGION with the [region][loc] your service is deployed in.
    • SERVICE_NAME with the name of your service.
  2. Add the network endpoint group to the backend service:

    gcloud compute backend-services add-backend --global BACKEND_NAME \
              --network-endpoint-group-region=REGION \
              --network-endpoint-group=NEG_NAME

    Specify the NEG_NAME you have created in the previous step for the region.

  3. Repeat the steps above for each region.

Terraform

  1. Configure a network endpoint group with name myservice-neg for the Cloud Run service for each region specified in run_regions variable:

    resource "google_compute_region_network_endpoint_group" "lb_default" {
      provider              = google-beta
      count                 = length(var.run_regions)
      name                  = "myservice-neg"
      network_endpoint_type = "SERVERLESS"
      region                = var.run_regions[count.index]
      cloud_run {
        service = google_cloud_run_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-beta
      name                  = "myservice-backend"
      load_balancing_scheme = "EXTERNAL_MANAGED"
    
      backend {
        balancing_mode  = "UTILIZATION"
        capacity_scaler = 0.85
        group           = google_compute_region_network_endpoint_group.lb_default[0].id
      }
    
      backend {
        balancing_mode  = "UTILIZATION"
        capacity_scaler = 0.85
        group           = google_compute_region_network_endpoint_group.lb_default[1].id
      }
    
      # Use an explicit depends_on clause to wait until API is enabled
      depends_on = [
        google_project_service.compute_api,
      ]
    }

Configure DNS records on your domain

To point your domain name to the forwarding rule you created, you need to update its DNS records with the IP address you created.

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

      gcloud compute addresses describe --global SERVICE_IP --format='value(address)'

    Replace SERVICE_IP with the name of the IP address you created previously. This command will print the IP address to the output.

  2. Update your domain's DNS records by adding an A record with this IP address.

Wait for load balancer to provision

After configuring the domain with the load balancer IP address, you need to wait a while for DNS records to propagate. Similarly you need to wait a while for the managed TLS certificate to be issued for your domain and become ready to start serving HTTPS traffic globally.

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

Once it's ready, visit your website's URL with https:// prefix to try it out.

Verify status

  1. To check the status of your DNS record propagation, using the dig command-line utility:

    dig A +short example.com

    The output should show the IP address you configured in your DNS records.

  2. Check the status of your managed certificate issuance, run:

    gcloud compute ssl-certificates describe CERT_NAME

    Replace CERT_NAME with the name you have previously chosen for the SSL certificate resource.

    The output should show a line containing status: ACTIVE.

Set up HTTP-to-HTTPS redirect

By default, a forwarding rule only handles a single protocol and therefore requests to your http:// endpoints will respond with 404 Not Found. If you need requests to your http:// URLs to be redirected to the https:// protocol, you need to create an additional URL map and a forwarding rule, using the following instructions:

Command line

  1. Create a URL map with a redirect rule.

    gcloud compute url-maps import HTTP_URLMAP_NAME \
              --global \
              --source /dev/stdin <<EOF
            name: HTTP_URLMAP_NAME
            defaultUrlRedirect:
              redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
              httpsRedirect: True
            EOF

    Replace the HTTP_URLMAP_NAME with the name of the URL map resource you will create (e.g. myservice-httpredirect).

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

    gcloud compute target-http-proxies create HTTP_PROXY_NAME \
              --url-map=HTTP_URLMAP_NAME

    Replace HTTP_PROXY_NAME with the name of the target HTTP proxy you will create (e.g. myservice-http).

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

    gcloud compute forwarding-rules create --global HTTP_FORWARDING_RULE_NAME \
              --target-http-proxy=HTTP_PROXY_NAME \
              --address=SERVICE_IP \
              --ports=80 \
            

    Replace HTTP_FORWARDING_RULE_NAME with the name of the new forwarding rule you will create (e.g. myservice-httplb).

Terraform

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

    resource "google_compute_url_map" "https_default" {
      provider = google-beta
      name     = "myservice-https-urlmap"
    
      default_url_redirect {
        redirect_response_code = "MOVED_PERMANENTLY_DEFAULT"
        https_redirect         = true
        strip_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-beta
      name     = "myservice-http-proxy"
      url_map  = google_compute_url_map.https_default.id
    
      depends_on = [
        google_compute_url_map.https_default
      ]
    }
  3. Create a forwarding rule on port 80 with the same reserved IP address resource (myservice-http-proxy):

    resource "google_compute_global_forwarding_rule" "https_default" {
      provider   = google-beta
      name       = "myservice-https-fr"
      target     = google_compute_target_http_proxy.https_default.id
      ip_address = google_compute_global_address.lb_default.id
      port_range = "80"
      depends_on = [google_compute_target_http_proxy.https_default]
    }

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

A Pub/Sub service by default delivers messages to push endpoints in the same Google Cloud region where the Pub/Sub service stores the messages. For a workaround to this behavior, refer to Using an authenticated Pub/Sub push subscription with a multi-region Cloud Rundeployment.