How to Configure Route 53 DNS Failover

This guide explains how web development and operations teams configure automated DNS failover using Amazon Route 53 health checks. It covers the essential steps to achieve high availability through an active-passive architecture, including defining endpoint health checks, routing policies for primary and secondary resources, and verifying automated traffic redirection during unexpected outages.

Understanding DNS Failover in Route 53

Route 53 DNS failover automatically detects when an application endpoint becomes unhealthy and reroutes incoming traffic to an alternative healthy resource, such as a standby server, a secondary region, or a static maintenance page hosted on Amazon S3.

The most common implementation is an active-passive setup, where all traffic is directed to the primary endpoint until a failure occurs, prompting Route 53 to redirect queries to the secondary endpoint.

Step 1: Create a Route 53 Health Check

Route 53 relies on health checks to monitor the operational status of your primary infrastructure.

  1. Open the Route 53 console and navigate to Health checks.
  2. Click Create health check.
  3. Configure the health check parameters:
    • What to monitor: Select Endpoint.
    • Specify endpoint by: Choose IP address or Domain name.
    • Protocol: Select HTTP, HTTPS, or TCP (HTTPS is standard for modern web endpoints).
    • Port: Default is 443 for HTTPS.
    • Path: Specify a dedicated health endpoint (e.g., /health or /api/healthz) that returns a standard 200 OK status code when internal dependencies like databases and caches are operating normally.
  4. Set the monitoring intervals:
    • Request interval: Choose Standard (30 seconds) or Fast (10 seconds) for quicker failover detection.
    • Failure threshold: Specify how many consecutive failed checks are required before Route 53 flags the endpoint as unhealthy (default is 3).
  5. Complete the setup and optionally link the health check to an Amazon SNS topic to notify the team when state changes occur.

Step 2: Configure the Primary DNS Record

Next, link the health check to the DNS record handling live production traffic.

  1. Navigate to Hosted zones in Route 53 and select your domain.
  2. Click Create record.
  3. Configure the primary record:
    • Record name: Enter the subdomain (e.g., app or leave blank for root).
    • Record type: Select A (or AAAA for IPv6).
    • Routing policy: Choose Failover.
    • Failover record type: Select Primary.
    • Value/Route traffic to: Enter the IP address or alias to the primary resource (e.g., an Application Load Balancer).
    • Health check ID: Select the health check created in Step 1.
    • TTL (Time to Live): Set a low TTL, such as 60 seconds. Lower TTL values ensure recursive DNS resolvers flush cached records quickly when a failover event occurs.
  4. Save the record.

Step 3: Configure the Secondary (Backup) DNS Record

The secondary record defines where users should be routed when the primary record fails.

  1. Click Create record within the same hosted zone.
  2. Configure the secondary record:
    • Record name: Must match the Record name used for the primary record.
    • Record type: Must match the primary record type (A or AAAA).
    • Routing policy: Choose Failover.
    • Failover record type: Select Secondary.
    • Value/Route traffic to: Enter the backup endpoint (e.g., a secondary region load balancer, a disaster recovery server, or an S3 website endpoint).
    • Health check ID: Optional. If the backup is a dynamic secondary server, attach a separate health check. If it is a static S3 bucket, a health check is generally unnecessary.
    • TTL: Match the TTL configured on the primary record (e.g., 60 seconds).
  3. Save the record.

Step 4: Validate and Test the Failover

Teams must simulate failure scenarios to verify that traffic redirects as expected:

  1. Simulate an Outage: Temporarily block inbound health check traffic at the security group level, or modify the primary application's /health endpoint to return a 500 Internal Server Error.

  2. Monitor Health Check Status: Open the Route 53 Health Checks dashboard and confirm that the primary health check status transitions from Healthy to Unhealthy.

  3. Query DNS: Use CLI utilities such as dig or nslookup to inspect DNS resolution:

    dig app.example.com +short

    Verify that the response returns the IP address or alias of the secondary endpoint once the failure threshold and TTL window pass.

  4. Restore Service: Revert the changes to return the endpoint to a healthy state. Confirm that Route 53 switches queries back to the primary record automatically.