Building a Production-Style Three-Tier Architecture on AWS
As I continue learning cloud engineering and DevOps, I wanted to move beyond static website hosting and start understanding how real-world applications are architected inside cloud environments.
Most production applications are not hosted on a single server directly exposed to the internet. Instead, they follow layered architectures focused on:
security
scalability
controlled communication
network isolation
traffic management
To better understand these concepts, I built a production-style three-tier architecture on AWS using:
Amazon VPC
Public and Private Subnets
EC2
PostgreSQL RDS
Application Load Balancer (ALB)
Security Groups
Target Groups and Health Checks
This project helped me understand not only how AWS services work individually, but more importantly how they communicate with each other inside a real cloud environment.
What is a Three-Tier Architecture?
A three-tier architecture separates infrastructure into three logical layers:
Presentation Layer → Application Layer → Database Layer
In this project:
The Application Load Balancer (ALB) acted as the presentation layer
The EC2 instance acted as the application layer
The PostgreSQL RDS database acted as the database layer
This architecture pattern is commonly used because it improves:
scalability
security
maintainability
reliability
Final Architecture
Internet
↓
Application Load Balancer
↓
EC2 Instance
↓
PostgreSQL RDS
The overall request flow works like this:
A user opens the application URL
The request reaches the Application Load Balancer
The Load Balancer forwards traffic to the Target Group
The Target Group routes traffic to a healthy EC2 instance
The EC2 instance processes the request
The application can communicate with PostgreSQL RDS if required
The response is returned back to the user
Designing the Network Architecture
The first step was creating a custom VPC to isolate the infrastructure inside a private AWS network.
Inside the VPC, I created multiple subnets to separate internet-facing resources from protected backend services.
Public Subnets
The public subnet hosted:
Application Load Balancer
EC2 Instance
These subnets had internet access configured using:
0.0.0.0/0 → Internet Gateway
Private Subnets
The private subnet was used for PostgreSQL RDS.
The idea behind this design was simple:
Users should access the application
Users should never directly access the database
This separation is one of the most important concepts in cloud architecture.
Configuring Security Groups
One of the biggest learning experiences from this project was understanding how communication between services is controlled using Security Groups.
I configured three different Security Groups:
ALB Security Group
Allowed HTTP traffic from the internet.
HTTP 80 → 0.0.0.0/0
EC2 Security Group
Allowed:
SSH access only from my public IP
HTTP traffic only from the ALB Security Group
SSH 22 → My IP
HTTP 80 → ALB Security Group
RDS Security Group
Allowed PostgreSQL access only from the EC2 Security Group.
PostgreSQL 5432 → EC2 Security Group
This created a controlled communication chain:
Internet → ALB → EC2 → RDS
Understanding this traffic flow was one of the most valuable parts of the project.
Application Load Balancer and Target Groups
An internet-facing Application Load Balancer (ALB) was created to distribute incoming traffic.
Instead of exposing the EC2 instance directly to users, the ALB acted as the public entry point.
The ALB forwarded traffic to a Target Group containing the EC2 instance.
One concept that became much clearer during this project was the purpose of health checks.
The Target Group continuously checks whether the EC2 instance is healthy and capable of handling traffic.
If the server becomes unhealthy, traffic stops being forwarded automatically.
This is an extremely important reliability feature used in production systems.
Challenges Faced During Implementation
This project involved a significant amount of troubleshooting and debugging.
Some of the biggest challenges included:
unhealthy target groups
Security Group configuration mistakes
region mismatch confusion
identifying public vs private subnets
ALB communication issues
One major issue occurred when the Target Group continuously showed the EC2 instance as unhealthy.
After debugging the networking flow carefully, I discovered that the EC2 Security Group was not correctly allowing HTTP traffic from the ALB Security Group.
Fixing this helped me better understand how traffic actually moves through AWS infrastructure.
Another important learning was understanding that subnets become public or private based on Route Table configuration rather than subnet names themselves.
Key Learnings
This project helped me gain hands-on understanding of:
AWS networking
VPC design
Security Groups
Load Balancers
Target Groups
Health Checks
Public vs Private networking
Cloud troubleshooting
One of the biggest takeaways from this project was realising that cloud engineering is heavily focused on:
networking
communication flow
security
debugging
rather than simply deploying services.
Conclusion
This project helped bridge the gap between theoretical AWS knowledge and practical cloud architecture implementation.
Rather than simply launching services, the project focused heavily on understanding:
secure communication between services
traffic flow
network isolation
cloud troubleshooting
production-style architecture design
The debugging process throughout the project was especially valuable because it provided insight into how real infrastructure problems are identified and resolved in cloud environments.
This project also gave me much more confidence in understanding how different AWS services work together as part of a complete system.