Failover Routing

What is failover routing?

Failover routing is a DNS routing policy that directs all traffic to a primary endpoint under normal conditions and automatically switches to a standby (secondary) endpoint when the primary becomes unhealthy. It’s the active-passive disaster-recovery pattern expressed at the DNS layer: one endpoint serves everything; the other waits in reserve; a health check on the primary is what triggers the switch. In AWS it’s a Route 53 routing policy paired with Route 53 health checks; other DNS/traffic-management providers offer the equivalent. Its whole job is availability — keeping the service reachable when the primary fails.

How it works, and the pieces that must be right

The mechanism has two essential parts. The health check continuously probes the primary endpoint (an HTTP check, a TCP check, or a calculated check combining several), and while the primary passes, DNS keeps returning it. When the health check fails, DNS starts returning the secondary endpoint’s address instead, redirecting new lookups to the standby. When the primary recovers (health check passes again), traffic fails back. For this to actually protect you, several things must hold: the health check must genuinely reflect application health — a check that only pings a load balancer’s TCP port will happily report “healthy” while the application behind it is throwing errors, so checks should hit a real application endpoint that exercises the critical path; and the standby must actually be ready to take traffic (warmed, with current data), or failover just moves users to a broken or empty endpoint. This is the active-passive contrast with weighted or latency-based routing, which spread traffic across active endpoints — failover deliberately keeps the secondary idle until needed.

The DNS caveats that limit it

Failover routing inherits DNS’s fundamental timing limitations, and ignoring them undermines the disaster-recovery goal. The big one is caching / TTL: because DNS responses are cached by resolvers and clients for the record’s TTL, failover is not instantaneous — even after the health check detects failure and DNS switches to the secondary, clients holding cached results keep hitting the dead primary until their cache expires. This means DNS failover has an inherent recovery-time floor governed by health-check interval + failure threshold + TTL, typically on the order of a minute or more, not milliseconds. The mitigation is low TTLs on failover records (so cached bad answers expire quickly), accepting the tradeoff of more DNS query volume. This latency is also why DNS failover suits disaster recovery (whole-endpoint/region outages where a minute of switchover is acceptable) rather than instant high-availability within a region — for sub-second, seamless failover you use a load balancer distributing across healthy instances (health-checking and rerouting at the connection layer, no DNS caching involved), not DNS. The other reality is data: an active-passive failover is only useful if the standby has the data to serve requests, which raises replication and consistency questions (is the secondary’s database a current replica?) — the routing is easy; keeping the standby genuinely ready is the hard, often-underinvested part. Pairing failover routing with proper multi-region replication and realistic failover drills is what separates a DR plan that works from one that only works on paper.

What people get wrong

• Shallow health checks — checking a TCP port or load balancer instead of a real application path reports “healthy” while the app is broken, so failover never triggers.
• Expecting instant failover: DNS caching (TTL) plus detection time means minute-scale switchover, not milliseconds — use low TTLs, and use load balancers for sub-second HA.
• An unready standby — failover to a cold or stale secondary just moves users to a broken endpoint; the passive side needs current data and warm capacity, verified by drills.

Primary source: Amazon Route 53 failover routing