DEV Community: Ankit Raj

Building a Complete DevOps Pipeline: From Infrastructure to Deployment

Ankit Raj — Fri, 15 Aug 2025 15:34:16 +0000

Hii

In this blog, I'll walk you through my journey of building a complete DevOps pipeline for a frontend application. This project covers everything from setting up Infrastructure on AWS to automatically deploying applications on Kubernetes using Jenkins.

What this project is about:

~ Infrastructure Provisioning using Terraform
~ Server Configuration with Ansible
~ Containerization with Docker
~ Kubernetes Deployment for orchestration
~ CI/CD Pipeline with Jenkins
~ Automated Deployment with GitHub webhooks

By the end of this project, every time I push code to GitHub, it automatically gets deployed to Kubernetes. Pretty cool, right? 😎

Architecture Overview

Here's how everything flows together in my project:

Code Push to GitHub
↓

GitHub Webhook Triggers Jenkins
↓
Jenkins Pipeline Starts
↓
Build Docker Image
↓
Deploy to Kubernetes
↓
Application Running!

The complete workflow:

1.Infrastructure Setup → Terraform provisions AWS EC2 instances

2.Configuration → Ansible installs and configures all required tools

3.Containerization → Dockerfile containerize the application

4.Kubernetes Deployment → K8s deployment and service files

5.CI/CD Pipeline → Jenkinsfile automates everything

6.Automation → GitHub webhook triggers pipeline on code changes

Let's dive into each step ............

Step 1: Infrastructure Provisioning with Terraform

First things first - I needed servers to work with. Instead of manually creating EC2 instances every time, I used Terraform to automate this process.

Setting up Terraform

I started by launching a single EC2 instance from AWS console and installed Terraform on it. This became my "control center" for managing infrastructure.

# SSH into the EC2 instance and install Terraform

curl -fsSL https://apt.releases.hashicorp.com/gpg | sudo apt-key add -
sudo apt-add-repository "deb [arch=amd64] https://apt.releases.hashicorp.com $(lsb_release -cs) main"
sudo apt-get update && sudo apt-get install terraform

Creating Terraform Configuration Files

Now came the interesting part - writing Terraform code to create infrastructure automatically!!!

1.Variables File

https://github.com/rajankit2295/smart-Frontened-DevOps-Project/blob/main/terraform-files/variable.tf

This file defines all the variables I can customize - like region, instance types, and key pair names. Think of it as a settings file where I can change values without modifying the main code.

What it does:

~ Defines AWS region (I chose us-east-1)
~ Sets instance types for different servers
~ Specifies the SSH key pair for accessing servers

2.Main Configuration File

https://github.com/rajankit2295/smart-Frontened-DevOps-Project/blob/main/terraform-files/main.tf

This is the heart of my infrastructure ..... It creates:

~ VPC with custom networking
~ Security Groups with proper firewall rules
~ Three EC2 instances: Jenkins Master, Jenkins Agent (with Kubernetes), and Ansible Server
~ All networking components like subnets, internet gateways, and route tables

How they work together:

Jenkins Master - Controls the CI/CD pipeline
Jenkins Agent - Runs Kubernetes and deploys applications
Ansible Server - Configures all other servers

3.Outputs File

https://github.com/rajankit2295/smart-Frontened-DevOps-Project/blob/main/terraform-files/outputs.tf

After Terraform creates everything, this file shows me the important information I need - like public IP addresses of all servers. Can be helpful for connecting to them later!

Deploying the Infrastructure

Time to make it all happen! Here are the commands I used:

# Initialize Terraform (it downloads required plugins)
terraform init

# See what Terraform plans to create ... planning dekhooo uski 
terraform plan

# This command wiil help you in actually creating the infrastructure 
terraform apply

After running these commands, I got three new EC2 instances ready to use !!!

Above Image Shows creation of EC2 instances ....!

Step 2: Configuration Management with Ansible

Now I had servers, but they were blank. I needed to install and configure all the required tools. Instead of manually SSH'ing into each server and running commands, I used Ansible to automate this and configure all of them.

# Connect to the Ansible server using its public IP ssh -i your-key.pem ubuntu@ansible-server-ip

Creating Ansible Configuration Files

1.Inventory File

https://github.com/rajankit2295/smart-Frontened-DevOps-Project/blob/main/ansible-files/inventory.ini

What is an inventory file?

Think of it as Ansible's book! It tells Ansible which servers exist and how to connect to them. I listed all my servers here with their IP addresses and connection details.

What's inside:

~Jenkins Master server details
~Jenkins Agent server details
~SSH connection information
~Server groupings for easy management
~My Pem file attached with all of them

2.Playbook File

https://github.com/rajankit2295/smart-Frontened-DevOps-Project/blob/main/ansible-files/playbook.yaml

This is where the magic happens! The playbook is like a recipe that tells Ansible exactly what to install and configure on each server.

What this playbook does:

~ Jenkins Master: Installs Jenkins, Java, Docker, and sets up initial configuration
~ Jenkins Agent: Installs Docker, Kubernetes (k3s), kubectl, and connects to Jenkins Master
~ Creates users and permissions for everything to work smoothly
~ Configures security settings and networking

Why it's awesome:

Instead of manually running 50+ commands on each server, I just run one Ansible command and it configures everything perfectly ....!

Running Ansible Configuration

# Test connection to all servers
ansible all -i inventory.ini -m ping

# Run the playbook to configure everything
ansible-playbook -i inventory.ini playbook.yaml

After this step, all my servers were fully configured and ready for action .............!!

Above Image Describes about the connection - Success or Failure.

Above image showing the configuration where all of the tools are configuiring on Jenkins-Master Server.

Above image showing the configuration where all of the tools are configuiring on Jenkins-Agent Server.

......!!

Step 3: Kubernetes Deployment Files

# Connect to Jenkins Agent server ssh -i your-key.pem ubuntu@jenkins-agent-ip

Creating Kubernetes Configuration Files

1. Deployment File

https://github.com/rajankit2295/smart-Frontened-DevOps-Project/blob/main/k8s/deployment.yaml

What this file does:

~Tells Kubernetes how to run my frontend application
~Defines how many copies (replicas) to run
~Sets up health checks to ensure app is working
~Configures resource limits (CPU and memory)
~Exposes the application on port 80

Some Cool features:

~ Auto-healing: If a pod crashes, Kubernetes automatically creates a new one
~ Rolling updates: Updates happen without downtime
~ Health monitoring: Kubernetes checks if the app is healthy

2.Service File

https://github.com/rajankit2295/smart-Frontened-DevOps-Project/blob/main/k8s/service.yaml

What this file does:

~ Creates a stable way to access my application
~ Acts like a load balancer between multiple pods
~ Exposes the app on NodePort 30080 so I can access it from outside

Why I need this:

-Pods in Kubernetes can come and go, but the service ensures there's always a stable endpoint to reach my application.

Pushing Files to GitHub

After creating these files, I pushed them to my GitHub repo where my frontend application code lives. This way, Jenkins can access everything it needs from one place.

git add k8s/
git commit -m "Add Kubernetes deployment and service files"
git push origin main

Testing Manual Deployment

Before automating everything, I tested manual deployment on Jenkins-Agent Server to make sure everything works:

# Create a namespace for my application
kubectl create namespace smart-Frontened

# Apply the deployment
kubectl apply -f k8s/deployment.yaml -n smart-Frontened

# Apply the service
kubectl apply -f k8s/service.yaml -n smart-Frontened

# Check if pods are running
kubectl get pods -n smart-Frontened

# Check service status
kubectl get svc -n smart-Frontened

# Get detailed pod information
kubectl describe pods -n smart-Frontened

# Check application logs
kubectl logs -f deployment/smart-Frontened-web-app -n smart-Frontened

# Test if application is accessible
curl http://jenkins-agent-ip:30080

Everything worked perfectly! Now time to automate this process ....!

Step 4: Jenkins CI/CD Pipeline

Now for the most interesting part - automating everything with Jenkins Pipeline! I SSH'd into the Jenkins Master server to set up the pipeline.

# Connect to Jenkins Master ssh -i your-key.pem ubuntu@jenkins-master-ip

Creating Pipeline Files

1.Dockerfile

https://github.com/rajankit2295/smart-Frontened-DevOps-Project/blob/main/Dockerfile

What this Dockerfile does:

~ Packages my frontend application into a container
~ Uses Nginx as the web server to serve static files
~ Creates a lightweight, portable image that runs anywhere
~ Exposes port 80 for web traffic

Why containerization rocks:

~Consistency: Runs the same way everywhere (dev, test, production)
~Portability: Can move between different environments easily
~Isolation: App runs in its own environment without conflicts

2.Jenkinsfile

https://github.com/rajankit2295/smart-Frontened-DevOps-Project/blob/main/Jenkinsfile

This is the core of my automation. The Jenkinsfile defines the entire pipeline that runs automatically.

What this pipeline does:

~ Checkout Stage: Gets the latest code from GitHub
~ Build Stage: Creates a Docker image of my application
~ Deploy Stage: Deploys the application to Kubernetes
~ Verification Stage: Checks if deployment was successful
~ Cleanup Stage: Removes old Docker images to save space

The magic behind it:

~Automatic triggering: Runs whenever I push code to GitHub
~Complete automation: From code to running application without manual intervention
~Error handling: If something fails, it stops and tells me what went wrong
~Rollback capability: Can easily go back to previous versions

Pushing Pipeline Files to GitHub

git add Dockerfile Jenkinsfile
git commit -m "Add Docker and Jenkins pipeline configuration file"  
git push origin main

Now Jenkins has access to everything it needs from my GitHub repo ....... !!!

Step 5: Automated Pipeline Trigger

The final piece of the project - making everything automatic .... I set up a GitHub webhook so that every time I push code, Jenkins automatically starts the deployment process.

What is a GitHub Webhook?

Think of it as a notification system. When I push code to GitHub, it immediately tells Jenkins "Hey, there's new code here!" and Jenkins goes into action.

How to set it up:

Go to GitHub repository → Settings → Webhooks
Add Jenkins webhook URL: http://jenkins-master-ip:8080/github-webhook/
Select "Push events" to trigger on code pushes
Save the webhook

Testing the Automation

Now comes the moment of truth! Let me make a small change and push it:

# Make some changes to my frontend application directly from github or by terminal 

# Commit and push the changes
git add .
git commit -m "Update frontend with new content"
git push origin main

What happens automatically:

~ GitHub receives my push and triggers the webhook
~ Jenkins pipeline starts automatically
~ Builds new Docker image with my changes and remove unused too
~ Deploys to Kubernetes replacing the old version
~ Application is live with my new updates ....

No manual work needed - it's all automatic Dudeeee !!!

Pipeline Execution Flow

Here's exactly how everything flows together when I push code:

Developer pushes code to GitHub
↓
GitHub webhook notifies Jenkins

↓
Jenkins Pipeline starts automatically
↓
Stage 1: Checkout - Gets latest code from GitHub
↓

Stage 2: Build - Creates Docker image from Dockerfile
↓
Stage 3: Deploy - Uses kubectl to deploy to Kubernetes
↓
Stage 4: Verify - Checks if deployment was successful
↓
Stage 5: Cleanup - Removes old Docker images
↓
Application is live with new changes!

Total time: Usually 3-5 minute from code push to live deployment...!!

See My Web Page 👇

What I Achieved 💫

Let me break down what each tool brought to my project:

From Terraform (Infrastructure Provisioning):

No more manual server creation - Everything is code-defined
Consistent environments - Same setup every time
Easy scaling - Can create more servers with one command
Cost control - Can destroy everything when not needed
Version control - Infrastructure changes are tracked in Git

From Ansible (Configuration Management):

No more manual software installation - All automated
Consistent server configuration - Same setup across all servers
Time saving - What took hours now takes minutes
Error reduction - No more human mistakes in configuration
Documentation - Configuration is self-documenting

From Kubernetes (Container Orchestration):

Auto-healing - If app crashes, it automatically restarts
Load balancing - Traffic distributed across multiple app instances
Zero-downtime deployments - Updates happen without service interruption
Resource management - Efficient use of server resources
Scalability - Can easily increase/decrease app instances

From Docker (Containerization):

Consistency - App runs the same everywhere
Portability - Easy to move between environments
Isolation - App doesn't interfere with other applications
Fast deployment - Quick to start and stop
Resource efficiency - Lightweight compared to virtual machines

From Jenkins (CI/CD Pipeline):

Complete automation - From code to production without manual steps
Fast feedback - Know immediately if something breaks
Consistent deployments - Same process every time
Rollback capability - Easy to go back to previous versions
Time saving - What took 30 minutes now takes 5 minutes

Challenges I Faced (And How I Solved Them)

Let me share some real challenges I encountered and how I overcame them:

Challenge 1: Terraform State File Issues

Problem: Terraform state file got corrupted, couldn't make changes
Solution: Learned to use terraform import to restore state and always backup state files

Challenge 2: Ansible Connection Problems

Problem: Ansible couldn't connect to servers due to SSH key issues
Solution: Made sure SSH keys were properly configured and added -vvv flag for debugging

Challenge 3: Docker Permission Denied (I can't tell about this) 😤

Problem: Jenkins couldn't build Docker images due to permission issues
Solution: Added Jenkins user to docker group and restarted Jenkins service

Challenge 4: Kubernetes Pod Crashes

Problem: Pods kept crashing with "ImagePullBackOff" error
Solution: Fixed Docker image naming and ensured images were properly built

Challenge 5: Jenkins Pipeline Failures

Problem: Pipeline failed at kubectl commands
Solution: Configured proper kubeconfig file and installed kubectl on Jenkins agent

Challenge 6: Application Not Accessible

Problem: Could access pods but not the application from browser
Solution: Configured NodePort service correctly and opened security group ports

Challenge 7: GitHub Webhook Not Triggering

Problem: Code pushes weren't triggering Jenkins pipeline
Solution: Fixed webhook URL format and ensured Jenkins was accessible from internet

Key Learning: I learned from every error .... Doesn't matter .... i'll forget again these things! 🥲 The more problems I solved, the better I understood how everything works together.

Conclusion

Building this DevOps pipeline was an incredible journey !!!!

What started as:

~ Manual deployments taking 30+ minutes with high chance of errors

~ Became: Fully automated deployments taking 3-5 minutes with zero manual intervention

The transformation: 😉

Time saved: 90% reduction in deployment time
Error reduction: Eliminated human (specially mine) errors in deployment process
Faster releases: Can deploy multiple times per day if needed
Scalability: Easy to scale infrastructure and applications
Reliability: Consistent, repeatable deployment process

This project taught me many things that i can't tell you about (My wifi goes down everytime and it checks my Patience). 🤧

My Github Project Repo 👉 https://github.com/rajankit2295/smart-Frontened-DevOps-Project/tree/main

DevOps #AWS #Cloud #LearningByDoing #Code #Community #Challenge #Web #JustDoIt

🌀 AWS Load Balancers - Explained in My Style

Ankit Raj — Sat, 02 Aug 2025 12:36:56 +0000

Okay, so I’ve been diving deep into AWS these days and today I wanted to talk about something that confused me A LOT in the beginning - Load Balancers. There are four types of Load Balancers in AWS, and at first, they all looked the same to me. But once I understood their layers and use cases, it all started to make sense.

This blog is my attempt to explain all four AWS Load Balancers in the easiest way possible - with visuals, analogies, and beginner-friendly terms. If you're also exploring cloud and DevOps like me, this will help you get a grip.

1.Classic Load Balancer (CLB) -- The Oldie But Goldie

This one’s been around for a while. It’s like that old Nokia phone - reliable, simple, but not really built for today’s advanced apps.

Features:

Supports both Layer 4 (TCP) and Layer 7 (HTTP/HTTPS)
Routes requests to EC2 instances
Lacks support for advanced routing (like path-based or host-based routing)
No container support or modern monitoring tools

#When to Use?

Only when you have some legacy systems running, or migrating old workloads. For anything modern, you’ll probably want to use ALB or NLB.

My thoughts: It still works, but not my go-to choice anymore.

2.Application Load Balancer (ALB) -- The Smart One 🧠

This is the modern HTTP/HTTPS load balancer. It's clever, context-aware, and knows how to handle different types of web traffic. Works on Layer 7 of the OSI model.

Features:

Smart routing: Supports path-based and host-based routing
Works great with containers and microservices (like ECS, Fargate)
Supports WebSockets and HTTP/2
Advanced monitoring with CloudWatch metrics
Integrated with AWS WAF for security

When to Use?

Whenever you want flexibility in routing traffic. Perfect for apps with multiple services like /login, /dashboard, /cart, etc.

My thoughts: Super helpful in modern architectures. I use this whenever I need custom rules or work with containers.

3.Network Load Balancer (NLB) -- The Speed Demon ⚡

This one’s all about speed and performance. NLB operates on Layer 4 (Transport Layer) and is designed to handle millions of requests per second with ultra-low latency.

Features:

Extremely fast and highly scalable
Supports TCP, UDP, and TLS traffic
Can handle volatile traffic spikes
You can assign Elastic IPs
Preserves the source IP for backend services

When to Use?

Real-time apps like financial systems, multiplayer games, or IoT workloads that need fast, reliable connections.

My thoughts: If speed is your top priority, this is your guy. But it’s not smart like ALB — it just forwards traffic.

4.Gateway Load Balancer (GWLB) -- The Security Guy 🔐

This one’s different. It’s not for routing user requests to your app - it's for routing traffic through security appliances like firewalls, intrusion prevention systems, etc.

Works on Layer 3 (Network Layer).

Features:

Integrates with third-party security appliances
Simplifies insertion of security services
Used in inline inspection of traffic
Deploy once, scale across multiple VPCs

When to Use?

When you want to add deep security inspection into your network flow. Great for enterprise-level setups.

My thoughts: Not for everyone, but if you're building something large-scale or security-heavy, it's a must-have.

Wrapping Up

That’s my take on AWS Load Balancers! I tried to keep it as simple and as "me" as possible.

If you're just starting in AWS, don't worry if this feels like too much. Save this, come back to it when you actually use them - trust me, it all starts to make sense once you do it hands-on.

If you liked this breakdown or learned something new, drop a like or comment. I'm learning and sharing as I go - let's connect and grow together!!!!

aws #cloud #loadbalancer #devops #learningbydoing #community #challenge

Understanding Networking Architecture (AWS Basics From My Learning)

Ankit Raj — Wed, 30 Jul 2025 07:46:59 +0000

Hey, again!

In my AWS learning path, I recently studied this Networking structure that shows how EC2 instances are protected using firewalls and how traffic flows in and out of a VPC through route tables, routers, and gateways. It's a layered concept but once it clicks, it's super logical.

So in this blog, I'm gonna break it down part-by-part just like how I understood it — simple and straight.

Here’s the image I followed while learning:

Let's Understand everything step-by-step :

💻 EC2 Instance (Inside the Subnet):

Before we talk about firewalls, let's first understand what we're protecting.

In AWS, your application usually runs on EC2 instances — virtual servers in the cloud. These instances live inside a subnet, which is part of your VPC.

Each EC2 can host your websites, APIs, backend systems, etc. And because they are exposed to networks (maybe even the internet), they need security — which is where firewalls come in.

So first comes your instance, then the Security Group (like armor around it), and the NACL (like the gate of the whole area).

🧱 Security Group (Inside the Subnet)

Let’s start from where the EC2 instance lives. Inside a subnet, you attach Security Groups to your instances. Think of them like the first line of defense or the bodyguard for each EC2 instance.

What is a Security Group?

It’s basically a virtual firewall that controls inbound (incoming) and outbound (outgoing) traffic at the instance level. Unlike NACLs, Security Groups are stateful.

Stateful? What's that?

It means if your security group allows inbound traffic on port 22 (SSH), then the response (outbound) is automatically allowed back. You don’t have to write outbound rules separately for it.

How it works:

You create a security group.
You add inbound rules (e.g., allow port 80 from anywhere).
You add outbound rules (e.g., allow all traffic to anywhere).
Then attach this SG to your EC2 instance.

This controls exactly what can come in and what can go out from that specific instance.
Example: Want to host a web app? Just allow inbound on port 80 (HTTP) and 443 (HTTPS).

🧱 Network ACL (Outside the Subnet)

Okay now jump one level above. Your subnet (which contains EC2s) is also protected — but this time, by Network ACL (NACL). You can imagine this as a neighborhood security gate, while Security Group is the security at your door.

What is a NACL?

NACL stands for Network Access Control List. It’s a set of rules that allow or deny traffic at the subnet level.

Stateless? What does that mean?

NACLs are stateless, meaning if you allow inbound traffic, you also have to allow the corresponding outbound traffic separately. Nothing automatic here.

NACL Rule Types:

Inbound Rules: Control what traffic can come into the subnet.

Outbound Rules: Control what traffic can go out of the subnet.

Rules are evaluated in order (from lowest to highest rule number).

First match wins. Rest is ignored.

Fun fact: If you don’t want a certain IP range hitting your subnet at all, block it in NACL.
So if someone somehow bypasses SG (which they shouldn’t), NACL acts like an extra shield. It's mostly used for high-level access restrictions or blacklisting specific IPs.

📦 Route Table

Every subnet in a VPC is associated with a Route Table. This defines where traffic should go once it enters the subnet.

What’s inside the Route Table?

Destination: IP range (like 0.0.0.0/0, or a VPC CIDR)

Target: Where to send it (like IGW, NAT, local, etc.)

How it works:

When an EC2 tries to send a request to the internet, route table checks the destination IP.

If the destination matches a rule, traffic is sent to the target.

Example: 0.0.0.0/0 -> IGW means all internet-bound traffic is forwarded to Internet Gateway.
Think of route table as the GPS inside your VPC.

🔁 Router (Between Internet Gateway / Virtual Private Gateway)

The router in the VPC isn’t a separate service — it’s automatically managed by AWS. It connects your subnets, gateways, and route tables.

What it does:

Connects different subnets within the VPC (east-west traffic)

Handles traffic from subnets to outside VPC (north-south traffic)

Works with route tables to know where to forward traffic

Think of this router like a smart traffic controller. It doesn’t ask questions. It checks route tables and forwards traffic.

🌐 Internet Gateway (IGW)

This is what allows your instances to communicate with the public internet.

Why is it attached to the VPC?

Because it gives the entire VPC access to the internet, but only subnets that are associated with a route table pointing to IGW can use it.

What it does:

Accepts traffic from the internet

Forwards it into your VPC based on the route table

Also lets your EC2 instances send responses back to the internet

Without IGW, your EC2 can’t even do a simple apt update if it’s in a public subnet.

🔒 Virtual Private Gateway (VGW)

This is used when your AWS VPC needs to connect with your on-premise network — like from your office data center.

How it works:

You set up a VPN connection from your on-prem setup to VGW

VGW connects to your VPC router

Route table entry like Destination: 10.0.0.0/16 -> Target: VGW

This is more like a private door that connects your VPC to a known internal network. Not public internet.

Helpful when companies have hybrid cloud setups.

🧠 Final Thoughts

At first, it all feels like too much — security group here, NACL there, route tables, gateways, blah blah. But when you draw it and walk through the flow, it all makes sense.

Want to protect individual instances? Use Security Groups.

Want to control subnet-level traffic? Use NACLs.

Want to route traffic in/out? Route Table + Router.

Internet access? Use IGW.

Private corporate access? Use VGW.

All these together make VPC powerful and flexible.

Hope this helped someone who’s just starting to make sense of all this.

LinkedIn: https://www.linkedin.com/in/ankit-raj-b20a0a305/
GitHub: https://github.com/rajankit2295

aws #cloud #ec2 #vpc #devops #architecture #networking #community #blog #learning

AWS EC2 High-Level Architecture Explained (From My Learning Journey)

Ankit Raj — Fri, 25 Jul 2025 07:30:50 +0000

Hey everyone!
So this is my first blog and I'm kinda excited to post this. While going through my AWS Learning Journey, I came across this really cool EC2-based architecture. I decided to understand it properly and write about it in my own words so I can learn better — and maybe help some of you too!

🌟 What this blog is about

I'm gonna explain a 3-tier EC2-based AWS architecture I recently studied. It includes:

Public and private subnets
Two types of load balancers
Auto Scaling
Amazon Aurora DB (with read replica)

I've added a diagram below (yes, it's the same one I followed):

In this architecture it shows a public-facing Application Load Balancer, which forwards client traffic to the public subnet consisting of a web tier. The EC2 instances within the web tier sit within Auto Scaling groups to allow for dynamic scaling. The web tier redirects all API calls from the instances in the public-facing subnet to an internal-facing Application Load Balancer. This internal-facing load balancer then forwards the traffic to the private subnet containing the application tier.

🏠 Web Tier (Public Subnet)

This is the top layer of the architecture. Here's what happens:

An Application Load Balancer is exposed to the internet via an Internet Gateway.

It receives all the incoming traffic (users accessing the app from browser/mobile).

That traffic is forwarded to EC2 instances inside Auto Scaling Groups (ASG).

These EC2s sit inside public subnets across two Availability Zones (AZs).

Why use ASG? Because traffic might increase or decrease, so your infra should scale accordingly.

🚀 Application Tier (Private Subnet)

Now, the frontend EC2s (in public subnet) don't directly talk to the DB.
They forward all API calls or backend logic processing to another Application Load Balancer.

But this one is internal-facing only — not exposed to the internet. It's private.

This ALB then routes traffic to another set of EC2 instances in private subnets.

These EC2s handle all backend logic, business operations, etc.

Again, distributed across multiple AZs for high availability.

📂 Database Tier (Private Subnet)

Now comes the final part: storage & data.

I'm using Amazon Aurora here as the primary database.

It's in a private subnet (for obvious security reasons).

And to reduce read load, there's an Aurora read replica in another AZ.

The app tier EC2s talk to the primary DB for writes.

And the read replica helps with all read-heavy operations (like fetching data for reports or dashboards).

👥 Why this setup is cool

Public and private subnet separation

Load balancing on both ends (frontend & app layer)

Auto Scaling for high traffic handling

High availability with multi-AZ deployment

Secure DB in private subnet

📊 What could be added/improved?

If I had to expand or apply this further, I’d probably add:

WAF (Web Application Firewall) for extra protection

CloudFront for CDN

NAT Gateway if private subnet EC2s need internet

CloudWatch for monitoring and alerts

🙌 Thoughts

I studied it during my AWS learning Journey and decided to break it down in my own words. Doing this helped me understand each part clearly.

If you’re just getting into AWS or preparing for, try to draw this architecture by yourself. Once you get the flow, everything else becomes easier.

Thanks for reading! If you liked this or have any suggestions, feel free to comment ❤️....

PS: I’m just a student, learning cloud step by step and building my portfolio. Let’s connect!!

LinkedIn: https://www.linkedin.com/in/ankit-raj-b20a0a305/
GitHub: https://github.com/rajankit2295

aws #cloud #ec2 #aurora #devops #architecture #community #blog