Amazon AWS Certified Advanced Networking Specialty – Advanced Route53 Configurations Part 7

19. Geolocation Routing Policy

Hey everyone and welcome back. In today’s video we will be discussing about the geolocation drouting. Now, as the name suggests, geolocation routing allows us to choose the resources based on the geographic location of the users. So basically this can be understood with a simple example. So let’s say that you might want all the queries from the Asia location. So all the DNA is queries which are originating from ratio location to be routed to the elastic load balancer in the Singapore region. Similarly, if you have the query which is from the US, then you might want to direct those queries to the North Virginia region.

So all of those configurations can be achieved with the help of geolocation routing. So let me quickly show you a quick demo on how exactly this might work before we discuss some of the important pointers. So, this is my route 53 console. Now, within my zone there are two records. Now both of these records have same name, which is my demo Kplabs internal. However, they have different IP address. One has the IP address of 1077 510 and second is 1077 520. Now, if you look into the routing policy over here, the routing policy is of type geolocation and within here we have actually specified the location as United States and we have given the idea of two.

Similarly, in the other record set we have the location of India and the idea of one. So basically from CLI I am actually logged into an easy to instance in the North Virginia region here. If we quickly do a Nslookup on my demo Kplabs internal, you will see that the record set which has been sent in, the response is 1077 520. Now this is the reason why, because for the record set of 1077 520 we have the location set as United States. You in fact have one more record set of 1077 five or ten, but this will be served only when the location is India.

So this type of geolocation based routing is quite useful. So many times it has been observed. I’m sure you also might have observed that whenever you visit a website you might get a message that the contents of this website are not visible for your country. So that can be easily achieved with the help of geolocation. You can also achieve it at the web server level, like at the NGINX level that can also be possible, but through the route 53 it is much more simpler. Now, in case if you want to create a geolocation based routing, it is very simple. So you create a record set, you can give it a name, let’s say I’ll give it a name of geolocation.

You can give it a value, I’ll say 1077 530. Now, the routing policy you can select here as geo location and within the location you can specify by continent. So you have Africa, Entrance A. Asia, Europe, north America. Oceania. South America. All right, so you can specify by continent, you can even specify by country. So this is the granularity which the geolocation based routing policy supports. Now, there are certain important considerations that you should remember before you go ahead and implement geolocation routing within your production environment. The first is that geolocation routing works by mapping the database to the IP addresses. Now in such cases of mapping, the results are not always accurate. Now the reason is because there might be certain internet service providers that might not have any geolocation data which is associated with them, or it can happen that some ISPs might move their IP block to a different country without notification.

So in such cases you might get an issue. So for such cases, route 53 allows us to have a default resource block associated with the geolocation based routing policy. So let me quickly show you that. So within the location if you go up there is a block of default. So this is the default block. So in case if you get a DNS query from an ISP which is not matching any of the container and yes, it does happen.

So in such cases you want to handle that in an appropriate manner. So for such cases you can have the location of default and then you can specify one of the IP addresses depending upon the use case that your organization might have. So this does happen. I would not say it is very common, but you need to make sure that if you’re implementing geolocation, make sure you also have the reservation for the default location.

20. Multi-Value Answer Routing

Hey everyone and welcome back. In today’s video we will be discussing about the MultiValue answer routing. Now the MultiValue answer routing basically allows us to return multiple values. So this multiple values can be IP addresses in response to a specific DNS query. Now one great feature associated with the MultiValue answer routing is that it allows us to check the health of the resources so that the route 53 can respond with details of only healthy resources. Now again, this might be a little confusing unless and until we go ahead and have a demo. So let’s jump to the practical session and look into how exactly the MultiValue answer routing works.

So within my CLI, if I quickly do an Nslookup on mydemo Kplabs internal, you will see that it is basically returning four record sets. So you have IP address 10770 six, then you have zero seven, you have zero eight and you have zero five. So for one specific domain you have multiple values which are being returned. Now this is referred as the MultiValue answer routing. So let’s look into how exactly it might look like in route 53. So this is my Route 53 console. Now within my hosted zone, you see I have four records. Now each of these records has the same domain which is my demo Kplabs internal. However, each one of them has a different set of IP addresses. So now if I just open up one of them in the right hand side, if you look into the routing policy, the routing policy is of type multi value answer.

So that basically means that anytime a DNS server requests for the domain of mydemo Kplabs internal multiple servers, IP addresses would be sent in the DNS response. Now this type of policy helps, let’s say you have a lot of web servers and if let’s say you want to distribute the traffic, then you can make use of multi value routing policy. Now again, this is not a replacement to the elastic load balancer. However, I hope at a high level overview, you got an understanding on what exactly this is.

Now if you look into the PPT, in the second point we were discussing that MultiValue answer routing allows us to check the health of the resources. So it might happen, let’s say that these are four web servers. Now among these four web servers, one of them is not working. And what we want is that anytime a DNS request comes for the domain of mydemo Kplibs internal, then the route 53 should only serve the IAP addresses associated with the web servers whose health check has been passed. It should not serve the IP addresses of the server which has failed the health check.

So that can be associated with the health check. So this multi value answer you can associate with the health check that you create within the route 53. So this is a great feature. So let me quickly show you on how exactly you can create the multi value answer based routing. So let’s say I’ll call it, let’s call it as MultiValue. All right? We’ll give it a value of 190 to 168 1021. Now, within the routing policy, I’ll call it as MultiValue answer and I’ll give it an ID of one. Now, you can also associate it with a health check. Now, for the simplicity, since you are studying a MultiValue, I’ll just set this as default no. All right, so I’ll go ahead and I create a record set. So this is the first record set. Let’s create one more record set. I’ll name it MultiValue. Make sure you name this same.

The value would be 190 to 168 ten two. The routing policy again would be multi value answer. The set ID would be two. In a similar case, we’ll do one more. Let’s name this MultiValue as a 190 to 168 ten three. And I’ll put an ID of three and I’ll go ahead and I’ll create it. All right? So now there are three records which are part of the MultiValue answer. Now, within the easy to instance, let’s go ahead and do ans lookup, I’ll say multi value Kplabs Internal. And now you see it basically responded back with three IP addresses associated with the record set of MultiValue Kplabs internal. Now, one important part to remember is that if you do not associate your multi value routing policy with a health check so if you see all the health check are being determined as no. So in this case, Route 53 will assume that all of these IP addresses are healthy.

And whenever a DNS query is being made, similar to what we had done whenever DNS query is being made, route 53 will respond with all the IP addresses. All right? So again, if you do not associate the multi value routing policy with any health check, route 53 will assume all the host to be healthy and it will return the IP addresses of all the records associated with the specific routing policy. In case if you associate it with the health check, and if the health check does not succeed, then the Route 53 will not send the IP address of the record whose health check has been failed. So this is the high level overview about the MultiValue answer routing. One last point to remember is that Route 53 can respond up to DNS query with up to eight healthy records. So this is one important part to remember.

21. Latency Based Routing

Hey everyone and welcome back. In today’s video, we’ll be discussing about the latency routing policy in route 53. Now, I can explain the latency based routing in the most simplest form with the help of Google Maps. So I’m sure most of you have already used Google Maps. So if you want to reach to a specific destination, the Google Maps can give you multiple path to reach that destination. Now the path that Google Maps will give you will depend upon the traffic conditions and how fast you can reach there. So it is not like the path that Google Maps has given you today will be the same path that Google Maps might give you tomorrow. It might be a different path depending upon the traffic conditions. Now, latency routing follows the similar approach.

Now, if your application is hosted in multiple AWS region, then we can improve the performance for the users by serving the request from the AWS region that provides the lowest latency. Now, as we have discussed that the latency between the servers might change over time. So there can be certain backbone network changes, certain routing changes that might happen. So depending upon the region which gives the lowest latency, the route 53 will be routing the traffic to that specific region. So it might be like a request that is routed to the Singapore region today, might be routed to the India region tomorrow. Again, it depends upon the overall latency. So let me quickly show you how exactly this might look like with a quick demo. So for today’s demo, we have a public hosted zone of Zeelbora. com. So this was one of the domains which I thought we used for testing for some amount of time. And for latency based routing, we need to have a public hosted zone.

So now if you see over here, I have two record sets which are available. Both of them have the record of latency Zelbora. com and you have latency Zboro. com. Now each of these record set has a different value. The first one has the record of 35, second one has 54. Now, if I click on one of the record set over here, you will see that the routing policy is of type latency. And the second one, the routing policy again is of type latency. So anytime a user makes a request to latency Zillbora. com, which record set would be served depends upon the overall latency.

So let’s say that I have one server in Mumbai region and one server in US region. Now, if a user tries to connect to latency Zeelboro. com, he’ll be redirected to the US region there. However, if someone from Singapore, someone from Asia who might try to connect to the same domain latency Zeelboro. com, he might be redirected to the nearest server. So let’s quickly look into how exactly that might look like. So I’m in my CLI, let’s quickly do a Nslookup on latency Zwura. com.

So since I am in India currently, I will be redirected to the record set which has the lowest latency from my location. So that is 35 154. All right. Now, let’s do one thing. So I’ll just open up one of the website which basically can do a Nslookup. All right? So this website mostly I believe this would be in the US region. So let’s say I’ll say latency dot Zhora. com. Now, this will work because the current zone is a public hosted zone. So let’s do a go now. And now you see here, it basically gave an address of 54 20. However, within the CLI, it gave the address of 35 154. Now, one of the questions that comes is how different it is from the Geolocation. Because even with the Geolocation, I can say that any request coming from US region would go to the AWS resources of US. However, there is certain difference. Let’s say you have one server in Mumbai, one server in Singapore.

Now, the request would be redirected to one of the server which has the lowest latency. It is not like that. Let’s have in Mumbai and someone from India is trying to connect to my domain. However, the Mumbai region server has the highest latency. So then the request would be directed to the Singapore region server. So that is where the latency based record sets really help. So, before we conclude, let me quickly show you one thing. So I’ll go to the EC two. So generally, if you want to create a latency based routing policy again, I’m sure that you already know the basic ways in which you can create a routing policy. It is quite simple. Let’s say I’ll say as my demo latency now here you have to give the value and before you give that, just select the routing policy here as latency.

Now, within the EC two instance, let’s select a Singapore region. And within the Singapore region, I’ll create an elastic IP here. Let’s quickly create an elastic IP all right. So I’ll copy the Elastic IP here and I’ll paste it within the value field. And you see, it automatically detected the region associated with the Elastic IP. Now, this is something which I really like. This is quite interesting. So you can give it an ID here. You can give it, say Singapore region and you can go ahead and do a create. All right. So now you have my demo latency Zloro. com. You can create multiple record set. Depending upon the Elastic IP that you might give, the region would be auto detected in the case of Elastic IP. So, once you have done that, then you can try it out and check whether the latency based routing works for your practical set.

• Category: Uncategorized