AWS 3 Tier Architecture: Designing Efficient and Scalable Applications

Preview:

• Offering a comprehensive range of tools and services, these resources empower the construction and management of cloud applications. These resources can be harmonized to construct robust, dependable cloud architectures. In the context of this tutorial, your objective is to design and establish a highly available three-tier architecture for your company’s upcoming web application. While this guide is extensive, it ensures a thorough understanding of the process. Bookmark this tutorial for future reference when building the web, application, and data tiers.

Use Case:

• A compact e-commerce venture embraces a 3-tier architecture, advised by its engineering team. The web tier manages content delivery and requests, backed by an Auto Scaling Group for traffic fluctuations. Public subnets facilitate access to EC2 instances. The application tier oversees business logic, transactions, and database interactions. Security is upheld by situating EC2 instances in private subnets, exclusively reachable through the Web Server Security Group. The database tier holds customer data and transactions. This architectural choice enhances scalability, security, and performance, bolstering the platform’s base.

Prerequisites:

• Create AWS account
• Basic Cloud Computing Knowledge
• Create an IAM user with Administrator permissions

Background:

What is a 3-Tier Architecture?

• A 3-Tier Architecture is a software design approach that divides an application into three layers: presentation, application logic, and data storage. This separation enables efficient development, scalability, reliability, and security. The presentation layer handles the user interface, the application logic layer manages functionality, and the data storage layer stores information. Each tier can be scaled independently, enhancing performance, and maintenance is simplified due to the clear separation of roles. This architecture is widely used for creating organized and efficient applications.
• The 3-Tier Architecture offers streamlined development with concurrent teamwork, efficient scaling based on demand, increased resilience through resource distribution, personalized security measures, simplified maintenance procedures, and component reuse for faster development and consistency across various projects.

Let’s start with this project:

Step 1: Creating the VPC and Subnets

1. Log in to your AWS console and navigate to “VPC”.
2. Select “VPC and more” and define a name and IP address range (CIDR) for your VPC. For example 10.0.0.0/16.
3. Using VPC and more we can choose options such as how many availability zones, public subnets name (2), the number of private subnets (4), Internet gateways, and also Nat gateways.
4. We will be able to see a frame that will show us how the connections will be routed to create private and public networks that can be connected through the Internet.

If we click on details we can see how all the Subnets, Nat Gateway, etc are being created…

When all of your VPC resources have finished creating, click “View VPC.”

Now that we have created everything we must go to the configuration of the subnet and enable the “Enable Auto-assign public IPV4 Address” option to do that we follow these steps:

1. Let's go to VPC

2. We select subnets

3. Click on Actions

4. Edit the subnet setting

First step: The Web Tier

In this segment, we will establish the initial tier responsible for our front-end user interface. Our objective is to create an auto-scaling group comprising EC2 instances that will serve as hosts for a custom webpage.

We are going to create an instance that can display a message as a first step to make sure that our Web tier will work correctly and we can test it

1. We select a name for our instance and select an AMI in this case I will be using Amazon Linux the free tier

2. we will use T2.Micro

3. Select a key pair

4. Select a VPC and I will be using the public subnet that is in the east-1a region.

5. Click on Enable auto-assign Public ID

We will create a security group that allows “HTTP SSH and HTTPS” traffic and in the source type we will select from anywhere to allow traffic from anywhere and we can test our instance

Then we will go down to the User data configuration and add a message to our instance, with this script we will install and enable the Apache server that will let us display the message "1Web Tier Testing !!" and then we can click on launch instance

#!/bin/bash

yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>1Web Tier Testing !!</h1>" > /var/www/html/index.html

Now we go to the instance and we take the IP address to run it in our browser and thus verify that the message that we use with the echo command can be displayed without any error.

This happens because we created an instance that had a VPC, we created a subnet in that VPC, then we routed the Subnet with a Nat gateway so that it can have internet connectivity allowing HTTP traffic from anywhere and the last step would be to test it.

Step 2: Create an Autoscaling group:

Given that we have a running EC2 instance and a working website, our next goal is to improve availability and reliability by implementing an autoscaling group.

Within Launch Templates we can create a template with the desired configurations

1. We select a name for our instance that we previously created

2. we will use T2.Micro

3. Select a key pair

4. We will not include a subnet but we will select the previously created security group

5. Click on Enable auto-assign Public ID

We will go to details and we will add the same script as in the last instance but this time we will display another message using the same echo command and click on Create a Launch Template

#!/bin/bash

yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Launch Template instances Web Tier Testing!!</h1>" > /var/www/html/index.html

Now that we will create our launch template we will use it in our autoscaling group so that the instance that is created is with the bases and configurations of our template and in an organized way with the correct configurations the instance will be created at the root of the autoscaling group or it could be said that The instance is born with the configurations of our template that we are using in our scaling group to create the necessary instances, which in this case will only be one

Step 2: we will add our VPC and choose our public Subnets of us-east-1a and us-east-1b

You are now given the option to add a load balancer. A load balancer is a good idea to distribute traffic amongst the instances. Since we haven’t created one yet, we will select “Attach to a new load balancer” and choose “Application Load Balancer” because we use HTTP connections. Give the load balancer a name and select “Internet-facing” for the scheme. This will allow us to communicate on the Internet, not just internally. Under Network mapping, you should see the VPC that you created and the two public subnets in our auto-scaling group. The load balancer needs a listener and target group. We can see HTTP is selected (port 80) and we will create a new target group.

Step 3 Creation de un Load Balancer:

We need to create a load balancer to distribute the traffic correctly this traffic will be distributed with the HTTP type we created a name for our load balancer and this will allow us to communicate with the internet

We will also create a target for our Load Balancer if we do not create a target by copying the DNS of the Load Balancer we will receive an error trying to communicate with the internet through the DNS of our Load Balancer

Enable health checks and choose “Turn on group metrics collection in CloudWatch”. Both configurations are optional. Once you are ready, proceed to the 4th step

In the Group sides, we only need the capacity of one (one instance) the following options would be:

1. Desired capacity 1
2. Minimum capacity 1
3. Maximum Capacity
4. the other options can remain as the default ones that are shown on the screen

This way we make sure that even if the instance is deleted, a new one will be created with the template configurations

In the last step, we can see the details we can click on Next and proceed to create our escalation group

Step 3: Testing instance:

We need to verify that everything has worked correctly so we will go to EC2, then to instances and we will be able to see that a new instance will be created, after a few minutes, we will select the IP address of the instance, we will paste it in the browser, if all the configurations were made correctly we could see the drop-down message that we created in our Template and that is now in our instance if we do not see any message the most common error is that the security group does not have the necessary permissions that should be HTTP

| Step 4: Updating our Route Tables

Step 1: Up to this point in our project, we have successfully set up our web layer. This layer consists of a Virtual Private Cloud (VPC), which includes two public subnets connected to an autoscaling group, a security group, an Internet gateway, and user data that makes it easy to install Apache and create a personalized home page for the company.

Step 2: To finish configuring our web layer, it's important to make sure that the route tables are automatically generated when creating the VPC and that the subnets are associated correctly. To do this, we're going to go back to the VPC dashboard. In the menu located on the left, select the option “Routing tables”.

Step 3: Once in the "Routing Tables" section, locate and select the public routing table assigned to the web layer resources. It then proceeds to review the list of associated subnets. This is where you should find the list of the two public subnets we created for this purpose.

Step 5: Application Tier

We will configure the application layer in our infrastructure, using the same VPC and private subnets from the first phase. We'll create an autoscaling EC2 instance and adjust security to restrict public access.

1. Choose the VPC and a private subnet.
2. Create an EC2 instance and scale group, as in layer 1.
3. Limit public access by adjusting security group permissions.
4. Follow the instructions above to launch the instance and complete the application layer.

We are going to strengthen security at the application layer. We will ensure that only authorized traffic from the web layer can access it. Follow these steps:

1. Enable SSH, HTTP, and ICMP only from the web layer security group.
2. When adding security groups, choose “Custom Source” and select the web layer security group as the source.
3. There is no need to assign a public IP, as this layer will be on a private subnet. This improves safety by avoiding unnecessary exposure.
4. This time we will not assign any script to the user data
5. Launch the instance

We will create a new Autoscaling group with a new template

We will use the same specifications and the AMi that we have released recently, that is:

1. t2.Micro
2. Key pair
3. Enable auto-assign IP
4. select the Web App security group

Step 6: Create an auto-scaling group for our App tier:

1. We will create a name for our auto-scaling group.
2. We click on refresh and select our last created launch template.
3. click on next.

We choose our VPC and select our private subnets in the east-1a and east-1b region and click on Next

We will create another load balancer but this time we will use the Internal option since this time the connection should only be internal and not external as in the other load balancer, we enable the health checks and the monitoring with Cloudwatch

In the Group sides, we only need the capacity of one (one instance) the following options would be:

1. Desired capacity 1
2. Minimum capacity 1
3. Maximum Capacity
4. the other options can remain as the default ones that are shown on the screen
5. We click on Create autoscaling group

This way we make sure that even if the instance is deleted, a new one will be created with the template configurations

Step 7: We need to update the Route tables configuration of the web tier app:

Step 1: Access the VPC control panel and in the menu located on the left side, select “Routing tables”.

Step 2: Click on one of your automatically created private routing tables (mine is called W9webtier-rtb-private1-us-east-1a).

Step 3: Look at the “Subnet Associations”. Make sure this private routing table is associated with two of the private subnets (I've chosen private-1-us-east-1a and private-2-us-east-1b).

Step 8: Creating a Database Tier

In this step, we will use MYSQL RDS as a database and we will create a subnet group, we will assign it a name, also a description and we will select our VPC

Step 1: Access the VPC console and choose "Routing Tables" in the menu on the left.

Step 2 – Select one of the automatically generated private route tables (for example, 1Web Tier-VPC-private1-us-east-1a).

Step 3: In the “Add Subnets” section, you will need to start by selecting the “Availability zones”.

Step 4 – If you don't remember which Availability Zones you used for your third and fourth private subnets, go back to the VPC console.

Step 5: In the left menu, choose Subnets. Then, select the last two private subnets you created (make sure you don't choose the subnets you already used in Layer 2).

Step 6: On the subnets page, you will find information about the Availability Zones that were used.

By following these steps, you can identify the correct Availability Zones to associate with the private routing table.

After having done that we select our availability zones us-east-1a and us-east-1a, then we will select our subnets of that availability zone and click on create

Step 9: Create a MySQL Database.

Now that we have created the subnet group for the database

Step 1: Now that you have created the subnet group for the database, go to the RDS console and click on “Databases” in the menu on the left.

Step 2: Then, select “Create database”.

Step 3: Opt for “Standard creation”.

Step 4: Select “MySQL”.

Let's create a cluster using the free tier template, without setting up multiple Availability Zones or secondary DB instances.

Create a name from the DB instance identifier, create a name for the master username, and create a key

Secure your credentials. Configure the instance (type and storage). Decide on connectivity (EC2 option and IPv4 network). Select the subnet group and prevent public access. Create a new VPC security group. Optionally, consider an RDS Prox

Step 1: Save your credentials Be sure to save the username and password you use. You will need them later to connect to your database.

Step 2: Instance Configuration In the Instance Configuration section, you'll notice that the only option available in the free tier is the “burstable” class, which is already pre-selected by default. If you want, you can change the instance type. In my example, I have chosen db.t2.micro, which is sufficient for a Virtual Private Cloud (VPC). You can also adjust the storage according to your needs, although for this case, I have left the default settings.

Step 3: Connectivity This is where you find various options. In the “Compute resource” section, you can decide if you want to establish a connection to a compute resource (such as an EC2 instance) for this database. This option automatically configures your VPC and network settings to create a secure connection between the EC2 instance and the RDS database. For this example, I have selected “Do not connect to an EC2 compute resource” as I prefer to configure network options manually.

Step 4: Network Type Select “IPv4” as the network type. Then, choose the VPC you've been using in this tutorial.

Step 5: Database subnet group Select the database subnet group (DB subnet group) that you created previously. This is essential to establish the proper network locations.

Step 6: Public access Since this database is for internal company use and should not be publicly available, select “No” in the “Public access” option.

Step 7: VPC Security Group Create a new security group for the VPC. Give the security group a descriptive name and choose a preferred Availability Zone.

Step 8 – Additional Options You will see the option to create an RDS Proxy, which allows for greater scalability, but note that this incurs additional costs. For this example, we will leave this option unchecked.

By following these steps, you will be configuring your DB cluster according to the parameters you have selected. Remember that these are the configuration steps based on your needs and preferences.

For database access, you’ve got three choices. You can also set up enhanced monitoring and make more adjustments. When you’re set, just hit the “Create database” button.

Step 10: SG Data Tiger

By following these steps, you will have adjusted your security rules to allow MySQL traffic from the application layer's security group instead of your IP address, which strengthens security and improves communication between layers.

1. Database group security access:

• We created a new security group for the database layer, but we didn't have the option to adjust the permissions.

Navigate to the VPC console:

1. We created a new security group for the database, but we were unable to adjust the permissions at that time.
2. Go to the VPC console.
3. Select “Security groups” in the left menu.
4. Find the security group you created for the database.
5. Remove the default rule that allows MySQL/Aurora traffic on port 3306 from your IP address.
6. Add a new rule:

• Click on “Add rule”.
• Choose “MySQL/Aurora” as the Type.
• Select “Custom Origin”.
• Choose the application layer security group.
• Press “Save rules” to confirm the changes.

Updating Private Route Tables for Layer 3 We come to the last step of configuring the database layer, and this involves making changes to the route tables that were created automatically. Access the VPC console and look for the “Route tables” option in the menu on the left. Select the private route table you want to link to the private subnets of the database layer. Then, go to the “Subnet associations” tab to check if the associations are correct. If they aren't, you can edit the subnet associations to add the correct subnets and make sure everything is running smoothly.

OMG we finished, we created the three tiers now its time to test everything

Step 11: use SSH client, to prove our connectivity

we should be able to log in using the copied command and answering yes to the prompts shown

Step 13: Web tier 1 check

When we decide to go to the public IPv4 address corresponding to layer 1 and we do it by browsing our system, we find the message that we have created in our template using the echo command:

Tier 1 is working healthily!!!!!

Step 12: Connection Verification: Pinging from Layer 1 to Layer 2

Let's move on to an essential check. This time, we will test the communication between Layers 1 and 2. Since you are already inside the Layer 1 instance, take the opportunity to ping the Layer 2 private IPv4 address and make sure that connectivity is working smoothly.

The test is also successful, demonstrating that Layers 1 and 2 can communicate effectively. This validates the joint functionality of our system and establishes a solid foundation for data transmission and collaboration between the layers. This robust interaction between the layers is a significant step towards overall system functionality and allows us to confidently move into the next stages of development and deployment.

ADVANCED

Application Load Balancers should be used for the Web Tiers with the same Security Group considerations. Example The ALB should allow HTTP traffic from 0.0.0.0/0 and the Web Server Security group should allow traffic only from the ALB. Don’t forget to create Target Groups and enable Health Checks.

Create a name and a description

Select our vpc

In inbound select the next options:

We return to the load balancer and change the security group to the default for the one we just created, then we take the DNS of our load balancer and paste it into our browser, which should show us the message that we wrote in the User code of the Web App

It works!!!!!!! there you have it — after all the hard work and effort, we’ve wrapped up this big three-tier rewrite project. Everything’s up and running, just like we wanted. It’s been quite the journey, but we made it work. If you’ve got any more questions or need help with anything else, just give me a shout. Cheers to us for pulling off this awesome project!