🌍 Scalable Travel Journal (AWS 3-Tier Architecture)

🎯 Objective

Architected and deployed a secure, highly available 3-tier web environment on AWS. This infrastructure supports a full-stack "Travel Journal" web app, allowing users to securely save and retrieve global itineraries from an isolated database. The application was deployed and validated in a sandbox AWS environment used for hands-on cloud architecture training.

🗺️ Architecture Diagram

⚙️ Tech Stack

• Frontend: React.js, Tailwind CSS, Vite (Hosted on Amazon S3)

• Backend: Node.js, Express.js (Hosted on Amazon EC2)

• Database: MySQL (Hosted on Amazon RDS)

• AWS Networking & Compute: VPC, Application Load Balancer, Auto Scaling Groups, NAT/Internet Gateways

• Security: Stateful Security Groups, IAM Roles

🧩 System Architecture

This project implements a classic 3-tier web architecture:

• Presentation Tier: React frontend hosted on S3
• Application Tier: Node.js API running on EC2 Auto Scaling Group
• Data Tier: MySQL database on Amazon RDS in private subnets

Traffic flows through an Application Load Balancer to ensure scalability and high availability.

🔄 Application Data Flow

1. 💻 Presentation (Amazon S3): Users access the React frontend hosted globally as a static website on Amazon S3.

2. 🌐 Routing (Application Load Balancer): Frontend API requests hit the internet-facing ALB, acting as a reverse proxy.

3. ⚙️ Compute (Amazon EC2 & ASG): The ALB routes traffic to healthy Node.js servers in an Auto Scaling Group. Zero-Trust Security Groups ensure these servers only accept traffic from the ALB.

4. 🗄️ Data (Amazon RDS): The API securely queries a MySQL database isolated in private subnets, accepting traffic exclusively from the compute layer on Port 3306.

🧪 Deployment Environment

This project was deployed in a restricted AWS training sandbox environment.

Due to sandbox limitations:

• Public endpoints cannot remain active after the lab session ends
• NAT Gateway and some production services were restricted
• Infrastructure was provisioned manually through the AWS Console

Despite these limitations, the full 3-tier architecture was successfully deployed and tested within the environment.

Auto Scaling Group Instance Management

App Load Balancer Resource Map

*Auto Scailing Groups EC2 Instances

MySQL RDS

🧠 Challenges Faced & Lessons Learned

• 🔒 Zero-Trust Network Routing: * Challenge: Initial bastion host timed out connecting to the RDS database (Error 2002).

  • Solution: Instead of opening the DB to the public internet, I mapped stateful AWS Security Groups to enforce the Principle of Least Privilege.

  • Impact: Established a secure, isolated data tier that explicitly trusts only the application tier.

• 🔀 Reverse Proxy Configuration: * Challenge: Frontend API calls to the load balancer were timing out.

  • Solution: Identified a port mapping mismatch. Configured the ALB to listen on standard HTTP (Port 80) while forwarding to EC2 target groups on the custom application port (TCP 8080).

  • Impact: Successfully decoupled frontend internet traffic from backend infrastructure processing.

• 🔄 Immutable Deployments: * Challenge: A backend Node.js API route required an update without causing downtime.

  • Solution: Avoided the anti-pattern of SSHing into live servers. Instead, I updated the EC2 Launch Template code and triggered a rolling instance refresh via the Auto Scaling Group.

  • Impact: Achieved a zero-downtime deployment while maintaining configuration consistency across the compute fleet.

☁️ Cloud Skills Demonstrated

• Designing a 3-tier AWS architecture
• Configuring VPC networking and subnets
• Deploying Auto Scaling Groups
• Implementing Application Load Balancers
• Secure RDS database connectivity
• Applying least privilege security groups
• Performing zero-downtime deployments

🔮 Future Improvements

• Add CloudFront CDN
• Implement CI/CD with GitHub Actions
• Add AWS WAF for web security
• Migrate backend to containerized ECS service