8. [SAA] NAT Gateways
Talk about routing policies for Route 53. So a routing policy is helping Route 52 respond to DNS queries and we shouldn’t be confused about the word routing, okay? This is not like when you have a load balancer and the actual balancer will route traffic to the back end. Easy two instances. No, no, this routing is from a DNS perspective. So the DNS does not respond, does not route any traffic, so the traffic doesn’t go through Router DNS. The DNS only will respond to the DNS queries and then the clients will know to which way they should be doing these Http queries for example. Okay, so the DNS just helps translate host names into actual endpoints that the clients can use.
Okay, so Route 53 will support the following routing policy. There’s simple weighted failover, latency based geolocation multival answer, and geo proximity. And we’re going to have a look at all of them in this section. Okay, so the first one is going to be the simple routing policy. And the idea is that with this that we’ve actually been using before, we’re going to route traffic to a single resource typically. So here’s an example. The clients will say, hey, I want to go to foo example and Route 63 will say, hey, go to this IP address and this is an A record.
So it is possible for us to specify multiple values in the same record. And if so, if multiple values are returned by the DNS, then a random one will be chosen by the clients or client side. So in this example, we have the clients asking again for foo example and Amazon route 53 will just reply with three IP addresses that are embedded into the A record and then the client will pick one of them randomly and apply it for the routing. So if you have enabled an alias record alongside the simple policy, then you can only specify one a toast resource as a target. And finally it’s called simple because it’s very simple and therefore you cannot associate this with health checks. And we’ll see health checks later on in this section and how they work. Okay, so let’s go into consult to see how a routing policy of typesimple can be created.
So let’s create a record and the record name is going to be Simple Stephanie share it’s an A record and the value of which is going to be, for example, my instance in AP Southeast one. Now for TTL I will say something very low like 20 seconds and the routing policy is going to be here. So as you can see, we have different possibilities, six of them and then one other that is somewhere else in the UI. So we have a TTL 20 seconds, a simple routing policy and let’s just create this record. So we’ve been doing this before, we know how this works. So now if we go to Simple Stefano Tshirt. com and go to this URL, we get Hello World from my instance in AP Southeast One D, which is awesome. And if we do a Dig command and have a look, so we need to reinstall Dig. So sudo yum install bin util. So this is because I restarted my machine here.
Okay, so we’re going to redo the Dig command. So we do the Dig command on this. As we can see, we have an A record of a TTL of 20 seconds pointing to this IP. But we can change this record. Now we’re going to edit the record. So I will just simply click on it and edit the record. And for the value now, I can enter multiple IPS, so I can enter my one in Apsafx One or one in US east One, for example. So when I do so and save this, what’s going to happen is that once the TTL expires from before, we’re going to get two records back. So let’s use Cloud Shell to verify this.
So I’m going to do a Dig command, and as you can see now we have in the answer section, we have two responses. We have one in this IP and one in this IP. So it’s a client side choice. So that means that if I go to this website and refresh, I have one chance out of two to go into US east One. And that didn’t. So it was back into APS east one b. But let me pause for 20 seconds and I’ll get back to you and I’m refreshing and I get back the Hello World from US east One A. So this worked. This absolutely shows how simple records work. I hope you liked it and I will see you in the next lecture.
9. [SAA] DNS Resolution Options & Route 53 Private Zones
Now let’s talk about the weighted routing policy. The idea is that you can have a percentage of requests you can control to go to a specific resource thanks to weights. So put it simply in the diagram, we have Amazon Route 53, and then we have three easy to instance that have been assigned different weights. So 70, 20 and ten. In my example, these weights sum up to 100, but you don’t have to in the real life, okay? What this means that 70% of the DNS response instances from as Amazon Route 53 are going to be redirecting to the first 82 instance, then 20% to the second, and 10% to the third.
So what we have to do in our way is to assign each record a relative weight and then the traffic percentage is going to be sent to each record is just the weight of the record divided by the sum of all the weights of all the records, which is like a percentage of all the weights. Okay? The weights don’t sum up to 100, they’re just indicative of how much we want to send to this instance compared to all the other records in your DNS name. So to make this work, the DNS records must have the same name and type and you can associate them with health checks, although we haven’t seen what health checks are again yet, but we’ll have a look at them very, very soon.
Now, the use cases for a weighted routing policy is pretty obvious, is to do, for example, load balancing, maybe across different regions, or to test a new application version by sending a small amount of traffic to it and so on. And then if you assign yourself a weight of zero, then you’re going to stop sending traffic to a specific resource so you can shift weight over time.
And if all the resource records will have a weight of zero, then all the records will be returned with equal weights. So let’s have a look in the console to see how that works. So let’s create a new record, and this one is going to be called Weighted Stefanotcher. com. It’s an A record and the routing policy is going to be weighted. So first for the first value, let’s enter the one from AP southeast one. And the weight I’m going to assign to it this time is going to be ten.
Okay? So it’s very, very small weight. For the TTL, I’m going to set it to something really low, 3 seconds to just show you the impact of weighted. But obviously this is not a TTL you would use in real life. So we can see, we can associate a health check with it, but for now we won’t. And we have a record ID that we can set. And this is to identify this specific record within the weighted record set. So for this one, I got this instance from the southeast. So I’m just going to write Southeast, okay. And then we can add another record.
And again, we’re going to use the same Weightedfoundture. com, okay? And the routing policy is going to be weighted and the value of which is going to be the one from US East one. So I’m going to copy this IP and paste it here. The wait is going to be on this Time, 70. So we’re going to send 70% of the traffic to us. East one. And then the record ID is us. East. Great. And the TTL again. 3 seconds. And one last record will win two. IDs. So again, weighted. And then the value of which is going to be EU. Central one in here. And I’m going to Send it as a weighted record. I’m going to send 20 as A Weights, and The Record ID is going to be EU, okay? And the TTL, 3 seconds.
So now let’s go ahead and create these records. And as you can see, we now have three records in this table, okay, so this is why it’s different from, for example, a simple Record that had two values. Here we have three Records, and each record has one value as an answer. But we have a Weight of 1020 and 70. So if I go to the URL knife, I go to weighted dot Stefan, the teacher. com and press enter. I’m getting a first response from US East One A, which makes sense because, well, this is where 70% of the traffic is supposed To Be going, okay, to this region.
But if I refresh, and I need to refresh maybe every 3 seconds, at some point, I should be getting a response from another region. And this is just based on weight. So this is the whole idea behind Weighted resources. So you can see this One is not changing a lot. So let’s do a Dig Command just to show you the output of what it is. So dig weighted. Stefan Teacher and here we get a TTL of three. And The Answer Is, I think, still the one from USD One, but so let’s try to issue one more and see if we get any luck here. So the weight of 70 definitely is a big weight, okay, but here, as we can see, we just got an answer. And this One is a different IP, 317 14, which is corresponding to the weight of 20.
So, as you can see, weighted does exactly what it’s supposed to do. It’s redirecting most of the Queries into the one that has the most weight, but from time to time, you will get other Answers, okay, and so on. So this is something you can practice in your Web browser as well as you can see. Cool. I just got Redirected into EU Central One C. So that’s it for this lecture and hopefully shows you the Power of weighted records. I hope you liked it, and I will see you in the next lecture.
