1. Route 53 Overview
So let’s learn about Route 53, which is a very important service in AWS. It is a managed DNS, and DNS stands for Domain Name System. So, what exactly is DNS? Well, a DNS is a collection of rules and records that will help clients. So that could be, for example, a web browser that understands how to reach a server through its domain name. So in AWS, there are four common records that you should know. There is the A record, which maps a host name. In the MyApp example to an IPV 4, for example, there is credible A, which is mapping a host name to an IPV 6 address CNAME. And I have a whole lecture dedicated to CNAME, which maps a hostname to another hostname. And finally, Alias, which maps a host name to an AWS resource.
So we have to remember these four types of records, but don’t worry, we’re going to practise them in this section. Okay? So let’s do a deeper dive and look at a diagram of how Route 53 will work. So we have a web browser, and it wants to access our application. And our application is hosted on an application server with the IPV4 address 324-5678-5. And we want to be able to get access to that server. So behind the scenes, our web browser is going to make a DNS request to our DNS system, which is Route 53. In this instance, it’s going to say, “Hey, for MyAppMyDomain.com, I’m giving you a DNS request to Route 53, and I want you to tell me where this is located.” So we have a host name, and Route 53 will tell us what IP address we should be looking at. It is 32.45 points, 67.85. And this is therefore an A record because we have mapped a host name to AIP. And then the web browser has finished the DNS request, and you say, “Okay, I know where to go now.” So I’m going to do an HTTP request, and I know the target IP, and I’m going to do an HTTP request. And the server will then receive a request and say, “Okay, here is your HTTP response.”
And this is the basic idea of how a DNS works. Now obviously, DNS can be way more complicated, but at a high level, this is what you get. A web browser makes a DNS query to a DNS system such as Route 53. And then the web browser is able to reach your server, wherever it is located. So Ruthlessly can employ a variety of techniques. You can use a public domain name that you own or buy, and then you can have whatever you want. application one, mypublicdomain.com, or a private domain that can only be resolved by your instances within your VPC. So, for example, this domain application is company-internal; that’s not something you can purchase on the Internet. You’ll have to make this a private domain, and only your applications can resolve this thing. Now, Route 53 has a lot of advanced features. Some will be load balancing, and we’ll see how that works through different kinds of records.
There will be health checks, and we’ll also see this in details. Then there’s routing policy, which we’ll go over in depth, such as failover, geolocation, latency weighted, and multi-valued. So, the last thing you should know is that you are going to pay $50. So fifty cents per month per hosted zone So root 53 is not something that’s free. There is no free tier. And if you go ahead with this tutorial and buy a domain name, you will also have to pay for the domain name, which is about $12. So, just so you know, if you go along with me in this lecture, then you’ll have to pay a little bit of money. So that’s it. In addition to the overview, we’ll take a deep dive into many of these advanced features. But for now, let’s go ahead, create a domain, and try out a small record.
2. Route 53 Hands On
So let’s go to the Root 53 console. And as we can see here, that’s a scalable DNS. As a result, Route 53 is a global service that requires no region selection. And then, when you go to Hosted Zones, if you’re a new AWS customer, you’ll see nothing. But, in my case, I had already purchased a domain name and created a hosted zone from it. So we see. Stephanieshire.com, so let’s go ahead and say we have nothing in it. What you want to do is purchase a domain. So for this, you go to RegisteredDomains and click on “Register Domain.” And here you’re able to choose a domain name. So say whatever you want as a domain name. Hopefully that’s available, and it is.
So, okay, it’s $12 per year, so just know that it’s going to be pricey. Then you add it to your cart, and you register for one year. You move your mouse down. Say continue. Then you enter all of your information and enable privacy protection to ensure that no one knows what’s in your personal details. So you click on Enable here, which is by default. Finally, you check your contact details, you check the terms and conditions, and you say you agree. And then finally, if you complete the purchase and it goes ahead and actually does the purchase, I’m not going to do it because I already have a domain name. Then it’ll take about an hour to get ready. And then you can follow me along in this class. After doing the request, it will be in “Pending Request,” and you’ll see it and can see the status; you’ll receive some emails; and then, when you’re all done, it will be under “Registered Domain,” and you’ll see the expiration dates, whether or not there’s “Auto, “Renew On,” etc., etc. All right, so then you go to Hosted Zone, and automatically, because you purchased a domain through Route 53, Hosted Zone will be created for you, and we can go ahead and click on it and start creating some records. So currently, I do have some records created for some of my applications. But don’t worry about it. Right now, you should only have two records.
So what we’ll do is make a record set and then make a random record set out of it. We’ll call it my first record. And then we’ll say an IPV4 address, and I’ll say the value will be 11223-4. Just a very simple DNS record right here, and click on Create. And here we go. It’s been created. So, if I go to the Internet and search for this URL, myfirstrecord Stefanitaire.com, I will be redirected to this URL 1, one dot 22344, this IPV-4 address. Now obviously, because I don’t have any servers at this address or anything like that, it will not work. But you get the idea of how these things work. Now, how do we verify programmatically that the DNS record of this thing actually points to this IP? That’s what I want to show you right now. So for this, we will go to the command line, and if you’re on Windows, it’s called Nslookup, and you type the domain name. So my domain name here was my first record, Stefan the Teacher, so that’s it, my first record, StefantheTeacher.com. And this will give you something like this on Windows. It tells you that my first record on Teacher.com resolves to “one,” “dot 2233,” and “dot 4,” which is fantastic.
And if you’re on Mac, and I’ll use this because I’m on Mac and I’m more familiar with the Dig command, you type Dig and then my first record is Stefan Teacher, and it gives you something similar, just a little bit more information. So here we see from the answer section that my first record at Defenders.com is the same, 112-2344. So you’re free to use whatever command you want. If you’re on Windows NS, lookup. If you’re on Mac or Linux, use Dig. It’s whatever you want, really. I like Dig, so I’ll just follow along with Dig. But you’re free to just use whatever you want. So this is how we check that a DNS record works. Obviously, we haven’t achieved much here. We just created a record for an IP that we don’t control. So there’s not much going on. But in this lecture, we’ll see how we can spice things up with a route to three DNS servers and some background applications. So, until the next lecture.
3. Route 53 – EC2 Setup
Okay? So I want to configure my infrastructure to have a slew of EC-2 instances in various regions, so that I can effectively have root three. Do some very interesting things with it in the next lectures. So right now, here’s the setup lecture. So I’ll go and open the EC console. And I’m currently in Ireland, so I’ll stay there, so I started an instance. I’ll make it. Amazon Linux version two I’ll select it now. You’re getting used to it, I’m sure. TWO microns I configured the instance details. I just want one of them for the user data. I’m going to send some texts. So my text is in route 53 user data sh. And so let’s take a quick look at what this does. So we install Apache. So this is http; we know this already. Here we do something really interesting that is quite cool to see. We kept the availability zone of the EC2 instance by querying the metadata service at this IP.
So this is the EC2 metadata service, if you don’t know it, and at 169, 254, 169, 254 we create the latest metadata. We want to get the instance placement and then the availability zone. As a result, we have the AZ. And then we echo “Lol” from the hostname of the machine in AZ. And then we pass into the availability zone. We put this into the index HTML, and that’s what will be displayed on the instance. So that’s really cool. Let’s go and paste that into the user data. Then we click on “add storage.” The storage looks good. There is no need for review; simply add tags. And then I’ll just create a new security group, allow all SSH and all HTTP reviews, and launch Launch. I’ll just select this key and launch the instance. Okay, we’re doing great. So this is one instance in Ireland. But what I want to do is also do this in other regions. So in North Virginia, on the east coast, I’m going to do the exact same thing. So launch an instance, select Amazon Linux, and configure the instance details, no previous.We’re going to put the user data in place.
Add storage, add tags, and configure a security group. And then we have to create a new security group because security group members are region-scoped. So we have to recreate the security group we just created. So we’ll just choose HTTP, clicker perfect, region, and launch. Launch. And here’s a key pair you already have, but you can create a new key pair otherwise. Or you can even proceed without a key pair. We won’t be Sashing into the instances, so it’s fine. So I clicked on Launch instances, and now this instance is launching. And then, finally, in a region in Asia, maybe I’ll choose Tokyo. I’m going to set up another instance in Tokyo and Asia Pacific. So we have three instances in three very different regions. We have Tokyo, Ireland, and North Virginia. So let’s launch an instance of Amazon Linux Two, which needs some details.
For advanced details, we’ll put the user data, add storage, add tags, configure security groups, create a new security group, make it HTTP, which is great, review, and launch And here I will say that I will proceed without a new key pair and launch the instances. So now let me wait for all my instances to start, and I’ll be right back with you. So, for example, if we look at a public IP address in Ireland and click on it, it says hello from, and you’re the host. There’s also the Naz EU West Onesie. So here, I know that this instance is EU West One C. I’m just going to copy all of these IPS so I can remember the AZ. So I’ll just make a small file right here and call it IP to AZ, and it’s just for me. I will not have this file in the code at the end. It’s just for me to remember what’s where. So this instance is in Ireland, which is great. There was one in North Virginia, so I’ll put one in North Virginia. I’ll also use this public IP to say this is US East 1, and there was one in Tokyo as well. So we’ll go to Tokyo and get another IP there. And this instance right here, Excellence, is in Tokyo, so it’s Northeast 1. So, northeast one IP.
Excellent. Let’s just check that these two instances also work after the use of data, but there is no reason why they wouldn’t. So this one works; it says hello from the Northeastern United States of America. And then finally, this one should say hello from US East One A. Okay, perfect. US east. One eastern Use everything is ready. Now the last thing we need to do is create a load balancer. And so we’ll go back to Ireland. Remember that load balancers are regional, so this will not affect many people. We can’t connect it to all of the students we’ve created. We’ll link it to this one in EUC, and you’ll see why a little bit later in this course. So let’s go to load balancers, which is in the bottom left load balancer, and I’ll quickly go ahead and create a new one. So I’ll create a load balancer. It’s going to be an application load balancer. I’ll create it and name it Demo Route 53. It’s going to be Internet-facing, and on Ipv4 it’s going to be listening on port 80. This is perfect.
I’ll test it in three AZs and then click on Next Configure Security Groups. I will choose to create a new security group because I can’t find the right one that allows ads igure security grI’ll configure routing. I’ll create a new target group. I’ll call it demo root 53. TG stands for target group, and it’s going to link directly to an instance, and the protocol is going to be http port 80. And this is great. Health checks are going to be left as is, and I’ll register a target. I’ll add my target to my target group. Excellent. Click “review,” then “create.” And I’ll just wait for this load balancer to be created. So it will take a little bit of time to get provisioned, but I’ll just pause until then. And my DNS name is now active. So let me just try it out to see if it works. I’ll copy it and paste it, and here we go. I still get my Hello World from my instance. So that’s perfect. All my setup is done. And now we’re ready to have some fun. We would re-route 53. Just to summarize, we’ve created three easy-to-create instances in three different regions, and we’ve created a load balancer in Ireland pointing to one of these easy-to-create instances. Alright, that’s good. I will see you at the next lecture.
4. Route 53 – TTL
Okay, so now let’s talk about DNS records. It’s time to start listing TTLs. So TTL is basically a way for web browsers and clients to cache the response to a DNS query. And the reason we do this is not to overload the DNS. So we have Route 53, and that’s our DNS for us. And we’re going to make a DNS request from MyApp MyDomain.com.
And what’s going to happen is that the root 53 will send back the IP 32 45, C 785, which is an A record because it’s domain to IP. And then, on top of that, it’s going to also send back the TTL. And the TTL is something we can configure, as we’ll see in the hands-on. For example, we can set it to 300 seconds. And what will happen is that the web browser will cash that DNS request and the response for the duration of the TTL. So as soon as we receive that reply, it’s going to be valid for 300 seconds. And whenever you visit My apps at Mydomain.com, the web browser will only look internally. In its own case, it will not ask root 3 again.
So, after this TTL, if something changes on the root of the three sides, say, the IP back is now 195-23-4522, then our cache will be updated, but only after the TTL has expired. And then we will have the chance to have an updated DNS record in our web browser. So it’s good to see here that as soon as you operate a change on the routed-three DNS record, that doesn’t mean necessarily that all the clients will see that change right away. They have to wait for the TTL to expire before they can see that change. So high TTL is considered to be something like 24 hours. And what that means is that you get way less traffic on your DNS. So Route 23 will have fewer queries because records are caged for 24 hours. But there’s a possible chance of outdated records, especially if you change them on Route 53.
Low TTL, for example, of 60 seconds, will result in a lot more traffic on your DNS, but the records will be outdated for less time, and changing the records will be very simple. So TTL is something you have to make a decision on. It basically depends on what your application is and does. And it’s mandatory for each DNS record to specify at least So let’s have a look at how that works on Route 53. So we’re going to create a new record, and I’ll call it the TTL demo. And it’s going to be an A record. And the value of it will point, for example, to my instance in Ireland. So I’ll choose my instance right here. I’ll select the public IP, and this is what I enter. So my Toledo Stephanie shoot is pointing to my IP address in Ireland. Now let’s look at the TTL seconds. By default, it’s 300, so 5 minutes. But let me set it to 120 seconds. So after 2 minutes, I clicked twice on 1 minute, and you get 120, but you can also enter whatever number you want in there. So here is my TTL: I’ll click on Create, and here we go. We have Ttldmo, which is right here.
So what happens is that if I go to Ttldmo Stefan teacher, I get Hello World back from my instances. West one century in the EU Excellent. But if I also get this record and use the Dig command, so I’ll use Dig and then this hostname, so I have to remove the HTTP, so Dig and the hostname, you get the response 342-551-2272. And this number right here is 119. I don’t think you can see it easily on NS. Look up. So that’s why you dig. But it’s just to show you that this number represents how long this record has been cached on my computer. So if I do a dig again on the same record, as you can see here, it says 101. So that means that this record, this section, and this answer right here are cached. It’s still cached for 100 seconds. So if I just do it again, I’ll have 90 seconds. And so that will expire in 90 seconds. So while we wait for it to expire, let’s change the record to point to US East 1. So I’ll select this and go back to Route 53 in my Route 53 and update this record, saving the record sets. And so now this points to us. East One.
So if I go and refresh the TTL demo page, I still see EU West One C. And if I go to my Dig and query the same URL, 90 seconds have expired. So I get a new record, obviously. But after the record expired, only then did I get a chance to see the updated IP. So that’s really, really cool because now if I go back to my web browser and wait 120 seconds, this will automatically get updated. So let me wait a little bit. So, after some time, we can see that Hello World was created primarily from the US Easton A, and I used the same Ttldemmode stfhandtoucher.com. So, as we’ve seen in this lecture, our DNS records are basically visible and easily accessible through Dig. They’re cached for a specific amount of time on our computer, and through the web browser, we saw directly that we only got access to the other easy instance after the TTL to expire.
So that was 120 seconds in our case. So it’s really, really good to know, because going into the next lectures I’ll be playing a bit with the TTL and setting it to different values, and you need to understand why I’m doing it, and I hope that this helps. So remember: low value means more queries to Route 53. As a result, there may be more pricing and traffic on the 53. And if you said something like “one day,” that means it’s going to be really, really hard for you to change the values and have the changes propagated very quickly. Alright, that’s it. I hope you enjoyed it, and I will see you in the next lecture.
5. Route 53 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 LD 11234, esu 2. So this is a URL that Amazon Web Services controls, but what you don’t want to do is expose your application as MyApp.MyDomain.com; 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. As an example, the app MyDomain.com can point to anything. And CNAMEs are great, but they only work for non-root domains. So it has to be something on mydomain.com. That’s what I mean by non-root. It cannot just be mydomain.com; it has to be something like mydomain.com. And then we have alias records. Alias records are very similar to CNAME, but they point a host name to an AWS resource. So it has to beep MyDomain.com to blah blah Amazon.com this time. So in this instance, it has to point to an AWS resource specifically, whereas a CNAME could point to anything. And the great thing about aliases is that they work for both root domains and non-root domains. So it can work for mydomain.com very simply. On top of it, alias records are free of charge and have the capability for native health checks. So the exam will ask you to understand the difference between a CNAME and an alias and when to use each.
And the answer is, if you have a root domain, then you have to use an alias. If it’s a nonfood domain, you can use either. And usually, it’s always going to be an alias anyway because, when you point to a resource, it’s going to be free of charge and better. But anyway, now you know the difference between CNN and an alias. But let’s go 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 please allow me to close everything. Here we go. I’ll create a record set, and it’s going to be my app, Stephanie share.com. And my first choice is for me to give it a C name, and I’ll give it a C name 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 also the C name pointing to this. This is a very valid C name, and it works. I’ll click Create, and as you can see if I go to MyApp Stefanheteacher.com, we get the hello world directly from the load balancer, which points to the EC2 instance, so this is working extremely well.
Also, what I could be doing instead of a CNAME is using an alias record because this is a load balancer. So here I am 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 my load balancer right away. So I copied this and made an alias hosted zone. 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, myaliasdefiniteissue.com, I get the exact same result pointing to the load balancer and EU One.
So in that regard, my CNAME, my app, and my alias all serve the exact same purpose. One is an alias record, one is a CNAME, and so this one is going to be free. This was going to be paid, but it served the same purpose. Overall, I do recommend that you use my alias. As we can see, in my Alias, we can evaluate the target’s 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, just leave it as “no.” Okay, now let’s look at the root domain. So if I go on Stefanche.com, I can make this an alias, enter the target name in there, and click on Create. And this works for signs. As a result, Stefanuniture.com is an alias for my load balancer. So my root domain is an alias, and that works just fine. But if I create a record set this time, let me just delete this one. Obviously, first I’ll delete this one, so I’ll make a new one, Stefan Tissue.com. But this time I’ll make a CNAME pointing to my domain name for my load balancer, which is right here, point it, and click on Create.
Here we get an error saying the CNAME with the DNS name is not permitted at apexinsure.com. So that means that, basically, I’m trying to create a CNAME at the root of my domain name. So I’m 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 Stefanoshi.com pointed at my load balancer, CNAME is not an option. It would be an error. The only way to do it would be to select an alias record and point directly to my load balancer in there, then click on “create,” and now let’s just test that out. I’ll go to StefanTshirt.com, and I’ll have to wait just a little bit for it to work, so let me just wait 1 second and then use an incognito window just to make sure that I have no DNS catching there. But here we go: stefancheer.com points directly to my load balancer, and it replies from my easyTo instance. So this is perfect. That just goes to show that alias records work for both the root domain and subdomains, whereas CNAME records only work for subdomains. And there is something you should know before taking the exam. I hope you like this lecture. I will see you in the next one.
6. Routing Policy – Simple
So let’s talk about routing policy. And the first one is going to be a simple routing policy. We have a web browser and route 53, and we just say, “Okay, we want to know where is Foo?” Example.com route 53 will respond that it is an ARRAY with an IP address of 1122 33 44. Excellent. So we just use it, basically, when we need to redirect to a single resource. Isn’t it a very simple routing? And the thing is, with simplerouting, you cannot attach health checks. So we have not seen health checks just yet. We’ll see them in a few lectures. But help checks cannot be attached to a simple writing policy. So it’s that easy. Very simple. That was referred to as simple. In simple terms, you can return multiple values to a client, in which case the client sees all the values and will choose a value at random to use. So let’s take 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 Simplest Definite Tshirt.com. It’s going to be an A record, and the TTL is going to be set to 60 seconds only. And the value will be murk in, say, the US West region.
So I’ll just choose this one and 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 one minute. And so, as you can expect, if I go to the Simple Stephan teacher, what we see is a Hello World directly coming from the US one. 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 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 a guess can be. But we can make things a little more complicated by adding another IP address. So, for example, 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. This means that when my web browser queries for simple, safe, and secure, it will receive two addresses in response, and my browser will choose which IP address to visit. 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, two errors, and two different IP addresses available to me. Similarly, if I go and open up the back of my simple definition URL, with a bit of luck, I’ve been transferred to EU West 1 C. So, if I refresh this page for 60 seconds, it will always go to EU Site One C. But after 60 seconds, my web browser will make another DNS request, and there’s a chance I will 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 a TTL, different IPS, Dig or NS, and so on. Look up, and I will see you in the next lecture.
7. Routing Policy – Weighted
So now a more interesting routing policy is called “weighted.” And weighting controls the percentage of the request that will go to specific endpoints that are concrete and visual. We have Route 53, and we’re going to assign different IP addresses that may be linked to EC 2 instances. And then we’ll assign wait, so 70, 20. And by the way, the sum does not have to be 100. It’s just me who chooses the easy number. But whatever weight you put in, whatever the sum is, it’ll just do the average and figure out a percentage from it. So what we mean by this weight is that nowroot 53 will send 70% of the answers back from this EC-2 instance, while it will send 20% of the answer back from the second one, and 10% of the answer back from 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 whites to different parts. So what do we do to do this? Well, for example, if you deploy a new application version and you want to test only 1% of the traffic on this new application 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 health checks. So if one instance is not working properly, no traffic will be sent to it. So let’s take a look at how this works. within the console I’m going to create a new recordset, and I’ll call this one weighted. And here I’m going to set different values. So the first value I’ll set is one from EU West, which is Ireland. And then I’m going to say that 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 for my Ireland data center. But you could set this to an arbitrary leg number, for example, 700. So 70 is fine. And here you could join the helpshack before I leave it as no. All right, we’ve created a wait, but now the cool thing is that we can recreate another record set under the same name. Defenseare.com weighed in on this. However, the value will now be something else, possibly a US-east value. 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 weight 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 we can see the weights as a column on the right hand side. And at the top right-hand side, we can see the ID we assigned to these records. So finally, we can set another wait record. So I’ll say “waited.” And the value will be my Tokyo instance. So I’ll copy this IP and paste the value in. Excellent. And the random ballot is weighted, 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 give weighted a shot. Stefan Cheer.com and here we get ananswer from US East One A. If I refresh, I’m always going to be redirected. To us. East One A. But when the TTL is gone, which happens after 300 seconds, I do not change the TTL. So the wait is going to be longer to wait.I will resolve to a new IP. And the idea is that, thanks to the weight, I have a 70% chance of lending in Ireland, a 10% chance of lending in Tokyo, and a 20% chance of lending in the US. You could also use Digto to query this DNS name and see what results you get. In this case, basically, what we’re going to get back from it is only one IP. As a result, we are unaware that any weight is being applied. We’ll just get one IP back. And this IP, if you remember, is from Ireland. As a result, the root 53 will serve the answers based on the weights. And so, from a client-side perspective, we’re not aware that there are multiple IPS on the back end.
8. Routing Policy – Latency
One of the most useful routing policies is going to be called latency. And latency, as his name indicates, will redirect the user to the server that has the least latency and is closest to us. That’s extremely useful when minimising user latency is a top priority. And latency is going to be evaluated in terms of the user’s direct connection to the AWS region. That means that if a user is in Germany and the US East one, for example, has 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 instances, one on the west coast of the United States and one in Sydney, 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 map’s right will be directed to Australia. So this is how a latency-based routing policy would work. But let us just demonstrate the point with our hands. 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 an EOS one. So I’ll just select this, put the value, and the routing policy will be latency. And here, as you can see, the routing policy is asking me, “Okay, where does this IP belong, and in which region is it located?” And so this is an EU-West one. And I’ll just say, “Okay, Ireland, for instance,” which is perfect. Then I click on “Create.” Let me create another record set because, under 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 this in this case and us in the east case. So I’ll just say, “OK, here is this value.” The latency policy is very clever because there are only two instances.
It recognises its region of it.So we’ll say, “Okay, this is America.” Okay, perfect. and click on “Create.” Finally, I’ll choose one at the end. This is for Tokyo. So I’ll just use latency.DefiniteShare.com to create recordsets. This is the value, the routing policy is latencies, and it is aware that it is an AP Northeast one. I’ll call it Tokyo. Excellent. So now, for this latency, we have three record sets. And as we can see here, this is an availability base, and we have the instance ID right here and the region it’s linked to. So now I’m in Paris. So 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 take a look. Yes, I’m in Europe, and it looks like I’m in the EU. West. One C, and yep. 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 choose 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 page now, I’ll 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 once you connect, for example, to the last region, maybe I’ll connect to China or to Japan. So I’ll choose Japan as a country and wait for me to be connected. OK, I’m now connected to Japan. Let me refresh this page, and hopefully we will see that. Yes. I get redirected to AP Northeast 1A. 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 deceive myself, to trick my web browser into thinking it was from another part of the world. Okay, so that’s it for latency. I hope you enjoyed it, and I will see you in the next lecture.
9. Route 53 Health Checks
So there are health checks in route 23, and the idea is that if an instance is unhealthy, just like an ELB, route 23 will not send traffic to that instance. So how do we know if a health checks failed? Well, basically, an instance, an IP, or a URL—whatever you want—is deemed unhealthy if it fails three health checks in a row. And it’s been healthy if it passes three health checks in a row. So it’s pretty easy. Now, the default health check interval is 30 seconds, but there is something called a “fast health check,” which is 10 seconds, but this will lead to a higher cost. And then when you do a health check, somehow AWS basically launches about 15 health checks in the background that will check the health endpoint. So, if you have a 32nd interval and 15 health checkers that check the endpoint’s health, you will receive a request every 2 seconds on average. If you have 10 seconds for a period of health checks and you have 15 health checkers, then it will be less than one request per second or more than one request per second.
So in terms of health checks, you have lots of options. You will receive http, TCP, and https health checks. Although, when you use https health checks, you’d get no SSL certificate verification. So be careful with this. And you can integrate these health checks with Cloud Watch if you want to. The really cool thing is that once you have these help checks defined in route 53, they can be directly linked to the record sets and the DNS queries, and they will basically change the behavior of route 53. So it’s just a theory lecture, but let’s go over creating a help check to see how that works. So, to create a help check, we go to the left hand side and click on “help checks.” And here we have a UI to create a help check. So this will help us with availability and performance monitoring, and it will give us some sort of DNS failure that we’ll test in the next lectures.
So we’ll create a health check, and I’ll just say the first one is my island health check, and we’ll test my island instance, and we’ll basically monitor an end point. But we could monitor the status of other health checks, which is called a “calculated health check,” or monitor the state of a cloud watch alarm. So this is how we could link Cloud Watch to Route 53. But right now we’ll just do endpoints, and then we’ll say, “Okay, the endpoint, do we want to specify it by IP address or domain name?” So we have two options. We’ll use an IP address because we link directly to our instance. In Ireland, the protocol we’ll use is http, but we could use https if you want to choose some encryption and TCP if you just want to check if the port is open, for example.
So we’ll use HTTP, and then we’ll say, “Okay, the instance I want to test right now is the one in Ireland.” So I will use this IP right here. So I’ll just copy this IP and paste it in there. Okay, we could specify a hostname as optional if you wanted to basically give a host name to that request. But we don’t do this for now. The port is 80, and the path is going to be Justslash images is one example of what you can do. But right now, because we go directly to the IP address, if I go straight to the IP address, as we can see, we just do the route, we do the slash, and so it’s the same. So I will not add any arguments here. You can do some advanced configuration, which is quite cool. Here we can see that we have standard health checks, as I said, or fast health checks, but you have to pay more if you do a fast one. A failure threshold can be defined. So we can say three failed requests equal failure, but we can say just one or maybe ten. I’ll put it at three, obviously.
Then you can do some string matching to test the response and see if there is some string in it. We can have some latency graphing enabled. If you wanted to see the latency of these health checks and make sure that they didn’t deteriorate, we could invert the health check status if you said okay, healthy checks. A health check is actually harmful and harmful. So you can invert it for whatever you want, disable it, and then you can configure the health checkers to be from specific regions. You can either customise this list or use the recommended list. So we’ll just use the recommended one. But here we go. Now, when you create a health check, you basically get a pricing estimate. So it currently states that it is basic, with no additional options selected. But if you wanted to view the pricing, it takes you to a new page, and in there you’re able to see that health checks cost you fifty cents per month on AWS endpoints and more on non-AWS endpoints.
And then if you use HTTP stringmatching, phasor, or latency measurements, you pay more per month for each optional feature. By the way, new and existing customers are not charged for health checks on up to 50 alias endpoints. So that means that right now we are fine with this health check. It shouldn’t cost us anything. Okay, so we’re good here. I click on “next,” and I will create an alarm or not when the health check fails. And right now we’ll just say no, I don’t want to create an alarm, and I’ll go ahead and create a health check.
So now create a first health check, and what I’m going to do is basically create my other two health checks, and then we’ll use them in the next lecture. So I’ll create my Tokyo health check. And this is great. I will say the IP address is going to be for my Tokyo instance. So this one is okay; paste it. I will leave everything as is. Click on “next.” Click on “Create a Health Check.” And then, finally, I’m going to create a last help check. This assistance check will be for us east ones. So I’ll just call it the Virginia Help Check. And I will put the IP address of my USD Swan instance there. Okay? And we’re good. Click on “Create a Health Check” next. And we’re done.
Now we have three health checks. And let’s just wait a little bit for the status to get updated because right now it is unknown. Okay, our health checks have been created. So this is perfect. Now, if I click on one, for example, the VirginiaHealth Check, we see all the configuration that’s in there. We could keep an eye on things. So here we can see the monitoring over time of the health check status, so we can get some graphs and choose the time range we want. And this comes straight out of Cloud Watch. So this is something we could use in CloudWatch—the alarms, if you have Cloud Watch alarms linked directly to the unhealthiness of these health checktags and you wanted to tag them. And Health Checkers displays all of the IPS for the things that will essentially ping my EC2 instance and query the URL we just had.
So, as you can see, we have about 15 health checkers. And all these things are going to constantly, every 30 seconds, ping for my URL and tell me if the HTTP status code is going to be 200. And if you’ve enabled latency, which we haven’t, you’ll be able to see a latency graph in this tab and get some information about how quickly the end point responds to our request. So that’s really cool. We have three; they’re all healthy, and in the next lecture, we’ll be able to play with them a little bit and see how things work using health checks in Route 53. So, until the next lecture.
10. Routing Policy – Failover
Okay, so let’s talk about a failover routing policy. So we have route 33 in the middle, and we have two easy instances, for example, but it could be whatever you want. Again, one will be called a primary easy to instance, and the other one will be a secondary easy to instance meant to be used only if the primary fails, and the second one is used for disaster recovery.
So this is a failover writing policy. So, hence the name, we need to use a health check, and that’s mandatory. So route 53 will have a health check pointing to the primary associated with the primary record, and it will check the health all the time. And in case that health check fails automatically, route 53 will failover to the secondary instance when there is a DNS query. So, when our web browser sends a DNS request, route 53 will respond with either the primary if the health check passes, or the secondary if the health check fails. If the health check fails, automatically reject three is smart enough to send back the secondary disaster recovery response to the web browser. So let’s have a look at it in this lecture. Okay, so we have three health checks, and now we’re going to go back to our hosted zone and create a record that will failover. So we’ll create a record set, and I’ll call it Failover DefendantChair.com.
And the first URL is going to be my instance in Ireland. So here it is, and I’ll have to recreate it; I apologies for the failure. And I’ll paste in the value, and the routing policy is going to be failover. So in failover, I say either the cord type is primary or secondary. And as the name indicates, you can only have one primary and one secondary. So this one is a primary, and we set the idea to be part of a primary, and we have to associate this with a health check. So I’ll just say TTL of 60 seconds, by the way, and we have to associate it with a health check; otherwise, it won’t work if I say Create. Now, basically, it says a novellas primary resource record set must have an associated health check. So let’s go back and say yes, associate this with a health check, and the health check I want to associate this with is the one I created in the past lecture. So I’ll associate this with the Ireland Health Check, and the IP I just checked is wrong. So I don’t want to make a mistake. Let me just take this one from this list. Here we go. Now the value is here.
Okay, I’ll click on “create,” and that’s basically my primary resource record. So for my failover, my failover is here, and this is my primary. But I’ll create a new record for FailoverStefanitas.com, and this time I will say, “Okay, the value is going to be America.” So I’ll just choose America right here. This anitas.com, and I’ll say 1 minute as well for the TTL. In addition, the routing policy will be failover secondary. And for this one, we actually don’t have to associate it with the health check; it doesn’t matter. So you can go ahead and create a secondary record, and it doesn’t need to be associated with a health check.
Okay, so now we have two record sets for failover at StephanieTree.com. If I scroll back to the right, we can see that one is failover primary and the other is failover secondary. Okay, excellent. So let’s try it out. If I go to this URL because my health check is healthy, I should be redirected to the EU-West one. So this is perfect. I’m in EU West 1, and this is great. But now what I’m going to do is stop my EC-2 instance. So I click on it and stop it, and basically this should make my health check fail because my instance is now stopped and it will not be able to respond to my health checks. So let’s go back to my health check console just to see things happening live. So right now everything is healthy, but let me wait a little bit, and we should see the island health check become unhealthy.
Okay, so my health check is now unhealthy. And as we can see in the Monitoring tab, we can see that, for example, the health checkers that report the endpoint healthy percentage have decreased, then reached 40%, and will go all the way to zero at some point. And so that made my health check switch from one to zero. So because my health check is unhealthy, now if I go back to my failover endpoint and refresh this page, what I expect is to be taken to the US instance. So let’s try it out. Refresh this. And now it says welcome from the East Coast of the United States. So it’s basically a failed over, as the record name indicates to the correct instance. So it’s perfect. Now we’ve seen how through health checks we’re able to basically have root at three, interact with those, and redirect to an instance that we know is working. That is insanely cool. Alright, just for this lecture, I’m just going to start my instance, and we’re all good. I will see you at the next lecture.
11. Routing Policy – Geolocation
Okay, let’s talk about the geolocation routing policy. So it is different from Lanc Base. This one is routing based on the user’s location. And so here we’re saying, OK, traffic that originates from the UK should go to this specific IP if that’s an A record.
And on top of it, we should create a geo-default policy in case, for example, we get a user from Germany but 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’s location and reduce 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, okay, all the traffic that comes from the UK should go to 011-22-3344, whereas all the traffic that comes from France should go to two, two, three, three, four, four, five, five. And then, by the way, there’s a default, and the default says if you don’t have traffic originating from the UK or France, then the default response is going to be 334-4556, six. 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. 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 your location is where all the traffic is coming from. For example, you can either say continents or countries or default. So I’ll just name a country right now, and all the traffic that comes from France should go there. So I’ll just set an ID. So I say Geofence should go to this IP right here.
So if my browser is in France, which it is right now, then I should get this answer. So I’ll create it. A new record set can also be created. So I’ll still name this geography, and now I will say maybe one for America. So if it comes from the United States or the whole American region, I will say, “Okay, you should go to this IP.” So let’s do geolocation. And the location is going to be on the continent of North America. Perfect. And I’ll just call it North America Geo Excellence and hit the Create button. Then I might want to make a record set geo. And this one is going to be, if you don’t have any matches, then send me to Tokyo. And so we’ll say okay, Tokyo, IP, and geolocation. This time, we’ll go with default. So we’ll say “default,” redirect to Tokyo, or whatever name you want to set, really. Okay.
So now, after creating this record set, what we should see is that we have three records associated with this geostiff on the chair, 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 and North America, then I should be going to this IP. Any other traffic should go to this one. So let’s try it out. I’ll go to Geo for 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 restarted my simple example. 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. As a result, I’ll keep this one on file as well. But when I stop and I start an app, for instance, obviously the public IP changes. And so, by the way, that means that all my records beforehand must be updated if I want 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. Excellent. I’m in Mexico, and when I try this URL, I get the response “us.” So excellent. because I come from North America. It redirected me directly to us. East Jane. But if I go to Brazil, 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 got redirected to AP Northeast 1A. So let’s try it out. Now I’m off to France, where we should see the one instance from Ireland. So let’s try it out. Okay. We’re in France. I refreshed my page, and here we go. I get my answer. West one century in the EU That’s really cool. We’ve had a good explanation of how geolocation works. So we base this on the origination of the traffic—where the traffic comes from—and then redirect to whatever we want. Okay, that sounds good. I will see you at the next lecture.
12. Routing Policy – Multi Value
Finally, the final routing policy will be known as Multi value. And this is when you want to route traffic to multiple resources and also associate Route 53 health checks with the records. So it’s some sort of improvement over the simple routing policy. It will return up to eight healthy records for each multi-value query. So, even if you have 50 records in the backend, you can get up to eight values back. And although it looks like a good replacement for ELB, it is not.
It’s not a substitute; it’s different. But it really helps to do some kind of load balancing on the client side as well. So what this will look like is that, for example, a record will have three different values, and all these values will be associated with a health check. And the idea is that if one of these instances stops serving traffic, the route D three will not send back the value of that to the clients, but the other two will still be happening. So let’s have a quick hands-on 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 the IP address of my Ireland instance, which has changed. I’ll just keep it here. Okay. And the routing policy is going to be a multivalue answer, and I will associate it with a health check. Yes, and I’ll associate it with the Ireland help check.
Click on “Create.” So this is “Set ideas empty” so you can 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 “Multi-US associate with health check.” Yes, and that one is going to be Virginia. Click on “Create.” And then, finally, I will have the Tokyo MultiValue answer in there. So I’ll say “Create record set, multi.” And the value will be as follows. The routing policy is going to be multi-valued. This is multilingual 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. It’s so good to know. I click on “Create.” And if you look at our multi, our multi here has three records. OK, so I’ll just say that I actually 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 multi.Stephanheteacher.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 are that the two IPS there are healthy. So as you can see, I 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, I should get three IPS back.
So let’s just wait a little bit. OK, so my health check is now healthy. As we can see, the health check just flipped to “healthy.” And so if I go back to Dig and run a query now, hopefully I should see three answers. And here we go. We have three answers directed at us because the third one, this one, just got healthy. And so Root 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 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, which it can return as part of the answer, it can try the others and see which one would work, which is quite cool and 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, that you now have a better understanding of how multi-record systems work, and that I will see you in the next one.
13. 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 organisation that manages the reservation of Internet domain names. And so there are some famous names in there that we all know. There are, for example, GoDaddy or Google, which offer 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 at a registrar and on AWS. But one thing you should know is that a domain registrar is different from a DNS. Although both bear the Route 53 name, we get these two features that are very different. One is to offer a DNS, and the other is to offer domain registration. So there is something little known: it 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, etc., etc. But how would you do it? Well, number one, you create a hosted zone in Route 53. And number two, you update the name servers. So NS records on the third-party website use the root 53 name servers. And then again, I want to remind you that a domain registrar is not DNS, but each domain registrar usually comes with some sort of DNS feature. 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 Accumulates.com, which is my own company. And so, as we can see here, are the name servers. I have 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 own DNS to be the one that comes with this interface. However, if I use custom name servers, I can insert the AWS name servers here. 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 and click on Hosted Zones, then I would need to create a new hosted zone for my domain name. So it would be dataaccumulus.com, etc. 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, as you can see, there are nameservers and these four name servers on the right side. All these four URLs are what I would have to put on my Google Domain Name Server. So I would put this one, and I would put the second one. You get the idea. I would combine all four of them and then click Save, and my domain DataKimos.com will now use this specific private hosted zone, public hosted zone, and route 23. So that’s 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 that answers your question. The idea is to create your domain elsewhere but have the name servers of that domain point directly into your hosted zone. So that’s it. I hope you like it, and I will see you in the next lecture.
14. 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, 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 recordsets” and then click on “Confirm.” And you basically do this for all the records that you want to delete. Then, as you may recall, we made a few things. So we’ve created an easy example in three different regions. So I’ll terminate all my easy to instance. So there was Ireland, there was North Virginia, and there was also Tokyo. So let’s go right here, to North Virginia and Iraq, and terminate this one. Yes, it’s happening. Then there was Tokyo, Iraq, and this one. Excellence. And then if I go back to Ireland and get load balancers, I also delete my load balancer from there. Excellence. And then you simply clean up everything we’ve made. 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 lecture? Okay, I’ll see you in the next lecture.
