You are designing multi-region failover on AWS and the target recovery time is a few seconds. Why is Amazon Route 53 failover routing a poor fit for that objective, and what would you do instead?

## Where the floor comes from Route 53 failover is two serial delays. **Detection.** An endpoint health check probes on its request interval and needs a configured number of consecutive failures. Even tuned aggressively — fast interval, threshold of two — that is roughly twenty seconds, and going lower trades reliability for speed because a single lost probe then triggers a regional move. **Propagation.** Route 53 changes what it answers immediately, but the internet is full of copies of the previous answer. Recursive resolvers honour the TTL; some clients cache longer than the TTL; application runtimes and connection pools may hold a resolved address for the process lifetime; and an open, healthy-looking TCP connection to a failing region is never re-resolved at all until it breaks. That second half is the reason DNS cannot deliver seconds. Detection you can tune. Cache behaviour belongs to other people's software, and the only lever you have — the TTL — has to be lowered *before* the incident to have any effect, and buys extra query volume and cost when it is. ## What changing the layer buys The insight to state in an interview is that DNS failover works by **changing the answer**, which means every client must ask again. Faster mechanisms work by **keeping the answer constant** and changing what the address leads to. - **Anycast entry points.** AWS Global Accelerator gives an application two static IP addresses announced from AWS edge locations worldwide. Clients resolve once, possibly forever; when an endpoint group becomes unhealthy, the accelerator steers new connections to another region at the network layer. No re-resolution, no TTL, no client cache in the path. The cost is a service to pay for and operate, and a design constrained to what the accelerator supports. - **In-region load balancing.** Inside a region a load balancer already does connection-level failover between targets, in seconds and without DNS involvement. Plenty of "multi-region" requirements are really availability-zone requirements, and a single regional load balancer across zones satisfies them at a fraction of the complexity. - **Client-side awareness.** Applications with their own retry and endpoint-selection logic — SDKs and mobile clients especially — can move between endpoints faster than any infrastructure mechanism, at the cost of shipping that logic to every client. ## Where Route 53 failover is still exactly right Do not overcorrect. DNS remains the only layer that can see *every* destination, so it is the right instrument when: - the standby is in another cloud, another provider, or an on-premises data centre; - the failover is a whole-stack, deliberate, human-approved event where minutes are acceptable; - the target is a static maintenance page or degraded mode rather than a live standby; - you need geographic or jurisdictional steering as well as failover, which anycast does not express. And Route 53 has a mechanism for the deliberate case that is worth naming: Application Recovery Controller routing controls, an explicit on/off switch per cell that a human or automation flips, with health checks driven by that control rather than by inferred endpoint health. It removes the "did the health check see the right thing?" question from the failover decision, which for a stateful system is often the real risk. ## The part that decides the objective The hardest question in a seconds-scale recovery target is usually not routing at all. If the standby region's database replicates asynchronously, arriving there in five seconds means arriving at data that is behind, and possibly writing into a state that will conflict when the primary returns. A credible design answers three things together: 1. **How traffic moves** — the routing mechanism and the honest recovery time it implies. 2. **What the data guarantees** — synchronous or asynchronous replication, the tolerated data loss, whether writes are single-region or active-active, and how a split brain is prevented. 3. **Who decides** — automatic failover is fast and can fire on a false signal; a human gate is slower but will not shift a stateful system on a network blip. Many mature designs deliberately automate failover for stateless tiers and gate the data tier. A candidate who tunes Route 53 TTLs down to five seconds and calls the objective met has answered the easiest third of the problem. The answer that lands is: DNS is a slow, globally-reachable, coarse control plane; put the fast failover where the client's address does not change; and be explicit that the recovery objective is bounded by the data layer, not by the routing layer.