Create a 3-Tier Architecture via AWS Cloud Formation
We first need to define what is a 3-tier application architecture, is a modular client-server architecture that consists of a presentation tier, an application tier and a data tier.
The application tier, also known as the logic tier or middle tier, is the heart of the application. The information collected in the presentation tier is processed/sometimes against other information in the data tier.
The data tier, sometimes called database tier, data access tier, or back-end, is where the information processed by the application is stored and managed.
Tier vs. Layer
Layers refer to a functional division of the software while tier refers to a functional division of the software that runs on infrastructure separate from the other division.
The benefit of the 3-tier architecture is that because each tier runs on its own infrastructure, each tier can be developed simultaneously by a separate development team and can be updated or scaled as needed without impacting the other tiers.
“Amazon RDS makes it easy to use replication to enhance availability and reliability for production workloads”. Using the Multi-AZ deployment option, which is in use for this project, you can run mission-critical workloads with high availability and built-in automated failover from your primary database to a synchronously replicated secondary database.
Multi-AZ creates a passive standby. Primarily used for disaster recovery.
Read Replicas are used for scaling database queries (reads).
For this project, we are going to create a 3-tier architecture. Don’t worry if you are unfamiliar with this term. I will walk you through it step-by-step. By the end of this project, you’ll be familiar with the term mentioned above. Keep in mind the first tier of our architecture will be the Web tier. This will consist of 2 public subnets in separate availability zones, and an auto-scaling group of EC2 instances launching a webpage with access to the internet. The second tier is the Application tier. This will consist of 2 private subnets, an ASG with EC2 instances that have inbound access from the web tier. The third tier is the Database tier. This will have an RDS database in 2 private subnets with inbound access from the application tier above it.
Prerequisites
· AWS account
· Access to the command line, this project will be done in Windows using (PowerShell).
Step 1
In this step, we will be creating a VPC. This is done by navigating to the AWS console to VPC > Your VPCs > Create VPC.
In this awesome tool, we can create a VPC with subnets and everything else we will need to create the bones of our 3-tier Architecture.
This is done by clicking on VPC and more. Then you can name your VPC and have it auto-generate your name tags and all the resources associated with them.
Scroll down to choose which resources you want to be created with the VPC. I chose 2 availability zones with 2 public subnets and 4 private subnets. For this project, we will have 1 NAT Gateway per availability zone to provide access to private subnets. You will be charged for the NAT Gateways. For the VPC endpoint, I chose “none”. Then click on “Create VPC”. It will take a few minutes before it creates. Please be patient!
It will take a few minutes before it creates the VPC workflow. Please be patient! When it is finished you should see something like the image below.
This will automatically generate 6 Subnets in your subnets 4 private and 2 public. To efficiently proceed to the next step of the project we will need to click on the public subnets we’ve just created and change the settings of “Auto-assign public IPv4 address”. Select the first subnet and click on Actions > Edit subnet settings > Enable auto-assign public IPv4 address and then save the changes. Make sure to do this for both of your public subnets.
Step 2
Now, in this step, we will work on our Web tier. This is done by navigating to EC2 Dashboard > Auto Scaling Groups > Create Auto Scaling group. Make sure to name your Auto Scaling group for the public EC2 instances we will create. Then click on “Create a launch template”.
After launching the template it will direct you to “Create launch template”. In there you will need to name your public launch template, choose the AMI (Quick Start), and instance type. I chose Amazon Linux and t2.micro. Make sure to create your key pair. If you have been reading my posts, you should be familiar with this step. This is the same token when creating an EC2 instance. Then, under Network Settings we will create a security group to allow HTTP and SSH access to our instances in the public subnets.
Now, scroll down and under “Advanced details” to the “User data” textbox we will enter our script bin bash message. This will enable us to install an Apache web server on our instances and provision a webpage with a script.
Click Create launch template. Go back to Auto Scaling Groups and your new launch template will populate as an option. Next, you will choose launch options. Select the VPC you created and select the 2 public subnets.
Click Next, leave this page default, and click next. On the following page which is “Configure group size and scaling policies page” we will input 2 desired instances 2 minimums and 5 maximums.
Then click next to Review and then click Create Auto Scaling group. If we go over to our instances, we should have 2 running in 2 Availability zones.
Awesome! Now we certainly know that our instances are up and running.
Now, we are going to check if the instances created are running with a webpage as desired. This is done by grabbing the IPv4 address and pasting it into your browser.
The image above shows that our instances are working perfectly fine. And thus completes the Web tier of our architecture.
Step 3
Now, in this step, we are going to the Application tier. In this step, we will place EC2 instances via an Auto Scaling group, into 2 private subnets. Please keep in mind that this is not a true application tier as we don’t have any provided code to run on the EC2 instances.
Navigate to Create launch template. This can be done by clicking an Auto Scaling group. We will be utilizing the same AMI and instance type as the previous launch template. Associate a key pair and then we will create a security group. This time since these are private subnets, we will want to only allow access from our web tier security group and to SSH as shown below.
Now, we will be creating another launch template. In ASG choose the new template we’ve just created. Click on next and choose launch options. Please make sure to choose the correct VPC and for the availability zones choose 2 private subnets to launch our instances in.
Use the same options as the web tier ASG and create your auto-scaling group. You will now have 2 Auto Scaling groups.
There you have it. 2 Auto Scaling group were just created.
And 2 instances were created.
Now, we will verify if have access to the private subnets from the public subnets. In this case, we will attempt to ping a private subnet from the command line. We will do this by typing “command SSH” into your command line; in my case, I’m using Windows so I will SSH in my PowerShell the public IPv4 of one of your public instances and SSH into that instance. I already have my key pair attached; you may need to add your key pair when you SSH.
It returned an amount that shows it was successful. I will now see if I can connect to my private instance using the SSH forwarding agent. You can do this by adding “-A” when you SSH into a public instance. SSH into your public IPv4 address using the following command.
SSH -A ec2-user@ec2–10.0.180.133
That worked. If you wish to get more information for the command above, you SSH into the private instance from the public instance by using the private IPv4 address. For me, I don’t need to do that because my first result of the command line tells me that it’s working.
Step 4
This is our third and final tier. In this step, we will add a database to the private subnets. In the AWS console navigate to Amazon RDS. From the dashboard click on “Subnet > groups > Create DB subnet group”. Here, we will create a new subnet group. Please make sure to name and select your VPC.
Now, we are going to create a multi-AZ DB instance to provide higher availability and data redundancy by choosing both availability zones. Please make sure to choose the private subnets you have not used yet that do not have to contain EC2 instances. Then create the group.
Go back to double-check which one you have already used to avoid a mistake.
Now, navigate back to the RDS dashboard and click Create Database. Select Standard create and MySQL.
For the template, I chose the Free tier. Under Settings, keep them default but add a Master password for your admin. Save the password for use later. For Instance, configuration and Storage keep the default. Under Connectivity, select your VPC and the subnet group you just created. For Public access, choose “no” since this is a private database and will only be accessible from inside the VPC. Then click to create a security group.
Now, click “Create Database”. Wait a few moments and then your database will be created. Click on it and scroll to connectivity and security. We will edit our security group to allow inbound access from the application tier. This is done by clicking on your database security group.
This will bring you to Security groups. Here you can edit the inbound rules.
Now to test that our private EC2 instances from the application tier can access the database we will head to the command line! First, you will need to SSH into one of your public subnets and include -A to add an SSH forwarding agent. Then from the public subnet SSH into one of the private subnets with your private IPv4 address.
We are going to install Mariadb to access the MySQL database.
To install MariaDB type the command:
Sudo yum install Mariadb
Now we should be able to access our database from the private instance. Type the following command:
mysql -h database-1.cm4bp7mgz27s.us-east-1.rds.amazonaws.com -P 3306 -u admin -p
The -h is your database endpoint which can be found in the console in your database under Connectivity and security. The -P specifies port 3306. The user, -u, is the admin. You will then be prompted to enter a password, the one you created earlier for admin.
The command above will give us the database tier from application tier access. This should confirm that all 3 ties created are up and running. And that is how you create a 3-tier architecture!
The End….