Amazon AWS SysOps – Networking – Route 53 part 2

6. CNAME vs Alias

So let’s try to understand the difference between a CNAME record and an alias record. So if you have an AWS resource that could be a load balancer or cloud front, it will expose an AWS host name. For example, if I have a load balancer, it could be LB 1234 dot es two elb Amazon U s. com. So this is a URL that Amazon Web Services controls. But you don’t. What you want to do is to expose your application as myapp dot my domain. com. But you want it to point to your load balancer. So what we need is a CNAME. So a CNAME, if you remember correctly, points a host name to any other host name. So for example, app dot my domain. com can be pointing to blah blah anything. And CNAMEs are great, but they only work for non root domain.

So it has to be something MyDomain. com. That’s what I mean by nonroot. It cannot just be MyDomain. com It has to be something my domain. com. And then we have alias records. Alias records are very similar to CNAME but they point a hostname to an AWS resource. So this time it has to be app MyDomain. com to blah blah Amazon Aws. com. So in this instance it has to point to an alias resource specifically where a CNAME could point to anything. And the great thing about alias is that they work for both root domain and non root domain. So it can work for MyDomain. com. Very simply. On top of it, alias records are free of charge and have capability for native health checks.

So the examiner will ask you to understand what is the difference between a CNAME and alias and when to use which. And the answer is, if you have a root domain, then you have to use an alias. If it’s a non root domain, you can use either. And usually it’s always going to be an alias anyway because you point to an image resource is going to be free of charge and better. But anyway, now you know the difference between the CNAME and an alias. But let’s go into hands on to see what I mean by that. So currently I have an A record for my root domain. So I’m going to delete this just for now, okay? Now I’m going to create a record set. So let me close everything. Here we go. I’ll create a record set and it’s going to be Myapp Stefanotisher. com.

And first choice is for me to make it a CNAME and I’ll make it a CNAME directly to the load balancer I have. So I scroll down, click on load balancer and I’ll select this DNS name right here and I’ll say, okay, CNAME pointing to this. This is a very valid CNAME and it works. I’ll click on create and as we can see now if I go to myapp Stefanthetteacher. com, as we can see, we get the hello world directly from the load balancer which points to the EC two instance. So this is working really, really great. Also, what I could be doing is instead of doing a CNAME, I could use an alias record because this is a load balancer. So here I’m doing something inefficient. I’m pointing directly to Amazon resources, but I don’t take advantage of the alias feature.

So I’ll create a record. I’ll call it my alias.And there I’m going to make this an alias record. So I click on alias. Yes. And you can say, okay, either you choose a target name and to be honest, I’m still confused about how this works because sometimes it just doesn’t show what you want to have. Or it says you can also type the domain name for the resource directly in there. So if I just paste this, it will work and find right away. That is my load balancer in there. So I’ve pasted this and we get an alias hosted zone ID. So this is perfect. Click on Create and here we go. We have an alias record being created. And so if I try this URL, myalias does define the tissue. com.  I get the exact same result pointing to the load balancer and eus one C.

So in that regard, my CNAME, my app and my alias, they do the exact same purpose. One is an alias record, one is a CNAME. And so this one is going to be free, this one’s going to be paid, but they achieved sort of the same purpose. Overall, I do recommend for you to use My alias. As we can see, though, in My Alias, we can evaluate the target health right away by clicking on yes. And I will directly leverage the load balancer health checks for this, which is really, really cool. But for now, I’ll just leave it as no. Okay, now let’s look at root domain. So if I go on Stefanchee. com, I can make this an alias and enter the target name in there and click on Create. And this works just fine. So Stefanotissue. com is an alias directly to my load balancer.

So my root domain is an alias and that works just fine. But if I create a record set and this time so let me just delete this one. Obviously, first I’ll delete this one confirm, so I’ll make a new one, Stefan tissue. com. But this time I make it a CNAME pointing to and my domain name for my load balancer, which is right here, pointing it and click on Create. Here we get an error saying the CNAME with the DNS name is not permitted at apex in zone Stefancier. com. So that means that basically I’m trying to create a CNAME at the root of my domain name, so at the apex of my zone. And that is just not allowed by Route 53. So I cannot do this. If I wanted to have Stefanoscher. com pointing to my load balancer. CNAME is not an option. It would make an error.

The only way to do it would be to select an alias record and point directly to my load balancer in there and click on Create. And now let’s just test that out. I’ll go to Stefanathshare. com and we’ll have to wait just a little bit for it to work. So let me just wait 1 second and I use an incognito window just to make sure that I have no DNS cache in there. But here we go. Stefanche. com points directly to my load balancer and it replies from my EC two instance. So this is perfect. That just proves that basically alias records both work for the root domain and also for subdomains, whereas CNAME just work for subdomains only. And it is something that you need to know going into the exam. I hope you liked this lecture. I will see you in the next one.

7. Routing Policy – Simple

So let’s talk about routing policy. And the first one is going to be simple routing policy. We have a web browser and route 53 and we just say, okay, we want to know where is foo dot example. com route 53 will reply it is an A record and the IP is 1122 33 44 excellence. So we just use it basically when we need to redirect to a single resource. It’s very easy, simple routing, right? And the thing is, with simple routing, you cannot attach health checks. So we have not seen health checks just yet. We’ll see them in a few lectures. But health checks cannot be attached to simple routing policy. So it’s dead easy. Very simple. That’s why it’s named simple. In simple though, you can return multiple values to a client, in which case the client sees all the values and the client will choose a value at random to use. So let’s have a look at how this works in practice.

So in this example, I’m going to create a record set and I’m going to call it simple that’s defined@tier. com. It’s going to be an A record and the Ttl is going to be set to 60 seconds only and the value is going to be my URL in for example, US West one. So I’ll just choose this one and I’ll paste it in, click on Create and we’re done. Okay, so this was a simple record and we have a low Ttl of 60 seconds. So 1 minute. And so as you can expect, if I go to Simplestfan Teacher, what we see is a hello directly coming from US one A. If I use Dig to basically query for this URL, what do we learn? Well, we’ll learn that and I don’t need to use the Http, otherwise things will not work. So let’s try again. We’ll learn that, yes, we have 59 seconds of Ttl left and the IP result is 386 116 186. Okay, that’s as simple as simple gets.

But we can make this a little bit more complicated basically by going and adding another IP. So for example, here, instead of just having one IP address, I can have multiple IP addresses. So I’ll just choose another one from my instance in Ireland, I’ll select this IP address and as we can see here, you can basically enter multiple IP addresses on separate lines. So here we have two IP addresses. And what this means is that when the web browser will query for Simple Stefano Cheer. com, it will receive two addresses back and then my browser will choose to which IP to go. It could be very helpful, basically, if you want the web browser to start doing some load balancing. It’s called client side load balancing.

So if I use Dig and now query for this little domain, as we can see now, the answer I’m getting back is that I have two answers. I have two A records and two different IP addresses available to me. Similarly, if I go and open up the backmysimple stefanache. com URL with a bit of luck, I’ve been transferred to EU West one C. And so if I refresh this page for 60 seconds, it’s for sure always going to go to EU West One C. But after 60 seconds, my web browser will make another DNS request, and there’s a chance I would fall back to this value again. So it’s something very important to see. It’s simple, but as we go along in this section, we’ll see more complicated policies, and it’s always nice to start with something a little bit simple. So have a play. Play with the Ttl, play with the different IPS, play with Dig or NS. Lookup, and I will see you in the next lecture.

8. Routing Policy – Weighted

So now a more interesting routing policy is called weighted. And weighted controls the percentage of the request that will go to specific endpoints to be concrete and visual. We have Route 53 and we’re going to assign different IP addresses may be linked to easy to instances and we’re going to assign weight. So 70, 20 and ten. By the way, the sum does not have to be 100. It’s just me who chooses easy number. But whatever weight you put, whatever the sum is, it’ll just do the average and figure out a percentage from it. So what we mean from these whites is that now Route 53 will send 70% of the answers to be back from this EC two instance, while it will send 20% of the answer back from the second one and 10% of the answer back to the third one.

What this means is that now our clients will send 70% of the traffic to the first instance, 20% of the traffic to the second instance, and 10% of the traffic to the last instance. So that’s really helpful to start, basically assigning different weights to different parts. So what we do to do this? Well, for example, you deploy a new application version and you wanted to test only 1% of the traffic on this new app version, for example, then that’s a nice way to do it with Route 53. Or it’s helpful to split traffic between two regions. And this is super quick because you can also associate this with hell checks. So if one easy to instance is not working properly, no traffic will be sent to it.

So let’s have a look at how this works. In the console, I’m going to create a new record set and I’ll call this one Waited. And here I’m going to set different values. So the first value I’m going to set is the one from EU West one A, which is Ireland. And then I’m going to say the routing policy is weighted. Weighted? Why? Because we’re going to be able to assign weights. So we’ll say this one is going to be 70 and we’ll set the ID my Ireland data center. But you could set this to an arbitrary link number, for example, 700. So 70 is fine and here you could associate with a health check. But for now we’ll leave it as no. All right, we’ve created a wait.

But now the cool thing is that we can recreate another record set on the same name. So Waited Stefancier. com, but now the value is going to be something else, maybe US East one. And I’ll just paste this here and here we go. Now, again, I will say that the routing policy is weighted and this time the wait is going to be 20 and the ID is going to be US. Whatever you want to set, really click on Create. And so the cool thing we see now in the bottom is that our two records right here are added in two different rows and they basically point to different values. And at the right hand side we can see the weights as a column right here. And at the top right hand side we can see the ID we set to these records.

So finally we can set another weighted record. So I’ll say weighted and the value is going to be my Tokyo instance. So I’ll copy this IP and place the value in excellence. And the random Palestinians waited. And the weight is going to be ten. And I’ll call it Tokyo. Excellent. Click on create. And now what we get out of it is three different records in here that point to three different instances. So now I know you’re dying to do it. Let’s try this URL. So let’s try weighted. Stefan Tshirt. com. And here we get an answer from us. East one A. And so if I refresh, I’m always going to be redirected. To us. East one A. But when the Ttl is gone, so when 300 seconds pass, I did not change the Ttl, so it’s going to be longer to wait.

I will resolve to a new IP. And the idea is that thanks to the weight, I have 70% chance of lending on Ireland, 10% chance of lending on Tokyo and 20% chance of lending in the US. You could also take this DNS name and use Dig to query it and see what you get back. In this case, basically, what we’re going to get back from it is only one IP. So we’re not aware that there is any weight applied. We’ll just get back one IP. And this IP, if you remember, is from Ireland. And so the idea here is that the Route 53 will serve the answers based on the weight. And so from a client side perspective, we’re not aware that there are multiple IPS in the back end.

9. Routing Policy – Latency

One of the most useful routing policy is going to be called Latency. And latency at this name indicates will redirect the user to the server that has the least latency close to us. That’s super helpful when latency for the users is your priority. And latency is going to be evaluated in terms of the user directly to the AWS region. That means that if a user is in Germany, if the U East one, a for example, region, is the least latency for that user, then that’s where it’s going to be redirected. So let’s look at the map. This is the map of all the AWS regions, and the numbers represent the number of AZ per region.

Say we have two easy two instances, one on the west coast of the United States and one in Sydney in Australia, and we have all these users around the world. Well, it turns out that maybe based on the latency routing policy, the four users on the left hand side of the map will be redirected to the US. While my users on the right hand side of the map will be directed to Australia. So this is how a latency routing policy would work. But let’s just prove the point through the hands on. So I’m going to create a record set. This time I’ll call it Latency, and this is going to point to an IP address, and the first one is going to be EU West One. So I’ll just select this, put the value, the routing policy will be Latency.

And here, as you can see, the routing policy is asking me, okay, where is this IP belonging to and which region is this located? And so this is an EU West one. And I’ll just say, okay, Ireland instance. Perfect. Then I click on Create. Let me create other record set because on the latency based policy, you have to create multiple record sets. So I’ll create a second one. I’ll call this Latency, and then I’ll have a second value. So I’ll put in this instance in US east one. So I’ll just say, okay, here is this value. The routing policy is latency. And automatically it’s really smart because it’s an easy two instance that recognizes the region of it. So we’ll say, okay, this is America, okay, perfect.

And click on Create. And then finally I’m going to select one last. This is for Tokyo. So I’ll just put Create record sets, latency stefanosher. com the value is this, and the routing policy is Latency and it knows it’s AP Northeast one. I’ll call it Tokyo excellence. So now for this latency, we have three record sets. And as we can see here, this is a latency based and we have the instance ID right here and the region it’s linked to. So now I’m in Paris, I’m in Europe. So if I go to this URL, guess what instance is going to reply to me. Well, it should be the one in Ireland because that’s the one that’s the closest to me. So I should have the least latency to the one in Ireland.

Let’s have a look. Yes, I’m in Europe, and it looks like I’m in EU West One C. And yeah, this is perfect. This is where my closest latency is. But let me try something else. I have a VPN solution, and I can basically connect to any country in the world. So I’m going to connect something like Costa Rica, for example, which is on the American continent, because I don’t want to use the US. But I want to show you that even in Costa Rica, I’m going to connect to the US. So let me now refresh this page. And now it looks like I’m in Costa Rica. So if I refresh this now, automatically I get the hello, world from us. East one A. Excellent. And if I just do one last test using my VPN, which is Nordvpn, by the way.

So if I just do one last test and want to connect, for example, to the last region, maybe I’ll connect to Japan. So I’ll choose Japan as a country and wait for me to be connected. Okay, I’m now connected to Japan. Let me refresh this page, and hopefully we should see that. Yes. I get redirected to AP northeast one A. So all of this is working. That’s really awesome. And it just shows how latency policies work. So I get redirected to my closest, lowest latency position. And this Nordvpn thing was for me to trick myself into trick my web browser to thinking that it came from a different region of the world. Okay, so that’s it for latency. I hope you enjoyed it, and I will see you in the next lesson picture.