9 Route 53 Health Checks
So there are health checks in route 23, and the idea is that if an instance is unhealthy, just like an ELB, route 23 will not send traffic to that instance. So how do we know if a health checks failed? Well, basically, an instance, an IP, or a URL—whatever you want—is deemed unhealthy if it fails three health checks in a row. And it’s been healthy if it passes three health checks in a row. So it’s 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 check, somehow AWS basically launches about 15 health checks in the background that will check the health endpoint. So, if you have a 32nd interval and 15 health checkers that check the endpoint’s health, you will receive a request every 2 seconds on average. If you have 10 seconds for a period of health checks and you have 15 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 have lots of options. You will receive http, TCP, and 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 want to. The really cool thing is that once you have these help 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 help check to see how that works. So, to create a help check, we go to the left hand side and click on “help checks.” And here we have a UI to create a help check. So this will help us with availability and performance monitoring, and it will give us some sort of DNS failure 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 end point. But we could monitor the status of other health checks, which is called a “calculated health check,” or monitor the 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 two options. We’ll use an IP address because we link directly to our instance. In Ireland, the protocol we’ll use is http, but we could use https if you want to choose some encryption and TCP if you just want to check if the port is 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 Justslash images is one example of what you can do. But right now, because we go directly to the IP address, if I go straight to the IP address, as we can see, we just do the route, we do the slash, and so it’s the same. So I will not add any arguments 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. A failure threshold can be defined. So we can say three failed requests equal failure, but we can say just one or maybe ten. I’ll put it at three, obviously.
Then you can do some string matching to test the response and see if there is some string in it. We can have some latency graphing enabled. If you wanted to see the latency of these health checks and make sure that they didn’t deteriorate, we could invert the health check status if you said okay, healthy checks. A health check is actually harmful and harmful. So you can invert it for whatever you want, disable it, and then you can configure the health checkers to be from specific regions. You can either customise 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 currently states that it is basic, with no additional options 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 fifty cents per month on AWS endpoints and more on non-AWS endpoints.
And then if you use HTTP stringmatching, phasor, or latency measurements, you pay more per month for each optional feature. By the way, new and existing customers are not charged for health checks on up to 50 alias 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 create 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 is okay; paste it. I will leave everything as is. Click on “next.” Click on “Create a Health Check.” And then, finally, I’m going to create a last help check. This assistance check will be for us east ones. So I’ll just call it the Virginia Help Check. And I will put the IP address of my USD Swan instance there. Okay? And we’re good. Click on “Create a Health Check” next. And we’re done.
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 VirginiaHealth Check, we see all the configuration that’s in there. We could keep an eye on things. So here we can see the monitoring over time of the health check status, so we can get some graphs and choose the time range we want. And this comes straight out of Cloud Watch. So this is something we could use in CloudWatch—the alarms, if you have Cloud Watch alarms linked directly to the unhealthiness of these health checktags and you wanted to tag them. And Health Checkers displays all of the IPS for the things that will essentially ping my EC2 instance and query the URL we just had.
So, as you can see, we have about 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 if you’ve enabled latency, which we haven’t, you’ll be able to see a latency graph in this tab and get some information about how quickly the end point responds to our request. So that’s really cool. We have three; 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, until the next lecture.
10. Routing Policy – Failover
Okay, so let’s talk about a failover routing policy. So we have route 33 in the middle, and we have two easy instances, for example, but it could be whatever you 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 for disaster recovery.
So this is a failover writing policy. So, hence the name, we need to use a health check, and 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 failover to the secondary instance when there is a DNS query. So, when our web browser sends a DNS request, route 53 will respond with either the primary if the health check passes, or the secondary if the health check fails. If the health check fails, automatically reject three is smart enough to send back the secondary disaster recovery response 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 DefendantChair.com.
And the first URL is going to be my instance in Ireland. So here it is, and I’ll have to recreate it; I apologies for the failure. And I’ll paste in the value, and the routing policy is going to be failover. So in failover, I say either the cord type is primary or secondary. And as the name indicates, you can only have one primary and one secondary. So this one is a primary, and we set the idea to be part of a primary, and we have to associate this with a health check. So I’ll just say TTL of 60 seconds, 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 novellas 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 the one I 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, my failover is here, and this is my primary. But I’ll create a new record for FailoverStefanitas.com, and this time I will say, “Okay, the value is going to be America.” So I’ll just choose America right here. This anitas.com, and I’ll say 1 minute as well for the TTL. In addition, the routing policy will be failover secondary. And for this one, we actually don’t have to associate it with the health check; it doesn’t matter. So you can go ahead and create a secondary record, and it doesn’t need to be associated with a health check.
Okay, so now we have two record sets for failover at StephanieTree.com. If I scroll back to the right, we can see that one is failover primary and the other is failover 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 the EU-West one. So this is perfect. I’m in EU West 1, and this is great. But now what I’m going to do is stop my EC-2 instance. So I 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 island health check 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 have decreased, then reached 40%, and 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 taken to the US instance. So let’s try it out. Refresh this. And now it says welcome from the East Coast of the United States. So it’s basically a failed over, as the record name indicates to the correct instance. So it’s perfect. Now we’ve seen how through health checks we’re able to basically have root at three, interact with those, and redirect to an instance that we know is working. That is insanely cool. Alright, just for this lecture, I’m just going to start my instance, and we’re all good. I will see you at the next lecture.
11. Routing Policy – Geolocation
Okay, let’s talk about the geolocation routing policy. So it is different from Lanc Base. This one is routing based on the user’s location. And so here we’re saying, OK, traffic that originates from the UK should go to this specific IP if that’s an A record.
And on top of it, we should create a geo-default policy in case, for example, we get a user from Germany but haven’t specified a routing policy specifically for Germany. Then we say, “Okay, by default, you go somewhere else.” So this is to route based on the user’s location and reduce traffic from a specific country. So if you look at the map, this is, for example, the west of the European Union. So here we get, for example, okay, all the traffic that comes from the UK should go to 011-22-3344, whereas all the traffic that comes from France should go to two, two, three, three, four, four, five, five. And then, by the way, there’s a default, and the default says if you don’t have traffic originating from the UK or France, then the default response is going to be 334-4556, six. And that’s how geolocation works.
Now let’s practice this in a second. So in my hosted zone, I’m going to create a record. I’ll call this one Geo, and I will say okay, the value of it is going to be my Ireland instance. So I’ll just say this one here, Ireland. And I’ll say okay, the routing policy is going to be that your location is where all the traffic is coming from. For example, you can either say continents or countries or default. So I’ll just name a country right now, and all the traffic that comes from France should go there. So I’ll just set an ID. So I say Geofence should go to this IP right here.
So if my browser is in France, which it is right now, then I should get this answer. So I’ll create it. A new record set can also be created. So I’ll still name this geography, and now I will say maybe one for America. So if it comes from the United States or the whole American region, I will say, “Okay, you should go to this IP.” So let’s do geolocation. And the location is going to be on the continent of North America. Perfect. And I’ll just call it North America Geo Excellence and hit the Create button. Then I might want to make a record set geo. And this one is going to be, if you don’t have any matches, then send me to Tokyo. And so we’ll say okay, Tokyo, IP, and geolocation. This time, we’ll go with default. So we’ll say “default,” redirect to Tokyo, or whatever name you want to set, really. Okay.
So now, after creating this record set, what we should see is that we have three records associated with this geostiff on the chair, and it turns out that if my traffic is from France, I should be going to this IP. If my traffic is from America North and North America, then I should be going to this IP. Any other traffic should go to this one. So let’s try it out. I’ll go to Geo for my URL, basically, and the answer I should get from this one should be from Ireland. So let me just take care of that. By the way, I should just remove this. So this is not working. Oh, I know why. because my public IP changed. Because I basically stopped and restarted my simple example. This is really silly of me. So I’m going to go back and basically change this IP to the correct one. So, as you can see, the last bits of my IP have changed. So this was a good error to have. As a result, I’ll keep this one on file as well. But when I stop and I start an app, for instance, obviously the public IP changes. And so, by the way, that means that all my records beforehand must be updated if I want to use them in the future. So in the meantime, what I can do is maybe go to Mexico and see what’s going on in Mexico.
So I’m connecting to Mexico. Excellent. I’m in Mexico, and when I try this URL, I get the response “us.” So excellent. because I come from North America. It redirected me directly to us. East Jane. But if I go to Brazil, let’s go to Brazil. Now, if I go to Brazil, basically because it says South America, I should be redirected to Tokyo. So let’s try it out. I’m going to connect to Brazil. Okay, I’m connected to Brazil. And now, if I refresh, the answer I should be getting is one from Tokyo. So let’s try it out. And yes, as we can see, we got redirected to AP Northeast 1A. So let’s try it out. Now I’m off to France, where we should see the one instance from Ireland. So let’s try it out. Okay. We’re in France. I refreshed my page, and here we go. I get my answer. West one century in the EU That’s really cool. We’ve had a good explanation of how geolocation works. So we base this on the origination of the traffic—where the traffic comes from—and then redirect to whatever we want. Okay, that sounds good. I will see you at the next lecture.
12. Routing Policy – Multi Value
Finally, the final routing policy will be known as Multi value. And this is when you want to route traffic to multiple resources and also associate Route 53 health checks with the records. So it’s some sort of improvement over the simple routing policy. It will return up to eight healthy records for each multi-value query. So, even if you have 50 records in the backend, you can get up to eight values back. And although it looks like a good replacement for ELB, it is not.
It’s not a substitute; it’s different. But it really helps to do some kind of load balancing on the client side as well. So what this will look like is that, for example, a record will have three different values, and all these values will be associated with a health check. And the idea is that if one of these instances stops serving traffic, the route D three will not send back the value of that to the clients, but the other two will still be happening. So let’s have a quick hands-on look at it in a quick hands on.So I’m going to create a new record set, and this one is going to be called Multi. And the first value is going to be the IP address of my Ireland instance, which has changed. I’ll just keep it here. Okay. And the routing policy is going to be a multivalue answer, and I will associate it with a health check. Yes, and I’ll associate it with the Ireland help check.
Click on “Create.” So this is “Set ideas empty” so you can say, “Okay, multi-Ireland.” Okay. Click on “Create.” Next, I have to create a new record set. So again, it will be a multi, but this time I will have my multi going to the US. So I’ll just take the one from the US, this IP right here, and then I will say “Multi-US associate with health check.” Yes, and that one is going to be Virginia. Click on “Create.” And then, finally, I will have the Tokyo MultiValue answer in there. So I’ll say “Create record set, multi.” And the value will be as follows. The routing policy is going to be multi-valued. This is multilingual Tokyo. I will associate it with the Tokyo Health Check. So I’ll say yes. Tokyo health check And I will also set the TTL to be 1 minute. And this will actually update all the TTLs for this multi-value. It’s so good to know. I click on “Create.” And if you look at our multi, our multi here has three records. OK, so I’ll just say that I actually could filter; I should have done that. But we have three multis in there. All of them have a 62nd TTL, and they’re associated with some health checks. Okay, so let’s look at the health checks. I suspect that one health check is unhealthy because my IP address has changed.
So this one is unhealthy. So I’m going to quickly edit it, edit the health check, and I will put this IP address in here, which is the correct IP address. But this is a really good time to actually test out a record. So for this, I’ll use Dig and see how it goes. So dig. And then I’ll say multi.Stephanheteacher.com, and what we get out of it is a strange answer, I have to admit, but here in the answer section, we have these two IPS. And this is actually due to my VPN. So we have these two answers right here, which are that the two IPS there are healthy. So as you can see, I didn’t return the third one because the health check was unhealthy. But what should happen is that as soon as this health check becomes healthy and I run the exact same query, I should get three IPS back.
So let’s just wait a little bit. OK, so my health check is now healthy. As we can see, the health check just flipped to “healthy.” And so if I go back to Dig and run a query now, hopefully I should see three answers. And here we go. We have three answers directed at us because the third one, this one, just got healthy. And so Root 53 was allowed to give us this answer back. And so, from a web browser perspective, if I go to this URL, basically, my web browser will pick any of these three IPS at random and just use this one. So if I just try it out and go here, as you can see, my web browser is able to just choose an IP. And if one of these was unhealthy for whatever reason, then because my web browser has other IPS as well, which it can return as part of the answer, it can try the others and see which one would work, which is quite cool and gives us as well some kind of fault tolerance, but this time on the client side. So that’s it. I hope you enjoyed this lecture, that you now have a better understanding of how multi-record systems work, and that I will see you in the next one.
13. 3rd Party Domains & Route 53
So Route 53 is also a registrar. And we’ve seen this before. What is a registrar? It’s basically an organisation that manages the reservation of Internet domain names. And so there are some famous names in there that we all know. There are, for example, GoDaddy or Google, which offer domains, etc. And also, we’ve seen this in this lecture, in this whole section. Route 53, or AWS, is also a registrar. So we can buy domain names at a registrar and on AWS. But one thing you should know is that a domain registrar is different from a DNS. Although both bear the Route 53 name, we get these two features that are very different. One is to offer a DNS, and the other is to offer domain registration. So there is something little known: it is possible to use a third-party domain registrar with AWS Route 53.
So if you buy your domain on another website, you are still able to use Route 53 to define all the rules, etc., etc. But how would you do it? Well, number one, you create a hosted zone in Route 53. And number two, you update the name servers. So NS records on the third-party website use the root 53 name servers. And then again, I want to remind you that a domain registrar is not DNS, but each domain registrar usually comes with some sort of DNS feature. So I just want to show you one of these things on my personal domain. So let me show you right now. So here is my Google domain for Data Accumulates.com, which is my own company. And so, as we can see here, are the name servers. I have an option. Either I use the Google domain name servers or I can use custom name servers. So if I use the Google Domain Name servers, then I choose my own DNS to be the one that comes with this interface. However, if I use custom name servers, I can insert the AWS name servers here. And then from there, I’ll be able to create a public zone and configure my DNS records in there. And then what would I put in the name server space?
Well, if I go back to Route 53 and click on Hosted Zones, then I would need to create a new hosted zone for my domain name. So it would be dataaccumulus.com, etc. I would not do it right now. But if I were to do this, then I would click on the domain name here on the radio button. And, as you can see, there are nameservers and these four name servers on the right side. All these four URLs are what I would have to put on my Google Domain Name Server. So I would put this one, and I would put the second one. You get the idea. I would combine all four of them and then click Save, and my domain DataKimos.com will now use this specific private hosted zone, public hosted zone, and route 23. So that’s it’s?just something that can come up with the exam. How do you integrate a third-party domain with Route 53? And I hope that answers your question. The idea is to create your domain elsewhere but have the name servers of that domain point directly into your hosted zone. So that’s it. I hope you like it, and I will see you in the next lecture.
14. Section Cleanup
Okay, so to clean up this section, you could go ahead and delete all the records from there that you wanted. So you could click on all of this, for example, for all of them. And then, once you have selected all of them that you’re ready for, you go and click on Delete record sets. So this is just an example. So I’ll click on “Delete recordsets” and then click on “Confirm.” And you basically do this for all the records that you want to delete. Then, as you may recall, we made a few things. So we’ve created an easy example in three different regions. So I’ll terminate all my easy to instance.So there was Ireland, there was North Virginia, and there was also Tokyo. So let’s go right here, to North Virginia and Iraq, and terminate this one. Yes, it’s happening. Then there was Tokyo, Iraq, and this one. Excellence. And then if I go back to Ireland and get load balancers, I also delete my load balancer from there. Excellence. And then you simply clean up everything we’ve made. You can also delete all these leftover records. So here we go. This way, they’re all clean, and that’s it. You’re ready to move on to the next lecture? Okay, I’ll see you in the next lecture.
