A fintech runs a payment API in us-east-1 with an Aurora Global Database standby in eu-west-1 and requires RTO under 5 minutes, automated health-based failover, and a manual safety gate to prevent flapping. Which disaster recovery failover design using health checks and routing controls meets these continuity requirements?

The correct design succeeds because Route 53 health checks tied to Application Recovery Controller routing controls give DNS failover that is health-aware yet gated: routing controls are on/off switches that drive Route 53 health checks, and safety rules (assertion and gating rules) block unsafe or conflicting changes so traffic does not flap on transient signals. Promoting the existing Aurora Global Database standby in eu-west-1 typically completes within a few minutes, which fits the under-five-minute objective. The fully automated promotion design fails on gating because DNS failover driven only by health check status can flap during intermittent signals and has no approval step. The manual weighted-record design fails on automation and safety because people must detect the outage and edit records with no safety rules, and cached TTLs lengthen recovery. The snapshot-restore design fails on recovery performance because restoring backups and replaying logs takes far longer and discards the already-replicated Global Database secondary. An exam caveat is that high availability controls and backup restore are often presented as interchangeable disaster recovery patterns, yet only the standby-promote pattern meets aggressive recovery targets with gating. A practical check is to rehearse the runbook with induced failure, validate routing control and safety rule states, and confirm Global Database replication lag and promotion readiness in eu-west-1 before relying on the design.