The Power of Layers: Our Three-Tier Architecture in AWS.

The Power of Layers: Our Three-Tier Architecture in AWS.

A typical architectural pattern in software development is the three-tier architecture, often known as the three-layer architecture. It separates an application into three distinct levels, each with its own set of duties and capabilities.

In general, a three-tier architecture offers an organized and modular method of developing systems, providing advantages such as increased scalability, maintainability, flexibility, and security. Three tier consists of :

  1. Presentation Tier (Front-end): The presentation tier is responsible for the user interface and handling user interactions. It typically consists of web servers that serve static content and handle client-side logic.

  2. Application Tier (Middle-tier): The application tier, contains the business logic and application processing components. This tier handles requests received from the presentation tier and performs computations or interacts with data sources as required.

  3. Data Tier (Back-end): The data tier is responsible for storing and managing data. It includes relational and non-relational databases, as well as caching mechanisms.

Simple Architecture

Note: The RDS instance is created in multi-az standby so we have RDS standby. It may not be available in the free tier.

Prerequisite

Knowledge about VPC and its components will do good. It is a walk-through tutorial where I will also be discussing the services and components we will use. But it is preferred to have knowledge about CIDR blocks.

STEP 1: Create VPC

Amazon Virtual Private Cloud (Amazon VPC) is a service provided by Amazon Web Services (AWS) that enables you to create a private virtual network within the AWS cloud. It allows you to define and control a logically isolated section of the AWS cloud where you can launch AWS resources.

Goto AWS Management console -> Services -> VPC -> Create VPC

  • The configuration page for VPC will be displayed. There are two ways to configure VPC.

    • VPC only: Where you have to configure all the subnets and gateways individually.

    • VPC and more: Where you have one configuration page and resource map to show all check all the subnets and gateways at once.

  • IPv4 CIDR block: This is the IP address of your VPC.

  • IPv6 CIDR Block: Currently we will not be using IPv6 in our case.

  • Tenancy: keep it default so you won't be paying a huge amount to AWS.

  • The number of Availability zones: It is the number in which our subnets will be spread for high availability and fault tolerance.

  • Customize AZs: Specify where you want your two of the AZ to be.

  • A number of public and private subnets: Specify the number of public and private subnets. We will be having 6 subnets in total.

    2 -> Public subnet (For our web/presentation tier)

    2-> Private subnet (For our application tier)

    2-> Private subnet (For our database tier)

  • Customize Subnet's CIDR block: The IP address range for each subnet can be configured by yourself or let AWS choose it for you. ( If you want a specific number of addresses in each subnet, you have to calculate and assign the required subnet)

  • NAT Gateway: A NAT (Network Address Translation) Gateway is a managed service provided by Amazon Web Services (AWS) that allows resources within a private subnet in an Amazon Virtual Private Cloud (VPC) to communicate with the internet while keeping them protected from direct inbound traffic. Choose how many of them you want, whether in 1 AZ or 1 per AZ. (check before using if it is free in the free tier or not)

  • VPC Endpoints: Choose No.

  • DNS options:

    Both of these should be checkmarked. It allows you to help DNS Hostname and resolve that into the instance IP of the EC2 you create inside of that VPC.

    Enable DNS hostnames

    Enable DNS resolution

  • Click on View VPC.

  • Click on subnets -> Choose public subnet -> Actions -> Edit subnet settings -> Enable Auto-assign public IPv4 address.

  • Click on Route tables -> choose public table -> routes

    Destination

    Target

    Status

    0.0.0.0/0

    igw-05af66a93e03570c6

    Active

    10.0.0.0/16

    local

    Active

    By using the IP address range 0.0.0.0/0 and attaching the internet gateway to the public subnet, you have set up your network to allow all incoming and outgoing connections with the internet.

  • Similarly, you can check the route table for private ones and you will find the NAT gateway attached to the private table. Since this method created four different private route tables, you can create only one private route table to include all the subnets and routes with the NAT gateway or two separate route table for application and data tier respectively.

  • Click on Route tables -> choose public table -> subnet association

    You will see the two public subnets associated with that table. Similarly, for other private tables, you will see each of the private subnets associated with each of the private tables.

You will have auto-configured Network Access Control lists. Network Access Control Lists (NACLs) are an AWS service that acts as a virtual firewall for controlling inbound and outbound traffic at the subnet level. Since it is at the subnet level, it has been created already during the configuration of subnets and VPC. We have to provide firewall security at the instance level too.

STEP 2: Configure Security Groups

Security groups are created at the instance level to provide a great level of virtual firewall security to our instances residing in the subnets. Let's configure security for three different tiers.

  • Presentation Tier (Front-end): The presentation tier is responsible for the user interface and handling user interactions.

    Click on VPC service -> Security groups -> Create

    Basic details:

    • Security group name: Name your security group so it will be easy to identify later on.

    • Description: Write something like what you are allowing in this security group.

    • VPC: Choose the VPC you have created.

    • Inbound rules:

      • Type -> The protocol to open to network traffic.

      • Protocol -> The type of protocol, for example, TCP or UDP.

      • Port range -> Port or Port range to allow.

      • Source -> Custom or your IP or from anywhere.

      • Description -> Provide an additional description.

We will be allowing SSH and HTTP traffic from anywhere on the internet to our web tier.

Similarly, I have created a security group for the Application tier where SSH will be only possible through the web tier. So in the place of Source, you have to choose custom and in place of IP range, choose the web tier security group.

Finally, we have created two security groups. But wait will you be able to SSH in the application tier now?

NO!

It's because we haven't set ALl ICMP- IPv4 on our application tier security group. Without this, you won't be able to SSH from the web tier instance.

Now let's create an EC2 instance in each subnet and check if the configuration till now is working or not. But wait, we are creating a highly available, scalable and fault-tolerant system then why are we planning to create an EC2 instance directly? Instead, why not use the Auto scaling groups and Elastic Load Balancer?

STEP 3: Create a Launch template

In AWS, both Launch Templates and Launch Configurations are used to define the configuration settings for launching instances in Amazon EC2. We would be using the launch template because it has some advantages over the Launch configuration.

Go to services -> EC2 -> Launch template -> Create Launch template

Configure launch template for web tier:

  • Launch template name: Provide an identifiable name such as web-tier-LT.

  • Template version description: Describe your launch template.

  • Check mark the guidance if you need it.

  • AMI Image: Choose Amazon Linux for this tutorial.

  • Instance type: Choose t2.micro as it is free.

  • Key pair: Generate a key pair so we can SSH later on.

  • Network settings:

    • For the subnet, Choose Don't include in the launch template.

    • Firewall: Select the existing security group. Choose the security group that we have created for the web tier.

    • Leave others as default.

  • Advanced settings: Since we are just testing, we will run the Apache server and our small HTML template. In the advanced settings, at last, you will find user data.

    Include this in the user data.

      #!/bin/bash
      # Use this for your user data (script from top to bottom)
      # install httpd (Linux 2 version)
      yum update -y
      yum install -y httpd
      systemctl start httpd
      systemctl enable httpd
      echo "<h1>Hello World </h1>" > /var/www/html/index.html
    

Similarly, create the Launch template for the Application tier too. Just you have to generate new key pair and change the security group. Others are similar.

STEP 4: Create Auto scaling groups

Auto Scaling groups in AWS are a feature that allows you to automatically adjust the number of instances in a group based on predefined scaling policies. It helps you maintain application availability, handle varying workloads, and optimize resource utilization.

Goto Services -> EC2 -> Auto Scaling groups -> Create Auto Scaling groups

Configuration:

  • Name: Provide a name such as web-tier-ASG for the web tier.

  • Launch template: Choose the launch template you have created before.

  • Network:

    • Choose your VPC.

    • For the availability and subnets, select the two public subnets of the web-tier.

For now, leave the other as default and click on next. We will attach an Elastic load balancer later on, but for now, you can choose to go without ELB.

  1. Desired Capacity: The desired capacity is the initial number of instances that you want the Auto Scaling group to launch when you create it. This value can be changed later if necessary.

  2. Minimum Capacity: The minimum capacity is the minimum number of instances that the Auto Scaling group can have at any given time. This is a safeguard against having too few instances to handle the incoming traffic or workload.

  3. Maximum Capacity: The maximum capacity is the maximum number of instances that the Auto Scaling group can have at any given time. This is a safeguard against having too many instances, which can lead to unnecessary costs.

Finally, the auto-scaling group for the web tier is created. Similarly, for the application tier too, you should create one.

Wait for a few seconds and you will see the instances running in the EC2. Give a name to each of them so it will be easy to identify. But which one is for the web tier and which one is for the application tier? Well, the one with the public IPv4 DNS is for the web tier and the other is for the application tier.

Take the Public IPv4 address of the web tier instance, and check on your browser. You will see the HTML content of your user data.

We will also check from the CLI whether the instances are running and security groups are running well.

Goto EC2 -> Click web instance -> Click on Connect -> EC2 Instance Connect -> Connect

  • curl your_web_public_IPv4_addres ( This will show your HTML content provided in user data)

  • ping private_IPv4_address_your_appicationtier_instance (This will show your connectivity with private subnet from your public subnet )

STEP 5: Configure Database

The data tier is responsible for storing and managing data. It includes relational and non-relational databases, as well as caching mechanisms. We will be using Amazon RDS (Relational Database Service) which is a managed service that supports various database engines like MySQL, PostgreSQL, Oracle, and others. We will be using MySQL as a database engine.

Goto services -> Amazon RDS -> Create Database

Configuration:

  • Choose a database creation method: We will choose a standard so we can configure everything ourselves.

  • Engine options: Choose MySQL

  • Templates: Choose a free tier to save some money.

  • DB cluster identifier: Enter a name for your DB cluster. The name must be unique across all DB clusters owned by your AWS account in the current AWS Region.

  • Master username: Type a login ID for the master user of your DB cluster.

  • Master password: Password for your master username.

  • Don't connect to an EC2 Compute resource.

  • VPC: Choose the created one.

  • DB subnet group: The DB subnet group defines which subnets and IP ranges the DB instance can use in the VPC that you selected.

  • Public access: Select No to block public access to your database.

  • VPC security group: Create a new security group since we don't have any for the database tier (we will edit it later).

  • Keep other as default and create.

Finally, you have created the database for the database tier.

Note:

  • Edit application tier security group and add Type as Mysql/Aurora and allow custom and in IP select the security group of the data tier.

  • Edit the data tier security group and add Type All TCP and allow custom IP as the security group of the application tier.

Testing Connection

I have copied by public instance pem key in appkey file and the private instance key in the key file.

chmod 400 appkey

ssh -i appkey ec2-user@private_ip_of_applicationtier

You will be now using the application tier instance. Check the private IP of the EC2-user that has changed in the terminal.

Now will install MySQL in the application tier.

Sometimes you have no idea what error might occur. This installation of MySQL only took more than an hour for me. LOL :(

To install the MySQL command-line client on Amazon Linux 2, run the following command:

sudo yum install mariadb

For more information :

https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ConnectToInstance.html

Visit this aws documentation and cover that within a second.

After installation of MySQL, access MySQL of data-tier from your application tier.

mysql -h database_endpoint -P port_no_of_db -u master_username -p

The database endpoint can be found in the database portion. The code will ask for a password. Enter the password and you will have access to the MySQL database.

This tutorial doesn't end here.

We will be pointing our custom domain name to the IP of the public instance.

Create A record pointing to the IPv4 address of the web instance.

Note: You should have hosted the domain name on Route 53. If you don't have one proceed to the next section directly.

Wait for some minutes and you will see the custom domain name pointing to your instance.

STEP 6: Adding Elastic Load Balancer

An elastic load balancer is a component in a network infrastructure that distributes incoming network traffic across multiple servers or resources. In AWS, there are different types of load balancers available. For our 3-tier application, an Application load balancer will be our choice.

Goto Services -> EC2 -> Auto scaling groups

Since we have already created our Auto scaling groups, we will be attaching our load balancers to them directly.

Goto Auto Scaling groups -> choose web auto-scaling groups -> Scroll and you will see load balancers -> Edit

Choose Application, Network or Gateway Load Balancer target groups and add a new load balancer.

For the web tier- we will be creating an internet-facing load balancer.

For listeners, Choose HTTP port 80 and Create new target groups.

Click update.

Similarly, we can create a load balancer for the application tier and attach it to the auto-scaling groups but for the application tier, we will be creating an internal load balancer scheme.

STEP 7: Routing through a custom domain

Finally, we are here. We will be allowing the traffic through the load balancer using our custom domain name.

Goto Route53 and create a new record with an alias.

  • Record name: I have used my subdomain.

  • Record type: Keep A record.

  • Route traffic to Choose Application/ Classic load balancer

  • Region: Choose the region where you have created the load balancer.

  • Choose load balancer

  • Create records

Wait for a few minutes and you will see the magic.

Congratulations! We have successfully implemented the 3-tier architecture in the AWS cloud which is highly available and scalable, fault tolerant, and secure.