Scalability and Elasticity
Welcome to domain Seven - Scalability and Elasticity - in the Solution Architect Professional for AWS learning path. In this group of lectures, we will walk through building a flexible, available and highly resilient application in the Amazon web services environment.
Hello and welcome back. In this lesson we are going to add Route 53 support. Part of our high availability design goal, we're going to use DNS failover to ensure we always have a site available to our users. Before we get into Route 53, we need to create an S3 Failover site. So let's head to S3 section of AwS and click the Create Bucket button. We have to name our bucket to match our domain in order for the site delivery from S3 to work properly. Our domain name is going to be www.cloud.e.co. AWS requires that the bucket name's unique across the entire S3 service which lends itself well to URLs. We will keep the bucket in the US standard region and click create. Now S3 bucket needs a file to serve up to visitors. We'll upload an index html to it. Once it has been uploaded, select the file, click on actions and make the file public. Lastly, the bucket needs to have website hosting enabled. We can do this by outing the properties for the bucket. Under the static website hosting section, click on the enable website hosting option, enter index.html for both the index and the error document, save the configuration. We can test out the site by grabbing the bucket's endpoint and bringing it up in the web browser. Next step is the creation of a hosted zone and record sets. Back in our Route 53 dashboard, click on hosted zones and then click on create hosted zone button. Type in the domain name we are going to use and click create. Route 53 will show us the delegation set. These DNS entries need to by applied to our domain record with our registrar. Each registrar has different instructions for how to do this. Once the domain record has been updated, we can add this to the hosted zone record set. First we create a primary alias that points to our elastic load balancer. Click the create record set button, under name we type in the sub domain which in this case is www. Ensure the type is set to AIPV4 addresses and change alias to yes for the alias target into the elastic load balancer DNS name. Next we change the routing policy to failover, the ELB will serve as our primary endpoint. We'll make sure that evaluate target health is set to yes. This will check the health of our website and determine if the secondary has to become active. Now we need to add the secondary DNS. Click the create record set button, again we enter www as the name. Set the target to AIPV4 and change alias to yes. We enter the 4S3 bucket name as the alias target. Change the routing policy to failover. The failure record type should be set to secondary. For secondary failover record types, we do not need to evaluate the health target, so we'll leave that set to no. Let's open up an new tab and verify the application is loaded when we hit our URL. As you can see, our site is up and running. This is all there is to creating a failover site. Next, we'll make other parts of our design fail in order to test the resilience.
Andrew is fanatical about helping business teams gain the maximum ROI possible from adopting, using, and optimizing Public Cloud Services. Having built 70+ Cloud Academy courses, Andrew has helped over 50,000 students master cloud computing by sharing the skills and experiences he gained during 20+ years leading digital teams in code and consulting. Before joining Cloud Academy, Andrew worked for AWS and for AWS technology partners Ooyala and Adobe.