# 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:

```text
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

```text
Internet
    ↓
Application Load Balancer
    ↓
EC2 Instance
    ↓
PostgreSQL RDS
```

The overall request flow works like this:

1.  A user opens the application URL
    
2.  The request reaches the Application Load Balancer
    
3.  The Load Balancer forwards traffic to the Target Group
    
4.  The Target Group routes traffic to a healthy EC2 instance
    
5.  The EC2 instance processes the request
    
6.  The application can communicate with PostgreSQL RDS if required
    
7.  The response is returned back to the user
    

![](https://cdn.hashnode.com/uploads/covers/69d24c9340c9cabf44d0c3dd/d05911c2-dde9-4936-8342-d1b3810e1380.png align="center")

# 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:

```text
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.

```text
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
    

```text
SSH 22 → My IP
HTTP 80 → ALB Security Group
```

## RDS Security Group

Allowed PostgreSQL access only from the EC2 Security Group.

```text
PostgreSQL 5432 → EC2 Security Group
```

This created a controlled communication chain:

```text
Internet → ALB → EC2 → RDS
```

Understanding this traffic flow was one of the most valuable parts of the project.

![](https://cdn.hashnode.com/uploads/covers/69d24c9340c9cabf44d0c3dd/61838977-4b13-4cdc-a891-875ae5685eef.png align="center")

# 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.

![](https://cdn.hashnode.com/uploads/covers/69d24c9340c9cabf44d0c3dd/bd328da1-0cb3-411f-98c1-b6dff4c61bbf.png align="center")

![](https://cdn.hashnode.com/uploads/covers/69d24c9340c9cabf44d0c3dd/d3b11ad2-52cd-4b70-9928-20f79f62e5d0.png align="center")

![](https://cdn.hashnode.com/uploads/covers/69d24c9340c9cabf44d0c3dd/b1787e12-8e69-4df0-b7e8-1668e0914a1b.png align="center")

# 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.

## Connect With Me

*   GitHub: https://github.com/KamleshDevopsAndCloud
    
*   LinkedIn: https://linkedin.com/in/kamlesh-dubale