How I Deployed a Production-Style 3-Tier Application on AWS with CI/CD

Muhammed Rifkhan — Mon, 29 Jun 2026 07:56:37 +0000

Recently, I completed a production-style AWS deployment project where I built and deployed a full-stack Application using a proper 3-tier cloud architecture.

The main goal was not only to make the application work, but also to design it in a way that follows real production concepts such as:

HTTPS

Custom domain

Public and private subnets

Load balancing

Auto Scaling Groups

Private database access

Nginx reverse proxy

PM2 process management

GitHub Actions CI/CD

GitHub Repository:

https://github.com/Rifkhan-SAA-DevOps/Blog_3Tier_Arch_AWS

Project Overview

This is a full-stack Application with:

User authentication using JWT
Blog create, read, update, and delete features
Category management
Comment system
Admin and author roles
Protected API routes
React + Vite frontend
Node.js + Express backend
MySQL database hosted on Amazon RDS

The application was first deployed manually on AWS using a complete 3-tier architecture. After the manual deployment was completed and verified, I added GitHub Actions CI/CD pipelines to automate both frontend and backend deployments.

Architecture Diagram

The application follows this flow:

User Browser
↓
Route 53 Custom Domain
↓
ACM SSL Certificate
↓
Public Frontend Application Load Balancer
↓
Frontend Target Group
↓
Frontend Auto Scaling Group
↓
EC2 Instances running Nginx
↓
Nginx serves React build and reverse proxies /api
↓
Internal Backend Application Load Balancer
↓
Backend Target Group
↓
Backend Auto Scaling Group
↓
EC2 Instances running Node.js with PM2
↓
Private RDS MySQL Database

The most important design decision in this project was this:

The browser should not directly access the private backend.

Instead, the browser calls the public frontend domain, and Nginx forwards /api requests to the internal backend load balancer.

Tech Stack

Frontend

React

Vite

JavaScript

Axios

Nginx for production serving

Backend

Node.js

Express.js

JWT authentication

REST API

PM2 process manager

Database

MySQL

Amazon RDS MySQL

AWS Services

VPC

Public subnets

Private application subnets

Private database subnets

Internet Gateway

NAT Gateway

Route Tables

EC2

Application Load Balancer

Auto Scaling Group

Launch Template

Amazon RDS MySQL

Route 53

AWS Certificate Manager

Security Groups

DevOps and CI/CD

Git

GitHub

GitHub Actions

SSH deployment

SCP

Nginx reverse proxy

PM2

Linux

Why I Used a 3-Tier Architecture

In a simple deployment, we can run the frontend, backend, and database on one server. That is useful for learning, but it is not suitable for production-style architecture.

In this project, I separated the application into three layers:

1. Frontend Layer

The frontend is a React application built using Vite. In production, the React build files are served by Nginx on EC2 instances.

The frontend layer is public because users need to access the website through the browser.

2. Backend Layer

The backend is a Node.js and Express API. It runs on private EC2 instances and is managed using PM2.

The backend is not directly exposed to the internet. It is accessed through an internal Application Load Balancer.

3. Database Layer

The database is Amazon RDS MySQL. It is placed inside private database subnets.

Only the backend security group can connect to the database. This means the database is not publicly accessible.

AWS Networking Design

The VPC was designed with multiple subnet layers:

VPC
├── Public Subnets
│ ├── Public Frontend ALB
│ └── Frontend EC2 instances
│
├── Private App Subnets
│ ├── Internal Backend ALB
│ └── Backend EC2 instances
│
└── Private DB Subnets
├── RDS MySQL

This structure improved the security of the application because only the required parts were exposed publicly.

The frontend load balancer receives public HTTPS traffic. The backend load balancer is internal. The RDS database is private.

HTTPS and Custom Domain

For the domain setup, I used:

Route 53 for DNS

AWS Certificate Manager for SSL/TLS certificate

HTTPS listener on the public frontend Application Load Balancer

The application can be accessed using:

https://rifkhan.xyz

This helped me understand how domain routing and HTTPS are configured in a real AWS environment.

Nginx Reverse Proxy Setup

One of the most important parts of this project was the Nginx reverse proxy.

The React frontend uses:

VITE_API_URL=/api

This means the browser sends API requests like this:

https://rifkhan.xyz/api/auth/login

Then Nginx forwards those /api requests to the internal backend ALB.

Example Nginx concept:

location /api/ {
    proxy_pass http://internal-backend-alb-dns/api/;
}

This solved a major production issue.

At first, the frontend was trying to call the internal backend ALB directly from the browser. That caused a timeout because the internal ALB is private and cannot be accessed from the public internet.

The correct solution was:

Browser
→ Public domain /api
→ Nginx reverse proxy
→ Internal backend ALB
→ Backend EC2
→ Private RDS

CI/CD with GitHub Actions

After completing the manual deployment, I added GitHub Actions to automate deployments.

I created separate deployment workflows for:

Frontend deployment

Backend deployment

Frontend CI/CD Flow

Developer pushes frontend code
↓
GitHub Actions starts
↓
Install dependencies
↓
Build React app using VITE_API_URL=/api
↓
Upload dist files to frontend EC2 using SCP
↓
Copy files to /usr/share/nginx/html
↓
Reload Nginx
↓
Validate frontend health endpoint

Frontend deployment proof:

Backend CI/CD Flow

The backend was more challenging because the backend EC2 instances are inside private subnets.

GitHub Actions cannot directly SSH into a private EC2 instance. To solve this, I used the frontend EC2 instance as a jump host.

GitHub Actions
↓
Frontend EC2 public instance
↓
Backend EC2 private instance
Backend deployment flow:
Developer pushes backend code
↓
GitHub Actions starts
↓
SSH into frontend EC2 jump host
↓
SSH into private backend EC2
↓
Upload backend source code
↓
Install production dependencies
↓
Restart backend using PM2
↓
Validate backend health endpoint

Backend deployment proof:

PM2 for Backend Process Management

The backend Node.js application was managed using PM2.

PM2 helped me keep the backend running continuously and restart it after deployment.

Useful PM2 commands used:

pm2 start server.js --name blog-backend
pm2 restart blog-backend
pm2 status
pm2 logs

PM2 process proof:

Security Design

Security was one of the main points of this project.

Here is how the security design was planned:

Component => Security Approach
Frontend ALB => Public HTTPS access
Frontend EC2 => Receives traffic through frontend ALB
Backend ALB => Internal only
Backend EC2 => Private subnet, no direct public access
RDS MySQL => Private database subnet
Database access => Only backend security group allowed
API access => Browser uses /api through Nginx reverse proxy
SSL => ACM certificate with HTTPS

Secrets Stored as environment variables, not committed to GitHub

This helped me understand the importance of layered security in cloud deployment.

Scalability and High Availability

This project includes production-style scalability components:

Frontend Auto Scaling Group
Backend Auto Scaling Group
Public Application Load Balancer
Internal Application Load Balancer
Multi-subnet architecture
Health checks for frontend and backend target groups
Private application and database layers

The Auto Scaling Groups allow EC2 instances to be replaced or scaled based on configuration. The load balancers distribute traffic to healthy targets.

Challenges I Faced and Solved

1. Browser Could Not Access Internal Backend ALB

Problem:

ERR_CONNECTION_TIMED_OUT

Reason:

The React frontend was built using the internal backend ALB DNS. Since the internal backend ALB is private, the browser could not access it.

Solution:

I changed the frontend API URL to:
VITE_API_URL=/api
Then Nginx reverse proxy forwards /api requests to the internal backend ALB.

2. Nginx Default Server Block Conflict

Problem:

Nginx had a conflicting default server block.

Solution:

I removed/commented the default server block and used only the project-specific Nginx configuration file.

Then I verified the configuration using:

 sudo nginx -t
 sudo systemctl reload nginx

3. Backend Private Subnet Deployment

Problem:

Backend EC2 instances were in private subnets, so GitHub Actions could not SSH directly into them.

Solution:

I used the frontend EC2 instance as a jump host.

GitHub Actions
↓
Frontend EC2 public instance
↓
Backend EC2 private instance

This helped me understand how private server deployment works in real production environments.

Live application home page:

Register page:

Dashboard:

Health Check Endpoints

Frontend health endpoint:

https://rifkhan.xyz/health.html

Backend health endpoint through public domain:

https://rifkhan.xyz/api/health

Backend local health endpoint:

http://localhost:5000/api/health

Health checks were useful for verifying whether the frontend and backend were running correctly after deployment.

What I Learned

Through this project, I practiced and implemented:

Designing AWS 3-tier architecture

Deploying frontend and backend on separate layers

Using public and private subnets correctly

Configuring Route 53 custom domain

Enabling HTTPS using ACM

Creating public and internal Application Load Balancers

Configuring Auto Scaling Groups

Hosting React production build with Nginx

Reverse proxying API requests through Nginx

Running Node.js backend using PM2

Connecting backend to private RDS MySQL

Debugging ALB, Nginx, API, and security group issues

Creating GitHub Actions CI/CD pipelines

Deploying to private EC2 through a jump host

Understanding real-world production deployment flow

Future Improvements

GitHub Repository:

https://github.com/Rifkhan-SAA-DevOps/Blog_3Tier_Arch_AWS

Live Demo:

https://rifkhan.xyz

Thanks for reading. Feedback and suggestions are welcome.

DEV Community: Muhammed Rifkhan

How I Deployed a Production-Style 3-Tier Application on AWS with CI/CD

Project Overview

Architecture Diagram

Tech Stack

Why I Used a 3-Tier Architecture

AWS Networking Design

HTTPS and Custom Domain

Nginx Reverse Proxy Setup

CI/CD with GitHub Actions

Frontend CI/CD Flow

Frontend deployment proof:

Backend CI/CD Flow

PM2 for Backend Process Management

PM2 process proof:

Security Design

Scalability and High Availability

Challenges I Faced and Solved

1. Browser Could Not Access Internal Backend ALB

2. Nginx Default Server Block Conflict

3. Backend Private Subnet Deployment

Live application home page:

Register page:

** Dashboard:**

Health Check Endpoints

What I Learned

Dashboard: