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

Expanding to multiple regions


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 the eighth and final lesson in our series on high availability. In this lesson, we will go over the steps needed to expand our application from a single region to multiple regions. While AWS makes this possible, it can still be quite complicated. We will not be going through a step-by-step instruction on every detail, instead we will just touch on certain subjects so let's start. First up, we need to create RDS read replicas for our application. From the RDS dashboard we head to our instance. Under the instance actions button, click the create read replica option. Read replicas will default to the same settings used for the RDS instance. In this case, a T1 micro instance with standard storage. We will give the instance and identifier that must be unique among all read replicas. Recall from our architecture diagram each database subnet will have its own read replica. Change the subnet group to our one and only subnet group. We will start with the US-east 1a availability zone. The other settings are good so we can create the read replica. It will take a while for the creation to complete. We will repeat this for the other availability zones in our region and in the new region. We have some configuration to do for our application. The application will need to be modified to support reading from a read replica and writing to a primary RDS instance. A challenge we experience with this set up is that each read replica has its own end point URL. Ideally we should be able to create an internal elastic load balancer that would be able to distribute the database traffic. As of this recording, internal ELBs do not support this option. One option would be to add an EC2 instance running HAProxy to handle database queries. Writing tot he primary RDS instance from another region requires a VPN connection. This can be accomplished using open VPN or another VPN option since VPC pairing is limited to VPCs within a region. The only remaining piece is to script the database fail over so a read replica in the new region is promoted to the primary database instance if the existing primary is unavailable. After finishing the modifications to our application to support read replicas, we need to create an AMI and copy the AMI to the new region.

From the actions menu, click the copy AMI option. Select the destination region and begin the copy. This is required because AMIs are limited to one region. Next, we will create a cloud formation template from our existing environment. Cloud formation is a way to build a template version of our AWS resources that can be used to create a new environment or for disaster recovery. There are many tools that build on top of cloud formation both from AWS and third parties. It is an important topic to understand. Under the AWS dashboard, click on the cloud formation link. Two options are presented to us. The first allows us to create a stack using a sample template, uploading a template, or linking to a template. The second option is cloud former. Cloud former will build a template from the environment which is exactly what we want.

After naming the template, accepting the access control settings and options we can review the settings. Everything looks good. We acknowledge the AWS warning about IAM rules and click the create button. It will take a fair amount of time for AWS to go through our resources to generate the templates. Cloud former will save the template it generates to an S3 bucket. We can modify this template if needed. In our case, we have to modify it since cloud former does not generate entries for all of our resources properly. After the template has been created, we can head to the settings to pull the cloud former URL from the outputs tab. The URL links to an EC2 instance that cloud former creates in our source region that is a T1 micro instance responsible for managing our template.

Clicking the URL will take us through a landing page that we can use to launch a new environment in a region. The Cloud Former wizards walks us through each AWS resource that is possible to launch in the selected region. Once launched, Cloud Former will build the resources. We are not going to finalize the creation of our stack in the EU west one region due to limitations and resources at the time that is recording. When created, our entire stack will be running in EU west one. In the event it fails during creation, and where the template has been configured to roll back, all resources created in the stack are deleted. Finally, we need to update Route 53 to support our new region.

We want the new region to be a fall back region which means we need to update our secondary ELB sub-domains target to our EU west one elastic load balancer. Should US east one become unavailable content will be delivered from the EU west one region.

That is all there is to supporting high availability within the region and across regions. Thanks for watching this series and be sure to check out our other courses.

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.