Creating a 3-Tier Architecture in AWS

Introduction

Hello! In this project, I will be going over how to create a 3-tier architecture using various AWS services.

A 3-tier architecture is a popular architecture. A user interacts with a web or mobile app in the web tier and makes a request. The web tier sends the request to the app tier which processes various information. The app tier translates the user actions to code that the database tier would understand before sending it off. The database tier then performs all the necessary actions to satisfy the user’s requests. The database tier sends the response back to the application tier which translates the code response back into understandable language by the user and forwards that response to the web tier which in turn provides it to the user.

Use Case

• An e-commerce company wants a scalable and reliable platform and decides to deploy a 3-tier architecture
• This architecture will be made up of 3 tiers, the Web Tier, Application Tier, and Database Tier
• The Web tier is responsible for receiving incoming traffic requests and serving the content to users. An Auto Scaling Group (ASG) will be used to automatically handle any increases or decreases in traffic by managing the EC2 Instances (servers). These servers will be hosted in Public Subnets to allow access by various users.
• The Application Tier is responsible for handling the business logic of the platform such as processing transactions, handling payments, and interacting with the database. An Autoscaling Group will also be used in this tier. However, the servers will be hosted in Private subnets as direct access needs to be restricted from the internet.
• The Database Tier stores all of the platform’s data such as customer information, product information, product availability, and transaction records. A free-tier MySQL RDS database will be used to allow for easy scaling as the platform grows. Database Instances will be placed in private subnets to prevent direct access from the Internet and only allow incoming traffic from the Application tier. Using the Multi-AZ feature that Amazon RDS provides ensures that the database is highly available.
• Multiple Security Groups are going to be used to achieve the correct access to the various EC2 and DB instances in the various tiers.
• VPC Endpoints and AWS Systems Manager (SSM) will be used to access the instances in the private subnet without needing to SSH. This is a secure method of accessing instances without requiring SSH keys. An EC2 Role will need to be attached to instances in the private subnet to allow this

Without further ado, let’s begin!

Pre-Requisites

1. An AWS Account
2. A Command Line Interface
3. An IAM user with administrative privileges (optional, but preferred). Log into your AWS account with this IAM user

Steps

1. Navigate to the VPC Console and Create a VPC.

• Use the VPC and more tool to create a VPC with the IPv4 CIDR 10.0.0.0/16, select 2 Availability Zones, 2 Public Subnets, 4 Private Subnets, A NAT Gateway in 1 AZ, and no VPC endpoints (This will be created later on), Enable DNS Hostname and DNS Resolution

The Subnets should have the following CIDR blocks:

• Public-Subnet-1: 10.0.1.0/24
• Public Subnet-2: 10.0.2.0/24
• Private Subnet-1: 10.0.3.0/24
• Private Subnet-2: 10.0.4.0/24
• Private-Subnet-3: 10.0.5.0/24
• Private-Subnet-4: 10.0.6.0/24

NOTE: For this project, only one NAT Gateway is going to be created. In a real-world environment, 2 NAT Gateways can be used in both Availability Zones to ensure high availability.

• Go to Security Groups in the VPC Console. Create 3 Security Groups for the 3 different tiers with the following Inbound rules.

NOTE: Make sure to select the VPC that was just created when making these. Also, create them in the order listed below.

WebServerSecurityGroup: Allow SSH, HTTP, and HTTPS traffic from Anywhere (0.0.0.0/0)

AppServerSecurityGroup: Allow All Traffic from the WebServerSecurityGroup, Allow HTTPS traffic from Anywhere (0.0.0.0/0). The second rule is needed to use SSM to access the instance without SSH’ing.

DatabaseSecurityGroup: Allow MySQL traffic from the AppServerSecurityGroup

• Go to Endpoints in the VPC Console. Based on AWS documentation, three endpoints need to be configured to use SSM to connect to instances without SSH.

The three endpoints are:

i. ec2messages.region.amazonaws.com

ii. ssm.region.amazonaws.com

iii. ssmmessages.region.amazonaws.com

• Click on create endpoint, name the endpoint, select AWS services under Service category
• Under services, search for “ec2messages” and select it. This is one of the endpoints needed

• Select the VPC created earlier
• Under Subnets, select the 2 AZs which have the 2 private subnets. Also, select the Subnet IDs of the private subnets created to reflect the subnets that the Application Tier Instances would be hosted in. i.e. In this case, Private-Subnet-1 and Private-Subnet-2
• Select the AppServerSecurityGroup, leave everything else as default and create the endpoints

• Repeat the last 5 steps. However, search for ssm and select the endpoint that ends with .ssm for the second endpoint. Search for ssmmessages and select the endpoint that ends with .ssmmessages for the third (and final) endpoint

2. Navigate to the IAM Console to create a role for SSM that the EC2 Instances can use

• Click on Roles > Create role
• Select EC2 as the Use case
• Search for the “AmazonSSMManagedInstanceCore” policy and select it

• Give the role a name and create it

3. Navigate to the EC2 Console

• Go to Launch templates and select Create launch template

2 different launch templates are going to be created. One is going to be used to launch instances in the web tier and the other is going to be used to launch instances in the app tier. I have an article which explains how to create this.

• Launch the Web Tier Template. Select an AMI, t2.micro as instance type, Create or Select a Key Pair, Select the WebServerSecurityGroup, Open Advanced network configuration and Enable “Auto-assign public IP”. Go to Advanced Details>User Data and paste the following code found here.

• Launch the App Tier Template. Select an AMI, t2.micro as instance type, Do not select a key pair, Select the AppServerSecurityGroup, Go to Advanced Details>IAM instance profile and select the role created earlier

NOTE: Next, we will create the 2 Auto Scaling Groups (ASGs) that will launch and manage instances in both the Web and App Tiers

• Go to Auto Scaling Groups and select Create an Auto Scaling Group

The Web Tier ASG will be created first

• Name the ASG, select the Web Tier launch template. Select the VPC created earlier, Select the two public Subnets, Select No Load Balancer, Choose a Desired Capacity of 2, Minimum Capacity of 2 and Maximum Capacity of 4. Leave everything else as default and launch the ASG

This ensures the ASG will always maintain at least 2 instances and never exceed 4 instances.

Now, create the App Tier ASG

• Name the ASG, select the App Tier launch template. Select the VPC created earlier, Select the two private Subnets for the App Tier (i.e. Private Subnet-1 and Private Subnet-2), Select No Load Balancer, Choose a Desired Capacity of 2, Minimum Capacity of 2 and Maximum Capacity of 4. Leave everything else as default and launch the ASG

Once these Auto Scaling Groups (ASGs) have been created properly, you should see 4 instances in the Instance dashboard

NOTE: I added tags when creating the ASGs. That was just another way of easily identifying which instances belong to my web or app tier.

4. Navigate to the RDS Console

• Select Create Database
• Choose Standard Create, MySQL for Engine Type, and Free Tier under Templates. Enter a password in the Master Password and Confirm Master password fields. Select db.t2.micro as DB instance class, and disable storage autoscaling. Under connectivity, select Don’t connect to an EC2 compute resource, Select the correct VPC needed, Select Create new DB Subnet Group, Select No for Public access, choose the DatabaseSecurityGroup, Select the preferred AZ (This is one of the AZs where Private-Subnet-3 or Private Subnet-4 is located in). Under Database Authentication, select Password Authentication. Create the Database

NOTE: It might take a few minutes for the Database to become available

Tests

We will now perform some testing.

1. Copy the Public IP addresses of the EC2 instances launched with the ASG and paste them in a browser. If successful, a home page with text stated in the user data will be seen

SUCCESS! We can view the home page of the Web Tier Servers

2. SSH into one of your Web Tier Servers (Instances) and attempt to ping both of the Application Tier Servers.

NOTE: You will need to copy both of the Private IP addresses of the App Tier Servers from the EC2 console

Run the following command to ping the App Tier Servers:

ping <Private IP>

To stop the ping command, press CTRL+C

As seen above, both App Tier Servers could be reached from the Web Tier.

3. Verify that without SSH enabled, the App Tier Servers can be accessed using Systems Manager

• Go to the App Tier instances in the EC2 console, click on Connect, and go to Session Manager. Click on the Connect Button

SUCCESS! You can access the App Tier instances without needing to SSH. As seen in the screenshot above, you are initially logged on as the ssm-user

You can also tell if SSM is managing the instances by going into the SSM console and going to Fleet Manager. The two instances in the Web Tier should show up here.

NOTE: I ran into an error here when first completing this as I did not have a rule allowing HTTPS traffic for the DatabaseSecurityGroup as that is needed. Just a reminder to make sure you read AWS documentation properly. This current set-up isn’t the safest as all HTTPS traffic can access the AppServer but it’s alright since we’re just testing it out. A bastion host would be a better solution to access the App Tier instances in the private subnet.

And that is it for this project! Congrats if you made it this far.

REMEMBER TO DELETE ALL RESOURCES CREATED TO CLEAN UP

Please let me know if you have any questions!