Amazon AWS Certified Developer Associate – Route53 & DNS Part 4

7. Failover Routing Policy Lab

So before we create our record set, we actually need to create a health check and we’re actually going to create two. So what I want you to do is just go back over to the EC Two section and what you want to do is just go into your elastic load balancer for your primary website. So for me, this is going to be London, and I’m going to copy the DNS name of my elastic load balancer in here.

And then I’m going to go over here, go back over to Route 53, and then I’m going to go in to health checks and I’m going to click in here and we’re going to create a health check. Now, health checks can be based on IP address or domain names. We’re going to use domain names for this. So we’re going to call this my London health check. And basically what this is going to do is it’s going to check an endpoint. And that end point is going to be our domain name and it is going to simply be the DNS address of our elastic load balancer.

So what this is doing is if our elastic load balancer or both instances behind it go down, this health check is going to fail. So I’m going to click on Advanced configuration in here. We can do the request interval. So is it going to check every 30 seconds or is it going to be fast and do it every 10 seconds? I’m going to say fast. I’m going to make sure it fails after one. So in theory, this health check will fail within 10 seconds of my site going down. Going to leave everything else as default.

Go ahead and hit next and you can create alarms. We won’t create an alarm on this one, but we will create an alarm on another one. So I’m just going to go ahead and hit create health check. So that is now creating my London health check. And what I want to do now is create a health check on my entire website. So we’re going to call this My production site. I’m going to go ahead and change it to Domain names and then that’s just going to be Hello Cloudgurus. com. And you can put in here a path so you could do index HTML if you wanted. Again, we’re going to do this fast. So it’s going to be ten.

We’re going to do a failure threshold of one. So it will be within 10 seconds and go ahead and hit next. And in this one I will create an alarm. And you can see I’ve played with this before. I’m going to create a new SNS topic and it’s going to be called my website is down. So I’m only going to get this email when my entire site goes down. So you can enter in an email address in here. And there we go. I created my health checks. Now the health checks can take a little bit of time to come online. Don’t forget, right now we are checking the elastic load balancers DNS name.

So that should actually come online fairly quickly. But right now, we haven’t configured any zone Apex records in route 53. So it’s not my production site is always going to fail. And if we just click refresh, yeah, we’ve got one that’s healthy, one that’s unhealthy. So let’s go back into our hosted zones and we’re going to go to Hello Cloud Gurus. And in here I’m going to create my first record set. So I’m going to leave it as my naked domain name. I’m going to make it an alias, so it’s going to resolve to an AWS resource. And in here, I’m going to click on my primary website. So we’re going to do this on my elastic load balancer. So it’s going to basically route any traffic from Hellocloud GURUS. COM to my elastic load balancer in London. I’m going to change the routing policy.

It’s going to be failover. Now, in here, we have to specify whether this is our primary or our secondary site. So primary is going to be your production site. Secondary is going to be your Dr site. So I’m going to make this my primary site. In here, we have to evaluate the target health and we have to associate it with the health check. Now there’s two health checks that we’ve got. My production site is your entire site and it detects whether or not it’s gone down.

So if I click in here, I’m actually going to get a little error message when I go in to create, and it says the record set could not be saved because the domain name to which this resource record set resolves is the same as the domain name of the endpoint that the health check is checking. So your health check isn’t going to work. That’s why you would use your elastic load balancers DNS name. So you go in and click in here and then you’ll get rid of that error message.

So go ahead and hit create. And there we go. So we’ve got a Hellocloud, GURUS. COM. It’s an a record. It’s using an alias. It’s resolving to our London elastic load balancer. Its target health is being checked and that’s the health check ID. So what we want to do now is create a secondary record set. Again, it’s going to be our naked domain name or our zone Apex record. I’m going to click in here and we’re going to fail it over to Sydney and then we’re going to use a failover routing. And this is our secondary site and we’re going to leave it all as no. So we go ahead and hit create.

So now we’ve got two DNS records. We’ve set our primary, which is associated to our health check. And you can see it here. We’ve got our secondary in here. So what I’m going to do now is I’m going to open up a new tab and I’m going to go to Hellocloud GURUS. COM. Okay, so I’ve gone to Hellocloud GURUS. COM. And as you would expect, it is resolving to London because it is my primary site. Let’s go back over to our management console. And now let’s simulate a failure. So we’ll go over to EC Two, and what I’m going to do is I’m going to stop both EC Two instances, both the primary and the secondary. You can go to instance State, and I’m going to hit stop. I’m going to go ahead and hit yes. Now this will take maybe up to 30 seconds to stop, so I’m just going to pause the video.

Okay, so they’re both stopped. So let’s go over to Services, go down to Networking, go to Route 53, and let’s have a look at our health checks. And we should expect one health check to have failed, which will be our Elastic load balancer health check. But our domain should still be up because it should be failing over to our Sydney region. So if we click on here there we go. So we’ve got one’s healthy one is unhealthy. So our London health check has gone down, but our website is still up, so we wouldn’t have gotten an email saying our entire website has gone down. And if I just go to Hellocloud GURUS. COM, you’ll be able to see that we are now on the Sydney web server.

So why don’t we take Sydney offline, let’s go back over here, go down to Services and go over to our EC Two. And then we want to change our regions over to Sydney. And go ahead and click in here. It’s just a little bit of latency. There we go. Click on our one running instance. So now I’m going to take this instance offline. So we are on our Dr site. Obviously, it’s resolving to our Dr site. So now we’re going to stop this instance.

And then what I’m going to do, it should be pretty quick. If we go back to Route 53 and then we go into our health checks, it might not be immediate, but if we just click in here, we should know within about 10 seconds of that instance going down, our health check is going to fail. So let’s go ahead and hit refresh. And there we go. It’s unhealthy. So now let’s go back over to EC Two and we’re going to go back to the London region and we’re going to boot everything back on, in fact. And then our website should come back up online a little bit of latency. Just going to go back over to London, should be much quicker this way. And then I’m just going to go into my running instances and I’m going to click in here. I’m going to go actions instance state start and yes, and then our health check, give it a couple of minutes.

But your health check should start coming back healthy for both of them, because you’re able to resolve both your naked domain name as well as the elastic load balances that these EC two instances sit behind. Okay, so London is back online. Let’s go over to services, go down to Route 53, and we’re going to click on our health checks. And in here, we should see both of them as healthy now. Yes. There we go. Both healthy. So that is it for this lecture, guys. In the next lecture, we’re going to look at geolocation and then we’re going to summarize what we’ve learned in the Route 53 section of the course. So if you’ve got the time, join me in the next lecture. Thank you.

8. Geolocation Routing Policy

Okay, so I’m in the AWS console. I’m going to go over to services and I’m going to go down to Route 53, and in Route 53 I’m just going to go over to my hosted zones and click in here I’m going to delete the ones from the last lecture. So just go ahead and delete the record sets and hit confirm. Now we’re going to create a record set. In here we’re going to leave it as the naked domain name or zone Apex record. And in here I’m going to use in alias. And the alias I’m going to use will be my European one. And in here I’m going to go for Geolocation. Now in Geolocation, so this is where your end users are located. So we can do it by continent, so we can say Europe. All our European customers go to our London one. You can do it by specific countries and for the US. You can even do it by specific states.

So what I’m going to do is I’m just going to say all my European customers, I’m going to call it European DNS Queries. And we’re going to leave the target Health and the Associate with Health check as no. And then I’m just going to go ahead and hit Create. Now we’re going to go and create a new record set. We’re going to make it an alias record, use our zone Apex record. And in here we’ll do Sydney. We’re going to change our Geo location.

And in here it says location. So let’s choose default, which will basically be everywhere else. And so I’m just going to say everywhere else and I’m just going to leave everything else as no. I’m going to go ahead and hit Create. Okay, so we’ve got our two records right now. So this is Geolocation, this is the Asterisk, so it’s basically everywhere else. So all my European customers will go to London. The rest of my customers will go over to Sydney. So let’s test this. I’m just going to go back up here. I’ve already got Hello Cloud Gurus open, just going to hit refresh and you can see it’s hitting our London web servers. I’m just going to fire up a VPN client now. Okay, so I’ve got my VPN client fired up and I can see here I’ve got a whole list of different countries. I’m going to choose one that is fast but is not within Europe.

So let’s go ahead and go over to USA. New York going to connect into that. So it’s relatively quickly. Relatively quick, I mean, okay, so that’s now connected. I’m just going to alt tab back over to Chrome. Just go back over here and refresh the page. So I’m just going to refresh the page. And you can see here it says hellocloudgurus. com page isn’t working. So why is that? Well, it’s because we stopped our Sydney instance in the last lecture and we didn’t start it back up again. So if I go ahead and hit start, go ahead and hit yes. This will take a couple of minutes to come back online, so I’m just going to pause the video. Okay, so my EC two instance is now online, and I’m just going to go here and hit refresh, and hopefully that will say yes.

There we go. Hello, Cloud Gurus. This is Sydney web server one. If I actually disconnect my VPN, go ahead and hit disconnect. It’ll take a couple of seconds to disconnect and then if I go back here and refresh. So there we go. Disconnected. If I go back here and now hit refresh back to London. So it’s all based off the geolocation. It’s all based off my local IP address from where I’m connecting into. So that’s it for this lecture, guys. If you have any questions, please let me know. If not, feel free to move on to the next lecture where we’re going to summarize what we learned.

9. DNS Summary

So I’m in the AWS console right now. Feel free to go through and start terminating all your instances because you don’t want to go over your free tier allocation. Also bear in mind that elastic load balances cost you money. So also go ahead and terminate your elastic load balances. It catches a lot of students out. Make sure you have deleted all of them and they can be difficult, you know, they can be things difficult to see and it can be easy to forget about them. So a lot of people do go over free tier just by keeping their ELBs on. So make sure you do it in your two regions. Go ahead and delete those instances and delete those elastic load balances. I just want to point something out that an elastic load balancer never has an IP four address. It’s always just got a DNS name that would of course resolve two IP Four addresses. But Amazon actually handle that for you.

So you can never have a public IP address for an elastic load balancer. And that’s a really, really important exam topic. It’s definitely worth a few marks. So if you got some kind of troubleshooting question that’s coming up and it’s saying resolve the DNS record to the IP four or IP Six address of the elastic load balancer, you know that that is an incorrect answer.

So as I said, just go through and delete everything so that you don’t incur a cost. And I’ve just gone in and terminated that. So now that you’ve terminated everything, like I was just saying, remember that elastic load balancers don’t have predefined IP four addresses. You resolve to them using a DNS name and Amazon handle that DNS resolution for you. You should understand the difference between an alias record and a CNAME. Remember, an alias record acts sort of like a CNAME, except you can resolve individual AWS resources. So you can resolve elastic load balances, for example.

You can resolve cloud front distributions, for example. And if you’re given a choice in any exam question to choose between an alias record and a CNAME, always choose an alias record over a CNAME because in most scenarios you’re always going to be resolving to an AWS resource. And then of course, remember the different routing policies and their use cases. So we have five simple is basically the simplest one that there is. It’s basically stupid round robin and you would typically use that with a single web server. Weighted is where you want to do things like A and B testing.

So maybe you’ve got a new website that you’re bringing into production, but you want to make sure that it’s going to increase in sales. So you send 10% to your new website and you send 90% to your old website. Latency is based on your end users, so how will they get the quickest performance? We use that example of someone in South Africa trying to connect in and then we have failover. Failover just means where you’ve got a production and a Dr site, and your Dr site only comes online if your production site has a fails health check. And we went in and created those health checks and then Geolocation is simply where your end users are. So we did a test and we set up Geolocation so that all our European customers went to London and the rest of the world went over to Sydney.

So that is it. This entire section of the course is uniform across the three associate courses. That’s just because this topic comes up again and again and again in all three associate exams. And it’s also actually really important for you to know if you’re going to work with AW, how to use Route 53, moving forward with your careers. Okay, so that’s it guys. Go have a break and when you’re ready, go on to the next section of the course. Thank you.

• Category: Uncategorized