14. [SAA/DVA] Routing Policy – Geolocation
So now let’s talk about the routing policy, geolocation, which is very different from latency based. So this is based on where the user is actually located. So for example, you can say if a user comes from a specific continent or a country, or even more precise on the US states, and the most precise location is going to be selected at first, then route to this IP. So you should create a default record in case there is going to be no match on location. And the use case for this is going to be for website localization to restrict content distribution, dolobalancing and so on. And these type of records can be associated with health checks. So the idea is that if we have a map of Europe with multiple countries, we can define a geolocation record.
For Germany to say that German users should go to this IP, which contains my German version of my app, and if I go to France, then go to this IP which contains the French version of my app, but for anywhere else go to the default IP here, which contains maybe the English version of my app. So this is how you would use a geolocation. Now let’s go practice in the console. Okay, so let’s go ahead and create our first geo record. So I’m going to create a record and I’ll limit geo. And the record type is going to be A. The value of it is let’s link it first to the AP southeast one. And what we’re going to do here is going to say the routing policy is going to be geolocation and we’re saying okay, all of Asia.
So any user located in Asia should go to my AP southeast one. EC two instance we could associate a health check with it if we wanted to. We need to give a record ID. So here we go. Now let’s add another two records. So what I’m going to do is that I’m going to say that for US east one I want to send any user from and we can say geolocation yet again. And let’s say for example, just a country. So we can say United States and we could say lastly, so this is record ID us.
And so as you can see here I specified a country and here I specified a whole continent, it doesn’t matter. And then lastly I will add one more record. Here’s the record name and the value of which is going to be EU central one, and this one is going to be my default. So I’m going to say geolocation and the location is default.
That means that anything that doesn’t match Asia or United States is going to go to my default location and this one is going to be called default EU. Now let’s create these records and they’ve been successfully created. So what I can do now is that I can test it, right? So currently I am not in the US. And I’m not in Asia. So if I open this URL, I will get the EU central one region. So this is good. That means that this is the default record that is working properly. So now let’s change geographic location, and to do so, I’m going to use my VPN. And now let’s go to a country in Asia.
So let’s go to India. So I’m now connected into India, and when I refresh this page, now what I expect is to get a hello world from my AP Southeast One instance. As you can see, there’s a long load, so I know what’s happening. So this is a timeout. And so whenever you see a timeout in AWS, usually you have to think about security groups. So if I go to my security group, yes, I’m in the right region, so in the Singapore region, and look at the inbound rules and edit them. If you remember, I had removed the Http rule to make the health check fail. So we need to add back that Http rule.
So let’s add it back. And it’s a good error to have on screen. So the Http rule has been added back. And so now if I go back into this page, as you can see, now we get the hello world from AP Southeast One B. So the Asia thing is working. Now, if I go to a country in the US, if I go to the United States overall, and I’m in the US. And refresh I’m going to get. Hello from us. East one A.
So this is perfect. And if I go to something right next to the US, but not in the US. For example, if I go to Mexico and refresh, as you can see, I get my EU Central One C, because this is my default record. And the Mexico was not specified as a rule in the Your Location Route 53 record. Okay, so this is it. This is working perfectly. I hope you like this lecture, and I will see you in the next lecture.
15. [SAA/DVA] Routing Policy – Geoproximity
So now let’s talk about another feature which is called geoproximity routing and it can be a little bit confusing but I will try to explain it with diagrams in the very next slide to make it clear. So this allows you to route traffic to your resources based on the geographic location of your users and resources. So the idea is that with this policy you’re both using a number called the bias to shift more traffic to resources based on specific locations. And I will show you this in a diagram in the very next slide. So the idea is that to change the size of a geographic location you need to specify a bias value.
If you want more traffic to go to a specific resource you expand the bias value by increasing it. And if you want less traffic to go to a resource you shrink it, you decrease the bias values to a negative number. So the resources can be resources from AWS in which case you specify the region they’re in and automatically a Rest will compute the correct routing. Or if there are non aus resources such as your on premises data center, then you will just need to specify the latitude and longitude such as Adobes knows where they are right now.
And then to use this feature you need to use the advanced route 53 traffic flow to be able to leverage the bias. So a diagram should make everything more simple and to me this is what you should remember. So let’s take an example of a resource in US West One and one resource in US East One and the bias is set to zero in both regions. So that means that if you have users all around the US trying to access these resources there’s going to be a line dividing the US is into and users left of that line will go to US West One and user right of that line will go to US East One.
Now this is simple, this is when there is no bias. Okay? And this looks like going to the resource region based on the user location. But thanks to the bias we can have the same set up but a different way to have the users routed to different regions. So let’s take an example. We have US West One and US East One and the bias is set to zero in US West One but we’re going to have a positive bias of 50 in US East One and we’ve seen that the bias makes more users and more traffic to that resource.
Why? Well, because of the bias. Now the quote unquote dividing line between the first the two resources is going to be a little bit more to the left because of the higher bias of US East One. And so that means is that the user left of that line can go to US West One, but the user’s right of that one will go to us east one. So why would you do this? Well, for example, you would set your resources all around the world and say you needed to shift more traffic to a specific region.
What you would do is that you would use a geoproximity routing policy to increase the bias in that specific region and therefore have more users dragged and more users have traffic attracted to that region. So what you need to remember going into an exam is that the geoproximity routing is really helpful when you need to shift traffic from one region to another by increasing the bias. Okay, so hopefully the diagrams help you make more sense of the geo proximity routing policy. I hope you like this texture and I will see you in the next lecture.
16. [SAA/DVA] Routing Policy – Traffic Flow & Geoproximity Hands On
So let’s have a look into a way we can build these complex geoproximity records using a feature called Traffic flow. This is not just applying to geo proximity, but applies to everything. So the idea is that we have a UI, a visual editor, that allows us to manage complex routing decision trees. So this is the UI we’ll have, and in there we can specify different rules. We’ll have a play with it. But the idea is that instead of writing the records one by one in your DNS management system in route 53, we’re going to just manage all of them visually. And the cool thing about it is that it’s going to be saved as a traffic flow policy and they can be version, they can be applied to different hosted zones and we can easily change them and apply them in our hosted zones. So let’s have a look in the hands on right now to see how we can do it.
Okay, so let’s go ahead. We’re going to go on the left hand side panel and you will find traffic policies. So in here we get the UI, we can create a traffic policy, and I call this one Demo Geo Policy and click on next. So here we have a starting point, and the starting point is you have to specify the type of record you want to create, is it an AAA, C name, et cetera, et cetera. And it gives you a detail about what each record is. So we’ll have an A record, and here we have to connect to a specific rule. And as you can see, we can get weighted rule, failover rule, geolocation rule, latency rule, MultiValue geoproximity or just an endpoint.
So if you wanted to specify something very simple, for example an A into an endpoint, you could say the A record will point to this value 123-4567, right? And this would be the record itself, a very, very simple record. But obviously we can create more complicated policies. So we can connect to a weighted rule. And in here we can specify multiple weights. So we say a weight of ten goes to and then again we could have some advanced records, for example a failover and so on. So you can get some really complicated stuff and when you’re ready you can say endpoint and specify the value of the IPV four that you want.
So obviously we’re not going to build something as complicated as you can see on the weighted rule. For example, we can add another weight and so on and so on. So all of it is visual and it really allows us to make sense of what is happening within route 53. So we are not going to create a weighted rule though, we are going to create a geoproximity rule and we can show the map as well to have a visual feedback of what we’re trying to do. So here we have to enter the first region. And then we can have the second region. So now for the first endpoint location, you can enter custom coordinates or you can, for example, have one of these regions of AWS available to you. So we’re going to use the ones we have created from before. So we’ll choose us east one.
And then we have to specify a bias. And then I will move the map a little bit to the left. I will just remove it for now. And then this record right here is going to connect to a new endpoint and the value of it is going to be my US East One EC Two instance. So I will paste the value and we’re good to go. For now, we’ll leave the bias as zero. Then for the second region, we can enter some coordinates. So if we can say, for example, Singapore, which was AP Southeast one, and let’s do it. Singapore again, here we go. And then it’s going to connect to a new endpoint.
And that end point has to be my IP address of AP Southeast One. Press Enter and we’re good to go. So now that we have created this policy, let’s have a look at the map. So for this I will click on Show map. And so this geo proximity map is going to show me, based on the input I have right now, which users are going to go to which instance. So if you’re on that side of the world, the blue side of the world, as you can see, there’s a line dividing the blue and the orange side of the world. Then you’re going to go to my first instance. If you’re on the second side of the world, you’re going to go to my second instance. And if we change the bias so if we increase the bias, for example, of my instance in here, so we put a bias of 34. This is going to increase the surface of the world that is going to be redirected to my instance in North America. If I decrease the bias to something negative, it’s going to do the opposite thing. It’s going to center more of the traffic onto my instance number two.
So we can really play it and really have visual aspects. And the cool thing is that we can consider more than two instances. Of course, we can add another job proximity location. And for the details we’re going to say this is in Frankfurt. And then we’re going to have, as you can see now, a new map. And again you can play with the bias and see how the bias is going to impact your geoproximity map. And so this Frankfurt, we’re going to have it to a new endpoint. And we’ll have the EU central one in here, paste it and then create traffic policy. So we’ve done this one and now we need to deploy this traffic policy with policy records. So for this, I will just deploy this one into the hosted zone. Stefanuthu. com and we can say that this policy record name is going to be proximity that’s defined. com, and we can specify a TTL. And very importantly, the pricing per month is $50 per month.
So to just create this policy record, you will pay $50 per month is prorated, obviously, for how long you keep it. But if you want to remain within the free tier and you shouldn’t recreate it, obviously. So I’ll just create it just to show you what it means. And I will delete it right after. But this is not necessary for you to go all the way, obviously. So let’s create this policy record. As you can see now, the policy versions are here. So we can edit this policy if we wanted to, and edit this and deploy it as a new version. And from there, we can see the records that have been created with this demo geo policy. And so if we have a look again at the map, we can demonstrate how this works. So let’s click on this geo proximity rule in here. So let’s edit this as a new version next. And then click on this map. So, as you can see, if I’m in Europe, like I’m in France, I will be able to connect to this instance. If I’m in Brazil, I will connect to that instance. And if I am in, for example, India again, I will connect to that region. So we’ll verify this in a second by testing the record. So let’s cancel and wait for this to be created. So, the policy record has been applied. As you can see, the version used is number one.
So if I connect from where I am, I’m in Europe right now, I will get the EU central one answer, which is perfect. If I go to Brazil, for example, Z, and refresh my page, then it should be connecting to my American instance. So let’s verify this in a second. Yes. And finally, if I connect to something in Asia, so let’s change this, go to Thailand, for example, and then refresh. I’m going to get my AP southeast. One b instance.
So this is perfect. And if we go back into route 53 now and refresh this, you can see if I go to filter and type proximity the record itself, this proximity record is directly routing to a traffic policy record. Okay? And the only way I can edit this record is clicking on Edits right here. And this will take me directly into the traffic policy UI. Okay, so that’s it for this lecture. I’m just going to save some money, obviously, and delete this policy record right now so it doesn’t cost me $50 a month. And I hope you like this lecture. I will see you you in the next.
