Building the infrastructure
Testing against failures
The course is part of these learning paths
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
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 firstname.lastname@example.org.
In this lesson, we are going to build our VPC environment. We have a couple of options available to us. When you open a new account with AWS, the default VPC with subnets, route tables and internet gateway etc. will be created for you. We can elect to use the default or create a new VPC. For our scenario, we will use the default VPC. Now let's reference our architecture diagram introduced in lesson one. We will start in the US-east-1 region. As you might recall, an availability zone is a distinct data center. If we only select one availability zone to run our application in and that availability zone happens to have a service disruption, visitors to our site would be unable to access our application.
Depending on the length of the outage and frequency of future outages, we would easily miss our design goal of five nines as a result of this single point of failure. Instead, we are going to launch our application into all three availability zones accessible to our account. Within each availability zone, we have made the design decision to separate our web tier from our database tier via subnets. There are many reason why this is a good practice. For our scenario, it makes the setup of RDS much cleaner and secure. This means we need a total of six subnets two in each availability zone.
Time to build our environment. From the AWS console, we will click on the VPC link. The VPC dashboard provides us an overview of our resource usage. With the default VPC, our dashboard shows that we have one VPC with three subnets. Clicking the VPC link drills down into a VPC list where we can acquire more details. We need to take note of the VPC CIDR, which we will use when allocating an IP range for our subnets. Next, let's click on the subnet link in the side navigation. We're immediately greeted with a list containing three subnets created by AWS. In the far right column, we can see that each subnet is associated with a different availability zone. And as part of the default VPC creation AWS will create a subnet for each availability zone within the region. We will use these subnets to represent our web tier. To make it easier for us to identify each subnet we're going to name them. Our naming convention is simple the prefix matching the purpose of the subnet, in this case web, followed by a partial availability zone name. Now we need to create the remaining three subnets for the database tier. We click the create subnet button and a window appears with several configuration options. We will name this new subnet using the same convention we did in our web tier. If we had more than one VPC in our account, we would need to select the VPC we are targeting. We can skip over it since we are using a single VPC. Next, we will pick an availability zone for this subnet and finally we add the CIDR block associated with this subnet. A quick note on that, because we are using the default VPC, our CIDR block for our network is set for us.
We cannot change it. Our subnets will have to reside in this range. If we had created a new VPC, we would have been able to set our CIDR block, meaning we could use an intuitive convention such as 10.0.1 range in the web tier and 10.0.100 range in the database tier. We do not have this option with the default VPC and for this series, we are not concerned about this. For your environment, however, you should plan accordingly. So now, we will repeat this process for the other two subnets selecting a different availability zone in CIDR each time. When all is said and done, our subnet list will look like this. Our VPC is now ready for the next step in our series setting up RDS.
About the Author
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.