Amazon AWS SysOps – Networking – Route 53 part 3

10. Route 53 Health Checks

So there are health checks in route 53 and the idea is that if an instance is unhealthy just like an Elb, route 53 will not send traffic to that instance. So how do we know if a health check failed? Well, basically an instances or an IP or a URL, whatever you want is deemed unhealthy if it fails three health checks in a row and it’s deemed healthy if it passes three health checks in a row. So pretty easy. Now, the default health check interval is 30 seconds, but there is something called a fast health check which is 10 seconds, but this will lead to a higher cost. And then when you do a health checks, somehow AWS basically launches about 15 health checkers in the background that will check the health endpoint.

And so that means that if you have 32nd interval and 15 health checkers that will check the endpoint health, you get on average a request every two second. If you have 10 seconds as a period, as a period of health checks and you have 15 health health checkers, then it will be less than one request per second or more than one request per second. So in terms of health checks, you get lots of options. You get http TCP https health checks although when you use https health checks you’d get no SSL certificate verification. So be careful with this. And you can integrate these health checks with cloud watch if you wanted to.

The really cool thing is that once you have these health checks defined in route 53, they can be directly linked to the record sets and the DNS queries and they will basically change the behavior of route 53. So it’s just a theory lecture, but let’s go over creating a health check to see how that works. So, to create a health checks, we go to the left hand side and click on health checks. And here we have a UI to create a health check. So this will help us with availability and performance monitoring and will give us some sort of DNS failover that we’ll test in the next lectures. So we’ll create a health check and I’ll just say the first one is my island health check and we’ll test my island instance and we’ll basically monitor an endpoint.

But we could monitor the status of other health checks which is called a calculated health check, or monitor a state of a cloud watch alarm. So this is how we could link cloud watch to route 53. But right now we’ll just do endpoints and then we’ll say okay, the endpoint. Do we want to specify it by IP address or domain name? So we have either choices. We’ll use IP address because we’ll link directly to our instance. In Ireland, the protocol we’ll use is http, but we could use https if you wanted to test some encryption and TCP if you just wanted to check if a port was open for example. So we’ll use Http and then we’ll say, okay, the instance I want to test right now is the one in Ireland.

So I will use this IP right here. So I’ll just copy this IP and paste it in there. Okay, we could specify a hostname as optional if you wanted to basically give a host name to that request. But we don’t do this for now. The port is 80 and the path is going to be just slash. Images is just an example of what you can put. But right now, because we go directly to the IP address, so if I go straight to that IP address, as we can see, we just do the route, we do slash and so it’s the same. So I will not add any argument here. You can do some advanced configuration which is quite cool.

Here we can see that we have standard health checks, as I said, or fast health checks, but you have to pay more if you do a fast one. You can say a threshold for the failure. So we can say three fail requests equals failure, but we can say just one or maybe ten. I’ll put it as three, obviously. Then you can do some string matching to test the response and test if there is some string in it. We can have some latency graph enabled if we wanted to see the latency of these health checks and make sure that they don’t deteriorate. We could invert the health check status if we say, okay, healthy checks, health check is actually unhealthy and the opposite.

So you could invert it for whatever you want, disable it, and then you can configure the health checkers to be from specific regions. You can either customize this list or use the recommended list. So we’ll just use the recommended one. But here we go. Now, when you create a health check, you basically get a pricing estimate. So it says right now it’s basic, no additional option selected. But if you wanted to view the pricing, it takes you to a new page and in there you’re able to see that health checks cost you month on AWS endpoints and more on non AWS endpoints. And then if you use Https string matching, faster journal or latency measurements, you pay more per month per optional feature.

By the way, new and existing customers are not charged for health checks on up to 50 a list endpoints. So that means that right now we are fine with this health check. It shouldn’t cost us anything. Okay, so we’re good here. I click on next and I will create an alarm or not when the health check fails. And right now we’ll just say no, I don’t want to create an alarm and I’ll go ahead and create a health check. So now I’ve created a first health check and what I’m going to do is basically create my other two health checks and then we’ll use them in the next lecture. So I’ll create my Tokyo health check. And this is great. I will say the IP address is going to be for my Tokyo instance.

So this one okay, paste it. I will leave everything as default. Click on next. Click on Create Health Check. And then finally I’m going to create a last health check. This health check is going to be for us east one. So I’ll just call it Virginia Health Check. And I will put in there the IP address of my USDA one instance. Okay? And we’re good. Click on next create health check and we’re gone. Now we have three health checks. And let’s just wait a little bit for the status to get updated because right now it is unknown. Okay, our health checks have been created. So this is perfect. Now, if I click on one, for example, the Virginia Health Check, we see all the configuration that’s in there.

We could have some monitoring. So here we can see the monitoring over time of the health check status, so we can get some graph and we can choose a time range we want. And this comes straight out of Cloud Watch. So this is something we could use in Cloud Watch, the alarms, if we had cloudwatch alarms linked directly to the unhealthiness of this health check tags, if you wanted to tag them. And Health checkers shows you all the IPS of the things that will basically ping my EC two instance and query this URL we just had. So here we can see we have about, I think 15 health checkers.

And all these things are going to constantly, every 30 seconds, ping for my URL and tell me if the Http status code is going to be 200. And in case you’ve enabled Latency, which we haven’t, but in case you’ve enabled Latency, then you could see a latency graph in this tab and get some information around how fast the end point is to reply to our request. So that’s really cool with three health checks, they’re all healthy, and in the next lecture we’ll be able to play with them a little bit and see how things work using health checks in Route 53. So see you in the next lecture.

11. Routing Policy – Failover

Okay, so let’s talk about a failover routing policy. So we have route 53 in the middle and we have two easy two instances for example, but it could be whatever we want. Again, one will be called a primary easy to instance and the other one will be a secondary easy to instance meant to be used only if the primary fails and the second one is used then for disaster recovery. So this is a failover routing policy. So hence the name we need to use a health check that’s mandatory. So route 53 will have a health check pointing to the primary associated with the primary record and it will check the health all the time. And in case that health check fails automatically, route 53 will fail over to the secondary instance when there is a DNS query.

So when our web browser does a DNS request, basically the answer that route 53 will give it is either the primary if the health check works, but if the health check doesn’t pass, then automatically route 53 is smart enough to send back the secondary disaster recovery response back to the web browser. So let’s have a look at it in this lecture. Okay, so we have three health checks and now we’re going to go back to our hosted zone and create a record that will failover. So we’ll create a record set and I’ll call it Failover Stiffandwear. com. And the first URL is going to be my instance in Ireland. So here it is and I have to recreate this, so sorry, failover. And I’ll paste in the value and the routing policy is going to be failover.

So in failover I say either the record type is primary or secondary. And as the name indicates, you can only have one primary and one secondary. So this one is the primary and we set the ID to be Faliver primary and we have to associate this with a health check. So I’ll just say Ttl of 62nd by the way, and we have to associate it with a health check otherwise it won’t work if I say Create. Now basically it says a nonalius primary resource record set must have an associated health check. So let’s go back and say yes, associate this with a health check. And the health check I want to associate this with is one I’ve created in the past lecture. So I’ll associate this with the Ireland Health Check.

And the IP I just checked is wrong. So I don’t want to make a mistake. Let me just take this one from this list. Here we go. Now the value is here. Okay, I’ll click on Create and that’s basically my primary resource record. So for my failover, so my failover is here and this is my primary. But I’ll create a new record set for failover defendant Tshirt. com and this time I will say okay, the value is going to be America. So I’ll just choose America right here. This IP. Excellent. And I’ll say 1 minute as well for the Ttl. And the routing policy is going to be failover secondary. And this one, we actually don’t have to associate this with a health check. It doesn’t matter.

So you could go ahead and create a secondary record and it doesn’t need to be associated with the health check. Okay, so now we have two record sets for fellowver Stephenacher. com, and as we can see on the right hand side, if I scroll back, one is fellowver primary and the other one is fellowver secondary. Okay, excellent. So let’s try it out. If I go to this URL, because my health check is healthy, I should be redirected to EU West one. So this is perfect. I’m in EU West one and this is great. But now what I’m going to do is stop my EC two instance so I right click on it and stop it.

And basically this should make my health check fail because my instance is now stopped and it will not be able to respond to my health checks. So let’s go back to my health check console just to see things happening live. So right now everything is healthy, but let me wait a little bit and we should see the Ireland health checks become unhealthy. Okay, so my health check is now unhealthy. And as we can see in the monitoring tab, we can see that, for example, the health checkers that report the endpoint healthy percentage has decreased and then it reached 40% and it will go all the way to zero at some point. And so that made my health check switch from one to zero.

So because my health check is unhealthy, now if I go back to my failover endpoint and refresh this page, what I expect is to be now taken to the US instance. So let’s try it out. Refresh this. And now it says, welcome from the US East one A. So basically I’ve failed over, just like the record name indicates to the right instance. So that’s perfect. Now we’ve seen how through health checks, we’re able to basically have roof DT three, integrate with those and redirect us to an instance that we know is working. So really, really cool. All right, just for this lecture, I’m just going to start back my instance and we’re all good. I will see you in the next lecture.