DEV Community: Tanay Jain

How I Deployed a Flask App on AWS with RDS, ALB, and VPC as a Student

Tanay Jain — Mon, 15 Jun 2026 08:37:17 +0000

Most Flask deployment tutorials end after launching an EC2 instance.

Mine did too.

The application worked, but the architecture had serious problems:

Database exposed on the same machine as the application
No load balancing
No monitoring
No network isolation
Application accessible directly through EC2 public IP

So I rebuilt the entire stack using AWS VPC, RDS, ALB, Security Groups, IAM, and CloudWatch — to understand how production cloud systems are actually designed.

This article documents that journey.

Why I Built This
Initial Architecture (v1.0)
Architecture Evolution
Target Architecture (v2.0)
Tech Stack
AWS Services Used
VPC Design
Security Model
RDS Migration
Load Balancer
Monitoring
Challenges
Security Improvements
Limitations
What This Project Taught Me
Project Outcomes
Roadmap
Source Code

Why I Built This

I wanted to move beyond tutorial deployments and understand:

How databases are isolated in production
Why load balancers exist and what they actually do
How AWS networking works at a real level
How monitoring is implemented across multiple services
How security is enforced between application layers

Instead of deploying another demo app, I focused on building a production-style architecture around a simple application — a Flask visit counter backed by PostgreSQL.

Initial Architecture (v1.0)

Flask App
    │
PostgreSQL Container
    │
Docker Compose
    │
Single EC2 Instance

Everything ran together on one machine. It worked for learning but had real limitations:

PostgreSQL inside a container — no managed backups, no isolation
No health checks — broken app still received traffic
No monitoring — no visibility into what was happening
Direct EC2 access — no traffic management layer

Architecture Evolution

Before (v1.0)	After (v2.0)
Flask + PostgreSQL on one machine	Flask on EC2 + RDS PostgreSQL
Direct EC2 public IP access	ALB as single entry point
No monitoring	CloudWatch Dashboard
No network isolation	Public + Private Subnets
PostgreSQL in a container	Managed Amazon RDS
Single point of failure	Production-style 3-tier architecture

Target Architecture (v2.0)

Figure 1: Final 3-tier AWS architecture used in this project.

Internet
    │
    ▼
Application Load Balancer
    │
    ▼
EC2 Instance (Docker + Flask)
    │
    ▼
Amazon RDS PostgreSQL (Private Subnet)

This follows a standard 3-tier architecture pattern:

Tier	Components
Presentation	Application Load Balancer
Application	EC2 + Docker + Flask
Data	Amazon RDS PostgreSQL

Tech Stack

Application

Python, Flask
PostgreSQL

Containerization

Docker
Docker Compose

AWS Services

VPC, EC2, RDS PostgreSQL
Application Load Balancer
IAM, CloudWatch

Networking and Security

Security Groups
Public and Private Subnets
Internet Gateway, Route Tables

AWS Services Used

Service	Purpose
Amazon VPC	Network isolation and segmentation
Amazon EC2	Application hosting
Docker	Application containerization
Amazon RDS PostgreSQL	Managed database
Application Load Balancer	Traffic distribution and health checks
IAM	Access control and least-privilege
Amazon CloudWatch	Monitoring and metrics
Security Groups	Traffic filtering between layers
Internet Gateway	Internet access for public subnets
Route Tables	Subnet traffic routing

Building a Custom VPC

The first step was replacing the default VPC with a custom one designed around isolation.

VPC: 10.0.0.0/16
│
├── Public Subnets
│   ├── 10.0.1.0/24   (AZ: ap-south-1b)
│   └── 10.0.4.0/24   (AZ: ap-south-1a)
│
└── Private Subnets
    ├── 10.0.2.0/24   (AZ: ap-south-1b)
    └── 10.0.3.0/24   (AZ: ap-south-1a)

Public subnets host the EC2 instance and ALB — internet-facing resources.

Private subnets host RDS — no route to the internet gateway, no direct access from anywhere outside the VPC.

The database is unreachable from the internet not just because of a firewall rule, but because it has no path there at all.

Security Group Layering

Each layer only accepts traffic from the layer directly above it:

Internet
   │
   ▼  HTTP 80, HTTPS 443
ALB Security Group
   │
   ▼  HTTP 80 — from ALB Security Group only
EC2 Security Group
   │
   ▼  PostgreSQL 5432 — from EC2 Security Group only
RDS Security Group

Nobody can reach EC2 directly from the internet.
Nobody can reach RDS — not from the internet, not even from a developer's machine.
Every request must pass through the ALB first.

IAM and Access Control

Before deploying anything, I set up proper access control:

IAM Admin User with MFA — root account never used for daily work
IAM Roles for AWS service-to-service access
Least-privilege policy — no account has more permissions than it needs

Root account credentials are the most dangerous thing in an AWS account. Building this habit early matters.

Migrating Database to Amazon RDS

Moving PostgreSQL from a Docker container to Amazon RDS was one of the biggest architectural improvements.

Containerized PostgreSQL	Amazon RDS PostgreSQL
Manual backups	Automated backups
Manual patching	Automatic patching
Container restart = potential data loss	Managed persistent storage
No monitoring built in	CloudWatch integration

The Flask application connects to RDS using SSL:

psycopg2.connect(
    host=DB_HOST,
    sslmode="require",
    connect_timeout=5
)

RDS is accessible only from the EC2 Security Group. Nothing else can reach it.

Application Load Balancer

The ALB became the single entry point for all traffic.

Health Check Configuration:

Path:               /health
Interval:           30 seconds
Healthy Threshold:  2
Success Code:       200

The /health endpoint verifies actual database connectivity before reporting healthy:

{
  "status": "healthy",
  "database": "connected"
}

If RDS goes down, the health check fails, and the ALB stops routing traffic to that instance.

Figure 2: ALB Target Group showing healthy EC2 target.

CloudWatch Monitoring

I configured a unified CloudWatch dashboard covering all three tiers.

Figure 3: CloudWatch dashboard monitoring EC2, RDS, and ALB metrics.

Load Balancer

Request Count
Target Response Time
Healthy Host Count

EC2

CPU Utilization
Network In / Out

RDS

CPU Utilization
Database Connections
Free Storage Space

Having visibility across all layers meant that when something broke during testing, I could immediately see which tier was affected.

Challenges I Encountered

RDS Connectivity Issues

When I first deployed, the Flask application could not connect to PostgreSQL at all.

The issue was Security Group configuration. The RDS Security Group was only allowing inbound traffic from a specific IP — which changed every time the EC2 instance restarted.

Fixing this by referencing the EC2 Security Group ID instead of an IP address made me understand AWS network security in a way no tutorial had managed before.

Health Check Design

My first health check endpoint simply returned 200 OK with no logic.

The problem was that the application could lose database connectivity and still appear healthy to the ALB. Traffic kept routing to a broken instance.

I redesigned the endpoint to verify actual database access before returning healthy status. If the database query fails, the endpoint returns 503. The ALB catches this and stops routing traffic until connectivity is restored.

Security Improvements

The migration introduced multiple security improvements over the original setup:

Database moved into private subnets — no public IP, no internet route
Security Group based access control between every layer
IAM Admin User with MFA — root account locked away
Least-privilege access model throughout
ALB as the only public entry point — EC2 not directly reachable
SSL connection between Flask and RDS PostgreSQL

These controls significantly reduced the attack surface compared to the original single-machine deployment.

Approximate Cost

This project was built within AWS Free Tier limits where possible:

Service	Cost
EC2 t2.micro	Free Tier (750 hrs/month)
RDS db.t3.micro	Free Tier (750 hrs/month)
Application Load Balancer	Minimal cost during testing
CloudWatch	Free Tier metrics

The goal was to experience production-style architecture without significant cost — and to understand which services carry real costs at scale.

Application Endpoints

Home

GET /
Response: Page visited X times!

Health Check

GET /health
Response: { "status": "healthy", "database": "connected" }

Current Limitations

While this architecture follows production patterns, it still has limitations:

Single EC2 instance — no redundancy at the application layer
No Auto Scaling Group — cannot handle traffic spikes
No CI/CD pipeline — deployments are manual
No Infrastructure as Code — resources provisioned via console
No HTTPS — SSL termination via ACM not yet configured

These are planned improvements for the next iteration.

What This Project Taught Me

Before this project, I knew how to deploy applications.

After this project:

I understood why VPC design matters before writing a single line of application code
I understood why databases belong in private networks, not just from a tutorial but from seeing what happens when they are not
I understood how health checks directly affect availability — a bad health check is worse than no health check
I understood how AWS services interact in a real architecture — not in isolation

The shift from deployment to architecture thinking was the biggest takeaway.

Project Outcomes

By the end of this project:

Designed a custom AWS VPC with public and private subnets across two Availability Zones
Deployed a Dockerized Flask application on Amazon EC2
Migrated PostgreSQL from a container to Amazon RDS in private subnets
Configured an Application Load Balancer with real health check logic
Implemented Security Group based network isolation across all three tiers
Built CloudWatch dashboards monitoring EC2, RDS, and ALB metrics
Documented the full architecture and deployment workflow

Roadmap

The current architecture uses manually provisioned AWS resources. Next steps:

Infrastructure as Code using Terraform — provision the entire stack from code
Automated CI/CD using GitHub Actions — code push triggers build, test, and deploy
HTTPS with AWS Certificate Manager
Container orchestration with Kubernetes on Amazon EKS
Auto Scaling Groups for high availability
Centralized logging with CloudWatch Logs

Source Code

Full source code, architecture diagrams, Dockerfile, Docker Compose, and documentation:

👉 GitHub Repository

Conclusion

This project taught me that cloud architecture is not about deploying applications — it is about designing systems that are secure, observable, and resilient.

Building the VPC, isolating the database, configuring Security Groups, implementing real health checks, and monitoring the full stack with CloudWatch gave me a much deeper understanding of AWS than any tutorial had.

The application itself is simple.

The infrastructure behind it is where the real learning happened.

Thanks for reading.

Feedback, suggestions, and architecture improvements are always welcome.

How I Built 5 Linux Automation Scripts on AWS EC2

Tanay Jain — Sat, 23 May 2026 08:21:06 +0000

I wanted to find out what working on a real Linux server actually feels like — not a local VM, not a simulator.

So in May 2026, I spun up an Ubuntu 22.04 server on AWS EC2, connected via SSH, and spent the entire month doing real work on it.

Here's what I built.

🖥️ Environment

Tool	Details
Cloud	AWS EC2 t2.micro
OS	Ubuntu 22.04 LTS
Editor	VS Code Codespaces
Auth	SSH key-based authentication
Automation	Bash scripting + cron jobs

📚 Topics Covered

Linux Fundamentals

User and group management
File permissions (chmod, chown)
Process management (ps, top, kill, systemctl)
Networking basics (ss, curl, UFW, DNS)
Package management with apt

Automation & Scripting

Bash scripting — functions and validation
Log management
Cron job scheduling
SSH workflows (scp, rsync)
Log analysis using grep, awk, and sed

🔧 The 5 Automation Scripts

By the end of the month, I had built and automated 5 production-style Bash scripts.

1. Server Health Check

A monitoring script that checks:

CPU usage
RAM usage
Disk usage
Service status
Internet connectivity

Scheduled every 15 minutes using cron.

./server_health.sh

Example output:

================================================
        SERVER HEALTH CHECK REPORT
================================================

Date: 2026-05-12 10:00:00
Hostname: ip-172-xx-xx-xx

--- CPU Usage ---
✅ CPU is OK (2.3%)

--- Memory Usage ---
✅ RAM is OK (45%)

--- Services Status ---
✅ ssh: RUNNING
✅ nginx: RUNNING
✅ docker: RUNNING

--- Network ---
✅ Internet: CONNECTED

================================================

2. Disk Usage Alerter

A script that scans partitions and generates alerts when disk usage exceeds a threshold.

Features:

Threshold-based alerts
Partition monitoring
Log generation
Color-coded terminal output

Runs every hour through cron.

3. Log Cleaner

A maintenance script that:

Compresses older logs
Removes outdated logs
Reduces disk usage automatically

Built using find, gzip, and mtime filters for log retention management.

Runs every Sunday.

4. User Creation Script

A provisioning script for creating users with a consistent setup.

Features:

Username validation
Group assignment
Home directory creation
Temporary password generation
Batch user creation using CSV files

sudo ./user_creation.sh --file users.csv

5. Backup Script

Creates compressed backups using tar.gz archives.

Features:

Backup verification
Retention policy
Automatic cleanup of old backups
Logging and integrity checks

Scheduled daily at 2 AM.

⏱️ Cron Job Automation

All scripts were automated using cron jobs.

# Health check — every 15 minutes
*/15 * * * * /home/ubuntu/scripts/server_health.sh >> /home/ubuntu/logs/health_cron.log 2>&1

# Disk alerter — every hour
0 * * * * /home/ubuntu/scripts/disk_alerter.sh >> /home/ubuntu/logs/disk_cron.log 2>&1

# Backup — daily at 2 AM
0 2 * * * /home/ubuntu/scripts/backup.sh >> /home/ubuntu/logs/backup_cron.log 2>&1

# Log cleaner — every Sunday at 11 PM
0 23 * * 0 /home/ubuntu/scripts/log_cleaner.sh >> /home/ubuntu/logs/cleaner_cron.log 2>&1

Once configured, the server handled routine maintenance automatically.

💡 Biggest Learnings

1. Linux becomes comfortable through repetition

At the beginning, basic terminal commands felt unfamiliar.

After working daily on a remote server, navigating Linux from the command line became much more natural. There's no shortcut — you just have to do it daily.

2. Automation changes how you think

One of the biggest mindset shifts was noticing repetitive work and immediately thinking:

"Can this be automated?"

That shift alone made scripting feel much more practical — and honestly, more fun.

3. Real infrastructure teaches different lessons

Working on an actual EC2 instance exposed me to problems that are difficult to fully understand in local environments:

SSH authentication issues
File permission problems
Cron debugging
Disk usage management
Log analysis workflows

Solving those problems on a live server taught me far more than just reading commands from documentation.

🚀 What's Next

Next, I'm moving into AWS Core Infrastructure — VPC, IAM, RDS, and Terraform.

That work starts in June 2026. Follow along if you're on a similar path.

📁 GitHub Repository

All scripts and documentation are open source:

👉 github.com/tanayjdev/linux-bash-scripts

BCA Student • Aspiring Cloud & DevOps Engineer

My CI Pipeline Failed on the First Push. Here's What I Learned.

Tanay Jain — Sun, 03 May 2026 12:59:58 +0000

My CI pipeline failed on the first push.

Not because of a big mistake.
Because of a layer conflict in my Dockerfile that
only showed up in a clean environment.

Locally — everything worked.
CI — red on the first run.

That one failure taught me more about Docker
than a week of tutorials.

Here's exactly what I built and what happened.

The Project

A Flask + PostgreSQL app running in Docker Compose.

It tracks page visits and stores the count
in a real PostgreSQL database.
Browser → Flask Container → PostgreSQL → pgdata Volume

Multi-container setup. Persistent storage.
Environment variables via .env.
Health checks and restart policies.

Every decision is production-style —
even though it's a learning project.

Why I Added CI

Before CI, my workflow looked like this:
Make a change
↓
docker compose down
↓
docker compose build
↓
docker compose up -d
↓
Open browser, check manually
↓
Repeat

This works for one or two changes.

But when you're pushing regularly —
manually checking every time is not sustainable.

I wanted the system to tell me if something broke.
Not discover it later.

What I Built

.github/workflows/docker-build.yml

name: Docker Build CI

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Setup Docker Buildx
      uses: docker/setup-buildx-action@v2

    - name: Build Docker image
      run: docker build -t flask-app:test .

    - name: Verify image exists
      run: docker images | grep flask-app

    - name: Run container test
      run: |
        docker run --rm flask-app:test python -c "
        import flask
        import psycopg2
        print('Flask:', flask.__version__)
        print('All imports OK')
        "

    - name: Check image size
      run: |
        SIZE=$(docker image inspect flask-app:test \
        --format='{{.Size}}')
        echo "Image size: $SIZE bytes"
        echo "Build verified"

What Each Step Does

Checkout — GitHub's server downloads my code

Docker Buildx setup — Prepares build tools on the runner

Build image — Runs my Dockerfile from scratch,
clean environment every time

Verify image — Confirms image was actually created

Container test — Runs the container,
checks Flask and psycopg2 import correctly

Size check — Tracks image size on every build

The First Run Failed

Pushed the code. Opened Actions tab. Red.

The error was in my Dockerfile.

I had this:

RUN apt-get update && apt-get install -y curl \
    && rm -rf /var/lib/apt/lists/*

The layer order was causing a conflict
in the clean CI environment that
didn't show up on my machine.

Reordered the layers. Pushed again. Green.

This is the whole point of CI.

Your local machine has cached layers,
existing images, leftover containers.
CI starts completely fresh every time.

It catches what you miss.

The Health Endpoint

I also added a /health route to Flask:

@app.route("/health")
def health():
    try:
        conn = get_connection()
        conn.close()
        return {"status": "healthy", "database": "connected"}, 200
    except Exception as e:
        return {"status": "unhealthy", "error": str(e)}, 500

A running container doesn't mean a working app.

This endpoint checks actual database connectivity.
200 = Flask is up and DB is reachable.
500 = Something broke inside.

Real monitoring tools and load balancers
use exactly this kind of endpoint.

Architecture

GitHub Actions CI:
Code Push → Build → Test → Validate
↓
Docker Hub (image stored)
↓
AWS EC2 (deployed)
↓
Flask Container ←→ PostgreSQL Container
↓
pgdata Volume

Project Versioning

v1.0 — Flask + PostgreSQL + Docker + EC2 deploy
v1.1 — CI pipeline + /health endpoint added

Tagging versions made me treat this
like a real product — not just practice code.

What Actually Changed

Before:
Push code → manually test → hope for the best.

After:
Push code → pipeline runs in ~2 minutes → green or red.

No guessing. No "I think it should work."
The pipeline knows.

Three Things CI Taught Me Practically

1. Clean environment matters

Your machine lies to you.
Cached layers, existing images, leftover state —
none of that exists in CI.

If it works locally but fails in CI,
the CI is right.

2. The pipeline is documentation

Anyone reading the workflow file
understands exactly how the project builds.
No README needed for that part.

3. Start CI early

Adding it to an existing project is harder
than starting with it.

Next project — pipeline goes in on day one.

Links

GitHub: https://github.com/tj2905

Docker Hub: docker pull tanayjain29/flask-devops-app:v1.0

Learning by building real things.

Turning ideas into working projects.
Sharing everything on GitHub.

From Zero to Deployment: Dockerizing a Flask + PostgreSQL App on AWS

Tanay Jain — Sun, 29 Mar 2026 18:56:16 +0000

When I started learning Docker, I had no idea I’d end up deploying a real application on a cloud server within the same month.

It ended up changing how I think about building software.

The Idea

I didn’t want to build just another static project.

I wanted:

A real backend
A real database
A real deployment

So I built a simple web app that tracks page visits and stores them in PostgreSQL.

Tech Stack

Python Flask (backend)
PostgreSQL (database)
Docker & Docker Compose
AWS EC2 (deployment)

Architecture

User (Internet)
   ↓
AWS EC2 Server
   ↓
Docker Engine
   ↓
Flask Container (Port 80)
   ↓ psycopg2
PostgreSQL Container
   ↓
Persistent Volume (pgdata)

Key Concepts I Implemented

🔹 Multi-container system

Instead of running containers manually, I used Docker Compose.

docker compose up -d

This starts the entire system in one command.

🔹 Environment variables (.env)

No secrets inside the code.

Cleaner
Safer
Production-ready

🔹 Health checks

Docker monitors the application continuously.

If Flask stops responding, the container is marked as unhealthy.

🔹 Auto-restart

Using:

restart: always

If a container crashes, Docker automatically restarts it.

🔹 Optimized Dockerfile

Used python:3.10-slim
Cleared apt cache after install
Used --no-cache-dir for pip
Optimized layer ordering

Result: Image size reduced significantly (~300MB → ~160MB)

Biggest Challenge

Connecting Flask to PostgreSQL inside Docker.

The key realization:

Containers communicate using service names, not IP addresses.

DB_HOST=db

Docker internally resolves db to the PostgreSQL container.

Once this clicked, the setup became much clearer.

Deployment

I deployed the app on AWS EC2.

Steps:

Launch EC2 instance
Install Docker
Clone project
Run Docker Compose

The application was then accessible via a public IP.

What I Learned

Docker is not just about containers.

It’s about building systems that are:

Reproducible
Isolated
Self-healing
Easy to deploy

Final Thoughts

This project was my first real experience combining backend, database, and deployment into one system.

If you're learning Docker, building and deploying even a small project like this gives much more clarity than just following tutorials.

DEV Community: Tanay Jain

How I Deployed a Flask App on AWS with RDS, ALB, and VPC as a Student

Table of Contents

Why I Built This

Initial Architecture (v1.0)

Architecture Evolution

Target Architecture (v2.0)

Tech Stack

AWS Services Used

Building a Custom VPC

Security Group Layering

IAM and Access Control

Migrating Database to Amazon RDS

Application Load Balancer

CloudWatch Monitoring

Challenges I Encountered

RDS Connectivity Issues

Health Check Design

Security Improvements

Approximate Cost

Application Endpoints

Current Limitations

What This Project Taught Me

Project Outcomes

Roadmap

Source Code

Conclusion

How I Built 5 Linux Automation Scripts on AWS EC2

🖥️ Environment

📚 Topics Covered

Linux Fundamentals

Automation & Scripting

🔧 The 5 Automation Scripts

1. Server Health Check

2. Disk Usage Alerter

3. Log Cleaner

4. User Creation Script

5. Backup Script

⏱️ Cron Job Automation

💡 Biggest Learnings

1. Linux becomes comfortable through repetition

2. Automation changes how you think

3. Real infrastructure teaches different lessons

🚀 What's Next

📁 GitHub Repository

My CI Pipeline Failed on the First Push. Here's What I Learned.

The Project

Why I Added CI

What I Built

What Each Step Does

The First Run Failed

The Health Endpoint

Architecture

Project Versioning

What Actually Changed

Three Things CI Taught Me Practically

Links

From Zero to Deployment: Dockerizing a Flask + PostgreSQL App on AWS

The Idea

Tech Stack

Architecture

Key Concepts I Implemented

🔹 Multi-container system

🔹 Environment variables (.env)

🔹 Health checks

🔹 Auto-restart

🔹 Optimized Dockerfile

Biggest Challenge

Deployment

What I Learned

Links

Final Thoughts