# Configuring DNS failover
When you have more than one resource performing the same function—for example, more than one HTTP server or mail server—you can configure Amazon Route 53 to check the health of your resources and respond to DNS queries using only the healthy resources. For example, suppose your website, example.com, is hosted on six servers, two each in three data centers around the world. You can configure Route 53 to check the health of those servers and to respond to DNS queries for example.com using only the servers that are currently healthy.
Route 53 can check the health of your resources in both simple and complex configurations:
+ In simple configurations, you create a group of records that all have the same name and type, such as a group of weighted records with a type of A for example.com. You then configure Route 53 to check the health of the corresponding resources. Route 53 responds to DNS queries based on the health of your resources. For more information, see [How health checks work in simple Amazon Route 53 configurationsHow health checks work in simple configurations](dns-failover-simple-configs.md).
+ In more complex configurations, you create a tree of records that route traffic based on multiple criteria. For example, if latency for your users is your most important criterion, then you might use latency alias records to route traffic to the region that provides the best latency. The latency alias records might have weighted records in each region as the alias target. The weighted records might route traffic to EC2 instances based on the instance type. As with a simple configuration, you can configure Route 53 to route traffic based on the health of your resources. For more information, see [How health checks work in complex Amazon Route 53 configurationsHow health checks work in complex configurations](dns-failover-complex-configs.md).
**Topics**
+ [
# Task list for configuring DNS failover
](dns-failover-how-to.md)
+ [
# How health checks work in simple Amazon Route 53 configurations
](dns-failover-simple-configs.md)
+ [
# How health checks work in complex Amazon Route 53 configurations
](dns-failover-complex-configs.md)
+ [
# How Amazon Route 53 chooses records when health checking is configured
](health-checks-how-route-53-chooses-records.md)
+ [
# Active-active and active-passive failover
](dns-failover-types.md)
+ [
# Configuring failover in a private hosted zone
](dns-failover-private-hosted-zones.md)
+ [
# How Amazon Route 53 averts failover problems
](dns-failover-problems.md)
# Task list for configuring DNS failover
To use Route 53 to configure DNS failover, perform the following tasks:
1. Draw a complete tree diagram of your configuration, and indicate which type of record you're creating (weighted alias, failover, latency, and so on) for each node. At the top of the tree put the records for the domain name, such as example.com, that your users will use to access your website or web application.
The kinds of records that appear in your tree diagram depend on the complexity of the configuration:
+ In a simple configuration, either your diagram won't include any alias records, or the alias records will route traffic directly to a resource, such as an ELB load balancer, instead of to another Route 53 record. For more information, see [How health checks work in simple Amazon Route 53 configurationsHow health checks work in simple configurations](dns-failover-simple-configs.md).
+ In a complex configuration, your diagram will include a combination of alias records (such as weighted alias and failover alias) and non-alias records in a multi-level tree like the examples in the topic [How health checks work in complex Amazon Route 53 configurationsHow health checks work in complex configurations](dns-failover-complex-configs.md).
**Note**
To quickly and easily create records for complex routing configurations and associate the records with health checks, you can use the traffic flow visual editor and save the configuration as a traffic policy. You can then associate the traffic policy with one or more domain names (such as example.com) or subdomain names (such as www.example.com), in the same hosted zone or in multiple hosted zones. In addition, you can roll back the updates if the new configuration isn't performing as you expected it to. For more information, see [Using Traffic Flow to route DNS traffic](traffic-flow.md).
For more information, see the following documentation:
+ [Choosing a routing policy](routing-policy.md)
+ [Choosing between alias and non-alias records](resource-record-sets-choosing-alias-non-alias.md)
1. Create health checks for the resources that you can't create alias records for, such as Amazon EC2 servers and email servers running in your data center. You'll associate these health checks with your non-alias records.
For more information, see [Creating, updating, and deleting health checks](health-checks-creating-deleting.md).
1. If necessary, configure router and firewall rules so that Route 53 can send regular requests to the endpoints that you specified in your health checks. For more information, see [Configuring router and firewall rules for Amazon Route 53 health checksConfiguring router and firewall rules for health checks](dns-failover-router-firewall-rules.md).
1. Create all the non-alias records in your diagram, and associate the health checks that you created in step 2 with the applicable records.
If you're configuring DNS failover in a configuration that doesn't include any alias records, skip the remaining tasks.
1. Create the alias records that route traffic to AWS resources, such as ELB load balancers and CloudFront distributions. If you want Route 53 to try another branch of the tree when a resource is unhealthy, set the value of **Evaluate Target Health** to **Yes** for each of your alias records. (**Evaluate Target Health** isn't supported for some AWS resources.)
1. Starting at the bottom of the tree diagram that you created in step 1, create the alias records that route traffic to the records that you created in steps 4 and 5. If you want Route 53 to try another branch of the tree when all the non-alias records are unhealthy in a branch of your tree, set the value of **Evaluate Target Health** to **Yes** for each of your alias records.
Remember that you can't create an alias record that routes traffic to another record until you have created the other record.
# How health checks work in simple Amazon Route 53 configurations
When you have two or more resources that perform the same function, such as two or more web servers for example.com, you can use the following health-checking features to route traffic only to the healthy resources:
**Check the health of EC2 instances and other resources (non-alias records)**
If you're routing traffic to resources that you can't create alias records for, such as EC2 instances, you create a record and a health check for each resource. Then you associate each health check with the applicable record. Health checks regularly check the health of the corresponding resources, and Route 53 routes traffic only to the resources that health checks report as healthy.
**Evaluate the health of an AWS resource (alias records)**
If you're using [alias records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) to route traffic to selected AWS resources, such as ELB load balancers, you can configure Route 53 to evaluate the health of the resource and to route traffic only to resources that are healthy. When you configure an alias record to evaluate the health of a resource, you don't need to create a health check for the resource.
Here's an overview of how you configure Route 53 to check the health of your resources in simple configurations:
1. You identify the resources that you want Route 53 to monitor. For example, you might want to monitor all the HTTP servers that respond to requests for example.com.
1. You create health checks for the resources that you can't create alias records for, such as EC2 instances or servers in your own data center. You specify how to send health-checking requests to the resource: which protocol to use (HTTP, HTTPS, or TCP), which IP address and port to use, and, for HTTP/HTTPS health checks, a domain name and path.
**Note**
If you're using any resources that you can create alias records for, such as ELB load balancers, don't create health checks for those resources.
A common configuration is to create one health check for each resource and to use the same IP address for the health check endpoint as for the resource. The health check sends requests to the specified IP address.
**Note**
Route 53 can't check the health of resources that have an IP address in local, private, nonroutable, or multicast ranges. For more information about IP addresses that you can't create health checks for, see [RFC 5735, Special Use IPv4 Addresses](https://datatracker.ietf.org/doc/html/rfc5735) and [RFC 6598, IANA-Reserved IPv4 Prefix for Shared Address Space](https://datatracker.ietf.org/doc/html/rfc6598).
For more information about creating health checks, see [Creating, updating, and deleting health checks](health-checks-creating-deleting.md).
1. You might need to configure router and firewall rules so that Route 53 can send regular requests to the endpoints that you specified in your health checks. For more information, see [Configuring router and firewall rules for Amazon Route 53 health checksConfiguring router and firewall rules for health checks](dns-failover-router-firewall-rules.md).
1. You create a group of records for your resources, for example, a group of weighted records. You can mix alias and non-alias records, but they all must have the same value for **Name**, **Type**, and **Routing Policy**.
How you configure Route 53 to check the health of your resources depends on whether you're creating alias records or non-alias records:
+ **Alias records** – Specify **Yes** for **Evaluate Target Health**.
+ **Non-alias records** – Associate the health checks that you created in step 2 with the corresponding records.
When you're finished, your configuration looks similar to the following diagram, which includes only non-alias records.
![\[Three weighted records and corresponding health checks.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/hc-weighted.png)
For more information about creating records by using the Route 53 console, see [Creating records by using the Amazon Route 53 console](resource-record-sets-creating.md).
1. If you created health checks, Route 53 periodically sends requests to the endpoint for each health check; it doesn't perform the health check when it receives a DNS query. Based on the responses, Route 53 decides whether the endpoints are healthy and uses that information to determine how to respond to queries. For more information, see [How Amazon Route 53 determines whether a health check is healthyHow Route 53 determines whether a health check is healthy](dns-failover-determining-health-of-endpoints.md).
Route 53 doesn't check the health of the resource specified in the record, such as the IP address that is specified in an A record for example.com. When you associate a health check with a record, Route 53 begins to check the health of the endpoint that you specified in the health check. You can also configure Route 53 to monitor the health of other health checks or monitor the data streams for CloudWatch alarms. For more information, see [Types of Amazon Route 53 health checksTypes of health checks](health-checks-types.md).
Here's what happens when Route 53 receives a query for example.com:
1. Route 53 chooses a record based on the routing policy. In this case, it chooses a record based on weight.
1. It determines the current health of the selected record by checking the status of the health check for that record.
1. If the selected record is unhealthy, Route 53 chooses a different record. This time, the unhealthy record isn't considered.
For more information, see [How Amazon Route 53 chooses records when health checking is configuredHow Route 53 chooses records when health checking is configured](health-checks-how-route-53-chooses-records.md).
1. When Route 53 finds a healthy record, it responds to the query with the applicable value, such as the IP address in an A record.
The following example shows a group of weighted records in which the third record is unhealthy. Initially, Route 53 selects a record based on the weights of all three records. If it happens to select the unhealthy record the first time, Route 53 selects another record, but this time it omits the weight of the third record from the calculation:
+ When Route 53 initially selects from among all three records, it responds to requests using the first record about 20% of the time, 10/(10 \$1 20 \$1 20).
+ When Route 53 determines that the third record is unhealthy, it responds to requests using the first record about 33% of the time, 10/(10 \$1 20).
![\[Three weighted records and the corresponding health checks. The third health check is unhealthy, so Route 53 considers the associated record to be unhealthy.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/hc-weighted-failed-hc.png)
If you omit a health check from one or more records in a group of records, Route 53 has no way to determine the health of the corresponding resource. Route 53 treats those records as healthy.
![\[Three weighted records, only two of which have health checks. Route 53 always considers the third record to be healthy.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/hc-weighted-missing-health-check.png)
# How health checks work in complex Amazon Route 53 configurations
Checking the health of resources in complex configurations works much the same way as in simple configurations. However, in complex configurations, you use a combination of alias records (such as weighted alias and failover alias) and non-alias records to build a decision tree that gives you greater control over how Route 53 responds to requests.
For example, you might use latency alias records to select a region close to a user and use weighted records for two or more resources within each region to protect against the failure of a single endpoint or an Availability Zone. The following diagram shows this configuration.
![\[DNS configuration that includes latency alias records and weighted alias records.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted.png)
Here's how Amazon EC2 and Route 53 are configured. Let's start at the bottom of the tree because that's the order that you'll create records in:
+ You have two EC2 instances in each of two regions, us-east-1 and ap-southeast-2. You want Route 53 to route traffic to your EC2 instances based on whether they're healthy, so you create a health check for each instance. You configure each health check to send health-checking requests to the corresponding instance at the Elastic IP address for the instance.
Route 53 is a global service, so you don't specify the region that you want to create health checks in.
+ You want to route traffic to the two instances in each region based on the instance type, so you create a weighted record for each instance and give each record a weight. (You can change the weight later to route more or less traffic to an instance.) You also associate the applicable health check with each instance.
When you create the records, you use names such as us-east-1-www.example.com. and ap-southeast-2-www.example.com. You'll wait until you get to the top of the tree to give records the names that your users will use to access your website or web application, such as example.com.
+ You want to route traffic to the region that provides the lowest latency for your users, so you choose the latency [routing policy](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) for the records at the top of the tree.
You want to route traffic to the *records* in each region, not directly to the *resources* in each region (the weighted records already do that). As a result, you create latency [alias records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html).
When you create the alias records, you give them the name that you want your users to use to access your website or web application, such as example.com. The alias records route traffic for example.com to the us-east-1-www.example.com and ap-southeast-2-www.example.com records.
For both latency alias records, you set the value of **Evaluate Target Health** to **Yes**. This causes Route 53 to determine whether there are any healthy resources in a region before trying to route traffic there. If not, Route 53 chooses a healthy resource in the other region.
![\[DNS configuration that includes latency alias records and weighted alias records.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-both-failed.png)
The preceding diagram illustrates the following sequence of events:
1. Route 53 receives a query for example.com. Based on the latency for the user making the request, Route 53 selects the latency alias record for the us-east-1 region.
1. Route 53 selects a weighted record based on weight. **Evaluate Target Health** is **Yes** for the latency alias record, so Route 53 checks the health of the selected weighted record.
1. The health check failed, so Route 53 chooses another weighted record based on weight and checks its health. That record also is unhealthy.
1. Route 53 backs out of that branch of the tree, looks for the latency alias record with the next-best latency, and chooses the record for ap-southeast-2.
1. Route 53 again selects a record based on weight, and then checks the health of the selected resource. The resource is healthy, so Route 53 returns the applicable value in response to the query.
**Topics**
+ [
## What happens when you associate a health check with an alias record?
](#dns-failover-complex-configs-hc-alias)
+ [
## What happens when you omit health checks?
](#dns-failover-complex-configs-hc-omitting)
+ [
## What happens when you set evaluate target health to No?
](#dns-failover-complex-configs-eth-no)
## What happens when you associate a health check with an alias record?
You can associate a health check with an alias record instead of or in addition to setting the value of **Evaluate Target Health** to **Yes**. However, it's generally more useful if Route 53 responds to queries based on the health of the underlying resources—the HTTP servers, database servers, and other resources that your alias records refer to. For example, suppose the following configuration:
+ You assign a health check to a latency alias record for which the alias target is a group of weighted records.
+ You set the value of **Evaluate Target Health** to **Yes** for the latency alias record.
In this configuration, both of the following must be true before Route 53 will return the applicable value for a weighted record:
+ The health check associated with the latency alias record must pass.
+ At least one weighted record must be considered healthy, either because it's associated with a health check that passes or because it's not associated with a health check. In the latter case, Route 53 always considers the weighted record healthy.
In the following illustration, the health check for the latency alias record on the top left failed. As a result, Route 53 stops responding to queries using any of the weighted records that the latency alias record refers to even if they're all healthy. Route 53 begins to consider these weighted records again only when the health check for the latency alias record is healthy again. (For exceptions, see [How Amazon Route 53 chooses records when health checking is configuredHow Route 53 chooses records when health checking is configured](health-checks-how-route-53-chooses-records.md).)
![\[DNS configuration that includes an alias record with both Evaluate Target Health set to Yes and a health check on the alias record.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-alias-hc-failed.png)
## What happens when you omit health checks?
In a complex configuration, it's important to associate health checks with all the non-alias records. In the following example, a health check is missing on one of the weighted records in the us-east-1 region.
![\[DNS configuration that includes one failed health check and one record that has no health check.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-missing-health-check.png)
Here's what happens when you omit a health check on a non-alias record in this configuration:
1. Route 53 receives a query for example.com. Based on the latency for the user making the request, Route 53 selects the latency alias record for the us-east-1 region.
1. Route 53 looks up the alias target for the latency alias record, and checks the status of the corresponding health checks. The health check for one weighted record failed, so that record is omitted from consideration.
1. The other weighted record in the alias target for the us-east-1 region has no health check. The corresponding resource might or might not be healthy, but without a health check, Route 53 has no way to know. Route 53 assumes that the resource is healthy and returns the applicable value in response to the query.
## What happens when you set evaluate target health to No?
In general, you should set **Evaluate Target Health** to **Yes** for all the alias records in a tree. If you set **Evaluate Target Health** to **No**, Route 53 continues to route traffic to the records that an alias record refers to even if health checks for those records are failing.
In the following example, all the weighted records have associated health checks, but **Evaluate Target Health** is set to **No** for the latency alias record for the us-east-1 region:
![\[DNS configuration that includes an alias record with Evaluate Target Health set to No.\]](http://docs.aws.amazon.com/Route53/latest/DeveloperGuide/images/hc-latency-alias-weighted-eth-is-no.png)
Here's what happens when you set **Evaluate Target Health** to **No** for an alias record in this configuration:
1. Route 53 receives a query for example.com. Based on the latency for the user making the request, Route 53 selects the latency alias record for the us-east-1 region.
1. Route 53 determines what the alias target is for the latency alias record, and checks the corresponding health checks. They're both failing.
1. Because the value of **Evaluate Target Health** is **No** for the latency alias record for the us-east-1 region, Route 53 must choose one record in this branch instead of backing out of the branch and looking for a healthy record in the ap-southeast-2 region.
# How Amazon Route 53 chooses records when health checking is configured
If you configure health checking for all the records in a group of records that have the same name, the same type (such as A or AAAA), and the same routing policy (such as weighted or failover), Route 53 responds to DNS queries by choosing a healthy record and returning the applicable value from that record.
For example, suppose you create three weighted A records, and you assign health checks to all three. If the health check for one of the records is unhealthy, Route 53 responds to DNS queries with the IP addresses in one of the other two records.
Here's how Route 53 chooses a healthy record:
1. Route 53 initially chooses a record based on the routing policy and on the values that you specify for each record. For example, for weighted records, Route 53 chooses a record based on the weight that you specify for each record.
1. Route 53 determines whether the record is healthy:
+ **Non-alias record with an associated health check** – If you associated a health check with a non-alias record, Route 53 checks the current status of the health check.
Route 53 periodically checks the health of the endpoint that is specified in a health check; it doesn't perform the health check when the DNS query arrives.
You can associate health checks with alias records, but we recommend that you associate health checks only with non-alias records. For more information, see [What happens when you associate a health check with an alias record?](dns-failover-complex-configs.md#dns-failover-complex-configs-hc-alias).
+ **Alias record with Evaluate Target Health set to Yes** – Route 53 checks the health status of the resource that the alias record references, for example, an ELB load balancer or another record in the same hosted zone.
1. If the record is healthy, Route 53 responds to the query with the applicable value, such as an IP address.
If the record is unhealthy, Route 53 chooses another record using the same criteria and repeats the process until it finds a healthy record.
Route 53 uses the following criteria when choosing a record:
**Records without a health check are always healthy**
If a record in a group of records that have the same name and type doesn't have an associated health check, Route 53 always considers it healthy and always includes it among possible responses to a query.
**If no record is healthy, all records are healthy**
If none of the records in a group of records are healthy, Route 53 needs to return something in response to DNS queries, but it has no basis for choosing one record over another. In this circumstance, Route 53 considers all the records in the group to be healthy and selects one based on the routing policy and on the values that you specify for each record.
**Weighted records that have a weight of 0**
If you add health checks to all the records in a group of weighted records, but you give nonzero weights to some records and zero weights to others, health checks work the same as when all records have nonzero weights with the following exceptions:
+ Route 53 initially considers only the nonzero weighted records, if any.
+ If all the records that have a weight greater than 0 are unhealthy, then Route 53 considers the zero-weighted records.
Because Route 53 will consider the zero-weighted records in some circumstances, it is important to make sure that the zero-weight target also has a viable answer to a DNS query.
For more information about weighted records, see [Health checks and weighted routing](routing-policy-weighted.md#routing-policy-weighted-healthchecks).
**Alias records**
You can also configure health checking for alias records by setting **Evaluate Target Health** to **Yes** for each alias record. This causes Route 53 to evaluate the health of the resource that the record routes traffic to, for example, an ELB load balancer or another record in the same hosted zone.
For example, suppose the alias target for an alias record is a group of weighted records that all have nonzero weights:
+ As long as at least one of the weighted records is healthy, Route 53 considers the alias record to be healthy.
+ If none of the weighted records is healthy, Route 53 considers the alias record to be unhealthy.
+ Route 53 stops considering records in that branch of the tree until at least one weighted record becomes healthy again.
For more information, see [How health checks work in complex Amazon Route 53 configurationsHow health checks work in complex configurations](dns-failover-complex-configs.md).
**Failover records**
Failover records generally work the same way as other routing types. You create health checks and associate them with non-alias records, and you set **Evaluate Target Health** to **Yes** for alias records. Note the following:
+ Both the primary and secondary records can be a non-alias record or an alias record.
+ If you associate health checks with both the primary and secondary failover records, here's how Route 53 responds to requests:
+ If Route 53 considers the primary record healthy (if the health check endpoint is healthy), Route 53 returns only the primary record in response to a DNS query.
+ If Route 53 considers the primary record unhealthy and the secondary record healthy, Route 53 returns the secondary record instead.
+ If Route 53 considers both the primary and secondary records unhealthy, Route 53 returns the primary record.
+ When you're configuring the secondary record, adding a health check is optional. If you omit the health check for the secondary record, and if the health check endpoint for the primary record is unhealthy, Route 53 always responds to DNS queries by using the secondary record. This is true even if the secondary record is unhealthy.
For more information, see the following topics:
+ [Configuring active-passive failover with one primary and one secondary resource](dns-failover-types.md#dns-failover-types-active-passive-one-resource)
+ [Configuring active-passive failover with multiple primary and secondary resources](dns-failover-types.md#dns-failover-types-active-passive-multiple-resources)
# Active-active and active-passive failover
You can use Route 53 health checking to configure active-active and active-passive failover configurations. You configure active-active failover using any [routing policy](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/routing-policy.html) (or combination of routing policies) other than failover, and you configure active-passive failover using the failover routing policy.
**Topics**
+ [
## Active-active failover
](#dns-failover-types-active-active)
+ [
## Active-passive failover
](#dns-failover-types-active-passive)
## Active-active failover
Use this failover configuration when you want all of your resources to be available the majority of the time. When a resource becomes unavailable, Route 53 can detect that it's unhealthy and stop including it when responding to queries.
In active-active failover, all the records that have the same name, the same type (such as A or AAAA), and the same routing policy (such as weighted or latency) are active unless Route 53 considers them unhealthy. Route 53 can respond to a DNS query using any healthy record.
## 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. When responding to queries, Route 53 includes only the healthy primary resources. If all the primary resources are unhealthy, Route 53 begins to include only the healthy secondary resources in response to DNS queries.
**Topics**
+ [
### Configuring active-passive failover with one primary and one secondary resource
](#dns-failover-types-active-passive-one-resource)
+ [
### Configuring active-passive failover with multiple primary and secondary resources
](#dns-failover-types-active-passive-multiple-resources)
+ [
### Configuring active-passive failover with weighted records
](#dns-failover-types-active-passive-weighted)
### Configuring active-passive failover with one primary and one secondary resource
To create an active-passive failover configuration with one primary record and one secondary record, you just create the records and specify **Failover** for the routing policy. When the primary resource is healthy, Route 53 responds to DNS queries using the primary record. When the primary resource is unhealthy, Route 53 responds to DNS queries using the secondary record.
### Configuring active-passive failover with multiple primary and secondary resources
You can also associate multiple resources with the primary record, the secondary record, or both. In this configuration, Route 53 considers the primary failover record to be healthy as long as at least one of the associated resources is healthy. For more information, see [How Amazon Route 53 chooses records when health checking is configuredHow Route 53 chooses records when health checking is configured](health-checks-how-route-53-chooses-records.md).
To configure active-passive failover with multiple resources for the primary or secondary record, perform the following tasks.
1. Create a health check for each resource that you want to route traffic to, such as an EC2 instance or a web server in your data center.
**Note**
If you're routing traffic to any AWS resources that you can create [alias records](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-sets-choosing-alias-non-alias.html) for, don't create health checks for those resources. When you create the alias records, you set **Evaluate Target Health** to **Yes** instead.
For more information, see [Creating and updating health checks](health-checks-creating.md).
1. Create records for your primary resources, and specify the following values:
+ Give each record the same name, type, and routing policy. For example, you might create three weighted A records that are all named failover-primary.example.com.
+ If you're using AWS resources that you can create alias records for, specify **Yes** for **Evaluate Target Health.**
If you're using resources that you can't create alias records for, associate the applicable health check from step 1 with each record.
For more information, see [Creating records by using the Amazon Route 53 console](resource-record-sets-creating.md).
1. Create records for your secondary resources, if applicable, and specify the following values:
+ Give each record the same name, type, and routing policy. For example, you might create three weighted A records that are all named failover-secondary.example.com.
+ If you're using AWS resources that you can create alias records for, specify **Yes** for **Evaluate Target Health.**
If you're using resources that you can't create alias records for, associate the applicable health check from step 1 with each record.
**Note**
Some customers use a web server as their primary resource and an Amazon S3 bucket that is configured as a website endpoint as their secondary resource. The S3 bucket contains a simple "temporarily unavailable" message. If you're using that configuration, you can skip this step and just create a failover alias record for the secondary resource in step 4.
1. Create two failover alias records, one primary and one secondary, and specify the following values:
**Primary record**
+ **Name** – Specify the domain name (example.com) or the subdomain name (www.example.com) that you want Route 53 to route traffic for.
+ **Alias** – Specify **Yes**.
+ **Alias Target** – Specify the name of the records that you created in step 2.
+ **Routing Policy** – Specify **Failover**.
+ **Failover Record Type** – Specify **Primary**.
+ **Evaluate Target Health** – Specify **Yes**.
+ **Associate with Health Check** – Specify **No**.
**Secondary record**
+ **Name** – Specify the same name that you specified for the primary record.
+ **Alias** – Specify **Yes**.
+ **Alias Target** – If you created records for your secondary resource in step 3, specify the name of the records. If you're using an Amazon S3 bucket for the secondary resource, specify the DNS name of the website endpoint.
+ **Routing Policy** – Specify **Failover**.
+ **Failover Record Type** – Specify **Secondary**.
+ **Evaluate Target Health** – Specify **Yes**.
+ **Associate with Health Check** – Specify **No**.
### Configuring active-passive failover with weighted records
You can also use weighted records for active-passive failover, with caveats. If you specify nonzero weights for some records and zero weights for other records, Route 53 responds to DNS queries using only healthy records that have nonzero weights. If all the records that have a weight greater than 0 are unhealthy, then Route 53 responds to queries using the zero-weighted records.
**Note**
All the records with nonzero weights must be unhealthy before Route 53 starts to respond to DNS queries using records that have weights of zero. This can make your web application or website unreliable if the last healthy resource, such as a web server, can't handle all the traffic when other resources are unavailable.
# Configuring failover in a private hosted zone
If you're creating failover records in a private hosted zone, note the following:
+ Route 53 health checkers are outside the VPC. To check the health of an endpoint within a VPC by IP address, you must assign a public IP address to the instance in the VPC.
+ You can create a CloudWatch metric, associate an alarm with the metric, and then create a health check that is based on the data stream for the alarm. For example, you might create a CloudWatch metric that checks the status of the EC2 `StatusCheckFailed` metric, add an alarm to the metric, and then create a health check that is based on the data stream for the alarm to check instances within a Virtual Private Cloud (VPC) that only have private IP addresses. For information about creating CloudWatch metrics and alarms by using the CloudWatch console, see the [Amazon CloudWatch User Guide](https://docs.aws.amazon.com/AmazonCloudWatch/latest/DeveloperGuide/).
For more information, see [Working with private hosted zones](hosted-zones-private.md) and [Monitoring health checks using CloudWatch](monitoring-health-checks.md).
# How Amazon Route 53 averts failover problems
The failover algorithms implemented by Route 53 are designed not only to route traffic to endpoints that are healthy, but also to avoid making disaster scenarios worse due to misconfigured health checks and applications, endpoint overloads, and partition failures.
**Topics**
+ [
## How Amazon Route 53 averts cascading failures
](#dns-failover-cascading-failures)
+ [
## How Amazon Route 53 handles internet partitions
](#dns-failover-internet-partitions)
## How Amazon Route 53 averts cascading failures
As a first defense against cascading failures, each request routing algorithm (such as weighted and failover) has a mode of last resort. In this special mode, when all records are considered unhealthy, the Route 53 algorithm reverts to considering all records healthy.
For example, if all instances of an application, on several hosts, are rejecting health check requests, Route 53 DNS servers will choose an answer anyway and return it rather than returning no DNS answer or returning an NXDOMAIN (non-existent domain) response. An application can respond to users but still fail health checks, so this provides some protection against misconfiguration.
Similarly, if an application is overloaded, and one out of three endpoints fails its health checks, so that it's excluded from Route 53 DNS responses, Route 53 distributes responses between the two remaining endpoints. If the remaining endpoints are unable to handle the additional load and they fail, Route 53 reverts to distributing requests to all three endpoints.
## How Amazon Route 53 handles internet partitions
Although uncommon, there occasionally are significant internet partitions, meaning that large geographic regions can't communicate with one another over the internet. During these partitions, Route 53 locations might reach different conclusions about the health status of an endpoint and might differ from the status reported to CloudWatch. Route 53 health checkers in each AWS Region are constantly sending health check statuses to all Route 53 locations. During internet partitions, each Route 53 location might have access only to a partial set of these statuses, usually from its closest regions.
For example, during an internet partition that affects connectivity to and from South America, the Route 53 DNS servers in the Route 53 South America (São Paulo) location might have good access to the health check endpoints in the South America (São Paulo) AWS Region, but poor access to endpoints elsewhere. At the same time, Route 53 in US East (Ohio) might have poor access to health check endpoints in the South America (São Paulo) Region, and conclude that the corresponding records are unhealthy.
Partitions such as these can give rise to situations where Route 53 locations make different conclusions about the health status of endpoints, based on their local visibility of those endpoints. This is why each Route 53 location considers an endpoint healthy when only a portion of reachable health checkers consider it healthy.