Hayden.
And welcome back.
In today's video will 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 now 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 Map 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 levels region, then we can improve the performance
for the users by serving their request from the region that provides the lowest latency.
Now, as we 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 on how exactly this might look like with a quick demo.
So for today's demo, we have a public hosted zone of Zee Vodacom.
So this was one of the domains which I thought we'll use 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 here, I have two record sets which are available both of them have the record of
latency or Vodacom and you have latency 20. com.
Now each of this 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 to your, you will see that the routing policy is of type latency.
And the second one, the routing policy again is of type latency.
So any time a user makes a request to latency to Vodacom, 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 to overcome, 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 to Vodacom, he might be redirected to the nearest server.
So let's quickly look into how exactly that might look like.
So I'm going to click, let's quickly do a lookup on latency dot Z, Vodacom.
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.1 54.
All right, now let's do one thing.
So I'll just open up one of the website, which basically can do a nice lookup.
All right.
So this website mostly, I believe this would be in the US region.
So let's say I'll say latency to Z Vodacom.
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 give an address of 54 to 110.
However, within the CLI, it gave the address of 35.1 54.
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 US 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 records 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 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 let's select a Singapore region and within the Singapore region
I'll create an elastic IP here.
Let's quickly create a elastic IP.
All right, So I'll copy the elastic IP here and I'll paste it within the value field and you'll 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 zillow.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.
So this is the high level overview about the latency based routing.
I hope this video has been informative for you and again, if you have created an elastic IP, do not
forget to release it, otherwise you will get unnecessarily charged.
So with this, I'll conclude this video.