12. [SAA/DVA] Route 53 Health Checks – Hands On
So let’s go ahead and create some health checks. So on the left hand side, I’m going to go into the health checks and we’re going to create health checks for all our EC two instances. So we’re going to three health checks. So the first one is going to be for my instance in US East One and it’s going to be an endpoint. And then you need to specify either an IP address or a domain name.
So we’ll keep it as an IP address. And my instance in US East one is right here. So we’ll paste that in. We have to specify a port. So we’ll keep it as 80 because this is the Http port. And for Path, we’re just going to be keeping the path as slash because, well, this is the same as the IP, which is the root of our websites. If we had a real application, sometimes it is very common to have a path health, for example, which responds with the health of the endpoint itself. Okay, so we have this ready.
So I will just remove the slash health and then we can look at some advanced configurations. So we can have either a standard every 30 seconds or a fast every ten second type of health check. We’ll keep it as standard because this is otherwise more expensive. How many times it needs to fail configured before being considered as a failure? Do you want to do string magic? So do you want to look for a string in the first 5120 bytes? Yes or no? Do we want latency graphs so to see whether or not to get to see how latency evolves over time, do we want to invert the health checkers?
So if you want healthy to be unhealthy and vice versa, or disable it. And then do you want to customize the regions of the health checkers or do you want to use the recommended and we’ll just keep it as is with using recommended. So every option is pretty much as default. And do we want to be notified whenever this help check fails? Yes or no by creating alarm? I will just say no for now. So we have created our first health check. Now let’s create our second health check.
And it’s going to be for AP southeast one. So AP Southeast One and then IP address right here, not Hostname and then next and create and the last health check is for EU Central one. So let’s create this health check and I will name it EU Central One. And then here is the IP address and click on next and create health check.
Okay, so our health checks are created and what I’m going to do is that I’m going to go to one of my instances, for example, the one in Singapore. And for the security group, I’m going to start blocking the port 80, removing this rule. And the idea is that I want to get a failing health check. So I’m going to go into the security group right here, I will do action and end it the inbound rules and I will delete my Http based rules. And what this will do is that the one health check for AP selfies one should give me an unhealthy status. So let me wait a little bit for the health checkers to do their thing and I will get back to you. Okay, so as we can see, we have three health checkers and one of them is unhealthy, obviously because I locked the security group and the other two are healthy because I didn’t change the security group of them.
So we can have a look at the health checkers and they give you some information around when it was last checked and so on. And for the unhealthy one, we can view the error status. So if we look at view last fail check, we can see that there was a connection, time out and maybe the requests are being blocked by my firewall and firewall is your security group. So that makes sense. So at least it gives us some information and they are working just as expected. And one last thing that you can create is a create a health check and this one is going to be a calculated health check. Calculated. Here we go. And it’s going to check for the status of other health checks. And now we can specify with which health checks we want to monitor.
And okay, we’re saying maybe you want to report healthy when one of the three health checks are healthy or when two or when all of them are healthy. So this is an end or one or more health checks are healthy. So this is or so we can definitely create a complicated rule. So I will just keep it as this should be healthy when all my health checks are healthy and then click on next. Next. And we have created a calculated health check. And the last kind of a health check we can create is to monitor the state of a CloudWatch alarm, in which case we need to specify the region the alarm is going to be in.
And then this alarm could be monitoring obviously the state of a private EC two instance for example. And this is how we would link the health check, the health of a private resource into a Route 53 health checks. Okay, but I can’t create right now because I don’t have an alarm available for us. Okay. Okay. So my calculated health check is now reported unhealthy because, well, one of the health checks I’m one trying to monitor is unhealthy and this is how we define it. So that really shows you the power of health checks. And in the next lecture we’ll be using them of course, alongside records in Route 53. So hope you like this lecture and I will see you in the next lecture.
13. [SAA/DVA] Routing Policy – Failover
Okay, so now let’s talk about routing policies and this one is going to be for the failover. So the idea is that we have Route 53 in the middle and we have two easy two instances. One is going to be our primary EC two instance and the second one is going to be a secondary or disaster recovery easy to instance. In this case, what’s going to happen is that we’re going to associate our primary record with a health check and this is mandatory. And if the health check becomes unhealthy, then Route 53 is going going to automatically fell over to the second ECU instance and start sending that result back instead. And of course the secondary ECU instance can also be associated with the health check as well if we wanted to. But there can only be one primary and one secondary.
Now the clients when MX DNS requests will automatically get the resource that is deemed healthy. So if our primary is healthy, then Route 53 will answer with the primary record. But if the health check is unhealthy automatically we will get the response of the second record which really helps us. Do I show you a failover. So that’s it, let’s go in the hands on to see how we can practice this. Okay, so now let’s leverage these health checks and create a failover record. So in my hosted zone, I’m going to create a record and this one is going to be called Follower Stiffanto. com and it’s an A record. And the first value is going to be for my EU Central one instance.
So the one close to me and the routing policy is going to be a failover. So the TTL will set it something really low like 60 seconds. And the failover record type has two options. It could be either primary or secondary, just used to. So this is my primary record and I will associate it with a health check. I have to. So I will associate with my health check named EU Central One and the record ID is going to be EU. So what this is saying is that this record should be my primary one, but this is going to be associated with the health check which means that you can failover to a second record.
So let’s add a new record and it will keep the record name as failover stayfontissue. com and the value of which is going to be my instance in US East one. Okay, we’re still going to have to do a failover. The TTL is 60 seconds and the failover record type is going to be secondary. Now we can optionally associate a hashtag with it of US East one, but you don’t have to and the record idea is going to be US. Now let’s create this record and now is that it was successfully created and so let’s go back into our health checks. And currently these two health checks I’ve associated with my records are healthy. So if I go into the URL, so if I go to failover dot defendantissue. com right now I get an answer from EU Central One C.
That’s perfect. But what I’m going to do is trigger a failure. So let’s go into the EU Central One region and I’m going to find my instances here and I’m going to find the security group and I’m going to again stop some security group rules. So let’s refresh this page. It does exist. That’s perfect. And for the in my role, I’m going to edit it and it will remove the rule on port 80. So that will make my instance completely unreachable from the health checkers. So what I have to do now is to wait for this health check to become unhealthy and then we’ll be able to test the failover. So let’s refresh. And as we can see now, my EU Central One health check is deemed unhealthy and we can look at the monitoring tab and see really when it got unhealthy. So this is quite cool. So the health checker was positive and then it went to zero. And then we can see how many percentage of the health checkers did report healthy. And again, this went down to zero. So what this means is that now that this health check is unhealthy because of the way we set up the failover, that it was linked to this health check, then next time I refresh this, I should not be in EU Central One C, I should be in US East One.
So let’s refresh this parent page. And yes, the answer is that we are in US East One. And so the fellow did work seamlessly behind the scenes. And once you fix it, you could just go back into your security group, you would edit the inbound rule and then you would add back the Http rule and then automatically the health check is going to pass again and therefore we are going to fail over back to our primary location. Okay, so let’s say for this lecture, I hope you liked it and I will see you in the next lecture.
