For most teams, manual failover with automated steps is the safer default. Fully automatic failover reacts fastest, but it can fail over on a false alarm and cost you data. Manual trigger plus scripted steps keeps a human in the decision and still makes recovery quick.
What each approach means
Automatic failover. Health checks or alarms detect trouble and traffic moves to the recovery region without a person deciding.
Manual failover. A person decides, then runs the failover. If the steps are scripted, starting it is close to pressing a button.
Why automatic can hurt
AWS guidance states that automatic failover based on health checks or alarms should be used with caution. Even with good practice, recovery time and recovery point are greater than zero, so every failover loses some availability and data. If you fail over when you did not need to, you take those losses for nothing.
Common ways a false alarm happens: a health check endpoint that fails because of a bad deploy, a monitoring blip, a partial dependency problem that looks like a regional fault, or a network issue between the checker and your service.
There is also the risk of flapping. If the system fails over, then fails back, then fails over again, you spend the incident chasing your own automation.
Why manual can hurt
A person needs to notice, decide, and act. At 3 a.m., that takes time. Manual failover also depends on the person having access, a current runbook, and a working path to the tools.
That last point matters during a regional event. AWS separates data plane operations, which serve live traffic, from control plane operations, which configure the environment. Data planes typically have higher availability goals. For maximum resiliency, the guidance says to use only data plane operations in the failover itself. A runbook that begins with creating resources in a degraded control plane may stall.
A middle path
- Detect automatically and alert loudly.
- Pre-build every step of the failover and script it.
- Keep the trigger manual, with a clear rule for who may press it.
- Make failover reversible, and rehearse failing back.
AWS describes one pattern for this on its DNS service: health checks that do not check anything, but act as on and off switches under your control, flipped by a script through a data plane API. Another option some teams use is changing routing weights, which AWS notes is a control plane operation and therefore less resilient. Whatever tools you use, check which plane each step relies on.
When automatic is the right call
Fully automatic failover suits cases where a delay is more costly than a false alarm, the checks are reliable and cover the whole user path, and you have tested the failover and failback many times. Active/active designs go further: with several regions serving traffic, there is no failover event, and testing shifts to how the workload reacts when one region disappears.
Decision guide
- Short outage costs are low and false alarms are costly: manual trigger.
- Seconds matter and checks are proven: automatic, with a rate limit on how often it can act.
- Unsure: start manual, collect evidence from drills, and move to automatic only where the data supports it.
Quick check
Is manual failover always slower?
Not if the steps are scripted. The delay is the decision, and a clear rule on who decides keeps it short.
What is a control plane dependency?
A step that needs the provider's configuration APIs to work, such as creating new resources. These tend to be less available than the services that carry live traffic.
Sources
Last reviewed: 19 October 2026.
