Understand AWS Route 53 Health Check
In a series of articles, we will demonstrate how to control routing for applications hosted on AWS cloud, especially when it spans across several regions. Instead of talking VPC routing tables, here I focus on methods to control traffic flow before them reach VPC border.
Specifically, I will introduce how to use DNS-based routing. Then, I will demonstrate how to control the routing behavior using Lambda@Edge in the next article.
DNS health check - Evaluate Target Health
For an alias record, select Yes for Evaluate Target Health. And this article only sticks to DNS records with Alias Target. The DNS records all have the same value for Name, Type, and Routing Policy.
Imagine you have a public application that is hosted on the AWS cloud. Let's have a quick view of the architecture of this application. We will refer to this application in this article over and over again, each time I will change some factors to demonstrate their real effect.
At Route 53, we created two DNS records with latency-based routing, and both of their "Evaluate Target Health" setting should be "yes" if not explicitly specified in this article.
There is a test PC that is located in Oregon. So during the latency competition, Oregon region always wins, if the relevant resources in us-west-2 are healthy.
Based on this architecture, when a viewer requests to access content, his/her client will initially query DNS server. If the domain name is registered to Route 53, the DNS service will feedback with the IP address of the CloudFront Edge location that near to the client.
Then, browser sends the request to the IP address that it gets, with all the contents in the packets, including host name, URL path, query string, message body and etc.
When the packet arrives at the Edge node, it will go thru some routing policies to decide where it should be routed to.
Before I get hands dirty, let's have a quick view of the criteria that Route 53 judges an ALB resource as healthy or unhealthy:
Nota bene
Route 53 doesn't check the health of the endpoint specified in the record, for example, the endpoint specified by the IP address in the Value field.
Records without a health check are always healthy
If no record is healthy, all records are healthy
If you specify an ALB and you set Evaluate Target Health to Yes, Route 53 routes queries to the load balancer based on the health of the target groups that are associated with the load balancer:
-
For an ALB to be considered healthy, every target group that contains targets must contain at least one healthy target. If any target group contains only unhealthy targets, the load balancer is considered unhealthy, and Route 53 routes queries to other resources.
-
A target group that has no registered targets is considered healthy.
Test case 1
In this test case, Route 53 points DNS record "alb.example.com" to two records, both of which have latency-based routing enabled. One record represents an ALB in ap-northeast-2, which is always healthy throughout this article. The other represents a terminated ALB, meaning that that DNS address non-exists, resulting in Route 53 deem it as unhealthy.
When the test server tries to access https://alb.example.com, Route 53 will respond by pointing to the ALB in ap-northeast-2 region.
Test case 2
In this test case, Route 53 considers the ALB in us-west-2 region to be healthy, because the only target group associated with it is empty. Route 53 deem this scenario as healthy.
When the test server tries to access https://alb.example.com, Route 53 will give a result pointing it to the ALB in us-west-2 region, which will give a 503 response page obviously, due to no target in there.
Test case 3
The target group associated with the ALB has one and only one target, and it is healthy.
When the test server tries to access https://alb.example.com, Route 53 will give a result pointing it to the ALB in us-west-2 region.