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 CO2
europe-southwest1
(Madrid)Low CO2
europe-west1
(Belgium)Low CO2
europe-west4
(Netherlands)europe-west8
(Milan)europe-west9
(Paris)Low CO2
us-central1
(Iowa)Low CO2
us-east1
(South Carolina)us-east4
(Northern Virginia)us-east5
(Columbus)us-south1
(Dallas)us-west1
(Oregon)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)Low CO2
northamerica-northeast1
(Montreal)Low CO2
northamerica-northeast2
(Toronto)Low CO2
southamerica-east1
(Sao Paulo, Brazil)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 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.
- NEG_NAME with the name of the network endpoint group resource.
(e.g.
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.