Route 53 Health Checks & Failover

Monitoring Targets:

• IP address (IPv4 or IPv6)
• Domain name (resolves to IP)
• HTTP, HTTPS, or TCP endpoints

Key Parameters:

• Request Interval: 10 seconds (fast) or 30 seconds (standard)
• Failure Threshold: Number of consecutive failures (1-10)
• Health Checker Regions: Choose specific regions or let AWS choose
• Port: TCP port to check (1-65535)
• Path: URL path for HTTP/HTTPS checks (e.g., /health)
• Search String: Text that must appear in response body (optional)
• Latency Graphs: Enable for performance monitoring

How It Works: Route 53 health checkers in multiple data centers worldwide send requests to your endpoint. If 18% or more of health checkers report the endpoint as healthy, Route 53 considers it healthy.

Aggregation Options:

1. AND Logic: Healthy only if ALL child health checks are healthy

   • Use for critical dependencies that must all be available

2. OR Logic: Healthy if at least ONE child health check is healthy

   • Use for redundant resources where any one being healthy is sufficient

3. Threshold: Healthy if at least N of M child health checks are healthy

   • Use for minimum quorum scenarios (e.g., 2 of 3 database replicas)

Inversion: Any health check can be inverted (healthy becomes unhealthy and vice versa)

How It Works:

1. Create a CloudWatch alarm monitoring a metric (e.g., CPU, error rate, custom metric)
2. Create a Route 53 health check that monitors the alarm's data stream
3. Health check status reflects the alarm state:
   • Alarm state = OK → Health check = Healthy
   • Alarm state = ALARM → Health check = Unhealthy
   • Alarm state = INSUFFICIENT_DATA → Configurable (healthy or unhealthy)

Limitations:

• Must be in the same AWS account
• Does not support metric math alarms
• Only supports standard-resolution metrics (not high-resolution)

Configuration:

1. Create health check for primary resource
2. Create two records with same name, different values:
   • Primary: Points to main resource, associated with health check
   • Secondary: Points to backup resource (can have health check too)
3. Use Failover routing policy

Behavior:

• When primary is healthy → Route 53 returns primary record
• When primary fails → Route 53 automatically returns secondary record
• When primary recovers → Route 53 returns to primary (failback)

Supported Routing Policies:

• Weighted: Distribute traffic by weight; unhealthy endpoints get zero traffic
• Latency: Route to lowest latency endpoint; skip unhealthy ones
• Geolocation: Route by user location; fail to next match if unhealthy
• Multivalue Answer: Return up to 8 healthy IPs per query

Key Difference from Active-Passive:

• All resources actively serve traffic
• No single "standby" resource
• Automatic removal of unhealthy endpoints from DNS responses

Request Interval:

• Standard (30 seconds): Lower cost, suitable for most workloads
• Fast (10 seconds): Faster detection, 3x the cost, requires more health checker regions

Failure Threshold:

• Number of consecutive failures before marking unhealthy (1-10)
• Lower threshold = faster failover but more false positives
• Recommended: 3 for production workloads

Health Checker Regions:

• Minimum of 3 regions required
• More regions = more accurate health assessment
• Can customize to match your user base geography

String Matching (HTTP/HTTPS):

• Search first 5,120 bytes of response body
• Must appear within 4 seconds of request
• Case-sensitive exact match
• Useful for validating application health, not just server availability

Architecture:

                        ┌─────────────────┐
                        │   Route 53      │
                        │ Hosted Zone     │
                        └────────┬────────┘
                                 │
              ┌──────────────────┼──────────────────┐
              │                  │                  │
    ┌─────────▼─────────┐ ┌─────▼─────┐ ┌─────────▼─────────┐
    │  Latency Record   │ │  Latency  │ │  Latency Record   │
    │    us-east-1      │ │  Record   │ │    eu-west-1      │
    │  (Health Check)   │ │ ap-south-1│ │  (Health Check)   │
    └─────────┬─────────┘ └─────┬─────┘ └─────────┬─────────┘
              │                 │                  │
    ┌─────────▼─────────┐ ┌─────▼─────┐ ┌─────────▼─────────┐
    │       ALB         │ │    ALB    │ │       ALB         │
    │   (Primary)       │ │           │ │   (Primary)       │
    └───────────────────┘ └───────────┘ └───────────────────┘

Behavior:

1. Route 53 routes users to lowest-latency healthy region
2. If regional endpoint fails health check, excluded from responses
3. Users automatically routed to next-lowest-latency region

A common disaster recovery pattern uses S3 to host a static error page when the primary application is unavailable.

Setup:

1. Primary: ALB with health check
2. Secondary: S3 bucket configured for static website hosting
3. CloudFront distribution with both origins (optional for HTTPS)

Route 53 Configuration:

• Failover routing policy
• Primary alias record → ALB (with health check)
• Secondary alias record → CloudFront/S3 (no health check needed)

Use Case: Graceful degradation when entire application stack is unavailable

ARC provides a simplified way to manage recovery across AWS Regions and Availability Zones.

Key Components:

• Routing Controls: On/off switches for traffic routing
• Readiness Checks: Verify resources are ready to handle traffic
• Safety Rules: Prevent unsafe configuration changes

Integration with Route 53:

• Routing controls connect to Route 53 health checks
• Update routing control → triggers health check state change → updates DNS

Benefits:

• Single API call to fail over entire application
• Safety rules prevent accidental misconfiguration
• Works with private resources
• No dependency on primary region during failover

Route 53 publishes health check metrics to CloudWatch for monitoring and alerting.

Available Metrics:

• HealthCheckStatus: 1 (healthy) or 0 (unhealthy)
• HealthCheckPercentageHealthy: Percentage of health checkers reporting healthy
• ConnectionTime: Time to establish TCP connection (ms)
• SSLHandshakeTime: Time for SSL/TLS handshake (ms)
• TimeToFirstByte: Time to first response byte (ms)

Alarm Examples:

# Alert when health check fails
Metric: HealthCheckStatus
Threshold: < 1
Period: 1 minute
Evaluation Periods: 1