DNS failover is bounded by caching

Changing a DNS record looks instant from the console. Each client sees the change only when its cached answer expires, and answers are cached in several places, so the old address outlives the edit.

The TTL is how many seconds a resolver may keep a record before asking again. Sam Newman's advice is to assume clients hold the old address for at least that long, and caches sit below the resolver too: AWS warns that some JVM configurations never refresh a lookup until the process restarts. Resolvers can keep answers longer than asked; Unbound, for one, has a minimum-TTL setting that overrides the domain owner's value. For health-checked failover records Route 53 recommends 60 seconds or less. All of this lag counts against the RTO.

Editing the record is also a control plane call, and AWS describes Route 53's control plane as more centralised than its data plane. It recommends failing over through health checks or routing controls instead, which belong to the data plane and do not depend on the control plane.

However it is set up, the number to plan with is the one measured by moving traffic for real.