Route 53 Health Checks and DNS Failover

Route 53 health checks are automated requests that evaluate the availability and responsiveness of an endpoint (e.g., an IP address or domain name). DNS failover uses these health checks to automatically update DNS records when a resource becomes unhealthy, directing traffic to healthy resources instead. This is essential for building highly available applications.

Route 53 health checkers are distributed across multiple AWS regions (at least 8 regions globally). Each health checker sends a request to the endpoint's IP address or domain name at a configurable interval (default: 30 seconds, minimum: 10 seconds with Route 53 health checkers). The request is an HTTP/HTTPS GET or TCP SYN. For HTTP/HTTPS, the health checker expects a 2xx or 3xx status code (configurable). For TCP, it expects a successful three-way handshake within a timeout (default: 5 seconds, configurable from 1-60 seconds).

If the endpoint does not respond within the timeout, the health checker marks that request as failed. Route 53 aggregates results from all health checkers over a configurable failure threshold (default: 3 consecutive failures) before declaring the endpoint unhealthy. The health check interval and failure threshold together determine the total time to detect a failure: e.g., with 30s interval and 3 failures, it takes up to 90 seconds (3 cycles) to mark unhealthy.

- Health Check Types: - Endpoint monitoring: Checks an IP address or domain name. - Calculated health checks: Combines multiple health checks via OR, AND, or at-least-N logic. - CloudWatch alarm health checks: Monitors a CloudWatch alarm (e.g., for a specific metric).

- Health Check Configuration Values: - Request interval: 10 or 30 seconds (default 30). - Failure threshold: 1-18, default 3. - Timeout: 1-60 seconds, default 5. - String matching: Optionally check for a specific string in the response body (up to 5,120 bytes). - Latency graphs: Enabled by default, shows response times. - Invert health check status: Reverses healthy/unhealthy (useful for CloudWatch alarms).

- DNS Failover Routing Policy: - Failover: You designate one record as primary and one as secondary (or more). Route 53 returns the primary record if its health check is healthy; otherwise, it returns the secondary record. You can associate health checks with any routing policy, but failover routing specifically uses primary/secondary logic. - Active-active vs. Active-passive: Failover routing is active-passive (primary-secondary). For active-active, use weighted or latency routing with health checks.

To create a health check via AWS CLI:

aws route53 create-health-check --caller-reference $(uuidgen) --health-check-config '{
  "IPAddress": "203.0.113.1",
  "Port": 80,
  "Type": "HTTP",
  "ResourcePath": "/health",
  "RequestInterval": 30,
  "FailureThreshold": 3
}'

To associate a health check with a DNS record:

aws route53 change-resource-record-sets --hosted-zone-id ZONEID --change-batch '{
  "Changes": [{
    "Action": "UPSERT",
    "ResourceRecordSet": {
      "Name": "example.com",
      "Type": "A",
      "SetIdentifier": "primary",
      "Failover": "PRIMARY",
      "HealthCheckId": "HEALTHCHECKID",
      "TTL": 60,
      "ResourceRecords": [{"Value": "203.0.113.1"}]
    }
  }]
}'

To verify health check status:

aws route53 get-health-check-status --health-check-id HEALTHCHECKID

When a health check fails, Route 53 propagates the status change. For failover routing, Route 53 will immediately return the secondary record in response to DNS queries. However, DNS caching by clients and resolvers (TTL) can delay the effect. The TTL on the record should be low (e.g., 60 seconds) to minimize failover time. Route 53 supports health checks for all routing policies except simple routing (which cannot have health checks).

Calculated health checks allow you to create a parent health check that monitors the status of up to 256 child health checks. You can specify a threshold (e.g., at least 2 of 3 child checks must be healthy) and how to treat missing data (last status, healthy, unhealthy, or ignore). This is useful for complex dependencies.

Health checks cannot directly monitor resources in a VPC because they run from public IPs. To monitor private resources, you must either:

In a typical enterprise deployment, Route 53 health checks and DNS failover are used to provide multi-region high availability. For example, a global e-commerce website runs active-active in us-east-1 and eu-west-1 with an Application Load Balancer (ALB) in each region. Route 53 latency-based routing is used with health checks on each ALB. If the us-east-1 ALB becomes unhealthy, Route 53 automatically stops sending traffic to that region, directing all requests to eu-west-1. This setup requires careful TTL tuning (e.g., 60 seconds) and health check intervals (10 seconds with low threshold) to achieve sub-minute failover. Another common scenario is active-passive failover for a legacy application that runs on EC2 instances in a single region, with a standby environment in another region. Route 53 failover routing with a primary record pointing to the active environment and a secondary to the standby. Health checks monitor the primary's ELB endpoint. If the primary fails, DNS automatically resolves to the standby's IP. Misconfiguration often occurs when health checks are not associated with the correct record, or when the health check endpoint is not reachable from Route 53 (e.g., security groups blocking probes). Also, forgetting to set 'Evaluate Target Health' on alias records to ELBs can cause Route 53 to return unhealthy ELB IPs. In production, teams often use calculated health checks to combine multiple endpoints (e.g., web server and database) into a single health check for a service. Scaling considerations include the default limit of 256 health checks per account, which may be insufficient for large environments. Route 53 health checks also incur charges per check per month, so cost optimization may involve reducing check frequency or using CloudWatch alarm health checks instead of endpoint checks for some scenarios.