A municipal web app has a primary ALB in one Region and a DR ALB in another. How should DNS fail users over when the primary becomes unhealthy?

Amazon Route 53 failover routing with health checks correctly fails a municipal web app from a primary Regional ALB to a DR ALB when the primary becomes unhealthy. The approach works because Route 53 continuously evaluates the primary endpoint’s health and, on failure, answers DNS queries with the secondary record so citizen browsers and staff clients reach the DR ALB without manual IP redistribution. Failover routing is purpose-built for active-passive DNS cutover between primary and secondary endpoints, which matches a city that keeps a DR ALB ready for Regional or application failure. TTL discipline and health-check configuration determine how quickly most clients observe the shift.

Hard-coding citizen browsers to the primary ALB’s IP addresses and emailing a new IP list after failure fails by concept because ALB IPs change, clients cache addresses poorly for operations, and human email is not an automated failover control plane. Using only weighted routing with equal weights and no health checks fails because equal weights split traffic continuously and without health evaluation cannot remove an unhealthy primary from rotation. Disabling DNS caching globally and requiring citizens to flush hosts files daily fails because it is operationally unrealistic for the public and does not implement health-based failover between ALBs.

Exam caveat: DNS failover is limited by resolver caching and health-check sensitivity—too aggressive checks flap; too long TTLs delay cutover. Operational check: set primary/secondary failover records to the two ALB DNS names, attach health checks that match real application readiness, choose a TTL aligned to RTO, and verify with a controlled primary ALB withdrawal that queries move to the DR ALB.