Building for the Cloud: Why Architecture Matters?
When crafting a cloud-based application, the foundation you build upon — its architecture — is just as crucial as the application itself. Choosing the right architecture involves several key considerations:
Scalability on Demand: Can your app seamlessly scale up or down based on user traffic? How important is it to avoid constant resource management and monitoring?
Always Available: Does your app require near- constant uptime? Can it tolerate extended periods of downtime? If a component fails, how resilient is the rest of the system?
Fortress of Security: How robust are your app’s security measures? How does it handle access control for different functionalities? If a breach occurs in one area, can the rest of the application be compromised?
AWS 3-Tier Architecture
Why 3-tier? The 3-tier architecture provides a robust foundation for cloud applications. By separating functionalities into distinct presentation, application, and data tiers, it fosters exceptional scalability, high availability, and enhanced security. This modular design allows for independent resource scaling within each tier, ensuring seamless performance even during peak loads.
Presentation Tier: This tier handles user interaction. It delivers the user interface (UI) and captures user input. Web servers, static content delivery networks (CDNs), and API gateways are common components.
Application Tier: This tier handles the application logic. It processes user requests, interacts with the data tier, and generates responses. Application servers, container orchestration services, and serverless functions reside here.
Data Tier: This tier stores and manages application data. Relational databases, NoSQL databases, and object storage solutions like Amazon S3 belong to this tier.
**Underlying Network Architecture
Setting up Foundational layer: VPC**
Imagine you’re renting an apartment in a giant building (public cloud). A VPC is like your own private floor within that building. You control who has access (security group) and how things are arranged (subnets). This private floor ensures your belongings (app data) are separate from other tenants (other cloud users). It’s a secure space to build your application (3-tier architecture) without worrying about neighbors.
**AWS 3-tier Architecture: VPC
Creating VPC for our project, “cloud-fortress”**
We’re creating a VPC, naming our project “cloud-fortress” with a CIDR block of 10.0.0.0/16.
To increase the availability of the project “cloud-fortress”, we’re using two AZs (us-east-1a and us-east-1b), two public subnets, and four private subnets.
Quick Lookup to visualize the resources about to be allocated.
Basic Manual Configurations
Enable auto-assign IPv4
Once all the resources have been created, we need to make sure we ‘Enable auto-assign public IPv4 address’ for BOTH public subnets so we can access its resources via the Internet.
Change the Main Route Table
When a VPC is created, it comes with a default route table as its ‘main table.’ But, we want our public route table to serve as the main table, so select the “cloud- fortress-rtb-public” from the Route tables dashboard and set it as the main table under the ‘Actions’ dropdown menu as shown in the image.
Deploying a NAT Gateway
Short Overview of NAT Gateway
NAT gateway acts as a security checkpoint. It allows resources within a private network (lacking public IP addresses) to reach the internet for essential tasks like software updates or data downloads. However, the NAT gateway functions like a one- way street. It blocks incoming internet connections, safeguarding private resources from unauthorized access. This creates a secure environment
for your network while enabling necessary communication with the outside world.
Now, Let’s create a NAT Gateway, Navigate to ‘NAT Gateways’ and create a new gateway called nat-public. Select one of the public subnets, allocate an elastic IP, and create the gateway.
Setting up NAT Gateway
Setting one Private Route Table
Select any one of the private route tables and adjust the name to something like ‘cloud- fortress-private.’ This will be our private route table.
Editing Subnet Associations
Now we can associate the updated table ”cloud- fortress-private” with all four private subnets (- subnet-private1, -subnet- private2, -subnet-private-3, — subnet-private4)
Adding NAT Gateway
Edit the routes, Add a new route with Target set to NAT Gateway and select the nat-public for the dropdown menu.
AWS 3-tier Architecture: Web Tier
Tier 1, The Presentation Tier
The Web Tier, also known as the ‘Presentation’ tier, is the environment where our application will be delivered for users to interact with. For Cloud fortress, this is where we will launch our web servers that will host the frontend of our application.
Setting up Launch Template
Now Let’s create a launch template that will be used by our ASG to dynamically launch EC2 instances in our public subnets.
In the EC2 console, navigate to ‘Launch templates’ under the ‘Instances’ sidebar menu.
We’re going to create a new template called ‘cloud-fortress- template’ with the following provisions:
AMI: Amazon 2 Linux
Instance type: t2.micro (1GB — Free Tier)
A new or existing key pair
Create a new security group with inbound SSH, HTTP, and HTTPS rules. Make sure the proper cloud-fortress-vpc VPC is selected.
Under the Advanced details, on User data section we need to paste in our script that installs an Apache web server and a basic HTML web page.
#!/bin/bash
#Update all yum package repositories
yum update -y
#Install Apache Web Server
yum install -y httpd.x86_64
#Start and Enable Apache Web Serversystem
ctl start httpd.servicesystemctl enable httpd.service
#Adds our custom webpage html code to "index.html" file.
sudo echo "<h1>Welcome to My Website</h1>" > /var/www/html/index.html
Creating an Auto Scaling Group
To ensure high availability for our Cloud Fortress app and limit single points of failure, we will create an ASG that will dynamically provision EC2 instances, as needed, across multiple AZs in our public subnets.
Navigate to the ASG console from the sidebar menu and create a new group. Use the cloud-fortress- template launch template that we have created in the previous step.
Next, we will set up a load balancer that will be responsible for evenly distributing incoming traffic to our EC2 instances in the Web Tier, thereby enhancing availability.
Select “Attach to a new load balancer”, then select “Application Load Balancer”. Name your load balancer, then select “Internet- facing”.
The ALB needs to ‘listen’ over HTTP on port 80 and a target group that routes to our EC2 instances.
In the “Listeners and routing” section, choose the option “Create a target group” and then select our newly created load balancer as shown in the image.
We’ll also add a dynamic scaling policy that tells the ASG when to scale up or down EC2 instances. For this build, we’ll monitor the CPU usage and create more instances when the usage is above 50% (feel free to use whatever metric is appropriate for your application).
We want to set a minimum and maximum number of instances the ASG can provision:
Desired capacity: 2
Minimum capacity: 2
Maximum capacity: 5
Review the ASG settings and create the group!
Once the ASG is fully initialized, we can go to our EC2 dashboard and see that two EC2 instances have been deployed.
To see if our ALB is properly routing traffic, let’s go to its public DNS. We should be able to access the website we implemented when creating our EC2 launch template.
AWS 3-tier Architecture: Application Tier
Tier 2, The Application Tier
The Application Tier is essentially where the heart of our Cloud Fortress app lives. This is where the source code and core operations send / retrieve data to / from the Web and Database tiers.
Creating Application Server Launch Template
This template will define what kind of EC2 instances our backend services will use, so let’s create a new template called, ‘cloud-appServer-template.’ We will use the same settings as the cloud-fortress-template (Amazon 2 Linux, t2.micro-1GB, same key pair).
Our security group settings are where things will differ. Remember, this is a private subnet, where all of our application source code will live. We need to take precautions so it cannot be accessible from the outside. We want to allow ICMP–IPv4 from the cloud-fortress-sg, which allows us to ping the application server from our web server.
The application servers will eventually need to access the database, so we need to make sure the mySQL package is installed on each instance. In the ‘User data’ field under ‘Advanced details,’ paste in this script:
#!/bin/bash
sudo yum install mysql -y
Creating Auto Scaling Group
Similar to the Web Tier, we’ll create an ASG from the cloud-appServer- template called, ‘cloud-appServer- asg.’
Make sure to select the cloud-fortress- vpc and the 2 private subnets (subnet- private1 and subnet-private2) as shown in the image down.
Now we’ll create another ALB that routes traffic from the Web Tier to the Application Tier. We’ll name it ‘cloud-appServer-alb.’
This time, we want the ALB to be ‘Internal,’ since we’re routing traffic from our Web Tier, not the Internet.
We’ll also create another target group that will target our appServer EC2 instances.
Confirm connectivity from the Web Tier
Our application servers are up and running. Let’s verify connectivity by pinging the application server from one of the web servers.
SSH into the web server EC2 and ping the private IP address of one of the app server EC2s.
If successful, you should get a repeating response like in the Image.
AWS 3-tier Architecture: Database Tier
3rd Tier, Database Tier
The database tier, also known as the data tier or data access tier, is the foundation of a 3-tier architecture responsible for storing, managing, and retrieving application data.
Creating a Database Security group
Our application servers need a way to access the database, so let’s first create a security group that allows inbound traffic from the application servers.
Create a new security group called, ‘cloud-fortress-db-sg.’ Make sure the cloud-fortress vpc is selected.
Now, we need to add inbound AND outbound rules that allow MySQL requests to and from the application servers on port 3306.
We’ll need to do the same for the cloud-fortress-appserver-sg.
Creating a DB subnet group
In the RDS console, under the ‘Subnet groups’ sidebar menu, create a new subnet group called, ‘cloud-fortress- db-subnetgroup.’ Make sure the cloud-fortress-vpc is selected.
Select our two AZs (us-east-1 and us- east-2) and our private subnets (subnet-private3 and subnet- private).
Unfortunately, the selection dropdown, doesn’t provide the subnet names, so we might have to navigate back to our main Subnets dashboard to get the right ids.
Creating a RDS Database
Under the RDS console and the ‘Databases’ sidebar menu, create a new database with a MySQL engine.
Choose the Free Tier Template
Name this database, ‘cloud-fortress- db,’ and create a master username and password (we’ll use this to log into our DB from the command line, so keep this info handy).
For ‘Instance configuration,’ we’ll use a db.t2.micro and leave the defaults for ‘Storage.’
For ‘Connectivity,’ we do not want to connect an EC2 instance but make sure the Cloud-fortress-vpc is selected.
Select the DB subnet group we created earlier. We also do not want to enable ‘Public access.’
Choose our cloud-fortress-db-sg security group and select us-east-1a as the preferred AZ.
Under ‘Additional configuration,’ provide the name of the database you want to create right on the initial setup (without dashes).
Leave the defaults for everything else and create the database (this may take a few minutes to fully provision).
Final Test, Checking Conectivity
Check appServer Connectivity
Connect to one of the web server and check if it can connect with app server with command, ping privateIPv4 Address. If it is working like in the image then You’re Done!
Thank you for reading until the end. Before you go:
Please consider following!
Follow me on LinkedIn.