DEV Community: Shraddha

Three Tier application on AWS.

Shraddha — Thu, 26 Feb 2026 15:40:34 +0000

While we deploy a three tier application,its very important to understand the three tiers or layers in short.I have explained the layers in brief:

Tier 1 — Presentation Layer (Frontend)
Component: Nginx on EC2
Subnet: Public subnet
Port: 80 (HTTP)

Role
Serves static files (HTML, CSS, JS)
Receives user requests
Forwards API calls to backend

Why in public subnet?
Any application has a frontend serving the clients so needs internet access.So that the users connect directly to it.

Tier 2 — Application Layer (Backend)
Component: Node.js app (Express)
Runs on: Same EC2 instance
Port: 3000
Managed by: PM2

Role
Handles business logic
Processes requests
Communicates with database

**
Security**
Not directly exposed to internet.This layer is not exposed to the internet and no traffic is directly allowed as its a secured layer where userdata will reside.The backend is only accessible through Nginx.(webserver)

Tier 3 — Data Layer (Database)
Component: RDS MySQL
Subnet: Private subnet
Public access: Disabled

Role
Stores books, users, reviews

Here we have used RDS(Relational database service) of AWS.Only backend can connect so that its a highly secured application server.

Security benefit
Database not exposed to internet
Reduces attack surface

The deployment of the three tier architecture goes like this:

NETWORK ARCHITECTURE :In this I have used VPC (virtual private cloud)

🔹 1️⃣ VPC
Name: capstone-vpc

CIDR: 10.0.0.0/16
DNS Resolution: ✅ Enabled
DNS Hostnames: ✅ Enabled

🔹 2️⃣ Subnets (2 AZ High Availability)

Public Subnets (Web + Public ALB + NAT)
Name
AZ
CIDR
web-public-a
ap-south-1a
10.0.1.0/24
web-public-b
ap-south-1b
10.0.2.0/24

✅ Enable Auto-assign Public IP on both public subnets

App Private Subnets (Internal ALB + App EC2)
Name
AZ
CIDR
app-private-a
ap-south-1a
10.0.3.0/24
app-private-b
ap-south-1b
10.0.4.0/24
DB Private Subnets (RDS only)
Name
AZ
CIDR
db-private-a
ap-south-1a
10.0.5.0/24
db-private-b
ap-south-1b
10.0.6.0/24

🔹 3️⃣ Internet Gateway
Name: capstone-igw
Attach to capstone-vpc

🔹 4️⃣ NAT Gateway
Create in:

Subnet: web-public-a
Name: capstone-nat
Connectivity: Public
Allocate Elastic IP
Wait until status = Available

🔹 5️⃣ Route Tables
Public Route Table

Name: capstone-public-rt
Route:
0.0.0.0/0 → capstone-igw
Associate:
web-public-a
web-public-b

Private Route Table
Name: capstone-private-rt
Route:
0.0.0.0/0 → capstone-nat
Associate:
app-private-a

app-private-b

db-private-a

db-private-b

✔ Network design is now correct.

✅ PART 2 — SECURITY GROUPS Chain:
Internet → Public ALB → Web EC2 → Internal ALB → App EC2 → RDS

1️⃣ Public ALB SG
Name: capstone-public-alb-sg
Inbound:
HTTP 80 → 0.0.0.0/0

Outbound:
Allow all

2️⃣ Web EC2 SG
Name: capstone-web-ec2-sg
Inbound:
HTTP 80 → Source: capstone-public-alb-sg

SSH 22 → My IP

Outbound:
Allow all

3️⃣ Internal ALB SG
Name: capstone-internal-alb-sg
Inbound:
HTTP 80 → Source: capstone-web-ec2-sg

Outbound:
Allow all

⚠ Not 0.0.0.0/0

4️⃣ App EC2 SG
Name: capstone-app-ec2-sg
Inbound:
Custom TCP 3001 → Source: capstone-internal-alb-sg

SSH 22 → Source: capstone-web-ec2-sg

Outbound:
Allow all

5️⃣ DB SG
Name: capstone-db-sg
Inbound:
MySQL 3306 → Source: capstone-app-ec2-sg

Outbound:
Default

Security design is correct ✅

✅ TASK 3 — RDS (Highly Available)
Engine: MySQL
Multi-AZ: Enabled
Read Replica: Enabled
Public Access: ❌ No
Subnet Group: db-private-a & db-private-b
Security Group: capstone-db-sg
Initial DB Name: databasename

✅ EC2 INSTANCES
AMI: Ubuntu Server 22.04 LTS
Username:
ubuntu

web-ec2
Subnet: web-public-a

Auto Public IP: Enabled

SG: capstone-web-ec2-sg

Key: capstone-key.pem

app-ec2
Subnet: app-private-a

Public IP: Disabled

SG: capstone-app-ec2-sg

✅ INTERNAL TARGET GROUP
Name: capstone-app-tg
Protocol: HTTP
Port: 3001
VPC: capstone-vpc
Target: app-ec2
Health Check:
Path: /

Port: traffic port

✅ INTERNAL ALB
Name: capstone-internal-alb
Scheme: Internal

Subnets:
app-private-a
app-private-b

Security Group:
capstone-internal-alb-sg

Listener:
HTTP 80 → Forward to capstone-app-tg

✅ SSH (UBUNTU)
From local machine:
chmod 400 capstone-key.pem
ssh -i capstone-key.pem ubuntu@
From web to app:
ssh -i capstone-key.pem ubuntu@
(You may use SSH agent forwarding instead — better practice)

✅ BACKEND SETUP (UBUNTU)
On app-ec2:
sudo apt update && sudo apt upgrade -y
sudo apt install git nodejs npm mysql-client -y
sudo npm install -g pm2
Clone:
git clone https://github.com/pravinmishraaws/book-review-app
cd book-review-app
npm install
cd backend
Edit:
nano .env
Add:
DB_HOST=
DB_USER=admin
DB_PASSWORD=Password123!
DB_NAME=databasename
PORT=3001
ALLOWED_ORIGIN=http://
Start:
pm2 start src/server.js --name backend
pm2 startup
pm2 save

✅ FRONTEND SETUP (UBUNTU)
On web-ec2:
sudo apt update
sudo apt install nginx git nodejs npm -y
sudo npm install -g npm
sudo npm install -g pm2
Clone:
git clone https://github.com/application_repo
cd app/frontend
npm install
Create .env:
NEXT_PUBLIC_API_URL=/api
Build:
npm run build
pm2 start npm --name frontend -- start
pm2 save

✅ NGINX CONFIG
Edit:
sudo nano /etc/nginx/sites-available/default
Use your internal ALB DNS:
proxy_pass http://;
Test:
sudo nginx -t
sudo systemctl restart nginx

✅ PUBLIC ALB
Name: capstone-public-alb
Scheme: Internet-facing

Subnets:
web-public-a
web-public-b

Security Group:
capstone-public-alb-sg

Target Group:

capstone-web-tg
Port 80
Target: web-ec2

✅ FINAL TRAFFIC FLOW
User
↓
Public ALB
↓
Web EC2 (Ubuntu + Nginx + Frontend)
↓
Internal ALB
↓
App EC2 (Ubuntu + PM2 Backend 3001)
↓
RDS (Multi-AZ MySQL)

In this designed architecture, we can host the application in three tiers:

Presentation Layer (Frontend)
Application Layer (Backend)
Data Layer (Database)

P.S.This post is a part of DMI Cohort run by Pravin Mishra.

Exploring Jira.

Shraddha — Thu, 05 Feb 2026 06:36:58 +0000

This article explains the workflow processes in DevOps, focusing on managing work items and utilizing various process templates for effective project management.
Managing work items effectively in DevOps is essential for delivering high-quality software on time. Jira acts as your project’s central hub, providing a real-time view of progress, priorities, and blockers. Teams can collaborate directly on work items, update statuses, and link tasks to code, builds, and releases—all in one place.

In a typical Agile Scrum setup, work moves through a few clear stages during every sprint.

Backlog grooming is where the Product Owner collects new requirements, user stories, and bug fixes, then prioritizes them so the most important work comes first.

Next comes sprint planning, where the team picks the stories for the sprint, sets a goal, and estimates how much effort each task will take.

During development and testing, developers build the features while testers verify everything works as expected.

Plan and track work with Scrum processes

You build a project plan by creating a backlog of work items that represent features, requirements, user stories, or other work. Track bugs, tasks, and blocking issues using the Bug, Task, and Impediment work item types. To support portfolio management, create features and epics to roll up PBIs across teams.
**
What is Scrum?**

Scrum is a framework for developing and sustaining complex products. This Guide contains the definition of Scrum. This definition consists of Scrum’s accountabilities, events, artifacts, and the rules that bind them together. Ken Schwaber and Jeff Sutherland developed Scrum; the Scrum Guide is written and provided by them. Together, they stand behind the Scrum Guide.
**
How Work Flows in an Agile Scrum Sprint**

When I started learning Scrum, one of the first things I wanted to understand was how work actually moves inside a sprint. It turns out that each sprint follows a simple but structured flow, and every stage has a clear purpose.

Let’s break it down step by step.

Backlog Grooming (Refinement)

This is where everything begins.

The Product Owner collects:

New requirements
User stories
Bug fixes
Improvements

All these items go into the product backlog.
Then they are prioritized, so the most valuable or urgent work is at the top.

This step ensures the team always knows what matters most.

Sprint Planning

Once the backlog is ready, the team moves into sprint planning.

During this meeting:

The team selects stories from the backlog
Defines the sprint goal
Estimates the effort required for each story

By the end of sprint planning, the team has a clear plan for the sprint.

Development and Testing

This is the main working phase of the sprint.

Developers build the features.
Testers validate the functionality.
The team meets daily in stand-up meetings to:
Share progress
Discuss blockers
Stay aligned

This keeps communication open and helps solve issues quickly.

Sprint Review and Retrospective

At the end of the sprint, the team holds two important meetings.

Sprint Review
The team demonstrates completed work.
Stakeholders give feedback.
The product direction may be adjusted if needed.
Sprint Retrospective
The team reflects on the sprint.

Discusses:

What went well

What could be improved
Decides small actions for the next sprint.
This is how teams continuously improve.
Final Thoughts

A Scrum sprint isn’t just about building features.
It’s a cycle of planning, building, reviewing, and improving.

When each stage is followed properly, the team stays aligned, work becomes predictable, and improvements happen naturally with every sprint.

P.S. This post is part of the DevOps Micro Internship (DMI) Cohort-2 by Pravin Mishra. You can start your DevOps journey by joining this Discord community (https://lnkd.in/dZEzMSUR).

Image credits: https://kodekloud.com

Further readings:
https://scrumguides.org/
https://notes.kodekloud.com/docs/AZ-400/Configure-Activity-Traceability-and-Flow-of-Work/Flow-of-Work-SCRUM/page

My Hands-On Journey with Git, GitHub & Real-World Team Workflows

Shraddha — Fri, 30 Jan 2026 12:37:15 +0000

Learning git was never such fun.Lets simplify the version control journey. Version control is one of those things everyone uses, but not everyone truly understands—especially how it fits into real DevOps workflows.

I spent time working deeply with Git, GitHub, and team-style workflows, and this week honestly changed how I look at source control. Git wasn’t about memorizing commands—it was about understanding why things are done a certain way in real projects.

From “Just Files” to Real Version Control

It all starts by setting up a small project on your local system. At first glance, it was just another folder—but the moment Git was initialized, that folder gained memory.How, use the command as:


`git init`

Every change, every experiment, every rollback suddenly became traceable. That’s when it really hit me:
Git isn’t about commands—it’s about accountability and confidence.

We use the command git status for tracing the changes. We create a new file for example index.html but how will git know its for the versioning or project so we add it by git add index.html command.

Now git knows the file is for git but what about the pals who work with you on the same project so we are making a commit for a understanding with the command git commit -m "Here goes the message"

I also worked with both local and global Git identities, which made me realize how important author attribution is in professional environments, especially when multiple teams and repositories are involved.Here we add our name and email while creating a config so that we all know who has done the commit, you now now where the accountability comes from!

The commands used for setting up are :

`git config --local user.name "username"
    git config --local user.email "user@example.com"
`

Suddenly we want to add a new file to the project so we create it but this time in a different way.Git is like a tree, the master/main is the tree trunk and we have to create a new branch and then merge it as different people are involved and we need to ensure that the main project is not effected.Imagine like its a production environment so slight change in the code can bring the application down.

So we create a new branch that a new file with the command as (lets say its a feature update/contact-page)

`git checkout -b feature/contact-page`

We then have to make the required changes and merge it.We can use the commands as

git checkout master
git merge feature/contact-page

So now we have create a new branch, edited the required and we have merged it with our main.(that is the tree trunk)This is the simplest way to understand git.

But what about enormous code on the internet.Aren't those like roots all over the earth. Imagine you wish to fetch something like some other persons or other organizations repository(used repo in short)so what we do, we use a fork to use the code for own github account.

Github is used as an example here so the enormous pool of code is the github, I can fork any public repo by forking it by simple pressing the button of 'fork'.

Now what, we have cloned it to our own repo.Lets imagine that you are a developer in an xyz organization with a repo where you are required to fork, clone and then update the code.Lets say you are two friends working on two different pages(branches) and would report to a project lead.So you for the particular code would work and make changes as per requirement and then create a pull request.By creating a pull request you are asking your manager to review the code.

But here's where security comes in, we have to set up a secured connection from your local machine to the organizations account.
So we generate PAT, nothing but access tokens that allow you to pass through the authentication grids.

Later we check the connectivity by

ssh -T git@github.com

These are the commands to set a origin URL and upstream URL:

git remote set-url origin 
git remote add upstream

You can verify the origin and upstream by the command as :

git remote -v

Once you have all set for the merging of your code and for your review you can then you can push it by

`git push -u origin nameofthebranch`

You can then create a pull request by going to your fork on GitHub, Click Compare & pull request.Ensure PR target is correct and create a Pull request.This is the general flow or understanding.

P.S. This post is a part of DevOps Micro Internship (DMIByPravinMishra) by

If you’d like to join cohort 3.

Join the Discord community here: https://discord.com/invite/GKUuEaknTG

https://discord.com/invite/GKUuEaknTG

A dive in nginx!

Shraddha — Thu, 22 Jan 2026 13:07:15 +0000

What is a webserver?In simple words it serves the request received from a client using the hardware its hosted on and the software being used.

So processing the request can be done in various ways right? Here comes the roles of different structures,and different types of webservers who have their own way of handling the request.Here are the main players namely apache, nginx,IIS Litespeed Openresty, Caddy etc.

I have elaborated nginx and its working in this blog,and soon will focus on the others as well.

Features:
Asynchronous, Event-Driven Architecture as compared to Process/thread-based
It can server max concurrent connections 10,000.

The Event Loop takes multiple requests without waiting.
Worker Processes prepares/computes and sends it to the client when each is ready.

Master Process

Supervises worker lifecycle
Reloads configuration without downtime
Never blocks on I/O or client handling

Worker Processes

Each runs an independent, single-threaded event loop
Handles connection acceptance, reading, writing, and multiplexing
Scales across CPU cores by running multiple workers.

Here are few use cases which we will cover in later blogs.
Load Balancing
Reverse Proxy
Forward Proxy
Caching

Deep diving further into the nginx architecture, the main configuration file is at the /etc/nginx/nginx.conf

At a glance, an nginx.conf file is divided into four main sections:

Global settings
events block
http block
server block

**1.Global settings**
These settings define user permissions, worker processes,file location, compression, caching, and more.

**2.Events block**
This controls Nginx’s event model and the maximum number of simultaneous connections per worker.

**3.http block**
Contains HTTP directives for logging, timeouts, compression, MIME types, and includes for server blocks.

**4.server block**
Configures how Nginx responds to requests for specific domain names or IP addresses (virtual hosts).

Here are some important configuration files.

/etc/nginx/nginx.conf Main configuration file
/etc/nginx/sites-available/ Store individual server block files
/etc/nginx/sites-enabled/ Symbolic links to enabled sites from sites-available
/etc/nginx/conf.d/ Additional configuration snippets (e.g., SSL, load balancing)
/var/www/... Default web content roots (Debian/Ubuntu)
/usr/share/nginx/html

I will further add the important and intermediate configurations as per the scenario so its easier for understanding.

Documents to refer:
https://nginx.org/en/docs/
https://notes.kodekloud.com

P.S. This post is a part of DevOps Micro Internship by Pravin Mishra.