Amazon AWS Certified Developer Associate – Route53 & DNS Part 3

5. Weighted Routing Policy Lab

Okay, so I’m here in the AWS console. I’m just going to go over to Route 53. And another thing you should always notice is route 53 is a global service. It doesn’t matter whether you’re in Sydney region or the London region or in Northern Virginia, this is a global service. So it applies all across the world, very similar to I am. You know, when you create new users, they are global users. So we’ll go into our Hello Cloud group, Gurus domains. So we’ve still got these two DNS records. I’ve actually just deleted the last simple one. So you can go ahead and do that if you want. You probably should, actually. So I’m going to go in and create a record set. I’m just going to use it as the naked domain name. So Hellocloud GURUS. COM. And then the type, I’m going to make an alias and I’m going to get it to resolve to my London ELB. And it’s just taking a little bit of time to load.

And there we go. So my London elastic load balancer and the routing policy, I’m going to do it as weighted. And then in here it says wait. So if you hover over it, you can see that you can set values between zero to 255 and essentially it’s going to add up all the weights and then assign a percentage. And that’s how it’s going to distribute the traffic. So if you do a weight of one and three, that means that the sum is going to be four. So 25% of your traffic will go to one and 75% of your traffic will go to three. I like to work in hundreds just to make it easier. So let’s say I want a weight of 70 to go to London. And then in here I’m just going to call it my London site. And then I’m going to leave everything else as default and go ahead and hit Create. Now, right now, even though we have a 70% or 70 in there, the sum is 70. So it’s just going to send everything to London. So we can check this by just going to, Hellocloud GURUS. COM. And here I am just hitting refresh and you can see it’s going between the two different web servers in my London region.

So now I’m going to go ahead and create a new record set. I’m going to leave it as the naked domain name. I’m going to make it an alias and then I’m going to click in here and I’m going to send it to Sydney. I’m going to change the routing policy to weighted. And in here I’m going to set a weight of 30 and we’ll call it my Sydney site. I’m going to leave everything else as default and hit Create. And so now you can see that we’ve got the same name, we’ve got the weight of 70 and a weight of 30.

This one’s going to London, this one’s going to Sydney. So if I come back here and refresh at the moment, it’s sending everything to London. And you can sit here repetitively, refreshing, for three, four, five minutes. Eventually it’s going to go over to Sydney and it’ll be there for a length of time, then it will go back over to London, et cetera. I’ve just hit refresh and now I’m in Sydney, and that took about five minutes. Now, what could be causing this is you’re only seeing it from your point of view, whereas Route 53 is viewing it globally. So as people do try and connect into your website, 70% of the traffic will definitely go to London, 30% will definitely go to Sydney. But because your ISP is caching the DNS, the IP address for this DNS server, it might be caching it locally, upstream, so that you don’t actually get the weighted routing in effect until you hit refresh after the TTL has expired.

That could be definitely one of the reasons for it. So just remember that Amazon take a global view of this. So 70% of your traffic will definitely be sent to London, 30% will definitely be sent to Sydney. Where you’re going to see this in the exams is exactly. That probably where your A and B testing will be an exam scenario. So you want to send a percentage of your traffic to the new website before you take it out of development it and put it into production. So weighted routing is absolutely perfect for that. Okay, so that’s it for this lab, guys. If you have any questions, please let me know. If not, feel free to move on to the next lecture. Thank you.

6. Latency Routing Policy Lab

But before we do that, what is a latency based routing policy? Or as you might guess, latency based routing is basically allows you to route your traffic based on the lowest network latency for your end user. So which region is basically going to give them the fastest response time? So, to use latency based routing, you create a latency resource record set for your EC Two or ELB resource in each region that hosts your website. And then when Amazon Route 53 receives a query for your site, it’s going to select the latency resource record for the region that gives the user the lowest latency. And then Route 53 will then respond with the value that’s associated with that resource record set.

So what does it look like? Well, let’s say I’ve got a user in South Africa and they’re sitting down in Cape Town, maybe in Seapoint on the beach, and they want to go to my website. So they type in Hellocloud GURUS. COM on their laptop and it connects up to Route 53. Route 53, that determines that there’s a 54 millisecond latency to go to EU West Two, which is London. So it’s going almost directly up to London. But it also determines that it would take 300 milliseconds to go to my Sydney site, because basically, it’s got to go across the Indian Ocean, then across Australia, and that’s probably not how the routing would actually work, but you get the idea. It’s got to go a lot further than just going straight up to London.

So in this example, Route 53 would send the traffic to EU West too, because it’s going to have a much lower latency than sending it over to Sydney. And for the user, it’s going to feel a lot faster. So let’s log into the AWS console and see how we set this up for Case. So I’m in the AWS console, I’m just going to click on Route 53. I’m going to go into my hosted zones and I’m going to go into Hello Cloud Gurus. And in here we’ve still got our A records from our last lab.

So just go ahead and hit Delete for those. Now we’re going to create a new record set and we’re just going to leave it as the naked domain name or the zone Apex record. And I’m going to make it an alias and I’m going to point it to my different elastic load balances. And again, sometimes it can take a little while to load. Okay, so there we go. So I’m going to set one up for London first of all, and I’m going to change this over to Latency. And then it says in here, please specify a region. So if you forget the name of your region, you can actually just check up here in the DNS name of your load balancer. So here we see EU West Hyphen Two. So I’m going to go for EU West Hyphen Two, and I’m just going to call it my London region. And then I’m going to leave everything else as default and go ahead and hit Create. And then I’m going to do exactly the same thing again.

This time I’m going to create a record set. I’m going to leave it as the zone apex record. I’m going to point it at my Sydney elastic load balancer. I’m going to use latency based routing, and then I’m going to specify a region which is going to be southeast. And again, if you forget it, just go over to your load balancer. I’m pretty sure it’s southeast too. Yes, it is. So go over to southeast two and we’ll just call this my Sydney region. Go ahead and hit create. And so now we’ve got two resource records for our naked domain name. One’s going over to EUs two, the other one’s going over to AP South two. So let’s go ahead and open up a new tab. So I’m in a tab and I’m just going to refresh it. I’m doing this from London as we record. So in theory, it should go straight to my London web servers, which it is doing now to test this. What I’m going to do is I’m going to VPN into Sydney and try it again. So this here is Viper VPN.

Great. VPN client. I’ve been using it for a long time now. It’s fantastic. So this is Viper VPN. It’s one of my favorite VPN clients. So what I’m going to do is I’m going to go in and go show all server locations. I’m going to connect into the Sydney region. So you can see 314 milliseconds. Going to go ahead and connect to that. And so for all intents and purposes, when Route 53 sees me making my website request, it’s going to think that I’m in Sydney now rather than in London. So I’m just going to alt tab back over to Google Chrome. Okay, so I’m in chrome. I’m just going to do a refresh. And it took a little bit, but there you go. It is automatically saying, this is Sydney web service. So it’s detecting that in terms of my latency because it sees my endpoint, sees me being inside Sydney. Now it’s going to be quicker to send me traffic through Sydney.

The reason it took a little bit of time is basically this is all going through a VPN. So I’m going to Sydney twice effectively. So that’s it for this lecture, guys. If you have any questions, please let me know. If not, feel free to move on to the next lecture where we cover failover routing policies.

• Category: Uncategorized