How to Design a Fault-Tolerant AWS System
The greatest aspect of cloud computing is its ability to create predictable and reliable systems. Unlike the cloud’s physical hardware counterparts, all IT infrastructure can be produced using code only. Anyone who has had to deal with load balancers on physical servers, server updates, and IT security, understands that if one thing goes wrong, then everything goes wrong.
All of these physical configurations are waved away by AWS’s IaaS — or Infrastructure as a Service. By using IaaS, anyone has the ability to architect a highly available and reliable system. IaaS, also known as infrastructure as code, is the ability to upload JSON or YAML configurations to the cloud that will automatically configure your environment for you.
By the end of this post, we will have created a fault-tolerant system using an open-source architecting model using CloudFormation. It will be a WordPress site spanning multiple Availability Zones. There will be NAT gateways, internet gateways, and all the other bells and whistles associated with a WordPress site. Let’s jump in.
High Availability: A Quick Refresher
Before diving into how we will create our High Availability system, let’s go over what a highly available system actually is. High Availability means that a system will almost always maintain uptime, albeit sometimes in a degraded state. In other words, the system will stay up, but the user may notice deficiencies. High availability is architected by keeping two things in mind: the complete removal of any single point of failure and system redundancy.
A single point of failure would be having one database in a server room. If that server room were to flood, then all of that data would be destroyed. To mitigate that single point of failure however, the data could be replicated periodically to a backup database. This backup database is what is known as redundancy. By mitigating single points of failure by utilizing redundancy, we create a fault tolerance system.
With AWS, one way (and really the main way) of maintaining system redundancy is by duplicating your environment in multiple Availability Zones (AZ). Remember that AZs will be in the same region, but they are isolated from each other, so there is no need to worry about any failure of redundancy here.
It’s now time to see how a fully functional web app can be created using CloudFormation in minutes. Yes, that is right; a high available site created in minutes.
How to Build a High Availability WordPress Site on AWS
There are two ways of building out AWS infrastructure. The first way is through the AWS Management Console. If you choose to do this, you would spin up your own EC2 instances, load balancers, and databases — and that is just the tip of the iceberg.
Spinning up services from the console is a great way to learn — and nice for the on-the-fly services that may be needed. However, it is not the best way to create production-grade architectures. The first principal of the first pillar of well-architected framework says to perform operations as code. This is where the second method of building out infrastructure comes into play.
The second method of building out infrastructure is using CloudFormation. CloudFormation allows users to create JSON or YAML infrastructure templates that they can upload to the cloud. CloudFormation reads this blueprint, and creates the infrastructure according to specification. This is the method that will be used here to build out our Highly Available WordPress site.
Don’t Reinvent the Cloud
One of the key aspects of cloud computing, and programming in general, is reusability. It is important that any code that is written is done so in a way that fosters reusability. That way others with similar purposes can repurpose that solution and save time and money. Now that may be simple with code, but with physical hardware that’s kind of difficult.
Unfortunately this is not Star Trek, where you can throw another company’s hardware into a replicator and create your own. Historically, replicating system configurations meant purchasing your own hardware and following instructions — but not anymore. AWS emphasizes that all operations should be performed as code, therefore infrastructure is now just as reusable as any other piece of code.
With all that being said, it would go against the grain of AWS to create our very own architecture template just for creating a highly available WordPress site. WordPress consists of over 35% of the internet, certainly someone has done this before, right? The answer is a resounding yes, and the template can be found on the official AWS template GitHub.
The AWS-samples repository has exactly the template required to create our WordPress site. It comes with everything that will be built, even AWS CloudFront. CloudFront is a Content Delivery Network (CDN) that is used to increase the response time of a website.
The template we will be following is on the official AWS template repository. Here is the link needed to continue following along.
Now that we have the template, the time to build out the website in CloudFormation has come. First however, there are a couple of caveats to mention.
AWS Services: Caveats to Keep in Mind
First, and probably the most obvious, there are many things happening on this page. It is perfectly understandable if there are some gaps of understanding as to what is being used here. This article is about how to deploy to the cloud, not necessarily all of the services that are required to do so. It will be assumed that before deploying this to the cloud there is a broad understanding of networking and some AWS services.
Second, deploying this to the cloud is not free. A charge is incurred on all of these services. However if you tear down the services quickly it will not cost all that much. (Just don’t forget!) Tearing down services can be a complicated process in its own right, so make sure you have a decent understanding of the AWS Management Console.
Lastly, it is assumed that you have access to the AWS Management Console with admin access or root access. So without further adieu, let’s get started.
Deploying With CloudFormation
First things first, go to the AWS Management Console and type “CloudFormation” into the search bar at the top. Click the link provided in the search result and this should bring you to the CloudFormation service page. There should be an orange button that says “Create Stack”. Go ahead and click that.
So far so good, but you may be wondering what a stack is. With regard to CloudFormation, a stack is essentially the instantiation of the CloudFormation template. It is a collection of resources such as EC2 instances, route tables, the block storage units that are utilized in tandem within the stack.
Now that you have clicked “Create Stack”, there will be three options provided: Template is ready, Use a sample template, and Create a Template in Designer. At this point, it should be noted that there are two paths that can be taken. One, we can use the AWS-Sample YAML file mentioned previously, or we can use the sample template provided by CloudFormation.
By using the YAML file, we will begin creating an environment that is more akin to an actual production environment. If you are in for a challenge, and want to see how a production CloudFormation stack is created, then continue with the YAML. However, if you want to see a proof of concept, then choose the WordPress sample template located under the radio button “Use Sample Template”.
If this is all completely new, the sample template may be the best bet. If this is not your first rodeo, then follow along for uploading the YAML file.
Creating the Stack
Go to the link provided earlier, and scroll to the bottom of the page until a large YAML file is visible. Copy this code into a text editor and save it somewhere like your desktop. It goes without saying that it would be advantageous to scan over the ReadMe associated with this repository. That way you’ll have a deeper understanding of the stack that will be created shortly.
Once the YAML file is saved, click “Template is ready” on the CloudFormation page. Click “Upload a template file” and browse to the YAML file location and upload it. At this point, you can either click “Next” or if you prefer “View in Designer”.
CloudFormation Designer is a visualization tool that displays exactly what will be deployed in your stack. It translates exactly what is in your YAML file and displays it as a picture. It is a great tool for visualizing the stack.
After you click “Next”, you will be taken to a screen that requires some parameter configuration. First, enter a name for your stack. Any name will do, such as “WordPress-Site”. After that make sure that the number of availability zones, (which should be set at 3) matches the amount of availability zones in the next input selection. So if the first input says “3”, then you must select three AZs.
After this, you will soon see that the parameters are displaying CIDR blocks. All of these have been configured in the YAML file, so you can click Next. CIDR blocks are just IP addresses used within your VPC that allow communication between the different services.
It is important to note that there are three of each type of subnet shown: Data, Web, and Public. Take notice that this is equal to the amount of availability zones entered. This is how Highly Available architecture is maintained. The public subnet is how your WordPress Site will access the internet. They contain NAT gateways that will route traffic to the EC2 instances.
The web subnets are where the majority of the business logic is located — the WordPress site itself is hosted in the web subnet. Lastly, the Data subnet is where the Amazon Aurora database is located.
After you click “Next”, you may notice that we are on the third step of four. The finish line is in sight. At this point, tags may be added to the stack. This is a great way of finding and tracking resources. For this example, tagging is probably unnecessary. But in a production environment, it is critical to give names to your stack so that it is possible to track resource utilization.
The next set of parameters requested are in regards to IAM Permissions (Identity Access and Management). It is visible directly below the Tags input text. IAM permissions are defaulted to the permission of the user creating the stack. In real life though it is important to think carefully about who has permissions to edit, delete, and create stacks. At this point click “Next”.
Before clicking “Create Stack”, click the checkbox that states, “I acknowledge that AWS CloudFormation might create IAM resources.” All this means is that in order for different services to communicate with one and other, IAM roles will have to be created. Once the stack is created, they can be reviewed on the IAM page.
Lastly, click “Create Stack” and voila. You’re finished. The stack should spin up successfully and you will be able to access your WordPress site from the internet. Check the IP address in the Internet Gateway area of the AWS Management Console. There will be a lot of areas to explore. An Aurora DB is created, load balancers, EC2 instances with autoscaling policies, and more.
Investigate all of these new services and enjoy your AWS High Availability WordPress Site!
The key takeaway from this is that all infrastructure can be created using code. If you find yourself manually spinning up services to create a production environment, then that is a red flag. Always remember that there is more than likely a template that can be used to either suit your business needs — or it can be repurposed and modified to fit the situation.
This may have been a daunting process, but hopefully it gave you a better understanding of the power of CloudFormation and IaaS in general. Oh, and AWS as a whole, of course!