Health Checks and DNS Failover

Route 53 health checks continuously monitor the health of your endpoints—web servers, load balancers, or any HTTP/HTTPS/TCP endpoint accessible on the internet. Based on health check results, Route 53 can automatically update DNS routing to avoid sending traffic to unhealthy resources.

Health checks are billed per health check per month. Route 53 global health checkers (located in multiple Regions) probe your endpoint simultaneously, providing redundancy in the health checking itself. An endpoint is considered unhealthy only when a threshold number of checkers agree it has failed.

Endpoint health checks monitor a specific IP address or domain name with your chosen protocol (HTTP, HTTPS, or TCP), port, and optional path. For HTTP/HTTPS checks, Route 53 verifies that the endpoint returns a 2xx or 3xx HTTP status code within the timeout period. For HTTPS checks, it optionally validates the TLS certificate.

Key configuration options: request interval (10 or 30 seconds—10 seconds is faster detection but costs more), failure threshold (1–10 consecutive failures before marking unhealthy), and string matching (optionally verify the response body contains a specific string).

Calculated health checks combine the results of multiple child health checks using Boolean logic (AND, OR, NOT). They enable you to define application-level health based on multiple signals without creating complex routing chains.

Example: a web application is healthy only if both the API server check AND the database check pass. Create a calculated health check with type AND that references both endpoint checks. If either fails, the calculated health check fails and Route 53 removes the associated DNS record from responses.

CloudWatch alarm health checks link a Route 53 health check to the state of a CloudWatch alarm. If the alarm is in the ALARM state, the health check is marked unhealthy; if OK or INSUFFICIENT_DATA, it is marked healthy.

This pattern is powerful for endpoints inside a VPC (which cannot be reached by Route 53's external health checkers). Instead of probing the private endpoint, you create CloudWatch metrics and alarms for it, then base the Route 53 health check on the alarm state. This also enables health checking based on business metrics like error rate or queue depth.

Route 53 health checkers are AWS-managed servers outside your VPC that reach endpoints over the public internet. Resources in private subnets are unreachable by standard endpoint health checks. For private endpoints, use one of these approaches:

• Publish a custom CloudWatch metric from inside the VPC (e.g., a success/fail signal from the application), create an alarm, and use a CloudWatch alarm health check
• Use a CloudWatch composite alarm that aggregates ELB, RDS, or application metrics inside the VPC

This pattern is critical for private-subnet databases, internal load balancers, and backend services.

You can view health check status in the Route 53 console under Health Checks or query it via the API. Route 53 publishes health check metrics to CloudWatch in the AWS/Route53 namespace, including HealthCheckStatus (1 = healthy, 0 = unhealthy) and HealthCheckPercentageHealthy (percentage of Route 53 checkers that report the endpoint as healthy).

Set up CloudWatch alarms on HealthCheckStatus to receive SNS notifications when an endpoint goes unhealthy, giving you visibility before your on-call team notices the DNS failover has already occurred.

When Route 53 detects that a Primary record's health check has failed, it removes the Primary from DNS responses and returns the Secondary's address. This is called DNS failover. The switch occurs within the evaluation period (number of health checker failures × request interval) plus the TTL of the record.

Example: request interval = 30 s, failure threshold = 3, TTL = 60 s. Worst-case failover time ≈ 3 × 30 + 60 = 150 seconds. Setting a lower TTL (e.g., 10 seconds) and faster health check interval (10 s) can reduce this to 3 × 10 + 10 = 40 seconds.

Health checks can be associated with Weighted and Latency records too, not just Failover records. When a Weighted record's health check fails, Route 53 redistributes that record's traffic weight proportionally among healthy weighted records. When a Latency record's health check fails, Route 53 routes queries to the next-lowest-latency healthy record.

This makes Weighted and Latency routing policies resilient to endpoint failures without requiring explicit Failover records. It is a common SAA-C03 pattern: Latency routing across Regions with health checks provides both performance optimisation and automatic disaster recovery.

A resilient multi-region active-active pattern using Route 53:

1. Create Latency records for each Region (us-east-1, eu-west-1, ap-southeast-1), each with a health check
2. When all Regions are healthy, users are routed to the lowest-latency Region
3. If one Region's health check fails (application down or unresponsive), Route 53 automatically removes it from DNS responses and routes queries to the next-best healthy Region
4. When the failed Region recovers, health check passes and Route 53 reintroduces it into the rotation

This provides automatic global failover with performance optimisation—no manual intervention required.

Route 53 health checkers originate from a set of published IP ranges in the ROUTE53_HEALTHCHECKS section of the AWS IP ranges JSON file. If your endpoint is protected by a firewall or security group that restricts inbound access, you must allow traffic from these IP ranges for health checks to succeed.

Alternatively, use a public-facing endpoint that proxies to your private backend (such as an ALB) for health checking. The ALB's security group only needs to allow Route 53 IP ranges, while the backend's security group only allows the ALB security group—maintaining a defence-in-depth approach.

Best practices for Route 53 health checks:

• Create a dedicated /health endpoint that checks all critical dependencies (database connectivity, cache reachability) and returns 200 only when fully operational
• Use a 10-second request interval for critical production endpoints to detect failures faster
• Monitor HealthCheckPercentageHealthy in CloudWatch—a partial failure (some but not all Route 53 checkers failing) may indicate a regional network issue or intermittent problem
• For VPC-private resources, use CloudWatch alarm health checks based on application metrics
• Test failover in non-production environments before relying on it in production

Test your understanding of AWS Solutions Architect (SAA-C03) concepts from this lesson.

In this lesson you learned: endpoint health checks probe HTTP/HTTPS/TCP from external Route 53 checkers, CloudWatch alarm health checks enable monitoring of private VPC resources, and calculated health checks combine multiple signals with Boolean logic. DNS failover speed depends on health check interval, failure threshold, and TTL. Next up we explore CloudFront distributions and origins.