Free — no signup required

Failover Routing: Active-Passive Disaster Recovery

2 min read

The Emergency Brake

Failover routing is the DNS equivalent of a circuit breaker. It is designed specifically for Disaster Recovery (DR) scenarios where you need automatic traffic redirection when your primary infrastructure fails.

The pattern requires exactly two records for the same DNS name:

  1. Primary record: Points to your main application (e.g., an ALB in us-east-1).
  2. Secondary record: Points to your backup (e.g., an ALB in us-west-2, or a static S3 error page).

The Mechanism

A Health Check is mandatory on the Primary record. Without it, Route 53 has no way to know the primary is down.

Normal operation:
  User → Route 53 → Health Check: HEALTHY → Primary (us-east-1 ALB)

Failure scenario:
  Primary ALB crashes
  Health Check: UNHEALTHY (after threshold is crossed)
  Route 53 automatically returns Secondary record
  User → Route 53 → Secondary (us-west-2 ALB or S3 page)

DNS TTL and failover speed: Route 53 health checkers detect failures quickly (within 10–30 seconds depending on configuration), but DNS propagation depends on the TTL of your records. Set a low TTL (60 seconds or less) on Failover records so that clients pick up the change quickly after a failover event. The trade-off is higher DNS query volume and cost.

Active-Active vs. Active-Passive

These two patterns are frequently tested in interviews:

Pattern Route 53 Policy Behavior
Active-Passive Failover Primary handles all traffic; Secondary is idle until Primary fails
Active-Active Latency or Weighted (with Health Checks) Both endpoints handle traffic simultaneously; if one fails, its traffic shifts to the survivor

When to use each:
- Active-Passive: When your secondary environment is a cold standby (lower cost, slower recovery). Common for non-critical workloads or when the secondary is a static maintenance page.
- Active-Active: When you need zero-downtime failover and can afford to run both environments simultaneously. Common for high-availability production systems.

Combining policies: You can nest routing policies using Route 53 Traffic Flow. For example: Latency routing at the top level (to pick the nearest region), with Failover routing within each region (to handle regional failures). This creates a multi-tier routing hierarchy.

This is one of 18 chapters

Get every chapter — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

See pricing