Building a Multi-Region Web Application on AWS

hey what's up everybody it's Mike Pfeiffer welcome back to another episode of cloud skills TV and this week we're switching things up just a little bit we're not doing any Azure content we're actually doing some AWS content finally now it's actually something that my company does we do a lot of AWS training on top of azure yes it's very challenging to keep up with both but in this week we're actually covering a project-based type of lesson so this is a pretty long video this content is from our AWS certified solutions architect training and it's a hands-on project that I kind of step you through showing you how to work with multi region high availability and really getting into the route 53 service working with the different routing policies and setting up some stuff in different regions it's actually really cool and so we're giving away this content for cloud skills TV the channel since we just kind of got started and I hope you really enjoy this so what we're gonna do here is we're gonna cut it over and I'm gonna take you through about 50 minutes of content showing you how to work with the ruffed III service so right after this you'll hop over I'll explain the project now if you have an AWS account feel free to follow along or if not just sit back and watch as we work with the route 53 service and setup multi-region high availability hey everybody its Mike Pfeiffer and welcome to project number two we're gonna be taking a look at building a multi region web application and when it comes to building solutions across multiple regions there's a couple common scenarios so number one there is the disaster recovery scenario so maybe your primary applications running in the west coast of the United States and obviously there's potential there for the west coast to get hit by a major earthquake or something like that you want to be able to failover to something like the East Coast that's one scenario where you might want to build a multi region application another scenario is just when you have a global application you've got users all over the world and you want them going to the web application or the application that's closest to them but in either way whatever you decide to do or whatever the use case is the patterns and practices that we cover in this week's project will show you what the services and tools are available to you at AWS to build multi-region applications so for our specific projects let's take a look at the requirements for our web application so number one obviously it needs to be architected for multi region high availability so we're gonna see how we can do that it needs to route users primarily to a specific AWS region so for example we could say that's you know our application is running primarily out of the East Coast the United States everybody should always go there unless there's a problem now another requirement here for the project is gonna be that we want to provide automatic failover in the event of a service disruption so if that East Coast based version of our application fails then users automatically start getting routed to another region like the western United States so that's the game plan for the project that we're gonna build so in terms of the architecture for the application we're not gonna go crazy because I don't want you to have to spend a ton of money to set this up so we're gonna keep it simple we're just gonna do a web server on a single ec2 instance we're going to do this in two different regions we're gonna have one server in the east coast one server in the west coast and so what we're looking at here is basically an active/passive type of model there's gonna be other architectures that we take a look at so we can get some understanding around how these things work but this is what we're actually going to build so primarily folks are gonna hit a domain in this example I've got your domain calm but I'll show you how to use a real domain with this solution we'll send people to the East Coast primarily now if you remember back to our previous project in the last week we worked on building an auto scaling group that was fronted by an elastic load balancer and the elastic load balancer was distributing connections across two different availability zones but in the model where we're using multiple regions we can't actually put a load balancer from Amazon Web Services in between the East Coast and the west coast because the load balancer itself is not a global service however route 53 the DNS service is a global service so what we're gonna do is we're gonna use the route 53 service to basically host our domain we don't have to register our domains there necessarily although we can we can use domains registered elsewhere with this service and I'll show you how to do that but the idea here is that users will go to the domain name route 53 we'll use some health checks to determine where to send the user and we'll be able to basically model the logic that we want in route 53 to do the behavior that we want so basically the idea is if we route 53 sees that the primary region is not working it's unhealthy or there's some kind of issue then what its gonna do is it's gonna start resolving the DNS resolution for our domain to the other region in this case the failover region is in the West Coast and it's a seamless process for the end users basically you know there's an issue in the East Coast Roth fifty-three figures that out starts routing people over to the fail of a region so that's what we're gonna set up here in this week's project although we do have a lot of theory in a lot of different ways to set things up so the first couple videos I'm gonna take you through some of the basics this will help you in the exam it'll help you in the real world so we got to understand where the different scenarios and then once we understand the scenarios we'll dive in and build out this multi region web application architecture so the first multi-region architecture that you should be aware of is in regards to disaster recovery it's called the pilot light architecture it's not going to be something we set up but it's very likely that you'll get a question about this architecture on the exam so let's say that we build something out like we did in the last week's project we've got basically an auto scaling group with some web servers we've got an RDS database instance sitting behind that application people come to the application through an application load balancer and everything is highly available across a couple of different availability zones in that single region now when it comes to doing disaster recovery a pilot light architecture is basically a minimal cost disaster recovery solution so here's the idea what you're gonna do is you're gonna have people go to your domain and hit the load balancer in your primary region all that makes sense but you're gonna set everything up in an alternate region that's far away from your primary region so natural disasters can impact the disaster recovery site and essentially you're gonna put the minimal amount of infrastructure required in that pilot light region some times you'll put the web servers your application servers over there get them pre provision to just power them off or other times you may just have some kind of automated process that when you decide to failover to the pilot light region you could go ahead and provision the infrastructure bring it online and then you're off and running but really the idea with pilot light region is that this is for a manual failover this is not something where we're expecting to failover gracefully across you know two different regions this is very much a cheap kind of low maintenance disaster recovery solution so minimal infrastructure and minimal cost involved now notice that we've got a synchronous replication for the RDS master database going to the pilot light region so what you can do is you can actually set that up we didn't look at read replicas last week when we set our project up but I will show you that here in a minute basically the idea though is that you could create read replicas in a single multi a-z deployments or you could do it across regions and so if you wanted to have a pilot light architecture for a web application that was using RDS you could basically replicate your data maybe have your servers powered off over there in that pilot light region and then any events of a failure of the primary region you can manually bring online that pilot light region so the idea is hey there's an issue in primary region we switched the DNS over for our domain we're pointing it now to a load balancer that maybe was pre provisioned in the pilot light region if we had servers that were there and powered off we powered those on and in the read replica gets promoted to a master database and so the big thing to remember there is that the master database promotion air of the read replicas would not be something that's automatic so we talked about the fact that RDS multi a-z deployments will failover automatically if there's an issue and one availability zone and you got a failover but when you're doing a read copy like this across regions again it's a manual switch so the pilot light architecture is great for manually bringing online a disaster recovery sites and getting your application back up and running now to give you some clarity around RDS let me jump over to the RTS console and I'll show you how you would manage these read replicas okay so here we are in the RDS console this should be familiar to you by now and we're going to do is take a look at my DB instance there's the my app DB instance what I would do here if I wanted to create a read copy of this database that's on this DB instance in another region is I would just select the DB instance go to instance actions and then I would do a create read replica and that would take me into this screen here and it would give me the opportunity to choose a destination region and so this one's currently running an organ and what I would do is just from the drop-down list to pick something else like Ohio and that's all there is to it would provision a read copy updates to the master database would be asynchronously replicated over to that read copy and later on you would have the ability if you needed to to bring the read replicas online now read replicas are basically a multi-purpose constructs you can use this for disaster recovery you can also use it to basically point your read traffic for really heavy read intensive applications 2004 mure primary database but it's also a great way to basically do some disaster recovery here now let me bring up this documentation here I'll leave this a link to this here in the portal but basically the idea here promoting a read replica to be a standalone DB instance that would be a scenario where you're replicating to an alternate region you have your pilot light architecture you want to bring that pilot light region online as your primary application you could go this through this process of promoting the read replica to a standalone DB instance so that'd be a read write copy at that point your application could use it you could continue running out of that other region the next disaster recovery architecture you want to be aware of is the warm standby architecture and it's actually very similar to the pilot light architecture we were just talking about so the idea what this one is you're basically just running additional infrastructure in that disaster recovery region so it's a warm standby in the sense that maybe you've got some servers already up and running maybe you're running smaller servers and you are in a primary region but you have the ability to scale up or scale out if you need to all the information or all the traffic I should say to your domain goes primarily to the primary region obviously or a synchronously copying database information from the master database to the read replicas and there may be scenarios we don't use a relational database you might want to use a global service like dynamodb if you want to implement the no sequel solution to make this a lot easier but the idea with the warm standby architecture is that you've got all your stuff pre provisioned your applications are installed the application is actually running and ready to go and the data is replicated so really all you got to do is flip the switch on the DNS record if you ever need to failover so once again typically with a warm standby disaster recovery architecture you're having no expectations in terms of automatically failing over it's typically a decision the business makes to say alright we've got major issues in the primary region let's change the DNS let's get everybody moved over to the warm standby region now if the server's over there we're running but they're kind of small and now you've got 100% of your application traffic hitting that environment you could scale up you could scale out and handle that production load and of course if you wanted to fail that master database over after you promoted it you could do the reverse create a read copy in the previous region and promote that to a master and go through that whole process so that's the difference between pilot light architecture and a warm standby now the next use case for multi region architecture would be for global application where you've got users all over the world and it's not really a disaster recovery scenario it's an active-active multi-region architecture so really the big difference here is you've got your domain all those connections are getting distributed to two different regions or it could be multiple regions in this case we're just doing a two for a simple concept and the idea is that the infrastructure in both regions exactly the same so you've got the same application load balancer the same auto scaling groups deploying the same version of your application if you're using a relational database service like the RDS service you're building your own database servers again you're using asynchronous replication to have a database copy in that secondary region and kind of the catch here with a multi region architecture like this that's active active when you're using relational databases you know you've always got a single master and so looking at the right hand side in the secondary region and those web servers and the app servers would actually have to go across region to talk to the master database for write operations so that's not super useful architecture however it does work and a lot of people will run that and again if you want a database solution that's actually global and basically multi-region inherently you could use something like dynamo DB a no sequel solution and we'll cover that in another week here in this program but basically when you're coming to this domain name and you're doing this active active type of routing you need a solution that will have the intelligence to be able to do that for you and there's third party solutions out there there's also a service from Amazon called route 53 that we're going to use that we'll see coming up but route 53 is often typically here as well because it has the intelligence and multiple routing policies that we'll take a look at that allows you to do this you can send 50 percent of the traffic to the primary region 50 percent to the secondary region and it works really well while we're on the topic of building multi-region solutions I wanted to introduce you to something called EPC peering this gives you the ability to connect your VP sees either across regions or just in a single region so there's multiple use cases for this it's not just for multi region but it is interesting when you're building a multi region solution let me give you an example so let's say that we're building out the infrastructure for a multi region application we've got some web and application servers that need to communicate and basically host the same version of the application and we want to do something like we've looked at previously an active active architecture or even a pilot light architecture and so let's say that we've got a network in the US West here on the left hand side the V PC cider range is 10 0.02 0 / 16 over on the right hand side we've got a V PC in the East Coast and the side arrange for that B PC is 192 168 0 0 / 16 so it's important to start out here that if we want to connect these two networks together that they have non overlapping IP address ranges so that's why we got different Network IP address information here so that's essential but let's say we've also got a relational database but let's say that we're not using the RDS service maybe that database runs on ec2 instances that we have to manage RDS is a great solution for managed service but there's a lot of times where companies want full access to the underlying server running the database engine so they want to be able to get root access and SSH in or RDP n they want to be able to install software on those servers and fully manage those servers and in that case you know setting up a read replica that's actually really challenging so doing this across regions with the B PC peering actually makes us a lot easier so for example you could go into the B PC console you could create a V PC P R in connection between these two different V pcs and then what you could do is inside the V pcs build up your database servers this could be a Microsoft sequel or my sequel or whatever set up database replication from one region to another using the internal network so you can basically think of this as kind of like a VPN connection a VP tunnel between tutor and bbc's technically that's not what it is but from a high level that's kind of the idea this gives our servers inside the BPC the ability to communicate with each other through a private network it doesn't have to go out to the BBC and over the Internet and it's very much like you're bringing up a branch office for your corporate environment building a VPN tunnel between two different sites and that's really the idea with the VPC peering now you don't have to be a master with this service but you do need to know that it exists and you could get kind of a high level question around this so let's jump into the V PC console and I'll just show you a couple things in terms of setting up a V PC peering connection so here on the console home screen let me scroll down to networking go to V PC and right now in this region I just have the default V PC but I could still set up hearing I could come over here and left hand side where it says peering connections this is where you would create a connection so you'd come in here click on creates you'd give it a name you would basically set up the requester because AWS actually supports the ability for you to POV PCs and different accounts but I would pick like Y kind of main V PC here in this organ region scroll down and pick whether or not this is within my own accounts but really what I'm really focusing on here now is the multi region solution so you would pick another region you would pick that region from the drop-down list and then you would plug in the V PC with a non-overlapping IP address range and then you would create the peering connection so I actually don't have a V PC in Northern Virginia with a non-overlapping site or range but that's basically what you would do once you create the connection you would have to come in here highlight it and then come to actions and accept the request and set up some routing so we don't really need to know it at that level for the solution architect associate exam but if you want to read more about this feature I'll drop this link here on the page where you're watching this video so you could read more about it and this takes you through it and if you actually wanted to set it up to test it yourself and see if you could ping across there's a number of things that you got to do you got to go in and build the V PC peering connection you got to set up some routing and of course you got to make sure that those networks don't overlap just like they show here we got the 10 Network on the left hand side the 172 31 Network on the other side but it's fairly easy to set up and you should know that this exists run 53 is a DNS based load balancing solution it's got different routing policies when we build our project here this week we're just gonna use the failover routing policy but I wanted to make sure you understood there's different routing policies in different times or you might want to use them so let's cover these real quick first of all we've got this simple routing policy this is just traditional DNS so you create a DNS record it's got a single value so for example my company comm the a record for that points to a specific IP address traditional DNS record like you've always worked with all these years now failover routing is going to be the one that we set up for active passive so like we're looking at on the slide deck we're gonna have a record for the East Coast everybody's gonna go to the East Coast unless it's not working then we'll start resolving a different IP address for our domain to that passive kind of implementation in another region and that'll become the active region if there's an issue we've got a couple of different geo based or geolocation based routing policies so we can get users connected to infrastructure that's close to where they're actually located we've got latency based routing so if you've got resources and multiple regions and you want to route traffic to a region that's got the least amount of latency you got the ability to do that there's a multi-value answer routing policy and this is good when you want to do kind of a round-robin load balancing solution so you use this when you want route 53 to basically respond to DNS queries with up to eight healthy Records selected at random so just kind of like a dumb load balance or a round-robin type of thing and then finally the weighted routing policy this is where you distribute traffic based on values that you define so for an active active multi-region you might do 50 percent goes to east coast 50 percent goes to west coast and the weighted value is how you control the distribution of that traffic and you could definitely have more than two locations there so keep that in mind but that's how the weighted routing policy works in order to do dns load balancing with route 53 we're gonna need a domain name and I'm gonna actually show you here how to register a domain with the route 53 service so route 53 supplies DNS records and does DNS routing but it also allows you to register domains so this does mean I'm gonna have to spend a little bit of money and if you already have a domain I'll show you in the next video how to work with the domain you already own with ratha p3s who not to spend any money let's scrolling down the list here on the console home screen I'm gonna go to route 53 and in here the first thing I'm gonna do is build out and register a domain so you can see when you get in here you've got DNS management's traffic management's availability monitoring and domain registration so the cool thing is in here in route 53 if you register a domain in here it'll build out a public DNS zone for you and do all that work but let me go ahead and come in here we'll register a domain you can also transfer a domain to Amazon and have it control here in route 53 but let me just check for AWS demo labs see if that's available okay and that's available so I'm go ahead and add that to the cart I'm gonna scroll down here and click on continue and then I'm gonna pause the video fill out all the registering information and then we'll continue okay so it's all filled out here I'm gonna scroll down I'm gonna go ahead and enable Whois protection because I don't want people spamming me if you've ever registered a domain and you don't have the privacy protection there's a bunch of people out there that are query the domain get your phone number your address and they start sending you stuff and I don't want that so I'm gonna leave that enabled click on continue go ahead and agree to the terms click on complete purchase and obviously this is going to charge the credit card that's connected to my AWS account so let's go to domains and notice that domain registration is in progress so I'm a good positive yo this should take about ten minutes to fully sync up and then we'll continue okay so about ten minutes has gone by and you can see that the pending domain registration is now empty if we go over to registered domains you can see there's my domain and it is set for Auto renew so obviously if I leave this domain in here this time next year I might get charged again and if you want to turn that off just go into the properties of the domain and you can basically turn that off in here you just set it to disabled for Auto renew let's go back to the dashboard here and when you have a domain connected here in Roth 53 basically you'll see a hosted zone was created for that so we come in here we see that we've got the domain registered and inside here we've just got the name server records the start of authority the typical DNS stuff you would have for a public DNS zone so if you want to save a few bucks and you've got a domain registered somewhere else you can actually use it with route 53 I'm going to show you how to do that so what I've done here is logged in to GoDaddy I've got a bunch of domains over here and GoDaddy one of them is stock advisor com let's say I want to use that with route 53 and I don't want to actually buy a new domain in the route that d3 console so first thing I would do in route 53 is build a zone for this domain so I would come in here to route 53 I would go to hosted zones I would create a new hosted zone and I would say my domain name is stack advisor comm this of course is going to be a public zone and you know when we queried the stack advisor comm namespace for DNS records this is going to be public on the internet you could also do private zones they could only be queried inside your Amazon VPC and depending on the application that may be interesting for you just to have that internal name resolution but in this case we're gonna do a public zone click on create and so what happens here is once this is created notice that if we select a domain here's all the name servers in this NS record type these are the name servers from Amazon that will basically answer any DNS queries for this domain so really all you got to do is create the domain name or create the zone I should say with the domain name take these values and then plug them in here with your domain registrar so in this case GoDaddy has a way of doing this he come down to the bottom you go to manage DNS so scrolling down the list you can change your default name server so mine are set to the GoDaddy ones right now cuz I'm not using this domain for anything let me change this I'm gonna say these are custom name servers and when I scroll down the list I would just plug in the stuff from Amazon right in here so let me pause the video what I'm gonna do is I'm gonna take these values and add them in here into the domain manager in GoDaddy okay after a couple of minutes I took the domains basically out of here from the name server records in the rum 53 console I copied them into the domain manager for my custom name servers clicked on save and now I'm all set so sometimes DNS changes take a while so I'll let this kind of burn in but basically anytime a DNS query comes in for stock advisor com basically the root name servers from GoDaddy are going to point to Amazon Web Services in the ratha p3 service so somebody queries something like WWE stock advisor com go down he's gonna say hey you need to go talk to route 53 and in here in Roth 53 I could create record sets like WWE stock advisor calm and that might go to something like 4.2 2.3 if that was my IP address I'm just stealing one that I already know off the top of my head but you get the idea that's how you would do it so if you're using your own domain give it some time you're gonna create your hosted zone you're gonna set up your DNS at your registrar but it could take some time for this these guys to basically report that what you can do to test that and make sure that's working and people are able to resolve that as you can go to network tools com do an advanced DNS lookup here so go to DNS records go to advanced and you can do a name server lookup go to NS search for your domain here szostak advisor comm plugging your domain name here like stock advisor com do a query and it looks like this is now reporting so these guys are doing a name server query for that domain and the showing up is the route 53 servers so basically that tells me that's I'm a pretty good shape I could go in here start creating DNS records for this domain and then everything would be good so if all that process if you need to I'm actually not going to use this so I'm go ahead and delete it and we've working with this domain here that I registered here in Roth 53 okay let's revisit the multi-region web application architecture so I've got AWS demo labs com registered and setup and route 53 so looking at the left hand side what we want to do is go into US East - that's the Ohio region that's gonna be the primary version of our application we're gonna create an ec2 instance over there then what we'll do later is build an ec2 instance in the West Coast West US - that's an organ that'll be our failover region we'll set up some help checks and route 53 and if the primary region dies people will automatically start going to the fail of a region there in Oregon so that's the model for this project let's jump into the AWS console and get started alright so back in the AWS console I'm gonna switch my region I'm gonna go to Ohio this is US East - I haven't actually deployed anything yet in here so let's go to ec2 and then let's go and launch an instance we're gonna do an Amazon Linux aim I'm just gonna pick the first one on the list click on next we're going to do a t2 time micro on the free tier hit next on this screen everything looks good we're going to auto assign a public IP now in the real world I would want this to be an elastic IP because I'm going to be going directly to this server so I'll actually show you that we can fix that after we deploy this server so let's just leave that there and we'll change this implementation in a second so we'll pick the default storage hit next we'll call this guy web one click Next we'll build a security group for this called web server and then we're not going to SSH into this guy because we'll use the session manager if we need to and scrolling down we'll do HTTP for the protocol they let anybody on the internet connect of course and then we'll launch the instance I don't have a key pair in this region because I've never used this region so I'll create a new one and I'll say this is Ohio or download that in case I'm going to need it close out of this and we'll launch the instance let's go here and view the instances this guy's coming online now and one of the things I should have done is associate an IM role with this me open up the security settings here scroll down the list where is it it's right here I am remember that I am role we created earlier for simple system manager so we could do such a manager and stuff like that and if we go into roles remember this guy SSM ec2 we use this I am role with our instances when we wanted to control the instances with the session manager so I should have attached this role to the ec2 instance and this is actually a good example of how you would set this up after the fact so highlight your instance go to actions go to instance settings and we're gonna attach or replace the I am role there's no role right now so we're gonna do SSM EC to apply that close out of this instance it's coming online now so next thing I want to do is go to services and then look for the systems manager overnight in a new tab because I want to stay in the ec2 consoles well we'll go to sessions or session manager start a session now if you get into the screen and there's no instances showing up in here it might be because you need to reboot the instance after attaching the I am role looks like I got lucky here but if you run into that that's the problem usually so let me go ahead and select this instance and update the SSM agent I got a pop-up blocked over here let me go ahead and say always allow you update again and so let's do a refresh looks like that was successful so now that the agent it's already pre-installed in the image has been updated will start a session on web one and then in here we'll sudo up so do a sudo su and then we'll do a yum install httpd - why - install install apache screen and then if we do an LS on bar WWE / HTML there's no document in there so let's do basically a nano bar ww HTML / index.html and what we'll do here is we'll just do a simple message using a header tag here in the webpage tool so we'll do an h1 tag and we'll say this is us east to now typically of course the web application code would be the same on every single server but as we're load-balancing these servers with DNS I want to know where I'm actually hitting because I'm just going to be going to AWS demo labs comm I want to see on the screen what server am I actually hitting so I'm gonna hit control X here I'm gonna type Y and hit enter to save that and then we'll do a cat on VAR w W slash HTML index.html and we see that information in there and so now that the web server is installed we got some code on there we need to do a service httpd start in a real world I would set that up inside this server so it always happens on the server boots I'm not going to take the time to do that right the second let's go over here to the server and the ec2 console highlight the current DNS record navigate over to that we see us east to so so far so good let me clean out some of these tabs here and all right so it looks good all right so here's what we're gonna do we've got a public IP on this server right now remember that was basically a dynamic public IP it's not an elastic IP so if I were to go in here go to actions instant state and then shut this guy down and stop him and I come and power him on tomorrow he's gonna get a different public IP and so if I'm pointing to this IP and DNS obviously that's a problem so let's do this let's go over here to elastic IPS let's allocate a new address we'll do an Amazon pool based elastic IP address allocate that and then what we'll do is we'll associate that address with our new ec2 instance so that's associated go back over to the ec2 instance through a refresh here and notice that now the elastic IP is now associated with this instance so we could actually just copy the IP as well and head over there and we're getting the same thing now that we've got our web server running here in Ohio let's switch over to organ and we'll build our web server here on the west coast so go ahead and do things a little bit differently this time let me go over to elastic IPS first allocate this address close out of that and then we'll go over here instances will launch the instance and to keep things consistent what I'm going to do is I'm going to pick Amazon Linux this guy here basically I had these in a different order when I was in Oregon so Amazon Linux 2 was on the bottom so I'm going to keep this consistent and we're gonna go ahead and attach the I am role properly this time at the beginning click on next tag the server this will be web 2 configure a security group server security group is evolved same thing as last time we'll remove the SSH rule because we're not going to need it and we'll add an HTTP rule that looks good anybody on the internet can connect to port 80 so we'll go to review and launch associate with my existing key pair and we're off and running all right Sal excu this and take a look let's go ahead and attach our elastic IP to this server associate this address with the instance as soon as it comes online no results found just yet still booting up hit refresh a few times here there we go pick web to associate that and we're good to go there all right so now what we could do is go up the services go back to the systems manager open this up in a new tab and the same drill as before we're gonna go to the session manager and click on start session and I'm gonna pick web to update the SSM agents and lay it refresh until that's ready to go alright and the agent is successfully updated so let's go to the session manager click on start session pick web 2 and start it alright again we're gonna sudo up we're going to do a yum install yum install httpd - why we're gonna clear the screen we're gonna do a nano on var www slash HTML / index.html and inside the source code for this HTML page what do you think I'm gonna put well if you're paying attention we're gonna do an h1 tag we're gonna do us west to you know if we go to this web application we'll know exactly which server we're hitting so control X type Y and enter to save let's go and make sure that that change is really there and there it is good and last thing is service httpd start okay and let's close out some of these tabs here and go back into the console and get out of this go back to my ec2 instance head over to the public IP address right click and go to and there we go we've got us West - showing up here so now what we can do is we can load balance these two different servers using our single domain name and then we'll be able to see Israel 53 sending us to the right place but we got some work to do in route 53 first if you remember back to our previous project we set up the application load balancer we set up some health checks on that load balancer in our target group to make sure that the destination servers and the applications were actually functional and we want to do the same thing in route 53 before we build any DNS records so I'm going to on the service home screen is scroll down and go to the networking section and go back to ratha p3 and in here when you're looking in the console you'll see you got health checks on the left hand side so we're gonna build these health checks they're basically gonna be looking at our servers making sure that the applications working and when route 53 determines the server is no good it's going to stop sending people there because that's how we're gonna set things up so let's build our first health check here the first one will build as we'll start with the East Coast so I'm going to call this East and when you're dealing with these health checks especially when you have multiple health checks it could get confusing very fast so you want to be very detailed about how you label these so I'm gonna say this is my East End point we're gonna be looking at the ec2 instance we can also do some monitoring on other things we could look at the status of another health check we could take a look at some cloud watch alarms and we'll dig into more monitoring stuff later and then down here you plug in the endpoint information so it's cool because you could put an IP address this endpoint could be a piece of infrastructure outside of the AWS environment it does not have to be an AWS resource I work with some customers that just strictly use route 53 or its DNS load balancing capabilities and that's it but what we're gonna do down here is we're going to monitor the east coast endpoints so let's go to services and open ec2 in a new tab head over to ec2 console switch to Ohio go into running instances and what I'm going to do is grab the public IP address for this web server in the East Coast this is our primary endpoint so down here in the list what I'm going to do is I'm going to tell route 53 to monitor this IP address and you've got different ways you can monitor it so you can monitor HTTP HTTPS or TCP now one of the benefits to using the HTTP or HTTPS protocol is we could actually check for a certain path so we could actually check for something like this health check PHP so you can put like a server-side scripts and have your own logic in there because really what the endpoint checker this help check is looking for is an HTTP ok response in this model where we got the HTTP protocol set and you could control that in a server-side script so this is a way for you to do a deep health check you could also just do a basic health check and say we're gonna do a port ping a TCP port ping is port 80 open and if it is then we'll say it's healthy now the benefit to using a deeper health check is you could actually make sure it's serving up content it doesn't have to be a script you wrote it could just be something like this index.html so make sure that not only is the server running on port 80 but is it serving up content so those are just a couple of ways you could go deeper but what I'm gonna do is just do a basic one a TCP port ping on that IP address and we'll scroll down and then the advanced configuration is actually kind of interesting let's take a look at this now the standard request interval is 30 seconds so if something fails it's gonna be 30 seconds before route 53 looks at it again so it might be beneficial especially in an active-active type of setup to have a fast health checker every 10 seconds we'll be taking a look now failure threshold that's how many times the health check actually fails before we'll call it a failure and so I'm pretty much gonna say if that happens twice we have a problem more than likely but you may find that if you have a buggy application you may just set that up but I'm gonna go ahead and set this to 2 and then down here another thing that's really cool is that if you take a look we've got health checker regions so we've got different regions where the health checkers are running all over the world in the AWS global infrastructure and so what that means is that's really going to eliminate kind of it falls positive because if it was only checking from the East Coast all the time and there was a problem in the East Coast with the internet then yeah the health checks gonna fail so there's an algorithm in here when we're using multiple checkers all over the world to really ensure okay this is down the application's dead and we have a problem so based on this everything looks good let's go ahead next I'm not gonna create an alarm for this we'll talk about alarms later in another lesson in this program in another week but basically we could have a we could have a text message sent to us a number of different things I'm going to skip that for now and create health check so when you create the health check it's gonna take a few minutes for the route 53 service and all the health checkers across the world to get out there and do a check on that guy so let's go ahead and let that sink up we'll create our next health check this will be for the West Coast and we're going to do the same exact thing as we did before in the ec2 console I'll switch over to organ web to server will get the public IP address go back over here and plug that in we're gonna do a TCP port ping on that IP address make sure we can get the port 80 scrolling down under advanced we're gonna do a fast health check a failure threshold of two and then we're gonna use the default recommended health checker regions so let's go ahead and create that hit next no alarms we'll just create the health check and close out of that so imma go ahead and pause the video here and let these guys sync up and then we'll come back when these health checks are reporting healthy all right couple of minutes later these are bolts reporting healthy let me select this guy here go to health checkers you can actually see in Tokyo they went out to that IP they were able to get connected they were able to do it in Singapore and on and on so that's really cool so at this point we've got health checks belts and now we can start building DNS records that utilize these health checks and that's where the routing policies come into play so here in the route 53 console we've got a single hosted zone for our domain we've got two health checks Bilt's and now we're ready to create the DNS records and the routing policies for this multi region web application so what's going to host it zones go to AWS demo labs comm and what I want to do is create a record set and that's basically that terminology just means we're gonna create a DNS record so let's click on that and then we've got AWS demo labs comm so what we could do is we could just leave it empty and just go to that root domain and we could put www record and then head over there that way now in terms of the type of DNS record we got a bunch of different types all the standard DNS record types that you would expect to have at a DNS service and we're gonna do an a record so this name is going to resolve to an IP address we're going to plug that in here now one thing that's interesting know is you can actually create aliases here that's targets different things in the AWS infrastructure and I encourage you to kind of take a look at this as you're messing around here in the console so you can resolve these DNS entries to CloudFront distribution domain names so you could have a custom domain for your CDN your content delivery network for an elastic beanstalk environment which is another service we haven't really talked about I'll cover that here and later in the program you can point an alias to an elastic load balancer and s free website enabled bucket all kinds of different options I'm not gonna do an alias what I'm going to do is I'm actually gonna put in a value here let's go to the ec2 console open this in a new tab ec2 I'm going to go to Ohio because the first record we're gonna build is for the East Coast end point I'm gonna come in here and once again copy the public IP address the elastic IP for this web server one so in here what I'm going to do for the value of the DNS record is I'm gonna plug in that public IP and notice we've got the TTL so the TTL is the time to live for this DNS record and what that means is if a client goes that w WAW s demo labs comm that client might be an iphone or your laptop it's gonna ask route 53 what IP address should i go to to actually get to the application route 53 is gonna answer with this and then the client based on this setting would cache it for 300 seconds and so this is great in most cases because the client caches that it doesn't have to constantly check in only check some of the route 53 every five minutes but in a failover situation that could be a problem because the IP address for the DNS record is going to change so what I like to do with a multi region routing solution like this is set the TTL lower to like 60 seconds that way if there is a failover the client will flush its DNS cache within a minute and it'll start getting a new IP address now when we get to the bottom in terms of routing policies remember a simple routing policy is basically traditional DNS that's just a name to IP address mapping we don't want to do simple we want to do a more advanced routing policy and these are the routing policies we were talking about earlier weighted latency failover based routing and failover is what we're gonna do here because we're gonna have a primary server in East Coast and then we'll only failover to the west coast if that primary servers are offline so pic failover this is going to be the primary and then we'll associate a health check with this record and if you could guess you would pick East right and you would be right so we want to associate this record with the east coast that's the health check we built earlier for this particular ec2 instance let's go ahead and create that record now the next step is to create another DNS record for w WAW SW m that resolves to the other IP address so an ec2 console let's go to organ go ahead and copy the IP address from this guy come back in here and then we'll create a new record set a new DNS record so w WAW s labs or ada is demo labs comm set the TTL the 60 seconds plug in the IP address for the secondary server and then for the routing policy it's gonna be failover and then this time this is the secondary server and just like you would imagine we're gonna associate that I'll check for the westcoast with this DNS record so route 53 is only gonna tell clients to go to this IP if that first server is not available on port 80 if those health checks fail so let's go ahead and create that record everything looks good let's see if this DNS load balancing with route 53 is actually working so to start off with I want to remind you here in the ec2 console for the East Coast based server in Ohio the public IP address is 13 58 138 zero we want people to go this server first and only go to the west coast if this guy is dead so what we can do obviously we could just open a browser tab and navigate over to the domain name and what I want to do first is show you how you could do a couple of different DNS checks DNS resolution checks so of course you could go into a terminal it could start off by just trying to ping that domain and based on the response here notice it resolves the IP address so this is what my computer is seeing in public dns 1358 138 dot 0 that's a good thing it's talking to route 53 it's getting the answer now DNS propagation around the world does take time so it's possible for me to get this DNS resolution and for somebody on the other side of the planet to get something different that's why I like to use tools like this online this is just one of many go to network tools comm you could do an advanced DNS lookup you could plug in your domain name here and say hey we're looking for a DNS record and a record do a query here and we see that it is reporting right so route 53 is doing its job properly everything looks good so far and so ultimately that means you know we can go over here open another tab literally go to the domain name and there's the East Coast based message we're expecting to see so this works great everything is working properly and now we want to do is basically fail this record so it starts resolving to that IP address the secondary fell over IP address so I want to ask you a question how do you think we should test that how could we break this web application in the first region and make this happen well there's two ways that I could think of off the top of my head in the ECU console one of the things we could do is we could go to the security groups and we could actually go to the web server group change the inbound rule bring this up a bit and we could change the HTTP rule and just delete it or change the source address and that'll break the health checkers if you think about it the health check infrastructure in route 53 is outside our BBC environment they're actually coming in through this rule so that's one way we could break it we could also go into the session manager and kill the Apache web service but it's actually just easier to break the security group so what I could do in here is say 2.2 2.2 for example like that and just save this that needs to be a slider notation so you do a slash 32 with that save it and now that security group is only gonna let people coming from that specific IP address to actually access the web page obviously that's going to break the health checkers and Rafah d3 so heading over here looking at the health checks let's go to the East Coast health check we did enable fast checks but let's go to health checkers and let's do a refresh alright and after refreshing a couple times you can see all these failures right failure and Tokyo failure and Singapore and all over the place so it's shooting green at the top but let me refresh that and sometimes the console in here kind of gets mismatched let me get out of the screen go back to health checks I like do a refresh and after waiting a minute we can see it's now reporting is unhealthy so as you're testing this stuff out on your own you're gonna want to give these things a little bit of time make sure that it's figuring out that it's unhealthy and it's doing what it's supposed to do but at this stage based on what we've set up it should now be resolving the alternate IP address let's go over to our terminal and see so we've pinged the namespace earlier it was responding with the right IP address in Ohio so that was 13 or 58 so let's ping it again and now we're getting a reply for the same exact domain on 54 69 54 and 239 so it's awesome now here's the catch sometimes browsers hang on to that stuff longer than your computer so in chrome over here I had this up previously let's hit refresh and see what happens and there it goes automatically switches to us West - but keep in mind that sometimes client devices like the browser will hang on to that previous cached information even if the computer is resolving the right IP information and sometimes it's one of those things where you got to tell the support people to have the clients that call in with the problem to reboot or something buts usually a small percentage but as you see we just failed over from the east coast to the west coast our web application is seamlessly working the end users still go to the same domain everything is super simple and that basically covers everything you need to know in terms of building a multi region application and leveraging route 53 but let me leave you with one last idea we go back to this routing policy information we were talking about earlier so here's a challenge for you if you're up for it and you have some extra time this week what you could do is now that you know how a failover routing policy works you could experiment with some of these other ones you could come in and do a weighted routing policy maybe send the majority of your traffic to the east coast and only sin may be the smaller percentage like 25 percent to the west coast and so you could go through this topic and read about these routing policies and go a little bit deeper as a challenge and see if you can get one working with a different scenario in a route 53 console what you would want to do is you can leave these health checks enabled but you would go back to your hosted zones go into your DNS oh and delete the previous DNS records that you had out there and then you can move on with a new exercise create a new record set with different routing policy setup so let's go through and clean up the AWS accounts in this hosted zone what I'm going to do is take these two records that I created the record set that was doing my failover routing them and delete those records go back to the dashboard checking in here you can see that we've got a couple health checks so I'm gonna get rid of those because I'm not using them anymore and AWS is gonna charge me for these because I'm doing fast checks so I want to get rid of those take a look in here and then you've got your domain in here so if you added your own personal domain you had registered somewhere else like GoDaddy you can delete this hosted zone and if you had the domain registered in your AWS account you can just clean up the records out of that hosted zone and use it for something else later don't forget you could come in to register domains you could disable Auto renewal here and it'll just go away in a year from now so that basically cleans up my rap 53 implementation because I am going to keep this domain and hosted zone for another demo later on but let's go to ec2 and clean this up we'll go into the running instance in Ohio we'll go ahead and get rid of this guy terminate it and while we're waiting on that we'll head over to organ we'll get rid of Webb too flip back over to Ohio while that one's going make sure this guy's shutting down they could look over here refresh a couple times and now you can see web 1 is terminated so let's look at the dashboard so that left behind an elastic IP so let's get rid of that guy and so this is something that you could run into as well if you try to do things too fast basically the allocation and the Association was still showing that it was connected to the silastic network interface which is the virtual Nick on the ec2 instance it says hey that doesn't exist so it's basically out of sync right we've got to give it a little bit more time let me hit refresh a couple times go to actions and so until it says release addresses are until that option is available this thing hasn't caught up yet with what I just did which was terminate the instance so let's give it a second and while we're waiting for that go back to the dashboard we can nuke this unused security group like webserver go and get rid of that guy go back over to organ and with the ec2 instance deleted here in Oregon go back to the dashboard snuke the security group go back to the dashboard see if we can get rid of this elastic IP address we do have the option to release this guy here so give her that that looks clean so in the dashboard I've no running instances I got a couple security groups but I also got something else running here in Oregon no elastic IP is so this is clean rot 53 is clean now we got to do is go to Ohio and see if we can get rid of this elastic IP address there's the release option and there we go so we've reversed everything that we've done in this video and you should have spent very little hopefully unless you had to register a domain but hopefully you could use that for something else going forward [Music]

Channel: CloudSkills

Views: 2,724

Keywords: AWS, route 53, multi-region

Id: X8LwfcmJghU

Length: 53min 39sec (3219 seconds)

Published: Fri Apr 12 2019