Amazon AWS Certified Advanced Networking Specialty – Advanced Route53 Configurations Part 6

16. Route53 – Understanding Failover Routing Policy

Everyone. And welcome back to the Knowledge Full video series. Now, in the earlier lecture, we were discussing on how we can create a basic health check in Route 53, which would send us an email alert when the domain is down. Now, this is a very simple way of doing it. There are a lot of additional things that you can do after the domain goes down. So let’s look into the PowerPoint presentation. So this is something that we had discussed earlier as well. So you have a Route 53 over here and you have a server. So you have a health check which is configured from Route 53 to your server. Now, in case your server goes down, route 53 will send you an email saying the server is down.

So this is something that we have looked for. Now, one additional thing that we can do is once the Route 53 sees that this server is down, then what it can do is instead of sending the traffic to this server, which is not working, it can automatically do a failover to another server which might have a similar website or it might have a maintenance page saying that we will be back soon. And this is something called as the failure routing. Now, this is something that you will find in most of the websites, because if the website itself is down, then you will get a temporary maintenance page saying that the website is coming soon.

So this is something that we’ll look into how exactly it will work based on Route 53 failure. So let’s do one thing. I have my Route 53 over here, and within the health check you will see I have the status as healthy and alarm is also one of one in. Okay, now what I have done is I have created a domain called Failure menu. com. And when I press Enter, you will see that I have an NGINX page up and running. Perfect. So what I’ll do, I’ll stop my Nguni systemctl. Stop NGINX. Perfect. So now we have stopped our NGINX web server. So what we are simulating right now is that we are simulating a web server which is not working. So after Route 53 health check detects that this web server is not working, it will automatically do a failover to another website, which I have configured in the failover routing policy.

So let’s quickly refresh the page and let’s wait for a few seconds because our interval is of 30 seconds. So we’ll wait for the status to become unhealthy. Perfect. So now the status has become unhealthy after a few seconds. So now what has happened is this web server has stopped working. So now what Route 53 will do is any subsequent requests that will be received for this specific domain failover mumming. com. It will not send it to the web server. It will send it to the maintenance space that we have configured. So let me just refresh this page again and see on what exactly has happened. Now you see, it has gone to the maintenance page saying the site is in maintenance. So this is the page that we can configure accordingly. I am too worried to write a good HTML code. So this is a simple text file that I have written for a text purposes. Now, you might be wondering on how we did that. Let me just quickly show you the overview.

So, within the route 53 there are two policies that I have configured. You see there are two records for failover subdomain. Now, this is the primary record and if the page stops working, then it will fall to the secondary record. So if you will see over here the failover record type is secondary. And in the first the failover record type is primary. So if the primary goes down, then route 53 will switch to the secondary record set and it will go to the alias target which is configured over here. So this is how exactly the failure routing policy really works. So this is it.

About this lecture, I hope this has been informative for you and it gave you an overview related to how a failure configuration might really look like. So in our case, this is a maintenance page, but depending upon your configuration, this can be another web server in some other region also. So depending upon the policy and the SLAs that your website might have, the way in which you do a routing might really differ. So this is it about this lecture. I hope this has been formative for you and I look forward to seeing you in the next lecture.

17. Route53 – Implementing Failover Routing Policies

Hey everyone and welcome back to the Knowledge Pool video series. Now in the earlier lecture we looked into a demo about how a failure based routing would really look like. So what we’ll be doing in today lectures will be doing the actual practical and see on how exactly it would really work. So I am in my Route 53 console and let’s do one thing. Let’s create a record set. I’ll say the name would be Demo Failover. So this is the sub domain and this is my main domain. Now within the value I’ll put the value of my server current server 162 59, 23. So this is where my NGINX is running perfectly. Now within the routing policy, you will see that there are various type of routing policy that are part of we’ll be using the failover routing policy. Now this is a primary record set.

That means that whenever someone visits this specific URL, then the primary answer will be the value which is present over here. So TTL just give a TTL of 30 seconds. So this is an optimal one when you are using a failover. Now you have to associate it with a health check because route 53 needs to know when to use primary or when to use secondary. So associate with Hell check and we’ll click on the health check that we have created and I’ll click on Create. Perfect. So now we have Demo Failover subdomain which is created. Now what we’ll do is we’ll create a S three endpoint where the failure will actually occur. So it really depends.

You can actually create one more server or you can create an S three endpoint depending upon your choice. So for our demonstration, we’ll be using the S three endpoint. So I’ll click on Create Bucket. I’ll say Demo Fail over the same name which we have given over here. Let me just okay I’ll click on Next. Select Next. Now since this is going to be a website, I’ll give a grant public read access to this bucket for everyone. Go to Next and click on Create Bucket. Perfect. So now the bucket is created, I’ll just upload my index HTML file over here. I’ll say index HTML file. I’ll just give it a read access so that everyone can view and then click on Upload.

So once this file has been uploaded, go to Properties static website hosting and use this bucket to host website. So I’ll put index dot HTML over here and I’ll click on Save. I hope you already know on how to do all these things by now. Now once this is created, just verify if everything is working fine. Perfect. So it seems to be working fine. So now let’s go back to the route 53 and this time we’ll create an alias record. So in order to do that, let me just copy the alias target. I’ll click on create a record set name. This record set the same which you had named earlier, which is Demo Failover. The alias will be yes. And this is where we’ll be putting the alias target name. So one thing to remember over here is that alias target name will be the S Three Hyphen website. So this is the US one.

So you need to replace this with the region that you had configured your S Three bucket for. So this is important to remember since I have configured it in North Virginia. This is the domain that I’ll be using. So now let’s go back and let’s create a record set as a demo failed over alias record. And I’ll use the S Three endpoint and within the routing policies it would be Failover. Now this failover record type would be secondary. And you can just say Evaluate target health is no because this is S Three and it is already meant to be durable. And I’ll click on Create. Okay, it says I have to remove the dot at the end. Click on create. Perfect. So now you will see what I have is I have two record sets. This is the primary one. You see the failover record type is primary.

And if the health check associated with this record so there is a Kplabs video course health check which we had created earlier. If this health check fails, then route 53 will switch to the secondary. So this is the secondary record and it will go to the alias target associated with the secondary record set. So let’s try this out. Let’s do a demo. Let me just actually copy the domain and let’s see if everything is working fine. Perfect. So this is our NGINX page. Let me quickly open up the mobile external and we’ll stop the NGINX manually. So I say root at the rate. Don’t worry, till the time you try, the web server might be deleted anyways. So I’ll click on no. Perfect. So let’s do one thing. Let’s stop the engineix.

It says System CTS Stop Nginics. Perfect. So now the engineer has stopped working. So now what will happen is the website will stop responding. So you see, the website will stop responding. Now, since this specific record is associated with the health check, which is Kplapse video course, the time when this health check will fail, route 53 will move from primary to secondary. So this is how it actually would work. So what we need to do is let’s open up the health check. And as we have discussed, it might take some amount of time, typically 30 seconds for the health check to fail. So let’s wait for a few seconds and then try it out. Perfect. So now the status is unhealthy.

So now route 53 has detected that it is unhealthy. So now what it will do is any subsequent request which comes to demo failover, it will move to the secondary endpoint. So now if I just click on Refresh, what will happen is route 53 has automatically moved this request to the secondary endpoint. So this is how basically the failover routing really works. So I hope this has been informative for you. Go ahead and try this out because these things are very, very important and it will help not only in your exams, but in real world scenario as well. So this is it, about this lecture. I hope this has been informative for you and I look forward to seeing you in the next lecture.

18. Weighted Routing Policy

Hey, Ryan. And welcome back. In today’s video we will be discussing about the weighted routing policy in route 53. Now, a weighted routing policy basically allows us to specify the proportions in which the traffic should be routed to the underlying server. Now, we’ll understand this in the upcoming point, so let’s discuss that. So let’s assume that if we want to send a small portion of the traffic to a newer website theme, then you can specify the weight of one to 99.

So in this case, what would happen is the resource width, one gets 1% of the traffic and the other gets 99% of the traffic. Now, this is very useful because let’s say that you have created a new theme for the website. Now, you don’t really want all the 100% of the traffic to be sent to your newer website. It might contain bugs. So what you do, you tell that only 1% of your traffic should be sent to the newer website, while the 99% would still be sent to the older stable website. Now, if you get a positive feedback from the 1% of the traffic, then you can start to move it to 5%, 10%, 20% of the traffic and so on.

All right, so the way in which you can tell that all right, one person out of traffic should be sent is based on weight. So you assign a weight to each record set. Now, the formula here is weight of a specific record by the sum of weight of all the records which are part of that specific record set. So let me quickly show you how exactly this might look like. So within my route 53 console, if you see I have two record sets which are available, one is weighted dot Zelbora. com and it has the IP of 54 30. And again you have the same record name which is weighted Zelbora. com which has the set of one to 832.

Now, within this record set, if you look into the routing policy, the routing policy is weighted and the weight here is two. Now for the other one year the weight is one. Now, depending upon the weight that you assign to each and every record set, the amount of traffic that will be sent across the domain will vary. So let me quickly show you if I quickly do a dig, the first record set is 128. The second time the record set is 128.

The third time the record set is 54 or 30. So you see the traffic is being droughted depending upon the weight. Now do make sure that if you create a weighted routing and if you are testing it within the EC two instance, the traffic might not drought primarily because of the DNS cache. So that is one important part to remember. Now let me quickly show you on how you can create a weighted routing set. So let’s say I’ll call it as demo weight. Now you can give it a random value, let’s say 54, 2054, 20 and the routing policy, you can select it as weighted. Now, here you can specify the weight. Let me specify the weight of two and the ID. You can just give random ID, I’ll say twice.

Now, you can also specify the TTL. Let’s put it as zero and I’ll create the record set in a similar way. I’ll create one more record set. Make sure you give the same name which is demo weight. Let’s give it a name of 127 or zero one. Again, this would be of type weighted. The weight would be one and set ID. You can give the name that you intend to I’ll give it the detail of 0 second and I’ll do a create. All right. Now, there are two record sets. Now, each record set has a different weight as we discuss in your testing. Specifically, if you’re doing it within your EC two instance, you might not see the records to be routed according to the weights, primarily because of the DNS cache.

So, let me do one thing, I’ll change the record to demo weight and it gave the response of 54. Now, if you’re wondering what this is, so this is basically the name server, which is NSY 187. So if you look over here, you have NS Hyphen 187. So this is the name server that we are querying too. So now, next time you did a query, it sent to 127001. So you see the traffic has been routed to multiple record sets. Now, before we conclude this video, there is one important point that you should remember. And the point is that if you want to stop sending traffic to the resource, you can change the weight of that specific record set to zero. So in this way the traffic would be stopped sending to the specific resource.

• Category: Uncategorized