Instructor: 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 latency-based routing policies.
And the idea is that you want to redirect 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 closest, identified AWS region for that record.
So for example,
if user in Germany and you have the lowest latency
to a resource in the US,
then this is where you will 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 us-east-1 and one in ap-southeast-1.
Then the users are all around the world
and the latency is going to be evaluated by Route 53.
And so the users closest and with the lowest latency
to the ALB, us-east-1, will be redirected there.
Whereas, the other users will be redirected
to ap-southeast-1.
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.stephanetheteacher.com.
And the first Value is going to be the one
in ap-southeast-1.
So I'm good 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-1, which is at Singapore.
Okay.
And the reason is that Alias is not smart enough,
at least in this stage,
to take this IP and know that it comes from an EC2 instance
that I have in Singapore,
because this could be any IP in the world actually.
So it's for us to specify,
this IP corresponds to the region, Asia Pacific, Singapore.
And then we can associate a Health check and a Record ID.
So I'll call this one, ap-southeast-1.
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-1.
So I'll have the Value here,
and it's going to be Weighted.
No, Latency. Excuse me, of course.
And then it's us-east-1.
And again, I will just have it as a us-east-1
for my Record ID.
And then one last record is going to be for eu-central-1.
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-1, so will be the Name.
Okay.
So as we can see, we have three records being created,
successfully created, and this is it 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-1c.
If I use CloudShell to try it out
and we do a dig command on this.
As we can see, we get an error code 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-1c.
And if I keep on refreshing,
because my latency hasn't changed to eu-central-1,
I'm going to get, always the same answer.
Okay.
But, so how do we test whether or not
that latency record is working?
Well, for this I can use a VPN.
And so let's go to Canada, for example.
And in Canada, it turns out that my latency
is going to be the closest to the U.S.
So if I refresh this page now,
I get the Hello World from the U.S.
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-1a.
But again, if I use dig because this hasn't changed, okay,
my CloudShell is still in Europe, okay.
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, this computer right here,
this CloudShell sits in eu-central-1.
And so this is still the closest location
to eu-central-1.
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-1b.
So the latencies 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.