AWS 3-Tier Architecture
The 3 tier architecture consists of three computing teirs. Each of these tiers are able to operate simultaneously, be developed independently, & yet integrate holistically.
It’s similar to dining out & having appetizers, a meal, & dessert. You can have any one of these independently, but together they make for an exceptional experience.
These three tiers consist of a Presentation tier (web/user-interface), an Application tier, & a Database tier.
Although it may take some time to lay the ground work, the value of this architecture model is in its integration efficiency, scalability, reliability, and it’s security.
Tier specific development teams can manage each tier separately, which is more organized and efficient. Tiers also have the ability to scale independently, so if there is an outage in one tier, it is less likely to impact availability. Also, because the Presentation tier and the Database Tier cannot communicate directly, the Application Tier operates similar to an internal firewall.
A 3 tier architecture should look something like this…
Let’s take a closer look by creating & testing this 3 Tier architecture in the AWS console.
It’s specifications are as follows:
A Web Tier with…
1) A Public Route Table — associated with 2 Public Subnets (1/AZ)
2) At least 2 EC2 instances with a boot strapped Static Web Page — managed by an Auto Scaling Group
3) EC2 Web Server Security Group
An Application Tier with…
1) A Private Route Table — associated with 2 Private Subnets (1/AZ)
2) At least 2 EC2 instances managed by an Auto Scaling Group
3) EC2 Application Server Security Group
A Database Tier with…
1) A Private Route Table — associated with 2 Private Subnets (1/AZ)
2) A Database Security Group
3) A free Tier MySql RDS Database
Let's Begin by Creating our VPC…
First off, enter the AWS Console & make sure you have specified your region (US East — N. Virginia). Then navigate to VPC, select “create VPC”, & name it. I am naming mine, “VPC-for-3”.
For our purposes in this lab, we will select “VPC only” and not select “VPC and more”. Although you may find the latter helpful for other projects, we will do each service separately for a more comprehensive understanding of their deployment.
Next, enter your IPv4 CIDR block as Manuel input, and below that add “10.0.0.0/16” to the IPv4 CIDR. We will use varying CIDR notations for our subnets from this later on.
Leave the rest default, and select “create VPC”.
Next, we will create our subnets…
Go to your Subnets page, and select “Create subnet”. Locate the correct VPC for each subnet, and begin configuring.
Note:On this page we can make multiple subnets, and for this project we will be making 6. Each one will also need a CIDR block, and you can add these by using a CIDR calculator (search for one on google if you don’t have a favorite).Also, each of these will fall into 1 of 2 availability zones. All subnets ending in “1” will go into our “us-east-1a” availability zone, and all the subnets ending in “2” into our “us-east-1b”.
The first two subnets are for my presentation tier, and I will name them “web-subnet-1" and “web-subnet-2”. These subnets will need the “Enable auto-assign public IPv4 address” setting changed. You can do that under “Actions” and “Edit subnet settings” after it has been created.
The next four subnets are for my application tier and my database tier. I will name them “app-subnet-1”, “app-subnet-2”, “db-subnet-1”, and lastly “db-subnet-2”.
When all the subnets are configured, go ahead and select “Create”. When they are finished, they should all be neatly listed on your subnets page.
Internet Gateways and Routing Tables…
Now that our subnets are created, we will set up the internet gateway. take a peek at the left hand dropdown menu, and choose “internet gateway”. Select “create internet gateway”, name it, and finalize by clicking “Create internet gateway”. Inside your internet gateway choose “Actions”, “attach to VPC”, then select your VPC, and then choose “Attach internet gateway”.
Next, we will navigate to the Route Tables page. Our subnets should be attached to our main route table by default, but we are going to make sure each tier has it’s own routing table.
The Application subnets and the DBsubnets will have their own private routing tables. When those are created, we will create a public route table for our two Presentation (Web) subnets.
You can start this by selecting “Create route table”, name it, then find your VPC and choose “Create route table”. Inside your new route table, choose “Subnet associations”, and then “Edit Subnet associations”. For each table you can associate the different subnets. At the end of each configuration, select “save”.
Next, we will create a NAT Gateway…
Again, on from the dropdown menu on the left choose “NAT Gateway”, and “Create NAT gateway”. Go ahead and name it (mine is “3-tier-NAT”), choose a public subnet (web-subnet-1), and make sure to select “Allocate Elastic IP”. Then, click “Create NAT gateway”. This will be used to connect our private subnets to the internet.
Note: You can create these for multiple subnets, but we will just use one for our purposes.
When this is done, go back to your Route Tables, select your public route table, then connect your public route table to the internet gateway we created earlier under the “Edit routes” section. Then click, “Save changes”.
Next, go into your private Application Tier route table and choose the NAT gateway as the target… click “Save changes”.
Next let’s create some Launch Templates…
In the AWS console, locate and select the service “EC2”. Then from the left-hand drop-down menu, choose “Launch Templates” and “Create launch template”. Because this is for our Presentation tier, I am naming mine “web-asg”. Click the box below for “guidance and help with setting up your template with EC2 Auto Scaling”.
Next, select your prefered AMI. I will use the Amazon Linux 2 AMI with free tier eligibility. You can find this under, “Quick Start”.
For the instance type I am going with the t2.micro, again because it is free tier eligible. Select or create your Key pair, then use or create a security group that allows inbound permissions from the internet. (Make sure to select the right VPC for this project)
It will look like this:
Lastly, under “Advanced details” we will scroll down until we see “userdata”. Here you can bootstrap an Apache webserver with your site details.
You can copy and paste mine if you do not have your own.
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<html><body><h1>Web Tier Success!</h1></body></html>" > /var/www/html/index.html
After this is done, go ahead and select “Create launch template”. We will do this same process for the application tier launch template as well, but it will have a different name and security group. I will name this one, “app-asg”. For the security group the rules will be configured like this:
On this template, you can forgo the userdata and finish up by selecting “Create launch template”.
Now it’s time to create our Auto Scaling Groups…
You can begin this process right from the launch templates page. Just select one of the templates, I will start with “web-asg”, and under the “Actions” choose “Create Auto Scaling Groups”.
Name your group, and select “Next”… I named mine, “web-ASGroup”
On this next page, make sure you have the correct VPC selected, then add both of your presentation tier subnets, and select “Next”.
On this next page we will add a new load balancer.
Make sure that it is an Application Load Balancer, that it is internet-facing, and that you have selected the correct VPC and subnets. Scroll down and choose the “internet-facing” option, then make sure your “Listeners and routing” looks like this…
Now, under “Default routing” drop the menu and choose “Create a target group”. This should generate a target group for you. Scroll all the way down, and select “Next”.
On this page you can configure your group size and scaling policies. I am going with a desired capacity of 2, and minimum of 2, and a maximum of 4. You can adjust these numbers according to your needs. After this, you can select “Next” until you are able to “Create Auto Scaling group”.
We will repeat this process for our Application tier by selecting “Create an Auto Scaling group”. This time through the differences will be the name, the launch template (app-tier template), and the subnets (app-tier subnets). When you configure your ASG for the Application tier, you will want to make sure it is internal facing.
Now lets create our RDS Database
Next, we will navigate to the RDS services page. From the left-hand drop-down menu select “Subnet groups” and then “Create subnet group”. I am naming this one, “db-tier-aws”. You can add a description, and then make sure you select your correct VPC and add your database subnets, then click “Create”.
Now that we did that, lets go back to the RDS services page and select “Databases” and “Create database”. We will select the standard option, with a “MySQL” engine type, and a “Free tier” template.
Go ahead and name this, and add your password, then leave the rest as default until you get to “Connectivity”. Here you will make sure you have the correct VPC selected, and that the subnet group you just made is showing. Then make sure that you do not allow public access, and that you created a new VPC security group. Choose one of your AZ’s, and select “Create database”.
When this is created, we will need to make sure the connectivity is updated between the Database tier and the Application tier. To do this, go into your database, select the “VPC security groups” link, go to “inbound rules”, and update them to look like this…
This will allow communication between the Database tier and the Application tier.
Now that we have created our 3-Tier Architecture, lets test a few things…
- Did our public EC2’s launch our website?
- Can we connect to our Application tier through our Public EC2's?
- Can we connect to our Database tier through our Application tier?
For the first test, lets go to our instances in the EC2 services page. Select one of our web tier EC2’s and open up the public IPv4 address in a new browser tab.
For the second test, let’s connect to that same EC2 through the terminal, and then ssh into the Application Tier from there.
We can do this by opening up that EC2, selecting “Connect”, and then choosing the “SSH client” option. The directions are there, you can just copy and paste.
Note: If you have not yet configured your private key you will want to do that first. The directions are in there as well.
First part looks good! Now, lets connect to the Application tier from there by opening up one of those EC2’s and following the same steps.
This took a little more effort for me, because I needed to configure my private key to the private instance. BUT...
We did it!
Finally, and for the last test…lets connect to the Database tier from our Application Tier…
To do this, we will need our database end point, the administrator’s username and password, and we will have to install MariaDB.
- The database endpoint can be found in your database under — “Connectivity & security”. It will be an AWS link.
- The admin name can be found under — “Configuration” and “Availability”. You will also need the password you set for this.
- Install MariaDB — The command for this is:
sudo yum install mariadb
Once this is installed you can run another command with the information you gathered…
mysql -h "Your endpoint here" -P 3306 -u "Your username here" -p
When you have submitted this command, you will be prompted for your password, and should all your information be accurate you should see something like this:
If you see this screen that means you have connected to the Database tier, from the Application tier, from the Presentation tier.
And that is how to make an AWS 3-Tier Architecture — now go out for a three course meal!
Make sure you terminate, delete, or stop any services you do not plan to use!