Route 53 Health Checks: What It Is and When to Use It

Definition

Amazon Route 53 Health Checks are a feature of the Amazon Route 53 Domain Name System (DNS) service that monitor the health and availability of your application's endpoints. They enable automated DNS failover by allowing Route 53 to stop responding to queries with an unhealthy resource and instead route traffic to a healthy alternative.

How It Works

Route 53 health checks determine the health of your resources by sending automated requests from a global network of health checkers to your specified endpoint. An endpoint can be an IP address, a domain name, or even another health check or an Amazon CloudWatch alarm. The service evaluates the health based on criteria you define, such as response time, HTTP status codes, or the presence of a specific string in the response body.

There are three main types of health checks:

1. Endpoint Health Checks: These directly monitor an IP address or domain name using HTTP, HTTPS, or TCP protocols. Route 53 considers the endpoint healthy if a sufficient percentage of checkers (over 18%) receive a successful response within a defined threshold.
2. CloudWatch Alarm Health Checks: This type monitors the state of a CloudWatch alarm. This is a powerful mechanism for monitoring resources that are not publicly accessible, such as instances within a private Amazon Virtual Private Cloud (VPC). A Lambda function or other process within the VPC can publish metrics to CloudWatch, and an alarm can trigger the health check status, effectively informing the public DNS plane about the health of a private resource.
3. Calculated Health Checks: These combine the results of multiple other health checks using logical operators (AND, OR, NOT). You can, for example, create a parent health check that is only considered healthy if a certain number of its child health checks are also healthy, which is useful for managing complex applications or during maintenance.

When a health check determines an endpoint is unhealthy, Route 53 routing policies—most notably the Failover routing policy—can automatically redirect traffic to a pre-configured secondary, healthy endpoint, such as a backup web server in a different AWS Region.

Key Features and Limits

• Global Health Check Network: Requests originate from a diverse network of locations around the world, providing a comprehensive view of your endpoint's public availability.
• Multiple Protocol Support: Supports health checks over HTTP, HTTPS, and TCP.
• Advanced Health Check Options: Offers features like string matching in the response body, latency measurement, and configurable request intervals (standard or fast).
• Integration with CloudWatch: All health checks publish metrics to Amazon CloudWatch, allowing you to create alarms and receive notifications when an endpoint's health status changes.
• Calculated Health Checks: Combine up to 256 child health checks for sophisticated health evaluation logic.
• Service Quotas (as of 2026): By default, you can create up to 200 health checks per AWS account, though this is an adjustable quota. A calculated health check can monitor up to 255 child health checks.

Common Use Cases

• Active-Passive DNS Failover: The primary use case is to automatically redirect users from a primary environment to a standby disaster recovery (DR) environment when the primary becomes unavailable.
• High Availability for Multi-Region Architectures: In conjunction with latency-based or geolocation routing, health checks ensure that traffic is only sent to regions that are both low-latency and currently healthy.
• Removing Unhealthy Endpoints from Multivalue Answer DNS: When using Multivalue Answer routing, which returns multiple IP addresses for a domain, health checks ensure that only the IP addresses of healthy endpoints are included in DNS responses.
• Monitoring and Alerting: By integrating with CloudWatch, health checks can serve as a simple, external monitoring system to trigger alarms and notify operations teams of an outage, even if you aren't using DNS failover.

Pricing Model

Amazon Route 53 Health Checks are billed on a per-health-check, per-month basis. The pricing structure as of 2026 is as follows:

• Basic Health Checks: There's a monthly charge for each health check. The price differs for monitoring AWS endpoints versus non-AWS endpoints.
• Free Tier: AWS provides a free tier for the first 50 health checks that monitor AWS resources.
• Optional Features: Additional charges apply for enabling features like HTTPS checks, string matching, fast request intervals, and latency measurement.
• Calculated and CloudWatch-based Checks: These are billed at the same rate as basic health checks for AWS endpoints.

Health checks for certain AWS resources, like Elastic Load Balancers and Amazon S3 website endpoints, are provided at no additional charge when using Alias records with the "Evaluate Target Health" feature. For detailed and current pricing, always consult the official AWS Pricing Calculator.

Pros and Cons

Pros:

• High Reliability and Global Distribution: The distributed nature of the health checkers prevents a local network issue from incorrectly marking a global endpoint as unhealthy.
• Deep AWS Integration: Seamlessly integrates with Route 53 routing policies for automated failover and with CloudWatch for monitoring and alerting.
• Flexible Health-Check Logic: Supports basic endpoint checks, monitoring of internal resources via CloudWatch alarms, and complex logic with calculated health checks.

Cons:

• Cannot Directly Check Private Endpoints: Health checkers are public and cannot directly reach resources inside a VPC without a public IP address. The workaround requires setting up CloudWatch alarms and potentially Lambda functions.
• DNS Caching Delays: Failover is not instantaneous. Due to the nature of DNS, clients and resolvers may cache the old, unhealthy IP address for the duration of its Time-To-Live (TTL), delaying the failover for some users.
• Cost: While flexible, the cost can increase, especially when using optional features or monitoring a large number of non-AWS endpoints.

Comparison with Alternatives

• Elastic Load Balancing (ELB) Health Checks: ELB health checks operate at the load balancer level, typically within a single region, to determine which backend targets (e.g., EC2 instances) are healthy enough to receive traffic from the load balancer. Route 53 health checks operate at the global DNS level, determining which entire endpoint (which could be an ELB itself) should receive traffic from users around the world. They solve for different scopes: ELB for intra-region high availability, and Route 53 for inter-region disaster recovery and DNS-level load balancing.

• Amazon CloudWatch Alarms: CloudWatch is a full-fledged monitoring and observability service that can track a vast array of metrics from nearly any AWS service or custom application. While a Route 53 health check can monitor a CloudWatch alarm, it is not a replacement for CloudWatch. CloudWatch is used for detailed performance monitoring, logging, and triggering a wide range of automated actions, whereas Route 53 health checks are specifically designed to make DNS routing decisions.

Exam Relevance

Route 53 Health Checks are a critical topic for several AWS certifications, particularly:

• AWS Certified Solutions Architect - Associate (SAA-C03): Examinees must understand how to use health checks with Failover, Multivalue Answer, and Latency routing policies to design highly available and fault-tolerant systems.
• AWS Certified Solutions Architect - Professional (SAP-C02): This exam requires a deeper understanding of multi-region failover strategies, the nuances of DNS propagation, and how to use calculated health checks and CloudWatch alarms for complex recovery scenarios.
• AWS Certified DevOps Engineer - Professional (DOP-C02): Candidates should know how to automate failover procedures and integrate Route 53 health checks into a broader monitoring and incident response strategy.

Key exam concepts include the difference between Alias records with "Evaluate Target Health" and standard health checks, and the pattern for monitoring private resources in a VPC.

Frequently Asked Questions

Q: What is the difference between a Route 53 health check and an ELB health check?

A: An ELB health check is used by a Load Balancer within a region to determine which of its registered targets (like EC2 instances) are healthy. It operates at the traffic-distribution layer inside your VPC. A Route 53 health check is used at the global DNS layer to determine which entire endpoint (like a whole region's ELB) is healthy, enabling DNS-level failover between regions or data centers.

Q: Can I use Route 53 health checks to monitor resources inside a private VPC?

A: Not directly, because Route 53's health checkers are on the public internet and cannot access private IP addresses. The recommended pattern is to use an Amazon CloudWatch alarm to monitor the private resource (e.g., via a custom metric pushed by a Lambda function). You then create a Route 53 health check that monitors the state of the CloudWatch alarm, effectively linking the private resource's health to a public DNS failover decision.

Q: How does Route 53 determine if an endpoint is unhealthy?

A: For endpoint checks, Route 53 uses a network of checkers in different locations. It considers an endpoint unhealthy if 18% or fewer of these checkers report it as healthy over a configurable number of consecutive checks (typically three). This consensus mechanism prevents localized network problems from triggering a false positive and causing an unnecessary failover.

---

This article reflects AWS features and pricing as of 2026. AWS services evolve rapidly — always verify against the official AWS documentation before making production decisions.