Amazon Route 53: Health Checks and DNS Failover
Amazon Route 53 health checks monitor the availability of your endpoints (public HTTP/HTTPS/TCP, or a CloudWatch alarm) and power DNS failover. In a Failover policy, associate the health check with the primary record; if it turns unhealthy, Route 53 returns the secondary record so users are routed to a healthy endpoint.
It’s common to use two or more resources that perform the same function in the AWS Cloud, such as two or more web servers (EC2 instances) or whole multi-tier infrastructures with web servers, databases, and static data storage. But how can you know that part of your infrastructure is working and that you are prepared to route your traffic somewhere else if it fails? This is where Amazon Route 53 DNS health checks and failover come in.
In this blog post, you will learn about Route 53 health-checking features and how to only route traffic to healthy AWS resources.
What is the Amazon Route 53 health check?
Route 53 health checks are a function that allow you to monitor the health of selected types of AWS resources or any endpoints that can respond to requests. Route 53 health checks can provide notifications of a change in the state of the health check and can help Route 53 to recognize when a record is pointing to an unhealthy resource, allowing Route 53 to failover to an alternate record.
Types of Route 53 health checks
At this moment three different types of Route 53 health checks are available to us. Endpoint health checks are the most common.
- Endpoint health checks: You can configure to monitor an endpoint that you specify by IP address or domain name. Within a fixed time interval that you specify. Route 53 submits automated requests over the Internet to your application, server, or other resources to verify that it is accessible, available, and functioning properly.
- Health checks that monitor other health checks: This type of health check monitors other Route 53 health checks. Basically, a "parent" health check will monitor one or more "child" health checks. If the provided number of child health checks report as healthy, then parent health checks will also be healthy. If the number of healthy "child" checks falls below a set threshold, the "parent" check will be unhealthy.
- Health checks for Amazon CloudWatch Alarms: You can also perform health checks associated with alarms created in the CloudWatch service. These types of Route 53 health checks monitor CloudWatch data streams sent to previously configured alarms. If the status of the CloudWatch alarm is OK, the health check will report as OK.
Amazon Route 53 DNS failover routing
Failover redirects your production traffic from the primary region to the recovery region. If you use Route 53 for DNS, you can set up your primary region and recovery region endpoints under one domain name.
A routing policy is then selected to determine which endpoint receives traffic for that domain name. If the primary server is unhealthy based on your configured health checks, failover routing will automatically send traffic to the recovery area.
Route 53 active-passive vs active-active failover
The main difference between the two architectures is when the architecture is available and running. Active-active failover gives you access to all resources during normal operation. In an active-passive failover, the backup resources only see operations during the failover and are usually in a standby state.
Active-active failover
Active-active failover is used when you want all of your app nodes in all regions to be available simultaneously. Use this failover configuration when you want all of your resources to be available the majority of the time.
In this example, both region 1 and region 2 are active all the time. When a resource becomes unavailable, Route 53 can detect that it's unhealthy and stop including it when responding to queries.
For example, this can be created by using Route 53 weighted, geolocation, geoproximity, latency and multivalue answer routing policy.
Active-passive failover
Use an active-passive failover configuration when you want a primary resource or group of resources to be available the majority of the time and you want a secondary resource or group of resources to be on standby in case all the primary resources become unavailable.
In this example, only region 1 is active all the time and region 2 will be only active when failover starts (after region 1 is unavailable).
This can be created by using Route 53 failover routing policy.
Stormit helps you to optimize your cost if you are already using the AWS cloud or just planning your cloud adoption.
Route 53 health check and failover example
This guide will show you how to set up a simple Route 53 active-passive failover with health checks in AWS Management Console. Our architecture is based in two regions and has Application load balancers (ALB), Auto Scaling groups, and EC2 instances (simple web servers).
The primary region is in Frankfurt. The secondary region is in Ireland.
This guide does not contain instructions on how to put some of the resources into operation. In this example, we already have some elements prepared, except for health checks and failover settings in Route 53.
Configuring Route 53 health checks for ALB
1. Log into the Route 53 Console.
2. Click on “Health checks” and then on “Create health check”.
3. Set the name of your Health check and provide the domain name of your ALB. And under Advanced configuration set “Request Interval” to 10 seconds and “Failure threshold” to 1. Click on “Next”.
4. In the next step only click on “Create health check”.
5. Repeat points 2, 3, and 4 with a different name and domain for the second ALB in a different region. You don’t have to change the Advanced configuration.
6. After a couple of seconds, you should see that our ALBs are healthy.
Configuring Route 53 failover
1. Click on “Hosted zones” in the Route 53 Console and on our hosted zone.
2. Click on “Create record”.
3. In the Quick create record window, fill in the details:
a. Record name: www. This tells Route 53 that it should direct traffic from our domain **www.**example.com to our ALB.
b. Select Alias.
c. Route traffic to: Select a domain name of ALB.
d. Routing policy: Failover.
e. Failover record type: Primary.
f. Health check: ALB-Frankfurt (name of the health check for the primary ALB).
g. Record ID: Frankfurt-ALB.
h. Click on “Add another record”.
4. Fill in the details for record 2; some of them are the same as for record 1:
a. Route traffic to: Select a domain name of ALB.
b. Failover record type: Secondary.
c. Health check: ALB-Ireland (name of the health check for the secondary EC2 instance).
d. Record ID: Ireland-ALB.
e. Click on “Create records”.
5. We should see the created records in the Route 53 Console.
6. Now, if the first ALB in the Frankfurt region is unavailable another one in the Ireland region will simply take its place.
FAQs
A Route 53 health check monitors an endpoint (or a CloudWatch alarm / calculated check) and marks it healthy or unhealthy. You can use that result to drive DNS failover so queries resolve only to healthy targets.
Publicly reachable HTTP, HTTPS, or TCP endpoints, by DNS name or IP. Health checkers run from AWS locations on the public Internet. For private/VPC-only resources, use a CloudWatch-based or calculated health check (direct HTTP/TCP probes can’t reach private endpoints).
Create a health check, choose the interval and failure threshold, then use a Failover routing policy: associate the health check with the PRIMARY record. When it becomes unhealthy, Route 53 returns the SECONDARY record. (If your record is an ALIAS to an ALB/NLB, you can alternatively enable Evaluate target health to use the load balancer’s own health.)
Multiple health-checker locations probe at your configured interval (e.g., 10s/30s). If enough consecutive probes fail to meet the failure threshold, the status flips to Unhealthy; consecutive successes return it to Healthy. For HTTP/HTTPS checks you can optionally require a specific status code or response string.
Create an ALIAS record pointing to the load balancer and enable Evaluate target health – Route 53 will use the load balancer’s target health for DNS decisions. For internal load balancers in private hosted zones, this works the same way; use CloudWatch-based checks only when you need health for private resources from a public zone or want to combine custom conditions.
An AWS Solutions Architect with over 5 years of experience in designing, assessing, and optimizing AWS cloud architectures. At Stormit, he supports customers across the full cloud lifecycle — from pre-sales consulting and solution design to AWS funding programs such as AWS Activate, Proof of Concept (PoC), and the Migration Acceleration Program (MAP).
