1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. How to Architect with a Design for Failure Approach

Adding Route 53 to the mix


Testing against failures
Start course

The gold standard for high availability is five 9s, meaning guaranteed uptime 99.999% of the time. That means just five and a half minutes of downtime throughout an entire year. Achieving this kind of reliability requires some advanced knowledge of the many tools AWS provides to build a robust infrastructure.

In this course, expert Cloud Architect Kevin Felichko will show one of the many possible alternatives for creating a high availability application, designing the whole infrastructure with a Design for Failure. You'll learn how to use AutoScaling, load balancing, and VPC to run a standard Ruby on Rails application on an EC2 instance, with data stored on an RDS-backed MySQL database, and assets stored on S3. Kevin will also touch on some advanced topics like using CloudFront for content delivery and how to distribute an application across multiple AWS regions.

Who should take this course

As an intermediate/advanced course, you will need to have some experience with EC2, S3 and RDS, and at least a basic knowledge of AutoScaling, ELB, VPC, Route 53 and CloudFront.

Test your knowledge of the material covered in this course: take a quiz.

If you have thoughts or suggestions for this course, please contact Cloud Academy at support@cloudacademy.com.


Welcome to lesson five in our series. In this lesson we are going to add Route 53 support. As part of our high availability design goal, we're going to use DNS failure to ensure we always have a site available to our users. Before we get in to Route 53, we need to create an S3 failover site. Head to the S3 section of AWS and click the create bucket button. We have to name our bucket to match our domain in order for site delivery from S3 to work properly. Our domain name is going to be www.cloud-e.co, AWS requires that bucket names be unique across the entire S3 service which lends itself well to URLs. We will keep the bucket in the U.S.

standard region and click create, our S3 bucket needs a file to serve up to visitors. We'll upload an index.html file 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 opening 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 error document. Save the configuration. We can test out the site by grabbing the bucket's end point and bring it up in a web browser, next step is the creation of our hosted zone and record sets. Back at our Rout 53 dashboard, click on hosted zones and then click on create hosted zone button. Type in the domain name we're going to use and click create.

Route 53 will show us the delegation set. These DNS entries need to be 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 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 in this case www. Ensure the type is set to A-IPv4 addresss, change alias to yes. For the alias target enter the elastic load balancer DNS name. Next, we change the routing policy to failover. The ELB will serve as our primary end point. 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 type to A-IPV4 address and change alias to yes, we enter the full S3 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 target health so we'll leave that set to no. Let's open up a new tab and verify the application is loaded when we hit our URL. As you can see, our site is up and running. That is all there is to creating a failover site.

In our next lesson, we will make this and other parts of our design fail in order to test its resilience.

About the Author
Kevin Felichko
Solutions Architect

Kevin is a seasoned technologist with 15+ years experience mostly in software development.Recently, he has led several migrations from traditional data centers to AWS resulting in over $100K a year in savings. His new projects take advantage of cloud computing from the start which enables a faster time to market.

He enjoys sharing his experience and knowledge with others while constantly learning new things. He has been building elegant, high-performing software across many industries since high school. He currently writes apps in node.js and iOS apps in Objective C and designs complex architectures for AWS deployments.

Kevin currently serves as Chief Technology Officer for PropertyRoom.com, where he leads a small, agile team.