You set up Amazon Route 53 failover records for an active-passive design across two regions. The primary region goes down, but users keep hitting it for several minutes before traffic moves. Walk through everything that contributes to that delay and what you would change.

## How failover records work A failover record set is two records sharing a name and type, distinguished by `SetIdentifier`, with the `Failover` field set to `PRIMARY` on one and `SECONDARY` on the other. Route 53 answers with the primary while it is healthy and with the secondary once the primary is not. The primary must have something telling Route 53 whether it is healthy: either an associated health check (`HealthCheckId`), or — when the record is an alias to an AWS resource such as a load balancer — `EvaluateTargetHealth`, which lets Route 53 inherit that resource's own view of its targets. A point candidates miss: if *both* records are unhealthy, Route 53 does not return an empty answer. It answers as though they were healthy, on the principle that a possibly-broken address beats no address at all. ## Delay one: detection Route 53 runs an endpoint health check from health checkers in multiple AWS regions. Each checker probes on the configured **request interval** — 30 seconds by default, or 10 seconds in fast mode at extra cost — and the endpoint is marked unhealthy after the configured **failure threshold** of consecutive failed probes, default 3 and configurable from 1 to 10. So the default configuration takes roughly 90 seconds of continuous failure before Route 53 changes its mind, and there is a further short interval before that decision is reflected in answers everywhere. An important nuance is that individual checkers disagree — they sit on different networks and see different paths. Route 53 aggregates: the endpoint counts as healthy while a documented minimum share of checkers still report success. That is deliberate. It means one bad network path does not fail your region over, and it also means a *partial* outage — the region is reachable from some networks and not others — may never trip the health check at all. Tuning: fast interval plus a threshold of 2 brings detection to roughly 20 seconds. Do not push it to a threshold of 1 casually; a single lost probe then fails your primary over, and a flapping record is worse than a slow one. ## Delay two: caching Once Route 53 is answering with the secondary, everything holding the old answer still uses it until that copy expires. The record's TTL is the lever you own here: a 300-second TTL means five minutes of continued traffic to a dead region no matter how fast the health check was. Failover records are normally set to 60 seconds or lower for exactly this reason, accepting the extra query volume and cost that a short TTL brings. Two caveats. Alias records to AWS resources do not take a TTL you choose — Route 53 uses a value fixed for the target type — so with an alias to a load balancer the cache delay is largely out of your hands. And the client side is not under your control at all: some runtimes and applications cache resolved addresses beyond the TTL, and an application with an established connection or a warm connection pool will not re-resolve until that connection breaks. This is why a failover that "works" in a test often looks slower in production. ## Making the plan honest Add it up: detection plus TTL plus client behaviour puts realistic DNS failover in the tens of seconds to a few minutes. Design changes that actually help: - **Fast health checks with a sane threshold**, and check an endpoint that reflects the whole stack, not a static file that stays up while the database is gone. A path that touches the real dependencies is what makes the health check mean something. - **Low TTL on the failover records**, set well before you need it — lowering a TTL only takes effect after the old TTL has expired everywhere, so it is not a thing you can do during an incident. - **Make the client cooperate**: sensible connection timeouts and retries so a stuck connection is dropped and re-resolved rather than hanging. - **Fail back carefully.** Automatic failback means the moment the primary passes a couple of probes, traffic returns — possibly to a region that is up but has a cold cache or an unreplicated database. Many teams deliberately make failback a human decision. ## When DNS is the wrong layer If the recovery objective is a few seconds, DNS cannot deliver it, because the caching delay is not yours to control. That is when you move failover below DNS — to anycast addressing that keeps one IP and reroutes the network, or to a load balancer that fails between targets at connection level within a region. Route 53 failover remains the right tool for cross-region, cross-provider, and hybrid failover, where DNS is the only layer that can see both destinations at all.