10. [SAA/DVA] Routing Policy – Latency
So let’s talk about a routing policy that’s super easy to understand, which is the latency based routing policy. Okay, so now let’s talk about latencybased routing policies. And the idea is that you want to redirect to the resource that is going to have the lowest latency. So the closest to US, which is super helpful when latency is your main concern for your websites or applications. Now, latency is going to be measured based on how quick it is for users to connect to the closed assist identified a US region for that record. So, for example, if you user in Germany and you have the lowest attendance to a resource in the US. Then this is where you be redirected. And this can be combined with health checks that we’ll see in the very next lecture. So let’s have a look at the map of the world to understand it. Say we deploy our applications in two different parts of the world, one in USC One and one in AP Southeast One.
Then the users are all around the world, and the latency is going to be evaluated by Route 53. And so the user’s closest and with the lowest latency to the ALB and your system will be redirected there, whereas the other users will be redirected to AP Southeast One. Now let’s put this into practice in the console. So let’s create new records, and the record name is going to be Latency stephaniechu. com and the first value is going to be the one in AP Southeast One.
So I’m going to paste the value in here, and then the routing policy is going to be latency. So when we do this thing, because we just put an IP address in here, we need to specify the region of our record. So this one is going to be corresponding to AP Southeast One, which is Singapore. Okay? And the reason is that Alice is not smart enough, at least in this stage, to take this IP and know that it comes from an easy to instance that I have in Singapore, because it could be any IP in the world actually.
So it’s for us to specify, hey, this IP corresponds to the region Azure Pacific, Singapore, and then we can associate a health check and a record ID. So I’ll call this one AP Southeast One, and it’s just a name that I give it. Now we can add another record. Again, the record name is going to be Latency, and the value of which this one is going to be for US East One. So I’ll have the value here and it’s going to be weighted latency. Excuse me. Of course. Then it’s us east one.
And again I will just have it as us east one for my record. ID. And then one last record is going to be for EU Central One. So I will copy this IP, and the record name is this. The value is here. The routing policy is latency and the region is EU Central One. So will be the name. Okay, so as you can see, we have three records being created, successfully created, and this sits right here. And so now let’s try them out. So right now, I’m in Europe, and so if I open this, I’m expecting it to Go to my Instance in Europe. So I go to this URL and I get a response. Hello World from this IP in EU Central One C. If I use Cloud Shell to try it out, and we do a Dig command on this, as you can see, we get an error record back of just one Value. Okay, so just one Value of the same IP address as this One.
So this Is my instance in EU Central One C. And if I keep on refreshing well, because my Latency hasn’t changed to EU Central One, I’m going to get always the same Answer. Okay, but how do we test whether or not the Latency record is Working? Well, for this, I can use a VPN. And So let’s go to Canada, for example. And in Canada, well, it turns out that my Latency is going to be the Closest To the US. So if I refresh this page now, I get the hello, world from the US. And when I did change my location, thanks to the VPN, it cleared all the TTL that I had for my DNS cache locally on my laptop. And so this is why automatically, by refreshing It, I was able to get the newest Value for US. East one a.
But again, if I use Dig, because this hasn’t changed, my Cloud Shell is still in Europe. If I use the Dig command and use the exact same command as Here, I’m still going to get the exact same value as before. Okay, because, well, this computer right here, this cloud shell, sits in EU Central One. And so this is still the closest location to EU Central One. And how do we test the one for AP? Southeast. Let’s go into Hong Kong. Okay, so I’m close to Singapore now, and I will refresh this, and the answer is Hello World from AP Southeast. Windy so the Latency’s record are Working, and they’re really, really good and very common to use online. I hope you liked it, and I will see you in the next Lecture.
11. [SAA/DVA] Route 53 Health Checks
So let’s talk about health checks in Route 53. So health checks are a way for you to check the health of mainly public resources, although there is a way for us to do it for private resources as well, as we’ll see in this lecture. So the idea is that, for example, we have two load balancers in different regions and they’re public load balancers, okay? And behind the scenes we have our application running in both of them. So we’re running into a multiregion setup because we want high availability and so on at the region level. Then we’re going to use Route 53 to create DNS records so that when users access our URL, for example, MyDomain. com, then they get redirected to, for example, the closest load balancer they have. So this would be the case with a latency type of record. But we want to make sure that if one region is down, then we don’t send our users to that region, obviously, right? So to do so, we’re going to create health checks from Route 53. So we’ll create a health checks on the one in US east one, and we will create a health check on our instance in EU West one.
Well, with these two health checks, we’re going to be able to associate them with our Route 53 records. And the reason we do so is to get automated DNS failover. So we have three health checks that are possible, the ones I just showed you, which are the health checks that monitor an endpoint, which is a public endpoint. So it could be an application, a server, or another a list resource. It could be a health check that monitors other health checks, also called a calculated health check. Or it could be a health check that monitors a CloudWatch alarm, which gives you more control and is helpful for private resources as we’ll see in this lecture.
Finally, these health checks have their own metric and you can view them in CloudWatch metrics as well. So let’s look at how health checks work with a specific end point. So if we have a health check for EOS, one for an ALB, then the health checkers of AWS are coming from all around the world. So it’s not just one health checker, it’s about 15 health checkers from all around the world. And they’re all going to send requests into our public endpoint to wherever route we set.
And then if it gets 200 okay, code back or the code we defined, then the resource is deemed healthy. So about 15 global health checkers will check the endpoint health. And then you can set a threshold for healthy or unhealthy, you can set an interval. So we have two options. It could be either 30 seconds for regular health checks or every 10 seconds, which is a higher cost, which is what’s called a fast health check. It supports many protocols, so http https and TCP and the rule is that if over 18% of the health checkers say that the endpoint is healthy then route 53 will consider it healthy. Otherwise it’s deemed unhealthy and you have the ability to choose which locations you want to use for the health checks. Now the health checks will only pass if you have the status two Xx or three Xx status code back from the load balancer and the health check has a cool capability.
So if it is a text based response then the help checkers can check the first 5120 bytes of the response to look for some specific text in the response itself. Finally, very important from a network perspective if you want for it to work. Obviously the health checkers must be able to access your application loan, sir or whatever endpoint you have. And so therefore you must allow incoming requests coming from the Route 53 health checkers IP address range and you can find this address range at the URL in the bottom right of the screen. Now the second type of health checks we have are calculated health checks. And so this is to combine the results of multiple health checks into a single health check. And so if we look at route 53 with three easy to instance we can create three health checks, they’re all going to be children health check and they can all monitor each easy to instance one by one. And then we can define a parent health check which is going to be defined on all these child health checks. And so the conditions to combine all these health checks could be an or an and or a not. You can monitor up to 256 child health checks and you can specify how many of the health checks need to pass to make the parent pass.
So the use case for this would be for example, if you want to have a parent health check to perform maintenance on your website without causing all the health checks to fail. And so how do we monitor the health of a private resource? So in case you want to monitor something private it’s going to be difficult because well, all the Rule 53 health checkers live on the public web and they’re outside of your VPC so they cannot access private endpoints. So if it’s a private VPC or an on premises resource and so the way we can do it though is to create a CloudWatch metric and assign a CloudWatch alarm on it and then you can assign the CloudWatch alarm into the health checker.
So the idea is that we’re going to monitor the health of our ECQ instance in a private subnet with a CloudWatch metric. And then if the metric is breached, we’re going you create a quite savage alarm on it. And when the alarm goes into the alarm state, then the health checker is going to be automatically unhealthy. And therefore we’ll have created exactly what we want, which is a health check on a private resource, which is the most common use case on how to do it. So that’s it for this lecture. I hope you liked it and I will see you in the next lecture.
