Amazon AWS SysOps – Networking – Route 53 part 4

12. Routing Policy – Geolocation

Okay, let’s talk about the Geolocation routing policy. So it is different from latency based, this one is routing based on the user location. And so here we are saying okay, traffic that originates from the UK should go to this specific IP if that’s a record. And on top of it we should create a default policy in case for example we get a user from Germany, but we haven’t specified a routing policy specifically for Germany. Then we say okay, by default you go somewhere else. So this is to route based on the user location and to redirect traffic from a specific country. So if you look at the map, this is for example the west of the European Union.

So here we get for example we say, okay, all the traffic that comes from the UK should go to 1122-3344, whereas all the traffic that comes from France should go to 2233-4455. And then by the way there’s a default and the default says if you don’t have the basically the traffic originating from the UK or France, then the default response is going to be 3344-5566 and that’s how geolocation works. Now let’s practice this in a second. So in my hosted zone I’m going to create a record and I’ll call this one Geo and I will say okay, the value of it is going to be my Ireland instance. So I’ll just say this one here, Ireland.

And I’ll say okay, the routing policy is going to be that ger location, all the traffic coming from, for example, you can either say continent or countries or default. So I’ll just say a country right now and I’ll say all the traffic that comes from friends should go. So I’ll just set an ID. So I’ll say Geo, friends should go to this IP right here. So here if my browser is in France, which is right now, then I should get this answer. So I’ll create it. You can also create a new record set. So I’ll name this Geo and now I will say maybe one for America. So if it comes from the United States or the whole America region, I will say okay, you should go to this IP.

So let’s do Geolocation and the location is going to be continent north America. Perfect. And I’ll just call this North America Geo. Excellent. And click on create and then finally maybe I want to create a record set geo. And this one is going to be if you don’t have any match then send me to Tokyo. And so we’ll say, okay, Tokyo, IP and geolocation. This time we’ll choose default. So we’ll say default, redirect to Tokyo, whatever name you want to set really. Okay. So now after creating this record set, what we should see here is that we have three records associated with this geo safefanderser. com and it turns out that if my traffic is from France, I should be going to this IP.

If my traffic is from America, North America. Then I should be going to this IP. Else any other traffic should go to this one. So let’s try that out. I’ll go to Geo, to my URL, basically, and the answer I should get from this one should be from Ireland. So let me just take care of that. By the way, I should just remove this. So this is not working. Oh, I know why. Because my public IP changed. Because I basically stopped and started my easy to instance. This is really silly of me. So I’m going to go back and basically change this IP to the correct one. So as you can see, the last bits of my IP have changed. So this was a good error to have. So I’ll keep this one as well on record.

But when I stop and I start an easy to instance, obviously the public IP changes. And so, by the way, that means that all my records beforehand must be updated if I wanted to use them in the future. So in the meantime, what I can do is maybe go to Mexico and see what’s going on in Mexico. So I’m connecting to Mexico. Excellence. I’m in Mexico and I try this URL. And the answer I get back is us. East one A. So excellent. Because I come from North America. It redirected me directly to us. East one A. But if I go to Brazil so let’s go to Brazil. Now, if I go to Brazil, basically because it says South America, I should be redirected to Tokyo.

So let’s try it out. I’m going to connect to Brazil. Okay, I’m connected to Brazil, and now if I refresh, the answer I should be getting is one from Tokyo. So let’s try it out. And yes, as we can see, we get redirected to AP Northeast One A. So let’s try it out. Now I’m going to go to France and we should be seeing the one instance from Ireland. So let’s try it out. Okay. We’re in France. I refresh my page and here we go. I get my answer. EU west one c. So really cool. We’ve had a good explanation of how Geolocation works. So this is based on the origination of the traffic, where the traffic is originated from, and then we redirect to whatever we want. Okay, sounds good. I will see you in the next lecture.

13. Routing Policy – Multi Value

Finally, the last routing policy is going to be called multivalue. And this is when you want to route traffic to multiple resources and you want to also associate Route 53 health checks with the records. So it’s some sort of improvements over simple routing policy. It will return up to eight healthy records for each multi value query. So you get up to eight values returned, even if you have 50 records in the back end. And although it looks like a good replacement for Elb, it’s not a substitute, it’s different. But it really helps to do some kind of load balancing as well on the client side. So what this will look like is that we’ll have example, a record will have three different values and all these values will be associated with the health check.

And the idea is that if one of these instances stop serving traffic, the route 53 will not send back the value of that to the clients, but the other two will still be happening. So let’s have a look at it in a quick hands on. So I’m going to create a new record set, and this one is going to be called Multi. And the first value is going to be my IP address of my Ireland instance, which has changed. So I’ll just keep it here. Okay. And the routing policy is going to be a multi value answer. And I will associate it with a health check. Yes, and I’ll associate with the Ireland Health Check. Click on create. So this is set, ID is empty, so I need to say, okay, multi Ireland. Okay. Click on Create. Next I have to create a new record set.

So again it will be a multi, but this time I will have my multi going to the US. So I’ll just take the one from the US, this IP right here, and then I will say multius associate will help check. Yes. And the one is going to be Virginia. Click on create. And then finally I will have the Tokyo multivalue answer in there. So I’m going to say Create, record set, multi. And the value is going to be this. The routing policy is going to be Multivalue answer. This is multi Tokyo. I will associate it with the Tokyo Health check. So I’ll say yes. Tokyo health check. And I will also set the Ttl to be 1 minute. And this will actually update all the TTLs for this multi value. So good to know. I click on Create. And if you look at our multi, so our multi here has three records.

Okay, so I’ll just actually I could filter, I should have done that. But we have three multis in there. All of them have a 62nd Ttl and they’re associated with some health checks. Okay, so let’s look at the health checks. I suspect that one health check is unhealthy because my IP address has changed. So this one is unhealthy. So I’m going to quickly edit it, edit the health check. And I will put this IP address in here, which is the correct IP address. But this is a really good time to actually test out a record. So for this, I’ll use Dig and see how it goes. So dig. And then I’ll say multitoucher. com. And what we get out of it is a strange answer, I have to admit. But here in the answer section, we have these two IPS.

And this is actually due to my VPN. So we have these two answers right here, which is the two IPS that are healthy. So as we can see, it didn’t return the third one because the health check was unhealthy. But what should happen is that as soon as this health check becomes healthy and I run the exact same query, then I should get three IPS back. So let’s just wait a little bit. Okay, so my health check is now healthy. As we can see, the health check just flipped to being healthy. And so if I go back to Dig and do a query now, hopefully I should see three answers. And here we go. We have three answers directly to us because the third one, this one just got healthy.

And so Route 53 was allowed to give us this answer back. And so from a web browser perspective, if I go to this URL, basically my web browser will just pick any of these three IPS at random and just use this one. So if I just try it out and go here, as you can see, my web browser is able to just choose an IP. And if one of these was unhealthy for whatever reason, then because my web browser has other IPS as well, return as part of the answer, it can try the other ones and see which one would work, which is quite cool, which gives us as well, some kind of fault tolerance, but this time on the client side. So that’s it. I hope you enjoyed this lecture. I hope you understand better how multi record work. And I will see you in the next lecture.

14. 3rd Party Domains & Route 53

So Route 53 is also a registrar. And we’ve seen this before. What is a registrar? It’s basically an organization that manages the reservation of Internet domain names. And so there are some famous names in there that we all know. There is for example, GoDaddy or Google domains, etc. And also we’ve seen this in this lecture, in this whole section. Route 53 or AWS is also a registrar. So we can buy domain names on a registrar in on AWS. But one thing you should know is that a domain registrar is different from a DNS. Although both under Route 53 name, we get these two features. They’re very different. One is to offer a DNS and the other one is to offer domain registration. So there is something little known that is possible to use a third party domain registrar with AWS Route 53.

So if you buy your domain on another website, you are still able to use Route 53 to define all the rules, et cetera, et cetera. How would you do it? Well, number one, you create a hosted zone in Route 53. And number two, you update the Name server. So NS records on the third party website to use the Route 53 name servers. And then again, I want to remind you, domain Registrar is not DNS, but each domain registrar usually comes with some sort of DNS features. So I just want to show you one of these things on my personal domain. So let me show you right now. So here is my Google domain for Data Accumulus. com, which is my own company. And so as we can see here, the Name servers. I got an option.

Either I use the Google Domain name servers or I can use custom name servers. So if I use the Google Domain Name servers, then I choose my DNS to be the one that comes with this interface. But if I use custom name server, I’m able to insert here the AWS name servers. And then from there I’ll be able to create a public zone and configure my DNS records in there. And then what would I put in the Name Server space? Well, if I go back to Route 53, click on Hosted Zones and then I would need to create a new hosted zone for my domain name. So it would be Datacumulous. com, et cetera. I would not do it right now. But if I were to do this, then I would click on the Domain name here on the radio button.

And on the right hand side, as you can see, there is Name Servers and these four Name servers. All these four URLs is what I would have to put in my Google Domain Name servers. I would put this one, I would put the second one. You get the idea. I would put the four of them and then I would click on Save and then automatically now for my domain dataacumos. com, it will be using this specific private hosted zone. Public hosted zone in route 53. So that’s it? It’s just something that can come up with the exam. How do you integrate a third party domain with Route 53? And I hope gives you a clear answer. The idea is to create your domain elsewhere but have the name servers of your elsewhere point directly into your hosted zone. So that’s it. I hope you liked it and I will see you in the next lecture.

15. Section Cleanup

Okay, so to clean up this section, you could go ahead and delete all the records from there that you wanted. So you could click on all of this. For example, I just do it for all of them. And then once you have selected all of them that you’re ready for, you go and click on delete record sets. So this is just an example. So I’ll click on Delete record sets and click on Confirm. And you basically do this for all the record set that you want to delete. Then, if you remember, we’ve created it a few things. So we’ve created an easy to instance in three different regions. So I’ll terminate all my EC two instance.

So Ireland, there was North Virginia, and there was also Tokyo. So let’s go right here.North Virginia. I right click and terminate this one. Yes, going on. And then Tokyo. I right click and terminate this one. Excellent. And then if I go back to Ireland and I go to load balancers, I also delete my load balancer from there, excellence. And that’s it. That’s how you just clean up everything we’ve created. You can also delete all these leftover records. So here we go. This way they’re all clean. And that’s it. You’re ready to move on to the next lectures? All right, see you in the next lecture.