Designing an AWS Three-Tier Architecture
For this week’s project, I’ll be walking through the process of building out an AWS Three-Tier Architecture comprised of a Web Server Tier, an Application Tier, and a MySQL RDS Database Tier. Multi-Tier Architecture is extremely popular and among the most utilized in cloud computing, and for good reason — the three-tier architecture has been around for decades and lends itself to designing user-facing applications. AWS states that the three-tiered architecture is comprised of three layers or tiers and include a Presentation Tier, a Logic Tier, and a Data Tier.
The Presentation Tier is the portion of the three-tiered architecture that end users directly interact with such as a web page or mobile web app user-interface.
The Logic Tier contains code that translates end user actions to application functionality such as Create, Read, Update, Delete (CRUD) database operations and processing.
Finally, the Data Tier contains storage media that contains data that is relevant to the application. Some examples might include databases, object stores, caches and file systems.
I will add that it’s a great idea to sketch out the logical design of the architecture simply to have a mental model or picture of how the different components interact with each other. It will greatly simplify in helping remember things like the NAT Gateways and Auto Scaling Groups.
Prerequisites:
- An AWS Account with console access
- A solid understanding of Linux and Networking
Project Parameters:
Verification and Deliverables:
- Make sure you can access the web tier web page from the internet.
- From the web tier verify that you can ping the application tier from the web tier by running the ping command from an EC2 instance in the web tier.
- Send diagram to coaches
FOUNDATIONAL
Scenario:
You have been asked to design and create a highly available 3 Tier architecture for your company’s new web application.
Advice:
1)Build out one tier at a time. The best way to eat an elephant is one bite at a time.
2)Verify that you can do the foundational project first before building out to the ADVANCED and COMPLEX options.
NOTE: NAT Gateways, Elastic IPs, and ALBs do have a small cost. Ensure you delete them after your project.
Web Tier
- 2 public subnets.
- Minimum of 2 EC2 instances with an OS of your choice (free tier) in an Auto Scaling Group.
- EC2 Web Server Security Group allowing inbound permission from the internet.
- Boot strap static web page or create a custom AMI that already includes the static web page.
- Create a public route table and associate the 2 public subnets.
Application Tier
- 2 private subnets.
- Minimum of 2 EC2 instances with an OS of your choice (free tier) in an Auto Scaling Group.
- EC2 Application Server Security Group allowing inbound permission from the Web Server Security Group.
- Associate with private route table.
Note: This is not a true application tier as we don’t have any provided code to run on the EC2 instances.
Database Tier
- Use a free Tier MySql RDS Database.
- The Database Security Group should allow inbound traffic for MySQL from the Application Server Security Group.
- 2 private subnets.
- Associate with private route table.
Note: No need to use Multi-AZ but be sure to document how you would add it
Considerations:
- You will need to configure a public route table along with private route tables.
- You will need a Nat Gateway in one of your public subnets to allow your instances in private subnets to update packages and patches. Make sure to include this in the private route table.
- In order to reach your EC2 instances in the private subnets, you will either need a bastion host in the public subnet or need to use SSM. You will need to research into both to see which works better for your use case.
- Plan out your CIDRs before you create your VPC and Subnets.
Let’s dive in and get started! Before we start building our three-tiered skyscraper, we will need some core infrastructure or piers and beams to support everything. Our skyscraper’s foundation won’t be poured in concrete, but in the form of basic network infrastructure including a VPC (Virtual Private Cloud), Internet Gateway, which will allow our external users to access the resources in our three-tiered architecture, and a NAT Gateway which will allow our private subnets to access the Internet. In addition, we will need to setup Availability Zones, Route Tables Security Groups, and Public and Private Subnets. We will utilize two public Subnets and four private Subnets.
I’m including the diagram of the architecture for reference as we’re getting started.
From the AWS Dashboard, type VPC into the search bar and click on it. From there, we will click “Create VPC” and enter the following settings shown below. Click on “VPC and more” and we’ll get to our configurations. I’m calling my VPC “Three-Tier-Arch” and am using an IPv4 CIDR block of 10.0.0.0/16.
Next, we will continue and select our Availability Zones, our number of public subnets, and number of private subnets. I’ve selected two Availability Zones that the entirety of the three-tier architecture will be built on. We’re going to customize our subnet CIDR Blocks according to our diagram. Our public subnets will live in the Web Tier because we need end users to be able to access the web servers. The public subnets will be 10.0.1.0/24 and 10.0.2.0/24.
The next two private subnets will land in the Application Tier and will be 10.0.3.0/24 and 10.0.4.0/24. Our last two private subnets will splash down in the Database Tier and will be 10.0.5.0/24 and 10.0.6.0/24. Note that the last subnet of 10.0.6.0/24 is not shown in the screenshot.
We’ll enable the check boxes for “Enable DNS Hostnames” and “Enable DNS Resolution” as this will allow end-users to access resources within the Web Tier. Then we’ll click “Create VPC”.
We can see here that our VPC creation was successful!
Before moving on, I went to the VPC Dashboard and went to “Subnets” to rename them so they would be a little bit easier to keep track of. I named the public subnets, 10.0.1.0/24 and 10.0.2.0/24 to Web so they would be easily identifiable. I also named the private subnets 10.0.3.0/24 and 10.0.4.0/24 to App for the Application Tier. The remaining private subnets, 10.0.5.0/24 and 10.0.6.0/24 — I’ve renamed to DB for the Database Tier.
Before moving on, we need to select each of the public subnets and enable the check box for “Auto-Assign Public IPv4 Address”. This will allow end users to access the resources in the Web Tier.
From here, we’ll check in with Internet Gateways, create one, and attach it to our VPC. The Internet Gateway will enable us to get out to the Internet, and also allow the Internet to reach our resources within the Web Tier. We will tighten down the security using a Security Group at a later point.
From here, we’re going to navigate to EC2 on the dashboard and click on Launch Templates and click the orange button, “Launch Templates”.
I’ve called this launch template “WebLaunchTemplate” as this will be the template that additional EC2 Instances are spun up from. I’ve given it the description of “Production Webserver for 3 Tier Architecture”.
In this screenshot, in the interest of simplicity, I’ve selected recently used because it brought up the Amazon Linux image that I’ve used many times in the past. You’re certainly free to select the OS of your choice, and I’ve chosen this one because it’s free tier eligible, which is perfect for our lab environment.
For the instance type, I’ve selected t2.micro as it’s free tier eligible and we won’t be pushing super heavy workloads here.
I’ve created a new key pair for this instance and downloaded it. Don’t forget to run chmod 400 Three-Tier.pem in the same folder you’ve downloaded it to. This changes the permissions so others do not have read/write/execute access to the private key. I will do that portion right before I connect to the instance.
Under Network Settings, we’re going to create a new Security Group for the web server tier. This will dictate what type of traffic is allowed into the Web Tier instances. I’m going to allow SSH (port 22) and HTTP (port 80). I’m also attaching it to the VPC we’ve created for this project, “Three-Tier-Arch-vpc”.
Under Advanced Network Configuration, we’re going to enable Auto-assign public IP. That will wrap up our configuration of our Security Group for the web tier.
In the User Data field, this is where we will enter the shell script that will install Apache for each instance we spin up.
#!/bin/bash
sudo yum update -y
sudo yum install -y httpd
sudo systemctl start httpd
sudo systemctl enable httpdOnce the shell script is entered, we will have completed the Launch Template portion of the configuration. Click “Create Launch Template” and we’ll move on to the next section.
Here we can see that the creation of our Launch template was successful.
Next, we’ll move on to creating the Auto-Scaling Group for the web tier portion of our Three Tier Architecture.
I’m calling mine “Web-Tier-ASG” and we’re attaching it to the Launch Template we created in the last step.
Here I’m selecting the Availability Zones that our new instances will spin up in. I’ve selected the subnets 10.0.1.0/24 in US-East-1a and 10.0.2.0/24 in US-East-1b.
Click Next and we’ll move on to the following step for Load Balancing.
Click Attach to new Load Balancer. For the Load Balancer type, we’ll choose Application Load Balancer and name it “Web-Tier-ASG-1” and we will make it Internet facing.
I’ve chosen the subnets 10.0.1.0/24 in US-East-1a and 10.0.2.0/24 in US-East-1b where our Load Balancer will be active. We’ll also create a listener on port 80 and give it a name.
For our group size, we’re going to configure the minimum capacity of 2 and a maximum of 4. This will configure the maxiumum number of instances on our Auto Scaling Group.
Let’s see how our first two instances are doing. They are running successfully. We’re going to go check one of the instances and pull it’s public IP address to make sure the Apache web server is up and operational.
We can see that the default Apache web page is up and operational.
Now let’s create the Application Tier Instances. We’ve already created the subnets so we’ll create a new version of Launch Template that’s specific to the Application Tier.
We will follow largely the same procedure for creating the Launch Template for the Application Tier that we used to create the web tier.
I’ve called my Security Group name “ApplicationSG” and we’re going to allow SSH and ICMP. We’re going to attach it to our VPC that we created earlier for our Three-Tier-Arch-vpc. For inbound traffic, we’re going to allow SSH from the Web Tier Security group and allow ICMP from anywhere. In a production environment, we would tighten this down and now allow from anywhere, however, this is a lab environment so I’m not as concerned about it.
To recap, where we’re allowing SSH from the Web Tier Security group and allowing ICMP from anywhere.
Here we can see that the creation of our Application Launch Template was successful.
Like we did for the Web Tier a few steps back, we’re going to create an Auto Scaling Group for the Application Tier. I’ve called mine “Application-Tier-ASG” and we’re going to attach it to the modified Launch Template. It’s a little confusing here because it shows WebLaunchTemplate. However, we have to be sure to select the correct version. Mine in particular is version 3 because I created another version because I thought I’d messed up my first Launch Template. I’ve been deliberate to ensure that I’ve selected version 3 because this references the Launch Template for the Application Tier.
We will make sure that our Auto Scaling Group is attached to the proper VPC that we created for the Three Tier Architecture. Here I’m selecting the Availability Zones that our new instances will spin up in. I’ve selected the subnets 10.0.3.0/24 in US-East-1a and 10.0.4.0/24 in US-East-1b as those subnets have been designed for the Application Tier.
Let’s review our Application Tier Auto-Scaling Group. Everything looks good so we’ll click Create.
Let’s peer in on our instances and see how things are looking. We can see that two additional instances have spun up in the Application Tier.
Lastly, let’s get our Database Tier created. Under Services, Click Databases and select Amazon RDS. Click Create Database and we’ll get started.
I’m going to do a Standard database creation and choose MySQL as the database type.
I’m calling mine “Database-Tier” and choosing a username and password for the database administrator.
I’m going to choose db.t3.micro and stick with the default settings for Storage Type and allocated storage. 200GB is a bit hefty for our purposes but it’s the default. In a production environment, I would scale this back significantly so we’re not using more than needed, but at the same time, having enough spare storage as the database grows in size.
Here we’re not going to connect to an EC2 compute resource and we’re going to make sure we attach to the Three-Tier VPC that we’ve created for this project. This database will not be publicly accessible so we’ve slected no for that.
Here we’re creating a new Security Group for the Database Tier. I’ve called mine “Database-Tier-SG” and am landing it in the US-East-1a Availability Zone. The Database will be authenticated by password that we configured earlier.
Click Create Database and we’ll be off to the races.
We can see that the Database creation was successful and it’s up and running and the status is “Available”. Perfect!
Click on the Database and under Actions, select Edit Inbound Rules. We’re going to select port 3306 because the Application Tier will need to be able to write to the database. With that said, we’re selecting the Security Group from the Application Tier as the “Source” for our inbound connectivity. The first rule is allowing connection from my IP address, which I’ve blurred out.
Now let’s create our NAT Gateway and attach it to the private subnets. This will allow the private subnets to access the outside world. I’ve called mine “Public NAT” and chosen the subnet in Availability Zone US-East-1a. For connectivity type, select Public and Allocate Elastic IP.
For each of the four subnets, click each one and individually modify it’s route table. I’m not showing the process for every one because it’s the same process of allowing traffic from anywhere (0.0.0.0/0) to our NAT Gateway.
For each of the four private subnets, go through the process of modifying the Route Table and click “Save Changes”.
Now I’m going to connect to our Web Tier Instance and SSH into it to see if I can ping the private address in the Application Tier. I went ahead and ran the chmod 400 Three-Tier.pem to modify the permissions on my private key to read only for myself and no access for anyone else.
We’ve successfully been able to ping the private address in the Application Tier!
In this project, we didn’t have any actual application logic running in the Application Tier, so nothing is being written to the Database, however, we’ve built the framework for all of that to take place. We simply need an Application. However, that was outside of the scope of this project.
This project has, far and away been the most involved AWS project I’ve done yet and there’s a lot of logic going on here. I highly recommend drawing out the architecture first so you’re able to keep a mental note of how everything is interacting and connecting together. Fortunately, I was able to draw on my extensive understanding of Network Architecture and how everything interoperates and plays together.
Thanks for tuning in and be sure to check out my next article!
