1. Home
  2. Training Library
  3. Amazon Web Services
  4. Courses
  5. Solution Architect Professional for AWS - Domain Seven: Scalability and Elasticity

Build our VPC for fault tolerance

Build our VPC for fault tolerance

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.


In this lesson, we are going to build our VPC environment. We can elect to use the default VPC or create a new VPC. So for our needs, we'll use the default VPC. Now let's reference our architecture diagram. We'll start in the US East one region. If 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. So instead, we are going to launch our application into 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 reasons why this is good practice and 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 with 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 drops down into a VPC list where we can acquire more details. We need to take note of the VPC CIDR block 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. As a 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. Next we will pick an availability zone for the subnet and finally we add the CIDR block associated with the subnet. A quick note here that because we are using the default VPC, our CIDR block for this network is set for us. We can not 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 the series, we're 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. Our subnet list will look like this. Our VPC is now ready for the next setup in our series which is setting up the RDS.

About the Author
Andrew Larkin
Head of Content
Learning Paths

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.