gcp
The global external load balancer is the piece of Google Cloud that makes multi-region failover feel easy. You point one anycast IP at backends in several regions, add health checks, and traffic finds the nearest healthy region on its own. That is genuinely powerful, and it comes with one honest caveat worth stating up front: the load balancer is itself a global dependency, so it can protect you from a region failing and still be the thing that fails globally. This guide covers both sides.
How the global load balancer routes traffic
The global external Application Load Balancer presents a single anycast IP address that is announced from Google's edge worldwide. When a client connects, they reach the nearest Google point of presence, and from there the request is routed to the nearest healthy backend that has capacity. Because the IP is anycast, you do not use DNS to steer traffic between regions; the routing happens inside Google's network on every request. That is what makes failover automatic and invisible to clients.
Backends can be Cloud Run services, GKE clusters, or managed instance groups. The load balancer groups them into backend services, and each backend service carries the health check and capacity settings that decide where traffic goes.
Health checks are the whole game
Failover is only as good as the health checks that trigger it. A health check probes each backend on a schedule and marks it healthy or unhealthy based on the response. The settings that matter:
- Check interval. How often the probe runs. Shorter means faster detection and more probe traffic.
- Unhealthy threshold. How many consecutive failures before a backend is pulled. Lower is faster but more prone to flapping on brief blips.
- Healthy threshold. How many consecutive successes before a recovered backend is added back.
- Timeout. How long to wait for a response before counting the probe as failed.
Point the health check at an endpoint that actually reflects your service's health, not just a static
200 OK. A /readyz route that checks a database connection and a downstream dependency tells the
truth; a route that returns 200 no matter what will happily keep sending traffic to a broken region.
Configuring cross-region failover
The building blocks fit together like this:
| Component | Role in failover |
|---|---|
| Global anycast IP | One entry point for all regions |
| Backend service | Groups backends, holds health check and capacity settings |
| Backends in 2+ regions | Provide the healthy destination when one region fails |
| Health checks | Detect an unhealthy region and stop routing to it |
| Capacity scaler | Controls how much load each backend accepts before overflow |
For an active-active setup, run comparable capacity in each region and let the load balancer balance by proximity, with overflow to other regions when one is saturated. For warm standby, keep the second region scaled down and let health-check-driven overflow carry traffic there when the primary fails. Either way, the failover path only exists because the backends already exist in more than one region, which ties directly back to the multi-region architecture guide.
The load balancer is a global dependency
Here is the part teams miss. The global load balancer has no "other region" because it is the global layer. When it degrades, it degrades for everyone, as the November 2021 GCLB outage demonstrated for customers who were otherwise well spread out. You cannot fail over from your failover mechanism, so you build resilience around it instead:
- Client retries with backoff and jitter ride out transient errors during a global blip.
- Graceful degradation keeps a read-only or cached experience alive when the load balancer returns errors, rather than showing a blank failure.
- Independent monitoring tells you the load balancer itself is the problem, so you stop chasing your backends. See the observability guide for how to set that up.
Test it like you mean it
A failover design you have never exercised is a guess. Run a game day: take one region's backends offline, watch the health checks flip, and time how long until traffic fully shifts. Confirm the shift back is clean when the region recovers, and confirm no client-visible errors leaked during the window.
For broader context, the wider strategy lives in surviving Google Cloud outages, and you can watch the live GCP incident feed or size historical risk at clouddowntime.com/data. If a load balancer outage breaches Google's SLA, cloudslacredit.com covers credit recovery and Next Signal can file the claim for you automatically.