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

13. Advanced Route53 Configurations

Hey everyone and welcome back to the Knowledge Pool video series. And in today’s lecture, we’ll be looking into the advanced Route 53 features which are being provided. So let’s look into what do I mean by this? Now, when you look into the managed DNS providers, generally a managed DNS providers gives a basic set of functions functionality like domains, registration, GUI, which allows us to put various type of DNS records like A records, C names, et cetera. Then it provides us the functionality of mapping and resolving domain name to various type of DNS records and also who is management. So this is the screenshot of the name. This is the DNS provider which I use for my domain. So if I’ll just show you so this is a very interesting domain name that I have brought.

Now, if you look over here, this name. com has a basic set of functionalities like within the DNS record, you can add various type of records like a Record MX, record, C Name. So this is the basic functionality which has been provided by a managed DNS provider. Now currently I am using Name, but you can use various other DNS providers like GoDaddy et cetera, and all of them will provide these basic set of functionality. Now, the question that really comes is that even route 53 is the managed DNS service and if it provides these basic functionality, then there is no use for me in switching my domain from Name. com to Route 53. So there needs to be certain good advantages which route 53 should provide, which will lure me to go towards Route 53.

And this is precisely what we will be speaking today. Now, Route 53 does a lot more. Not only it will do the basic functionalities which we just discussed, there are a lot of advanced things which it really supports. So the first thing that makes Route 53 really unique is the support of public and private hosted zone. So this is something that we already know about. So whenever you create a hosted zone, it can either be public or private which is connected to the VPC. So this is one thing that we already know. Apart from this, it does a lot of things like latency based routing, geod, it supports health checks and monitoring, it supports DNS failure, it supports weighted routing. Now, many of the organizations specifically startups, they use route 53 as a load balancer. So, because of the great features which route 53 provides, in fact half of the route 53 documentation of AWS is about the additional features of Route 53. So let me just show you about this.

So, when you go into the Route 53 console, a hosted zone is something that we already know about. So whenever you create a hosted zone, it can be a public or a private. And if you’re using a private hosted zone, you can attach it to a specific VPC. Now, apart from this, let me show you. I have my domain Mu and Mu. com in my Route 53. And if you go to the Create record set so this is the basic record set which a DNS provider provides. So if you’ll see over here within name, you see when I try to add a record, there are various DNS record types which are available. Similar record types are available in Route 53 with some additional parameters like alias record that we’ll be discussing anyway. So apart from this, if you go a bit down, there is a routing policy and within routing policies there are various type of policies which are present, namely weighted, latency, failure, geolocation. So this routing policies makes Route 53 a really strong competitor. Apart from this, there is also health checks.

So health checks is something which basically monitors your website to which the Route 53 is sending the traffic to. So this is something that we will be discussing. Along with that you have a great functionality of traffic flow where you can actually create traffic policies via GUI. So this is a visual editor through which you can configure some complex routing policies. So these are some of the additional features of Route 53 and because of this, organizations are now moving their domain from Name. com or from other providers to Route 53. And this is something that I have already done. So if you look into the name servers, currently I am using the Name servers of AWS Route 53 service. So even though my domain is hosted here, the entire name servers and the DNS management is done through the Route 53. So this is the high level overview about some of the advanced features which are being supported by Route 53. In the upcoming lectures we’ll be discussing into some of these and really look into how enterprise can use these advanced features for the organization.

14. Route53 – Understanding Health Checks

Hey everyone, and welcome back to the Knowledge Pool video series and continuing a lecture journey about advanced Route 53 features. Today we’ll be speaking about a very important feature called as health checks. So let’s go ahead and talk more about this. So if you remember in the earlier lectures, we were discussing on some of the features which Route 53 provides and one among them is the health checks and the monitoring part. So this is something that we will be looking in today’s lecture. So let’s begin. Now, Route 53 has a great feature called as health checks. And health checks is responsible for monitoring health of a specific endpoint. So let’s look into what do I mean by this? So let’s assume this is the route 53 DNS and I have a website. Now this route 53 DNS is sending or it is resolving the domain name to the IP address of the specific website. So generally what we want is that if the website is up or not, that monitoring part should be there and that monitoring part is done with Route 53. So let’s assume that we have enabled health check. So what route 53 will do, it will constantly or at a specific time interval, it will send a request to my website and if my website is responding back with a 200 or a similar status code, then it will consider that the website is up and running. If my website is not up and running, then Route 53 can be integrated with Cloud Watch or SNS to send me an alarm saying the website is down. So let’s look into how that would work. So this is route 53, this is my website. My website stops working. Route 53 can send me an alarm or it can do a lot of different things. So one of the example I can show you is it can automatically route all my traffic from this domain to my backup domain, which will have a we’ll be back soon page.

So this is something which route 53 can do automatically because if your website is down, you will not get this page directly. You might get some kind of a 500 internal server error or something similar. So if you have a static page in your S three, route 53 can do a failover routing. That means if this website goes down, it can route it to a different server by itself. So this is something very interesting which route 53 does anyway. So we’ll be looking into this in the upcoming lectures. But for the timing, let’s look into how we can configure basic health checks. So if you look into my, this is my Route 53 console and here I have my health checks. And if you’ll see I have one health check which is already created. If I show you, this health check is for Mu and mu. com. Now the protocol is http and let’s look into what exactly it does. So this is basically my server where my website is hosted.

I’ll just open this up in my browser and you’ll see it will have a default NGINX page. Now let me do an echo on VAR log, NGINX access log. And let’s do a tail on this specific. And what you see over here is that you are getting a lot of get requests. You see a lot of get requests from Amazon Route 53 health check service and the domain name associated. If you see you’re getting the health check requests from various IP addresses, which are quite different. So this ends with 13. Then you have 237, you have 173. Then you see you have 177 IP address. So you’re getting requests from a lot of IP addresses. And basically this is the response code. So whenever these IP gets the response code of 200, which means everything is okay, then the Route 53 will consider the website to be up. So let’s do one thing. Currently, if you will see it is healthy by default, the time interval is 30 seconds.

So let me manually shut down my NGINX server. So now, whatever request that comes to my blog, let me just show you. See, if I just refresh, you see the site can’t be reached because I have stopped my Ngenx. Now, essentially, what would happen here is that the health check that I have created, it should fail. So currently the status is healthy. Let’s wait for some time. Currently, the time interval is of 30 seconds. We’ll wait for the 30 seconds to complete and then we’ll see whether the status is updated or not. See, you can always increase the time limit. So currently, if you see the request interval is every 30 seconds, you can increase at any time, or you can decrease it, but it comes with the price. So this is how it really is all about. Perfect. So now you see, now Route 53 is basically showing a status of unhealthy. That means that Route 53 sent certain requests.

The Route 53 Health Checker Service. If you see, this is the Route 53 health check service. It sends certain requests to my domain and it did not get a response back. So you see the site, this is like no response has been received. And this is the reason why Route 53 is considering that the website is down. Now, along with this, you can definitely integrate the Route 53 health check with an alarm. So this is integrated with Cloud Watch and SNS service. So let me just try and open up my email and I can show you that I have received an alert from the Route 53 health checker service. So you will see this is the alert saying that my website is down. So this is the basics about Route 53 health checks and monitoring. In the upcoming lectures, we will look into how we can actually configure this specific hijacks that we have been having a demo about.

15. Route53 – Implementing Health Checks with NGINX

Hey everyone and welcome back. Now, in the earlier lecture, we were discussing about Route 53 Hell checks. And we had done a simple demo on how exactly a health check would really work. So what we’ll be doing today is we’ll be configuring our first health check. So before we do that, let me actually delete the health check that I had configured earlier. Now now before we do that, we have to make sure that our website is up and running. So what I’ll do is I’ll start my NGINX. So I’ll say System CTL, start NGINX and I’ll just quickly verify our domain is up and running. Perfect. So once that domain is up and running, you can go to Route 53, go to Hell Checks and click on Create a Health Check. Now you need to give a name for the Hell checks. So I’ll say KP Labs video course. I’ll just name this and what to monitor would be Endpoint for now.

Now, within the second section, which is Monitor and Endpoint, there are two options which you can give. One is the IP address and one is the domain name. So for my case, I’ll use the domain name directly and I’ll copy the domain name which I have within the domain name section. Let’s remove this. So protocol will be http Since I don’t really have a https for Mumu. com, I’ll use the http domain. This is the port and within the advanced configuration you have request interval. So request interval is basically after how many seconds should Route 53 check whether my domain is up and running. So the standard is 30 seconds. But you also have Fast, which does every 10 seconds. But remember, everything comes at a specific price. So since we are doing a demo, we’ll be using a standard of 30 seconds. Failure threshold will leave it as one for the time being. And next thing that is very important is the health checker regions.

So health checker region is basically the regions from which the request will be sent to my server. So by default, if you must have seen, I was actually getting requests from various IP addresses. So somewhere from 54, somewhere from 177. So Route 53 held checker service were actually sending me traffic from various servers. And these servers are actually belongs to a specific region. Now, you can customize it according to your needs, but for the time being, I’ll use the recommended one I’ll go to next. Now, if the question is what happens once the health check fails? Should you get notified? And the answer is yes, I would like to get notified if my website is not working. So for this, you need to click on Create Alarm. And here you have to put a SNS topic data.

So I’ll select new SNS topic. I’ll say KP Labs and recipient mail would be instructors at the rate Kplabs in and I’ll click on Create Hell Check. So now what will happen is this is the Hell checks that we have created. Now, the status is unknown right now because it will take certain amount of seconds for this to get updated. Now, since we have created an alarm, let me select we have created an alarm. We have to approve the SNS related functionality.

So if you go to an email, you see I have received the AWS notification. I click on confirm notification and perfect. So now the notification is confirmed. So SNS will be able to send us email perfectly now. So let’s wait for some time, I would say a few seconds for this status to get updated. Till the time being, let’s do a tail on Warloghenginex access log. And now you see, you have actually you’ll actually start to get requests from the Route 53 service to the domain. And you see the status is now healthy. So let’s do one thing. Let’s verify both the scenarios. Now I’ll stop the NGINX. I’ll say systemic. And again, since we have a threshold of 30 seconds over here, we need to wait for 30 seconds for the Route 53 held check service to send request to our domain. So let’s wait. So currently alarm is one of one in OK. Now let’s wait for a few seconds and we’ll see the alarm going down. So let’s quickly verify that munu. com is not working. Perfect. And patience is virtue. So let’s wait for some time. Perfect. So now you will see the status is currently unhealthy and the reason why is because Route 53 sent request to a domain and there was no web server listening, so no one responded back.

And this is the reason why status went to unhealthy. Now, if you go into the monitoring section, just click on the monitoring section, it will actually give you a nice little graph related to the health check status related to our domain. So this is one important part that we need to look into. Now, the second part that we have to look into is the alarm section. So once the website is unhealthy, we should either receive an alarm in email or even in SMS saying that the website is unhealthy. So if you go into the alarms, you see now the alarm went from one of one okay to one of one in alarm. So this is the state. You see, the state is changed from OK to alarm.

So now, since this cloud watch is configured with SNS that we should ideally receive an alarm saying that the website is down. So if I go into my Gmail, you see now Route 53 has sent us an alarm. Basically, SCS along with SNS has sent us an alarm saying that my website is down. So this is one of the ways in which you can create the Route 53 Hell checks. Now, there are a lot of interesting things that you can do once the Hell check part is up and running. So some of these things is something that we’ll be looking in the upcoming lectures. I hope you got the basic overview about the practicality aspect on how you can configure Route 53 hell checks. I would really recommend you to try this out because these are some interesting things and very useful in organizations. 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.

• Category: Uncategorized