Cloud Run services are deployed to a single region by default, but you can make them globally accessible with a multi-region load balancer.
Here’s a Cloud Run service deployed in us-central1 that we’ll make globally accessible.
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
name: my-global-app
namespace: default
spec:
template:
spec:
containers:
- image: us-docker.pkg.dev/cloudrun/container/hello
This service, my-global-app, is running in us-central1. If you access it directly, requests will always go to that region. To achieve global access, we need to set up a Global External HTTP(S) Load Balancer. This involves creating a Backend Service that points to our Cloud Run service, a URL Map to route traffic, a Target Proxy to terminate SSL, and a Global Forwarding Rule to tie it all together with an IP address.
The core of this setup is the Backend Service. We’ll configure it to use a "Serverless network endpoint group" (Serverless NEG) that specifically targets our Cloud Run service.
gcloud compute network-endpoint-groups create cloudrun-neg \
--region=us-central1 \
--network-endpoint-type=SERVERLESS \
--cloud-run-service=my-global-app
This command creates a Serverless NEG in us-central1 that acts as a pointer to our my-global-app Cloud Run service. The load balancer will use this NEG to know where to send traffic.
Next, we create a Global Backend Service that uses this Serverless NEG.
gcloud compute backend-services create cloudrun-backend \
--global \
--load-balancing-scheme=EXTERNAL_MANAGED \
--enable-cdn
And then add the Serverless NEG to it.
gcloud compute backend-services add-backend cloudrun-backend \
--global \
--network-endpoint-group=cloudrun-neg \
--network-endpoint-group-region=us-central1
The --enable-cdn flag is optional but highly recommended for improving performance by caching static content closer to users.
Now, we need to route traffic. We create a URL Map to define how requests are routed to backend services. For a simple setup, all requests go to our cloudrun-backend.
gcloud compute url-maps create cloudrun-url-map \
--default-service=cloudrun-backend
This URL map will be used by the Target Proxy. To handle HTTPS, we need an SSL certificate. You can use a Google-managed certificate for simplicity.
gcloud compute ssl-certificates create my-ssl-cert \
--domains=your-domain.com
Replace your-domain.com with your actual domain. Google will provision and manage this certificate.
With the SSL certificate ready, we create a Target HTTPS Proxy.
gcloud compute target-https-proxies create https-proxy \
--ssl-certificates=my-ssl-cert \
--url-map=cloudrun-url-map
Finally, we create a Global Forwarding Rule that associates a public IP address with the target proxy. This is the IP address users will use to access your globally distributed service.
gcloud compute addresses create global-ip --global
gcloud compute forwarding-rules create https-forwarding-rule \
--address=$(gcloud compute addresses describe global-ip --global --format='value(address)') \
--global \
--target-https-proxy=https-proxy \
--ports=443
After these steps, you’ll have a global IP address. When users access https://your-domain.com, the load balancer will receive the request, terminate SSL, and then intelligently route the traffic to the closest healthy instance of your Cloud Run service. If the closest region is unhealthy, it will automatically failover to the next closest region.
The most surprising thing about this setup is how the load balancer doesn’t actually "know" about other regions’ Cloud Run services directly. Instead, it relies on the Serverless NEG pointing to a specific region’s Cloud Run service, and it’s the load balancer’s global presence and health checking that provide the multi-region availability. If you were to deploy the same Cloud Run service in another region, say europe-west1, and create a separate Serverless NEG and add it to the same backend service, the load balancer would then automatically consider both regions.
You’ll now need to configure your DNS A record for your-domain.com to point to the global IP address assigned to the forwarding rule.