Deploying a full, three-tier book review web app on Azure

#architecture #azure #devops #networking

I designed and deployed one of my most hands-on cloud engineering projects: deploying a secure, scalable book review application using a full three-tier architecture on Microsoft Azure.
But the real growth came from the challenge I hit along the way and how I solved it.

The Problem I Encountered
After deploying the backend (Node.js/Express) for the book review app in private subnets, the frontend couldn’t reach it.
The internal load balancer was healthy, and the backend was running on port 3001, but every request from the frontend timed out.
Everything looked correct: subnets, routes, health probes, VM status—yet the app simply wouldn’t connect.

How I Solved It
The issue turned out to be a Network Security Group (NSG) misconfiguration.
The App Tier NSG wasn’t allowing inbound traffic from the Web Tier on port 3001, even though the internal load balancer was configured correctly.

I fixed it by:
•Updating the App Tier NSG
•Allowing inbound traffic only from the Web Tier NSG
•Opening port 3001 specifically for internal communication
As soon as that rule was added, the Book Review app connected instantly.
This experience reinforced a key lesson: Azure NSGs don’t assume trust; you must define it explicitly.

What I Built
Here’s the full architecture behind the book review app:
Frontend (Web Tier)
•Next.js served via Nginx on Ubuntu
•Behind a Public Azure Load Balancer
•Lives in public subnets only
Backend (App Tier)
•Node.js/Express API on port 3001
•Deployed in private subnets
•Accessible only through an Internal Load Balancer
Database (Data Tier)
•Azure Database for MySQL Flexible Server
•Multi-AZ high availability
•Read replica for scaling
•NSGs allowing only App Tier traffic on port 3306
Networking
•Custom VNet (10.0.0.0/16)
•6 subnets across 2 zones
•Strict NSGs per tier
•No public exposure for backend or database