What could be happening?

You have deployed a web application targeting a global audience across multiple AWS Regions under the
domain name.example.com. You decide to use Route53 Latency-Based Routing to serve web requests to
users from the region closest to the user. To provide business continuity in the event of server downtime you
configure weighted record sets associated with two web servers in separate Availability Zones per region.
Dunning a DR test you notice that when you disable all web servers in one of the regions Route53 does not
automatically direct all users to the other region.
What could be happening? (Choose 2 answers)

A.
Latency resource record sets cannot be used in combination with weighted resource record sets.

B.
You did not setup an HTTP health check to one or more of the weighted resource record sets associatedwith me disabled web servers.

C.
The value of the weight associated with the latency alias resource record set in the region with the disabled
servers is higher than the weight for the other region.

D.
One of the two working web servers in the other region did not pass its HTTP health check.

E.
You did not set “Evaluate Target Health” to “Yes” on the latency alias resource record set associated with
example com in the region where you disabled the servers.

Explanation:
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 resource record sets
(including weighted alias, latency alias, and failover alias) and nonalias resource record sets to build a decision
tree that gives you greater control over how Amazon Route 53 responds to requests. For more information,
see How Health Checks Work in Simple Amazon Route 53 Configurations.
For example, you might use latency alias resource record sets to select a region close to a user and use
weighted resource record sets 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.

Here’s how Amazon EC2 and Amazon Route 53 are configured:
You have Amazon EC2 instances in two regions, us-east-1 and ap-southeast-2. You want Amazon Route 53 to
respond to queries by using the resource record sets in the region that provides the lowest latency for your
customers, so you create a latency alias resource record set for each region. (You create the latency alias
resource record sets after you create resource record sets for the individual Amazon EC2 instances.)
Within each region, you have two Amazon EC2 instances. You create a weighted resource record set for each
instance. The name and the type are the same for both of the weighted resource record sets in each region.
When you have multiple resources in a region, you can create weighted or failover resource record sets for
your resources. You can also create even more complex configurations by creating weighted alias or failoveralias resource record sets that, in turn, refer to multiple resources.
Each weighted resource record set has an associated health check. The IP address for each health check
matches the IP address for the corresponding resource record set. This isn’t required, but it’s the most common
configuration.
For both latency alias resource record sets, you set the value of Evaluate Target Health to Yes.
You use the Evaluate Target Health setting for each latency alias resource record set to make Amazon
Route 53 evaluate the health of the alias targets—the weighted resource record sets—and respond
accordingly.

The preceding diagram illustrates the following sequence of events:
Amazon Route 53 receives a query for example.com. Based on the latency for the user making the request,
Amazon Route 53 selects the latency alias resource record set for the us-east-1 region.
Amazon Route 53 selects a weighted resource record set based on weight. Evaluate Target Health is Yes for
the latency alias resource record set, so Amazon Route 53 checks the health of the selected weighted resource
record set.
The health check failed, so Amazon Route 53 chooses another weighted resource record set based on weight
and checks its health. That resource record set also is unhealthy.
Amazon Route 53 backs out of that branch of the tree, looks for the latency alias resource record set with the
next-best latency, and chooses the resource record set for ap-southeast-2.
Amazon Route 53 again selects a resource record set based on weight, and then checks the health of the
selected resource record set. The health check passed, so Amazon Route 53 returns the applicable value in
response to the query.
What Happens When You Associate a Health Check with an Alias Resource Record Set?
You can associate a health check with an alias resource record set instead of or in addition to setting the value
of Evaluate Target Health to Yes. However, it’s generally more useful if Amazon Route 53 responds to queries
based on the health of the underlying resources—the HTTP servers, database servers, and other resources
that your alias resource record sets refer to. For example, suppose the following configuration:You assign a health check to a latency alias resource record set for which the alias target is a group of
weighted resource record sets.
You set the value of Evaluate Target Health to Yes for the latency alias resource record set.
In this configuration, both of the following must be true before Amazon Route 53 will return the applicable value
for a weighted resource record set:
The health check associated with the latency alias resource record set must pass.
At least one weighted resource record set 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, Amazon
Route 53 always considers the weighted resource record set healthy.

If the health check for the latency alias resource record set fails, Amazon Route 53 stops responding to queries
using any of the weighted resource record sets in the alias target, even if they’re all healthy. Amazon Route 53
doesn’t know the status of the weighted resource record sets because it never looks past the failed health
check on the alias resource record set.
What Happens When You Omit Health Checks?
In a complex configuration, it’s important to associate health checks with all of the non-alias resource record
sets. Let’s return to the preceding example, but assume that a health check is missing on one of the weighted
resource record sets in the us-east-1 region:

Here’s what happens when you omit a health check on a non-alias resource record set in this configuration:
Amazon Route 53 receives a query for example.com. Based on the latency for the user making the request,
Amazon Route 53 selects the latency alias resource record set for the us-east-1 region.
Amazon Route 53 looks up the alias target for the latency alias resource record set, and checks the status of
the corresponding health checks. The health check for one weighted resource record set failed, so that
resource record set is omitted from consideration.
The other weighted resource record set 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, Amazon Route 53 has no
way to know. Amazon 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 also want to set Evaluate Target Health to Yes for all of the alias resource record sets. In the
following example, all of the weighted resource record sets have associated health checks, but Evaluate Target
Health is set to No for the latency alias resource record set for the us-east-1 region:

Here’s what happens when you set Evaluate Target Health to No for an alias resource record set in this
configuration:
Amazon Route 53 receives a query for example.com. Based on the latency for the user making the request,
Amazon Route 53 selects the latency alias resource record set for the us-east-1 region.
Amazon Route 53 determines what the alias target is for the latency alias resource record set, and checks the
corresponding health checks. They’re both failing.
Because the value of Evaluate Target Health is No for the latency alias resource record set for the us-east-1
region, Amazon Route 53 must choose one resource record set in this branch instead of backing out of the
branch and looking for a healthy resource record set in the ap-southeast-2 region.