Blogging

Overview

In the recent, I have got this big obsession with cloud. I have been using cloud since 2019 now, but things have changed now and they look ever so more interesting. Here In this blog, I will try to get you through each and every step of a Three Tier Web Architecture and get you going.

This is a step by step guide, and is a hands-on walk through of a three-tier web architecture in AWS. You can use this link to go to the Hands-On Worksop guide. This is an official guide by Amazon. It will help you understand the networking concepts like VPC, ELB, ILB, Internal Subnet’s, External Subnets along with some AWS core concepts like, EC2, RDS, S3, ELB and the AWS Console. We will follow the guide to create necessary network, security, app, and database components.

Solution Architecture / Cloud Architecture

I am not the best at drawing, so I am using this image from Amazon. This is a simple solution architecture for a 3 Tier Application.

1. VPC: We can see from the diagram that we have got a VPC (Virtual Private Cloud). This means that this is your logically isolated network segment within AWS cloud. You can provision this within your own IP address range.
2. We have got two zones, that are AZ1 and AZ2 zones and we see the three tier architecture in the form of Web-Tier, App-Tier, and Database Tier. The zones will later be useful for High Availability.
3. Web Tier: First let us see what do we have in the Web Tier. Consider it like a front page of a Pizza page written on React.JS. This is a Web Tier. It does not show everything, but only what you want using the special API calls. Out public-facing Amazon EC2 instances servers this all and they are using Ngnix web servers with the star signs in yellow showing that they can auto-deploy when they get disrupted and deleted by any reason. The web tier in this architecture serves a React.js website and forwards API calls to the application tier.
4. FYI: Ngnix is an Open Source Web Server and is used in delivering the web content.
5. If you look a close look we take requests from the Internet Gateway and servers it using an Elastic Load Balancer (ELB) to the Amazon EC2 instances. The load balancer redirects you to EC2 instance between AZ1 and AZ2 depending on the work load.
6. App Tier: This is served on an internal subnet which means that this is a piece of code that should not be available to the outside world. We have this connected to an Internal facing Load Balancer which is ILB. ILB helps to distribute the land between the two EC2 instances on AZ1 and AZ2. This handles the logic of the website, like when you click on Pizza order on the webpage, it sends the request to this layer. This runs on Node.Js.
7. Database Tier: This is the Database Tier. This Tier stores all the website’s data, like the data collected from the Pizza website. We are using Amazon Aurora DB to store all this information and a replica for High Availability. By using HA, Even If one server fails, another one can take over.

Steup

How to use GitHub and Git-bash

The first thing that you would need for this project is the Git Bash.  If Git is not already installed, you’ll need to install it first. You can use this link to install Git: Git-Scm Link

The link will give you the documentation for Git, but most importantly, let us install the Git and see how does the commands look like. First, you need to select if you are looking to install for MacOS, Windows or Linux. This blog is specifically for MacOs. Follow these steps:

1. Install HomeBrew on your M1 Macs: /bin/bash -c “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)”
2. Once you have it installed, you can then install Git using the command: $ brew install git

Now, we are basically installing the Git by using brew. Here is what it will look like:

The above may look a bit different for you. I already had the Git installed, so this just upgraded the Git to the latest version.

Optional

1. You can install the Git-GUI. I will attach the screenshot after the optional.
2. You can install the GitHub Desktop.
3. FYI: The links to everything will be attached to the same link: Git-Scm Link.
4. Sign In to Git Desktop.

Here is what the Git GUI installation would look like:

Cloning the Repository

Once you perform the steps above, clone the repository into your local environment, you can run the command: git clone https://github.com/aws-samples/aws-three-tier-web-architecture-workshop.git

Here is what the structure looks like once you clone the git on your local drive.

S3 Bucket Creation

Next, we need to create a S3 Bucket. What is S3 bucket though? Well, S3 means Simple Storage Service, which is S*S*S. An S3 bucket is a public cloud storage container provided by Amazon Simple Storage Service (Amazon S3). It’s designed for object storage, offering scalability, data availability, security, and performance. You can think of an S3 bucket like a file folder where you can store any amount of data, such as documents, images, videos, etc and manage them. Here are some of the best scenarios to use an S3 bucket:

• Data Lakes: For storing vast amounts of data in its native format for big data analytics.
• Websites: Hosting static websites or as a backend for CloudFront distributions for faster content delivery.
• Mobile Applications: Storing application data, including user-generated content like photos and videos.
• Backup and Restore: Creating backups of databases or systems and restoring them when needed.
• Archive: Archiving data that is infrequently accessed but needs to be retained for long-term storage.
• Enterprise Applications: Storing files and documents that are used across different enterprise applications.
• IoT Devices: Collecting and storing data from IoT devices for analysis and processing.
• Log Storage: Keeping logs that are frequently accessed, reviewed, or have analytics run against them.

These scenarios leverage the benefits of S3’s durability, availability, and security features, making it a versatile choice for various storage needs. 

Follow these steps for creating your AWS S3 Bucket:

• First, Navigate to the S3 service in the AWS console and create a new S3 bucket.

• This is important as next you need to think of a unique name to give to your S3 Bucket. We are creating a demo app for the purpose of this blog, so we write it down as demowebapp-anshul-279.
• Leave the rest of the settings to default. And, make sure to select the region that you intend to run this whole lab in. This bucket is where we will upload our code later. We are using East Virgina for the demonstration purpose of this blog.
• Herr are the snips for how this looks like:

IAM EC2 Instance Role Creation

Next we need to create an IAM EC2 instance role for our S3 Bucket. Before that, what is a IAM and EC2? Well, I am here to explain these concepts to you with short examples:

• What is IAM?
  • Identity and Access Management (IAM) is a framework that ensures only authorized individuals and services have access to the technological resources they need. It’s like having a digital bouncer at the door of your company’s IT club, checking IDs and deciding who gets in and what they’re allowed to do once inside.
  • Example: Imagine your company has a secure file server. With IAM, you can ensure that only the HR department can access employee records, while the marketing team has access to the latest campaign materials.
• What is EC2?
  • Elastic Compute Cloud (EC2) is a service from AWS that offers flexible, scalable computing power in the cloud. Think of it as renting a computer from Amazon to run your applications, with the ability to choose the size, power, and location of your virtual machine.
  • Example: You’re hosting a website that sells handmade crafts. With EC2, you can start with a small server to handle a few daily visitors. But when you’re featured on a popular TV show, you can quickly scale up to a larger server to accommodate the sudden influx of traffic, ensuring your site stays up and running.

Now are concepts about EC2 and IAM are clear, let us create our IAM EC2 Instance role. Follow the steps as below:

• Got to the search bar or look for Option+S combination on your keyboard to Navigate to the IAM dashboard in the AWS console and create an EC2 role. Make sure you select the roles on IAM.

• Now, once you hit the create role option, make sure you select AWS service here as it allows services like EC2, Lambda, etc. There are other services like SAML 2.0 which may be for authentication tokens or so. Our focus here is to get this paired with EC2 instance. Here is what it looks like when you select EC2 instance:

• When setting up permissions, make sure to add these specific AWS managed policies:
  • AmazonSSMManagedInstanceCore and AmazonS3ReadOnlyAccess.
  • Just look them up and pick them out. These policies are key because they let our servers grab our code from S3 storage, and they also let us safely log into our servers using the Systems Manager Session Manager. This is all done through the AWS console, and it’s super secure because we don’t need to use SSH keys.
  • Give your role a name, and then click Create Role.
• Here is what it looks like to add the policies:

Networking and Security

Next we need to setup the VPC networking components. Also, we will add the security groups to add to the layer of protection around the EC2 instances, DB, ELB, etc. We talked about the same during explanation of the solution architecture.

VPC and Subnets

Let us understand first in layman language that what is a VPC and a subnet. Imagine you’re building a private playground. In the world of AWS, this is called a Virtual Private Cloud (VPC). It’s a space in the cloud that’s just for you. You can set up your own rules, decide who gets in, and keep your stuff separate from everyone else’s.

Now, within this playground, you might want to have different areas for different games—like a sandbox, a swing area, and a slide. These are like subnets in your VPC. Each subnet is a separate section where you can place different resources, like your databases or servers.

Simple Example:

Let’s say you have a VPC for your company’s online services. You decide to create two subnets:

• Public Subnet: This is like the front yard of your house. It’s where you put things that need to be seen, like your company’s website server.
• Private Subnet: This is like your house’s backyard, hidden from view. Here, you place sensitive stuff, like the database that stores user information.

Both areas are part of your property (the VPC), but they serve different purposes and have different levels of access.

VPC Creation

First let us create a VPC on your AWS dashboard. Navigate to the VPC dashboard or run a search query (option+S) in the AWS console and navigate to Your VPCs on the left hand side. You will get a better idea from the snip below.

Setting Up Your VPC

First things first, pick the VPC only option. Then, give your VPC a friendly name and decide on a CIDR range that suits you. Here is what the AWS screen looks like for this option:

Remember:

• Keep an eye on the region where you’re setting up shop. Stick to one region to avoid confusion.
• Your CIDR range should be big enough to split into at least 6 subnets later on.

Creating Your Subnets

Now, let’s slice up that VPC:

1. Head over to the Subnets section on the left of your dashboard.
2. Click on Create subnet to get started.

You’ll need six subnets split between two different availability zones—think of them as separate neighborhoods. In each zone, you’ll create three subnets, each one matching a layer of our three-tier architecture. Here is what the actual values looks like on one of the subnets:

Here’s a tip: Give your subnets names that make sense, like Public-Web-Subnet-AZ-1 for public access, Private-App-Subnet-AZ-1 for your apps, and Private-DB-Subnet-AZ-1 for your databases. Here are the list of subnets we created:

• Private-DB-Subnet-AZ-1 on East-1a (IPv4 subnet CIDR block: 10.0.4.0/24)
• Private-DB-Subnet-AZ-2 on East-2a (IPv4 subnet CIDR block: 10.0.5.0/24)
• Private-Web-Subnet-AZ-1 on East-1a (IPv4 subnet CIDR block: 10.0.2.0/24)
• Private-Web-Subnet-AZ-2 on East-2a (IPv4 subnet CIDR block: 10.0.3.0/24)
• Public-Web-Subnet-AZ-1 on East-1a (IPv4 subnet CIDR block: 10.0.0.0/24)
• Public-Web-Subnet-AZ-2 on East-2a (IPv4 subnet CIDR block: 10.0.1.0/24)

Make sure the IPv4 subnet CIDR block range must not overlap with each other. You can refer to what I used on my setup from the snip below:

Internet Connectivity

Next, we need to establish internet connectivity so let us look at different concept like Internet Gateway and NAT gateway. Here’s a simple explanation to Internet Gateways and NAT Gateways for blogs along with setting up both.

Internet Gateway: The Bridge to the Web

• Think of an Internet Gateway as the bridge between your private cloud network (your VPC) and the vast ocean of the internet. It’s like the main door of your house that opens to the street, letting you step out into the world and also allowing guests to come in.

• Example: Imagine you have a bunch of computers (EC2 instances) in your VPC that need to access the internet to download updates or to serve web pages to users. The Internet Gateway is what allows them to do that. It’s like assigning a postal address to your house so that you can receive mail from anywhere in the world.

Let us setup our Internet Gateway:

• As I mentioned, we need to give the public subnets in our VPC internet an access. To do so, we will have to create and attach an Internet Gateway. On the left hand side of the VPC dashboard, select Internet Gateway.

• Select “Create Internet Gateway” and give a name to your Gateway. I gave it three-tier-demo.

Once you have created the Internet gateway, you need to connect it to your VPC. This will connect the bridge between your private cloud network (your VPC) and the vast ocean of the internet. You have a couple options on how to do this, either with the creation success message or the Actions drop down.

Here is what it looks like once the VPC is attached to Internet gateway:

NAT Gateway: The One-Way Mirror

• A NAT Gateway, on the other hand, is like a one-way mirror or a backdoor in a stage theater. It allows your private resources (like servers that don’t have a public IP address) to reach out to the internet – say, to download updates – without exposing them directly to incoming traffic.

• Example: You have a secure room in your house where you keep all your valuable items. You can see out through a one-way window to check the mail, but no one can look in. Similarly, your private servers can send requests out to the internet through the NAT Gateway, but the servers themselves remain hidden from the outside. These gateways help manage traffic and ensure that your AWS resources can communicate with the outside world in a controlled and secure manner. Feel free to use these analogies to make the concepts more relatable to your readers!

Let us setup our Internet Gateway:

• Enable access for app layer instances in private subnets by routing their traffic through a NAT gateway.
• Ensure High Availability and failover support by deploying a NAT gateway in each of the public subnets.
• Head over to the NAT Gateways section. You’ll find it on the left side of your dashboard, just sitting there waiting for you.
• Hit that Create NAT Gateway button with the excitement of a kid in a candy store.
• Here is what it looks like:

Remember that we have two subnets AZ1 and AZ2 so we need to enable NAT for both AZ1 and AZ2 public subnets. Fill in the details and make sure you enable the elastic IP.

Route Tables

Route Tables play a crucial role in directing network traffic between different tiers.  They are like the address books for your network traffic. They contain rules, known as routes, that determine where network traffic should go based on its destination. In AWS, each subnet in your Virtual Private Cloud (VPC) must be associated with a Route Table, which dictates how the traffic flows from that subnet to other subnets or the internet.

Example:

Let’s say you have a VPC with two public subnets and two private subnets. The public subnets host your Web Tier, and the private subnets host your Application and Database Tiers.

1. Public Route Table: Associated with your public subnets, it has a route that allows direct access to the internet via an Internet Gateway. This enables users to access your web application.
   • Destination: 0.0.0.0/0 (represents all IP addresses)
   • Target: Internet Gateway (IGW)
2. Private Route Table: Associated with your private subnets, it restricts direct access to the internet and routes internal traffic between the Application and Database Tiers.
   • Destination: 10.0.0.0/16 (represents the IP range of your VPC)
   • Target: Local (ensures internal traffic stays within the VPC)

In this setup, when a user accesses your web application, the request hits the Web Tier in the public subnet. The Route Table ensures that the request can reach the internet. When the Web Tier needs to communicate with the Application Tier, it uses the Private Route Table, which routes the traffic to the private subnet without exposing it to the outside world.

This separation of routing logic enhances security and allows for better management of traffic flow within your AWS environment. It’s a fundamental aspect of setting up a scalable and secure three-tier architecture on AWS.

Creating Route Tables

• We need to create a Public and a Private Route Table. First, Navigate to Route Tables on the left side of the VPC dashboard and click Create route table.
• We will first create one route table for the web layer public subnets and name it accordingly.

• After creating the route table, need to add routes. You will be redirected to the screen below. You need to look for the Routes tab. Click on the Routes tab and Edit routes.

• Manually add a route that directs traffic from the VPC to the internet gateway. We point it to 0.0.0.0/0 for all traffic destined for IPs outside the VPC CDIR range. We direct it to the internet gateway as a target. Save the changes.

• Next we need to edit the Explicit Subnet Associations (starting with adding the public zones) of the route table by navigating to the route table details again. Select Subnet Associations and click Edit subnet associations.

• As mentioned before, look for the Public Web Layer zones for the assosciations. Select the already existing two web layer public subnets which you created eariler and click Save associations.

• Now we need to repeat the steps for Private App tier in zone AZ1 and AZ2. We will choose them as NAT as they are our private subnets.
• Below is how the setup for AZ1 will look like.

Repeat the same step for AZ2 as well. Make sure you name the Route table to be like “private-route-table-AZ2”, and create a route table. Then you need to edit the route, and make sure it points to the NAT gateway in the AZ2 region. Then make sure you assign this to the associated subnet in AZ2 (Private-Web-Subnet-AZ-2, in my case).

Absolutely, let’s dive into Security Groups with an easy-to-understand example for your blog on a three-tier AWS architecture:

Security Groups in AWS Three-Tier Architecture

Security Groups in AWS act as virtual firewalls that control the inbound and outbound traffic to your resources, such as EC2 instances in our case. They are crucial for maintaining the security of each tier in a three-tier architecture.

Example:

Let’s continue with the three-tier application example from before, which includes a Web Tier, Application Tier, and Database Tier.

1. Web Tier Security Group (web-sg):
   • Purpose: Controls access to the EC2 instances serving the web application.
   • Inbound Rules:
     • Allow HTTP (port 80) and HTTPS (port 443) traffic from anywhere (0.0.0.0/0) so that users can access the web application.
   • Outbound Rules:
     • Allow all outbound traffic to the Application Tier Security Group to communicate with the backend services.
2. Application Tier Security Group (app-sg):
   • Purpose: Regulates traffic to the application servers processing business logic.
   • Inbound Rules:
     • Allow specific traffic (like custom TCP ports) only from the Web Tier Security Group (web-sg) to ensure secure communication between the web and application layers.
   • Outbound Rules:
     • Allow all outbound traffic to the Database Tier Security Group for database queries and transactions.
3. Database Tier Security Group (db-sg):
   • Purpose: Protects the database instances containing sensitive data.
   • Inbound Rules:
     • Allow database-specific traffic (like MySQL on port 3306) only from the Application Tier Security Group (app-sg) to ensure that only the application layer can access the database.
   • Outbound Rules:
     • Typically, outbound rules are set to allow responses back to the Application Tier Security Group.

Simplified Example:

Imagine your application is a secure office building with three departments: Reception (Web Tier), Offices (Application Tier), and Vault (Database Tier).

• Reception (web-sg): Open to the public, but with security checks. Anyone can walk in (HTTP/HTTPS traffic), but they can only proceed to the offices if they have a valid appointment (outbound rules to app-sg).
• Offices (app-sg): Only people from the reception can enter (inbound from web-sg). Employees can send files to the vault (outbound to db-sg).
• Vault (db-sg): Only accessible by office employees (inbound from app-sg). The vault can send requested files back to the offices (outbound to app-sg).

This analogy helps illustrate how Security Groups work to ensure that each tier communicates securely and efficiently, keeping the application secure from unauthorized access. By configuring Security Groups with these rules, you ensure that each tier can only be accessed as intended, providing a robust security posture for your AWS application.

Settings up Security Groups

Remember that the Security groups will tighten the rules around which traffic will be allowed to our Elastic Load Balancers and EC2 instances. To setup Security Groups for our Three Tier AWS application, follow these steps:

• Navigate to Security Groups (Or do a search Option + S on Mac) on the left side of the VPC dashboard, under Security.

Security Group 1 ( Internet facing Load Balancer )

• We have got 6 different security groups to cater for the public access and the others for the private access. Let us first create a Security Group for the Public internet facing load balancer. Click on “Create Security Group,” and then give a Security group name. We are using the official AWS guide, so we will name it same as, “internet-facing-Ib-sg.” For description, we will write it as, “External load balancer security group”
• After typing a name and description, select your VPC.
• Add an inbound rule to allow HTTP type traffic for your IP. We will select the requests for both iPV4 and iPV6 traffic. Here is what the rules for the public access looks like:

Security Group 2 ( Web Tier )

• Now we will create a Second Security Group. This will be public instances in the web tier. We will repeat the steps as before.
• We will give it a name “WebTierSg” and description “SG for the web tier.”
• We can then add an inbound rule that allows HTTP type traffic from your “internet facing load balancer security group” you created in the previous step. For this, you can choose Custom and search for the “internet facing load balancer security group.” This basically comes from the description as we set before.
• This will allow traffic from your public facing load balancer to hit your instances. Then, add an additional rule that will allow HTTP type traffic for your IP. This will allow you to access your instance when we test. Here is a snip of how the rules must look like:

Security Group 3 ( Internal LB )

• If we look at the Solution Architecture, we can see that the third SG will be for our internal load balancer.
• We will repeat the steps again and a new security group. The name will be “internal-lb-sg” and the description will be “SG for the internal load balancer.”
• Then we will add an inbound rule that allows HTTP type traffic from your public instance security group that is the Web Tier group. This will allow traffic from your web tier instances to hit your internal load balancer.
• We need to select Custom and point the first rule to the “SG for the web tier”. Here is what would it look like at your end:

Security Group 4 ( Private instances – App Tier)

• Now as we can see in our solution architecture diagram, we will configure for our private instances that is the App Tier.
• The steps mostly remain the same. We will name it as “PrivatelnstanceSG” and we will keep the description to be “SG for our private app tier sg.”
• Now, we will add the inbound rules to allow TCP traffic on port 4000 from the internal load balancer security group to app tier. We selected this port for out application tier. The concept is simple, this SG will allow the traffic from our internal LB to hit the Port 4000 which is again our application as in the private instance.
• Allow a second route for port 4000 that allows your IP for testing.
• Here is what our rules will look like.

Security Group 5 ( Private instances – DB Layer)

• This is the last SG for our three tier application. This will protect our private database instances.
• The steps are almost the same as we discussed before.
• Create a Security Group with name “DBSG” and the Description to be “SG for our databases “.
• We will then add an inbound rule that will allow traffic from the private instance security group to the MYSQL/Aurora port (3306). Here is what our rules will look like:

Database Deployment

Well, next we need to deploy our DB. Here we will learn more about the Subnet Groups and Multi-AZ Database. Let me explain the concept of each first.

Deploy Database Layer

• The database layer is the part of a three-tier architecture where data is stored and managed. When you deploy a database layer, you’re setting up databases on a server that can be accessed by the other layers of the architecture.
  • Example: Imagine you have a website that sells books. The database layer would be where all the information about the books, such as titles, authors, prices, and stock levels, is stored. When a customer looks up a book on your website, the database layer is queried to retrieve this information.

Subnet Groups

• Subnet groups are collections of subnets that can be used to organize resources in a network. Subnets are segments of a larger network, designed to optimize and improve network performance.
  • Example: Think of a large office building with different departments like Sales, Marketing, and HR. Each department could be assigned its own subnet group within the company’s network, much like having separate rooms in the building. This way, network traffic and resources are managed more efficiently.

Multi-AZ Database

• A Multi-AZ database is a high-availability option that places copies of your database in multiple geographical locations or ‘Availability Zones’. This ensures that if one copy goes down, another can take over, minimizing downtime.
  • Example: It’s like having backup generators in different areas of a town. If the power goes out in one area, a generator from another area can quickly kick in to restore electricity, ensuring that the town’s essential services remain operational.

Setting up Subnet Groups

• For DB we will use the RDS service. You can use Option+S on your MAC to or look for search bar and type in RDS. Here is an action snip for this.

• Now click on Subnet groups on the left hand side. Click Create DB subnet group. Please refer to the snip below.

• Now, you need to give your subnet group a name. This cannot be changed once you name it. Also give in a description, and choose the VPC we created.

• Now we need to Select our Availability zones. In our case we had it in us-east-1a and us-east-1b.
• We also need to select the subnets. FYI: These are the same subnets as we created before for our DB. Refer to VPC>Subnets>Filter for DB. I have attached the snips for both of these steps below.

Database Deployment

Now we have setup subnet groups, the next step is to create a DB. We will choose the Aurora Engine as it is more optimized. Here are the steps:

• Once you are on the RDS dashboard, Navigate to Databases. Next Navigate and Click on the Create database button.

• We’re going to set things up one step at a time. First, select the ‘Standard create’ for the MySQL-Compatible Amazon Aurora database. For the ‘Engine options’, just leave everything else as it is.
• In the Templates section, pick Dev/Test because we’re not using this for real-world operations right now.
• In Settings, choose your own username and password, and write them down. We’ll need them to sign in to our database.
• For Cluster storage configuration, select Aurora standard, and select the DB requirement size as you want. Refer to the snips by the end of these steps.
• Then, in Availability and durability, choose to add an Aurora Replica or reader node in a different area for better reliability.
• For Connectivity, select the VPC we’ve discussed before, pick the subnet group we set up, and make sure public access is turned off.
• Finally, use the security group we designated for the database, confirm that password authentication is the method we’re using, and go ahead and create the database.

I choose server less for this Demo as it would have cost. Below is what the final DB setup looks like with High Availability Zone.

To be continued.