Route users to the nearest healthy region with latency-based or geo-based DNS routing backed by health checks, an anycast global load balancer, or a platform that combines deployment and routing behind a global endpoint. How fast traffic moves away from a failed region depends on how quickly health checks detect the failure and how long clients hold onto the old DNS answer. Failover is often slower than expected when nobody has measured the full chain from detection to the last cached client. This guide compares the three methods, works out worst-case failover times from each provider’s documented defaults, and explains how to test the result.
Disclosure: Control Plane publishes this guide.
TL;DR
Three methods route each user to the nearest healthy region automatically:
- Platforms with a built-in global endpoint. A platform like Control Plane deploys one workload definition to multiple locations and routes each user to the nearest location where the workload is healthy, using the workload’s own readiness probes, with no per-service DNS records or external health checks to configure.
- DNS routing with health checks. Amazon Route 53, Azure Traffic Manager, and Google Cloud DNS answer each query with the closest healthy endpoint. Failover time is health check detection plus DNS TTL plus resolver and client caching.
- Anycast global load balancers. AWS Global Accelerator, Google Cloud’s global external Application Load Balancer, and Azure Front Door announce anycast IP addresses from edge locations and forward traffic to healthy backends. Failover avoids DNS caching; with default health checks it ranges from about 10 to 30 seconds (Google Cloud) to about 90 seconds or more (Global Accelerator, and Azure Front Door with Microsoft’s example settings), and tuning brings it lower.
Failover time is detection (health check interval × failure threshold) plus propagation (DNS TTL and caching, near zero for anycast) plus the time long-lived connections take to close. Test by failing a health check on purpose and timing the shift with synthetic probes and with real clients that cache DNS.
How do I route users to the nearest healthy region automatically?
Automatic region routing rests on two building blocks: choosing the nearest region, and removing an unhealthy region from the pool.
Choosing the nearest region can be done by latency or by geography. Latency-based routing uses the provider’s latency measurements between the user’s network (identified by the resolver’s IP, or the client subnet when the resolver sends EDNS Client Subnet) and each region, then returns the lowest-latency region. Geolocation routing maps the user’s IP to a country or subdivision and returns a pre-assigned region. VPNs and mobile carriers can make a geographically close region slower than a distant one, and both methods see the resolver’s location instead of the user’s when the resolver does not send EDNS Client Subnet.
Removing an unhealthy region requires active health checks. The routing system probes each regional endpoint on a schedule. If a probe fails a configured number of times in a row, the region is marked unhealthy and excluded from routing answers. When it passes enough consecutive checks, it is added back.
DNS routing with health checks
DNS routing services answer each query by latency or geolocation policy and stop returning an endpoint’s IP once it fails its health check. Resolvers and clients cache answers for the TTL and sometimes longer, so some clients keep reaching the failed region until their cached answer expires. Weighted, geolocation, and failover policies give fine-grained control over which users reach which region.
Anycast global load balancers
Managed anycast load balancers announce the same anycast IP addresses from many edge locations. BGP delivers each client to a nearby edge, which forwards traffic to the closest healthy backend region. When a region fails its health checks, the edge stops sending it traffic. The anycast IP and BGP announcements stay the same, so failover waits on neither DNS TTL nor BGP convergence. Plain anycast setups that you run yourself fail over by withdrawing a region’s BGP route instead.
Platforms with a built-in global endpoint
Some platforms run one workload definition in multiple regions behind a global endpoint that handles health-aware routing, which removes much of the work of configuring DNS records, health checks, and failover policies separately for each service.
How fast each routing method fails over
Values are defaults and configurable ranges documented on each provider’s own pages. Detection time is roughly the health check interval multiplied by the failure threshold (Traffic Manager marks an endpoint unhealthy only after tolerated failures plus one consecutive failure; Front Door and Cloudflare use sample- and quorum-based rules). Propagation covers DNS TTL plus resolver and client caching for DNS methods, or the time the edge takes to stop sending to a failed backend for anycast methods. Totals are estimates from documented defaults.
| Method | How it picks a region | Health check defaults | Detection time (defaults) | Propagation delay | Worst-case switch time (estimate) | Notes |
|---|---|---|---|---|---|---|
| Amazon Route 53 latency or geolocation routing with health checks | Latency or geolocation DNS policy | 30 s interval × 3 failures (default; threshold 1 to 10); fast checks: 10 s interval | ~90 s (standard); ~30 s with fast checks | TTL you set (AWS recommends 60 s or less with health checks) plus resolver and client caching | ~2.5 minutes to several minutes | Checkers run from multiple regions; the endpoint is marked unhealthy when 18% or fewer of checkers report it healthy. |
| Azure Traffic Manager (performance routing) | Latency-based DNS | 30 s interval; tolerated failures 3 (range 0 to 9); probe timeout 10 s | ~2 min (marked degraded after the fourth consecutive failure) | Profile TTL (Azure CLI default 30 s; can be set as low as 0 s) plus resolver and client caching | ~2.5 minutes to several minutes | Supports custom headers in probes. Microsoft says failover can complete under 10 s after an endpoint goes unhealthy with 10 s probes, 0 tolerated failures, and TTL 0. |
| Google Cloud DNS routing policies with health checks | Geolocation, weighted round robin, or failover DNS policy | External endpoints: 30 to 300 s interval × unhealthy threshold (Google Cloud default 2); internal load balancers: their own health check (default 5 s × 2) | ~60 s at the 30 s minimum interval for external endpoints; ~10 s for internal load balancer targets | TTL you set plus resolver and client caching | ~1 minute plus TTL to several minutes | Public zones health-check external IPs, including a global external Application Load Balancer VIP; private zones health-check internal load balancers. |
| AWS Global Accelerator | Anycast; routes to the nearest healthy endpoint group | 30 s interval × 3 (default; interval 10 or 30 s, threshold 1 to 10) | ~90 s | No DNS change; the anycast IPs stay advertised and the edge sends new connections to the next healthy endpoint group | ~90 to 120 s | These settings apply to EC2 and Elastic IP endpoints; ALB and NLB endpoints use Elastic Load Balancing target-group health checks. |
| Google Cloud global external Application Load Balancer | Anycast; routes to the nearest healthy backend | 5 s interval × 2 failures, 5 s timeout (defaults) | ~10 to 15 s | No DNS change; the anycast VIP stays advertised and Google’s front ends stop sending requests to unhealthy backends | ~10 to 30 s | Fastest defaults in this table. Each backend service can set its own health check. |
| Azure Front Door | Anycast; routes to the nearest healthy origin | 30 s probe interval in the health-probes doc (the CLI reference says 240 s); healthy if at least x of the last n probes succeed | No documented default sample counts; ~90 s with Microsoft’s example (30 s, 5 samples, 3 required) | No DNS change; the edge stops routing to unhealthy origins | ~90 s or more with that example | Every edge location probes origins independently. Latency sensitivity picks among healthy origins; it does not decide health. |
| Cloudflare Load Balancing | Steering policy (failover, geo, proximity, dynamic latency, and others), DNS-only or proxied (anycast) | 60 s interval, 5 s timeout, 2 immediate retries (defaults in Cloudflare’s API schema); minimum interval by plan | ~15 to 75 s per failed check cycle, plus 60 s for each extra consecutive failure you require | Proxied: no client DNS change. DNS-only: the load balancer TTL plus resolver caching | ~75 s (proxied) to several minutes (DNS-only) | Minimum interval is 60 s on Pro, 15 s on Business, and 10 s on Enterprise. Health is decided by a majority of data centers per region, then a majority of regions. |
Shortening the health check interval, lowering the failure threshold, and reducing the DNS TTL improve every value in the table. After tuning, measure with real clients and real traffic, since detection times on paper leave out caching.
What decides how fast traffic moves to another region?
Failover time is the sum of several independent delays, so shortening one delay cuts the total only by that amount, and the slowest delay usually dominates.
Health check interval and failure threshold. Detection time follows from the interval and the threshold. A 30-second interval with a threshold of 3 means up to 90 seconds pass before the system acts. Lower values speed detection but raise the risk of flapping if probes are flaky.
What the health check actually tests. A TCP port check confirms the process is listening but says nothing about whether it can serve requests. An HTTP check on a path that exercises the request path catches failures a port check misses. Leave out dependencies every region shares: if a shared database fails, every region fails its check at once, and Route 53 then treats all endpoints as healthy. Set probe timeouts shorter than the interval.
DNS TTL and real-world caching. The TTL tells resolvers how long to cache an answer, but some recursive resolvers and client operating systems apply a minimum floor, and browsers and connection pools reuse addresses for the life of a connection. Measure how resolvers in your client population actually honor TTLs.
Connection reuse and long-lived connections. gRPC streams, WebSocket connections, and HTTP/2 pools can stay open for minutes or hours and are unaffected by DNS changes until they close or error out. Use reasonable idle timeouts and retry logic with backoff that re-resolves DNS on reconnect.
Warm capacity in the surviving region. If the surviving region cannot absorb the redirected traffic, failover succeeds at the routing layer and fails at the application layer. Autoscaling helps, but new instances take time to become ready. Running active-active with enough headroom in each region to absorb the largest region’s share of traffic avoids this gap. The guide on how to run an app across multiple regions with routing, databases, and failover covers the full architecture.
How do I deploy one application to multiple regions with a single configuration?
Routing works only if every region runs the same application version and has enough capacity to serve traffic.
- Infrastructure as code modules. Terraform or Pulumi can parameterize a deployment module by region and apply it to several regions in one pipeline. Adding a region means adding an entry to a list.
- Kubernetes with GitOps tooling. Argo CD ApplicationSets, or Flux bootstrapped on each cluster against the same repository, deploy to multiple clusters from one Git repository. Federating health signals across clusters needs additional tooling.
- A platform that deploys one definition to many locations. A workload deployed to a Control Plane Global Virtual Cloud (GVC), a named set of locations across one or more clouds, runs in every location from one definition, with no per-region pipeline or cluster configuration to maintain.
Whichever method you use, the pipeline should verify that every region converges on the same version. Staged region-by-region rollouts are safe only when old and new versions are backward-compatible. The best multi-region and multi-cloud networking platforms compares platforms that handle multi-region deployment and networking.
How do I test that failover works?
Run this checklist at launch and on a regular schedule.
- Fail a health check on purpose. Stop the application in one region or return an unhealthy response from the health check endpoint, and record when the routing system reacts.
- Measure the shift with synthetic probes from several regions. Run HTTP probes from at least three locations, record when each starts reaching the new region, and compare it to the worst-case switch time in the table.
- Test with real clients that cache DNS. Synthetic probes often resolve DNS fresh on every request, so use a browser, a mobile device, or a CLI with DNS caching enabled.
- Check capacity in the surviving region. Watch CPU, memory, latency, and error rates, measure how long autoscaling takes to reach steady state, and confirm new instances pass readiness checks before they receive production traffic.
- Test failback. Restore the failed region, confirm traffic rebalances, and watch for flapping if the healthy threshold is too low.
- Run the test under load. A failover test on an idle system does not reveal capacity problems.
- Document the results. Record detection time, propagation time, and total switch time, and adjust health check settings, TTLs, or capacity against your SLA targets.
Lessons from real regional outages are collected in how companies stay online during AWS us-east-1 outages.
How Control Plane routes users to the nearest healthy location
Control Plane is the unbreakable platform for running production workloads. It runs serverless, standard, stateful, and cron workloads natively on AWS, GCP, Azure, and Oracle Cloud Infrastructure (OCI), VM workloads on locations joined through Control Plane’s Managed Kubernetes, and workloads on Kubernetes clusters you already run or your own machines, including on premises, active-active across regions and clouds.
A workload runs in every location of its GVC, so routing always has a set of identical locations to choose from. Adding a location provisions it for every workload in the GVC; removing one drains its replicas and shifts traffic to the locations that remain, without touching a workload definition.
On Control Plane, every workload gets its own global endpoint (its canonical endpoint), and each custom domain you route to it gets one too. Control Plane DNS geo-routes clients to the nearest location where the workload is healthy, using the workload’s own readiness probes, so a location drops out of DNS answers when the workload there stops reporting ready. Each GVC also has an alias endpoint; by default it is health-checked only with a basic TCP probe, so point its alias workload link at a workload to make the alias follow that workload’s health.
Control Plane’s location routing options, set per location on the GVC, reshape that default for every endpoint in the GVC:
- A priority tier per location. Lower tiers are preferred, and within a tier the lowest-latency location wins. If every location in the preferred tier is unavailable, traffic moves to the next tier, which lets you prefer one region and keep others as backup.
- A latency offset that nudges a location up or down in the latency ranking.
- A latency threshold past which a location is treated as unavailable. If every location exceeds its threshold, Control Plane ignores the thresholds so traffic is not dropped.
For TCP or UDP traffic that should bypass the HTTP ingress, you can enable a direct load balancer on a workload. Control Plane then creates a load balancer in each location and registers each one as a Geo DNS target with latency-based routing.
During the October 20, 2025 AWS us-east-1 outage, Control Plane customers with us-east-1 in their GVC had workloads active and running in healthy locations within 10 seconds, with no customer downtime, according to Control Plane’s internal incident telemetry, as reported in Beyond Backups: Designing Systems That Survive the Inevitable. The guide to keeping your app online during an AWS region outage walks through the pattern.
The 99.999% availability SLA applies to workloads running at least two replicas in at least two locations. Control Plane handles Day 2 operations for you, including autoscaling, built-in observability, and security. Control Plane is PCI DSS Level 1, SOC 2 Type II, HIPAA, and GDPR compliant.
Control Plane’s global endpoints are DNS-based, so clients that cache DNS answers beyond their TTL can keep sending traffic to a withdrawn location for a short time. Teams that want an anycast IP or a specific CDN in front of their traffic can place a global load balancer or CDN ahead of Control Plane endpoints. Failover options beyond routing are compared in the best multi-cloud failover solutions in 2026.
FAQ
Short answers on deployment, DNS failover speed, TTLs, health checks, backup regions, and testing.
How do I route users to the nearest healthy region automatically?
Use latency- or geo-based DNS routing with health checks, an anycast global load balancer, or a platform with a built-in global endpoint such as Control Plane. Each method health-checks every region and sends users to the nearest one that is passing its checks.
How do I deploy one application to multiple regions with a single configuration?
Use infrastructure as code modules parameterized by region, Kubernetes GitOps tooling such as Argo CD ApplicationSets, or a platform like Control Plane, which runs one workload definition in every location of a GVC. Every region should run the same version and have spare capacity before it receives traffic.
Is DNS failover fast enough?
It depends on your tolerance. With default settings, worst-case failover on the DNS services in the table ranges from about a minute plus the TTL to several minutes, and resolver and client caching makes the tail unpredictable. If your SLA requires sub-30-second failover, use an anycast global load balancer with tuned health checks (Google Cloud’s defaults already detect in about 10 seconds), or tune DNS health checks to their fastest settings and keep TTLs very low, knowing some resolvers do not honor them, and confirm the result by testing.
What DNS TTL should I use for failover?
A TTL of 30 to 60 seconds is a common starting point for failover-critical records. Lower TTLs shorten the stale-answer window but raise query volume and cost, and some resolvers apply a minimum floor or ignore TTLs, so measure what your clients actually honor.
What is the difference between anycast and DNS-based routing?
DNS-based routing returns different IP addresses depending on policy, so failover waits for clients to look up DNS again after cached answers expire. A managed anycast load balancer gives every user the same IP, and its edge stops forwarding to a region once health checks mark it down, so DNS caching plays no part. Total failover time for both still depends on health check settings.
How do health checks decide a region is down?
A health check probes each endpoint over TCP, HTTP, or HTTPS at a fixed interval and marks the region unhealthy after a set number of consecutive failures, usually combining results from probers in several locations (Route 53 marks an endpoint unhealthy when 18% or fewer of its checkers report it healthy); Azure Front Door uses a sample-based rule instead. An HTTP check that exercises the region’s own request path and region-local dependencies catches failures a TCP port check misses.
Can I prefer one region and use others only as backup?
Yes. Most DNS routing services offer failover policies that send traffic to secondary endpoints only when the primary fails, and Azure Front Door supports origin priority. On Control Plane, assign each location in the GVC a priority tier; traffic moves to the next tier only when every location in the preferred tier is unavailable.
What happens to in-flight requests during failover?
Requests in flight to the failed region fail and need a retry. With DNS routing, existing connections keep pointing at the old IP until they close or error out; with a managed Layer 7 anycast load balancer such as Google Cloud’s global external Application Load Balancer or Azure Front Door, the client’s connection to the edge usually survives and new requests go to a healthy backend; with Global Accelerator, which works at Layer 4, clients reconnect and land on a healthy endpoint. Long-lived gRPC streams and WebSockets need idle timeouts and reconnect logic that re-resolves DNS.
How often should I test failover?
Test at least quarterly and after any change to regions, health check settings, or DNS TTLs. Automate the test in a pipeline, and measure detection time, propagation time, and surviving-region capacity under load each time.
Control Plane routes users to the nearest healthy location without per-service DNS records, external health checks, or per-region deployment pipelines. Talk to the Control Plane team or sign up free.
Originally published on the Control Plane blog.
Top comments (1)
The comparison table is the most useful part here — seeing Route 53's roughly 90-second default detection next to the GCP global load balancer's 10 to 15 seconds makes the trade-off between DNS routing and anycast concrete instead of abstract. The point about long-lived connections is one teams often miss: DNS failover does nothing for gRPC streams and WebSocket connections already open to the failed region. Have you seen teams pair this with connection draining or retry budgets at the client to cover that gap?