Serving traffic from multiple regions

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.

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

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 datacenter that has your service deployed).

Before you start

Install Google Cloud CLI. This guide uses the gcloud command-line tool.
A domain for your application. You can register a domain name from Google Domains.

Creating a load balancer

Creating an external load balancer involves creating various networking resources and connecting them together, as shown in the following instructions.

Command line

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.
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).
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).
Create a managed TLS certificate for your domain to serve HTTPS traffic. (Replace example.com with your domain name.)
```
gcloud beta 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).
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).
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).

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

Choose regions you want to make your service available in.
Deploy your Cloud Run service to individual regions.
```
  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.
Repeat the previous step for each region.

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) Low CO₂
europe-southwest1 (Madrid) Low CO₂
europe-west1 (Belgium) Low CO₂
europe-west4 (Netherlands)
europe-west8 (Milan)
europe-west9 (Paris) Low CO₂
us-central1 (Iowa) Low CO₂
us-east1 (South Carolina)
us-east4 (Northern Virginia)
us-east5 (Columbus)
us-south1 (Dallas)
us-west1 (Oregon) Low CO₂

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) Low CO₂
northamerica-northeast1 (Montreal) Low CO₂
northamerica-northeast2 (Toronto) Low CO₂
southamerica-east1 (Sao Paulo, Brazil) Low CO₂
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 console.

Configuring 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:

Create a network endpoint group for the Cloud Run service in REGION:
```
gcloud beta 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 your service is deployed in.
- SERVICE_NAME with the name of your service.

Add the network endpoint group to the backend service:

gcloud beta 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.

Repeat the steps above for each region.

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

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.
Update your domain's DNS records by adding an A record with this IP address.

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

Verifying status

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.
Check the status of your managed certificate issuance, run:
```
gcloud beta 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.

Setting 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:

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

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

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