3 Tier Web Application
A 3-tier AWS architecture typically consists of three main layers, each serving a specific function:
Presentation Layer (Web Tier): This is the front-end layer, often consisting of web servers or services that interact directly with the end users. It is responsible for presenting the user interface and handling client-side interactions.
Application Layer (Logic Tier): This middle layer hosts the application's business logic. It processes user requests, executes specific business rules, and makes decisions. This layer often communicates with both the front-end and the backend (database) layers.
Data Layer (Database Tier): The third and bottom layer is where data is stored and managed. It includes databases and data storage systems. This layer ensures data integrity and security.
Each layer is typically isolated from the others, promoting security and scalability. The architecture is designed to be highly available and scalable, allowing each tier to scale independently as needed. AWS provides various services and tools to manage, monitor, and scale each layer effectively.
Technologies used:
Overview of the architecture
A VPC.
Two (2) public subnets spread across two availability zones (Web Tier).
Two (2) private subnets spread across two availability zones (Application Tier).
Two (2) private subnets spread across two availability zones (Database Tier).
One (1) public route table that connects the public subnets to an internet gateway.
One (1) private route table that will connect the Application Tier private subnets and a NAT gateway.
One (1) bastion host that sits in the public subnet and will provide access to the private subnet.
The first step will be to create a new VPC for the three-tiered application.
Navigate to the VPC console within the AWS management console and create a new VPC.
Select VPC and more
Name the VPC
Ensure CIDR block is set to 10.0.0.0/16
The number of Availability Zones (AZ) will be 2. I will be using us-east-1a and us-east-1b.
Number of public subnets is 2. (Web Tier)
Number of private subnets is 4. (App and Data Tier)
There will be 1 NAT gateway
Take note of the CIDR blocks.
Create the VPC.
Navigate to the VPC Subnets and view the 6 newly created subnets.
Select the 2 public subnets and check the box next to "Enable auto-assign public IPv4 address". This will allow resources to be accessed via the Internet.
There is a default route table that is set as the main when the VPC is created. We need to change the main route table so that the public-rtb serves as the main.
Navigate to the Route Tables dashboard.
Select the public-rtb route table and under "Actions", select "Set main route table".
Tier 1 - Web
This section includes:
Web Server Launch Template - defines the EC2 instances that will be provisioned
Auto Scaling Group (ASG) - dynamically provisions EC2 instances
Application Load Balancer (ALB) - routes incoming traffic to targets
Navigate to the EC2 console and on the left-hand side, select "Launch Templates".
Select "Create launch template"
Name the launch template.
Choose an OS image. I went with Amazon Linux.
Select t2.micro as the Instance type.
Create a new key pair. This will be used to connect to the instances.
For network settings:
Create security group
Name the group
Give description
Select the VPC that was created for this lab
Set Inbound Security Group Rules to allow SSH, HTTP, and HTTPS.
Under Advanced details > User data, we will need to paste a script that will install an Apache web server and a basic HTML page. The script can be found here.
Next, we need to create an auto-scaling group (ASG) for the web app. This will ensure high availability and limit any single points of failure. The ASG will automatically provision instances as needed.
Navigate to the ASG console and create a new group.
Name the ASG group
Select the Launch Template that was just created
Select the VPC for this lab
Select the 2 public AZs and Subnets
An Application Load Balancer (ALB) will need to be created to distribute incoming traffic.
Name the ALB
This will be Internet-facing
Ensure VPC is correct
Ensure AZs and Subnets are correct (public)
Create a target group and name it. The ALB will need to listen over port 80 (HTTP). This will ensure that traffic is routed to the correct EC2 instances.
Configure the group size and scaling.
Desired capacity: 2
Minimum capacity: 2
Maximum capacity: 5
This policy will tell the ASG to scale up or down based on CPU utilization. For this example, once the CPU utilization reaches 50%, the policy will create more instances.
Under EC2 Instances, we can see that 2 resources were created. These are our 2 public instances. Note their public IP addresses.
Now that the web tier is built, let's ensure that the ALB is properly working and routing traffic. Navigate to the ALB in the AWS console and copy the public DNS.
Visit the URL and we should see the Apache Web Server.
Now we need to confirm that we can access the EC2 instances. Pick one of the instances and SSH into it.
For details on how to SSH into an EC2 instance, please see the link below: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/connect-linux-inst-ssh.html
Great news! The web tier is working as it should.
Tier 2 - Application
The application tier is where the logic and source code live. This tier is responsible for the operations of sending data between the web and database tiers.
This section includes:
Application Server Launch Template - defines the EC2 instances that will be provisioned
Auto Scaling Group (ASG) - dynamically provisions EC2 instances
Application Load Balancer (ALB) - routes incoming traffic from the web tier
Bastion Host to securely connect to application servers
Navigate to Launch Templates.
Create a new launch template and name it.
Select an OS Image. I selected Amazon Linux again.
Select t2.micro for the instance type.
Select the same key pair that was created in the previous section.
Network settings:
Create security group
Name the security group
Provide a description
Select the VPC for the three-tiered app
Inbound Security Group Rules: we need to allow all ICMP-IPv4 from the web server security group. This will allow us to ping the app server from the web server.
Under Advanced details > User data, paste the command below. This will ensure that mySQL is installed on each instance that is created. Having mySQL installed will allow these servers to access the database tier.
Next, we need to create an ASG for the application tier.
Navigate to the ASG console and create a new group.
Select the appropriate VPC.
Select 2 private subnets (subnet-private1 and subnet-private2).
Configure a new ALB.
This ALB will be Internal since we are routing traffic coming from the web tier (internal) and not from the internet.
Create a new target group for the application server instances.
Configure the group size and scaling.
Desired capacity: 2
Minimum capacity: 2
Maximum capacity: 5
This policy will tell the ASG to scale up or down based on CPU utilization. For this example, once the CPU utilization reaches 50%, the policy will create more instances.
Navigate to the ASG console. We can see that there are now 2 ASGs (Web tier and App tier).
For organizational purposes, I renamed the EC2 instances.
Select one of the private ec2 instances and make a note of the private IP address.
From within the web app ec2 instance, ping the app server. You should receive a response. If not, revisit the network settings.
Bastion Host
A bastion host is a server on a network specifically designed to provide a secure and monitored entry point to another network, typically an internal network or a demilitarized zone (DMZ).
We do not want any outside/public access directly to the Application Tier. To access the app servers, the bastion host will be located in the Web Tier. This will then be used as our gateway.
Navigate to the EC2 console and launch a new instance.
Select an OS image. I am using Amazon Linux.
Select t2.micro as the Instance type.
Use the same key pair.
Network settings:
Select the three-tier lab VPC
Chose one of the public subnets where this bastion host will be located
Enable Auto-assign public IP
Create security group
Name the security group
Provide a description
Inbound Security Group Rules: Allow SSH from your IP
Edit the inbound rules for the app server security group to allow SSH only from the bastion host.
Connect to the App Server
There are several different methods to access the application server from the bastion host. I am using a Windows device and accessing it via PuTTY. With this method, I utilize SSH Agent Forwarding to pass the private key on my local device.
I have listed some resources below on how to get started.
We've connected successfully from the bastion host to the application server!
Tier 3 - Database
The final tier of the architecture is the Database tier. The Database tier is used by the application tier to read and write to databases. It is also used to store data such as user information, session data, application content, etc.
This section includes:
Database Security Group - allows inbound/outbound mySQL requests from app servers
Database Subnet Group - ensures the database is created in the correct subnet
RDS Database with mySQL
The application servers need a method to access the database. This can be configured through a security group that allows inbound traffic from the app servers.
Navigate to the EC2 console and select Security Groups.
Create a new security group.
Ensure that the three-tier lab VPC is selected.
Inbound rules: Allow MYSQL/Aurora on port 3306 from the App Server security group
Outbound rules: Allow MYSQL/Aurora on port 3306 to the App Server security group
Navigate to the App Server security group and add new rules for the database.
Inbound rules: Allow MYSQL/Aurora on port 3306 from the Database security group
Outbound rules: Allow MYSQL/Aurora on port 3306 to the Database security group
Navigate to the RDS console and select Subnet groups.
Create a new DB subnet group.
Ensure the three-tier lab VPC is selected.
We want to use the remaining 2 subnets for the database.
Select the 2 AZs (us-east-1a and us-east-1b).
Select the 2 remaining subnets.
Create database:
Select Standard create.
Engine options: MySQL
We will use Free tier for this lab. For production or development environments, it is best practice to enable Multi-AZ deployment. This will create a standby/failover database that will serve as a backup if there is any negative impact on the main instance or AZ.
Provide an identifier
Make a note of the Master username and create a Master password
Select db.t2.micro as the Instance configuration
Don't connect to an EC2 compute resource
Select the three-tier lab VPC
Select the DB subnet group that was created earlier
Select "No" under Public access.
Choose the security group for the database
Select us-east-1a as the preferred AZ
Under Additional configuration, name the initial database. All else can remain as default.
Navigate to the Database in the AWS console and find the endpoint name.
From the application server, connect to the database.
We were successfully able to connect!
This brings us to the end of this lab where we successfully created a three-tier application in AWS.
Remember to delete the resources that were created and release any elastic IPs that were used.
Last updated