In this project, I focused on building the foundational layer of a two-tier architecture in AWS using EC2 for the web layer and RDS for the database layer, with a clear separation between public and private resources.

This type of architecture is widely used in real-world environments because it improves both security and scalability. The web server is accessible to users, while the database remains isolated and only accepts traffic from the application layer.

My approach here was to establish a solid, functional baseline by correctly structuring networking, access control, and communication between services.

From here, the next step is to extend this architecture by introducing a load balancer to remove direct public access to the EC2 instances and distribute traffic across multiple Availability Zones. This not only strengthens security but also prepares the environment for higher availability and scalability.

Even at the foundational level, the goal was to build with that direction in mind.

Moving From Individual Services to Real Architecture

Working with EC2 and RDS individually is one thing.

Designing how they communicate securely and reliably is something else entirely.

This project focused on that transition. Not just launching resources, but making intentional decisions around networking, access, and separation between layers.

What I Built

This architecture is made up of two main layers:

• A web layer (EC2) that handles user interaction
• A database layer (RDS) that stores and retrieves data

The key was not just standing both up.

It was making sure:

• The web layer is publicly accessible
• The database layer is private
• Communication between them is controlled and intentional

Building the Network Foundation

One of the most important parts of this build was creating the networking foundation.

I built a custom VPC and separated the environment into public and private subnets across two Availability Zones. That separation gave the architecture structure and made the design much more intentional.

The EC2 instance was placed in a public subnet so the application could be reached, while the RDS instance was placed in a private subnet so that it remained isolated from direct public access.

That separation is what gives this architecture its shape.

Security Was a Big Part of the Design

Security groups were one of the most important parts of this project.

Instead of simply opening access, I had to define exactly how communication should happen:

• The EC2 instance allows HTTP/HTTPS from the internet and SSH only from my IP address
• The RDS instance does not allow public access at all
• The database only accepts traffic from the EC2 security group

That setup makes it clear that the database is not meant to be reached directly. It only exists to support the application.

This is where the architecture becomes more than just deployed resources. It becomes a designed system.

The Database Layer Stayed Private by Design

One of the most important settings during the RDS setup was:

Public access: No

That one setting reinforces the purpose of the database tier.

The database is not there to serve end users. It is there to support the application behind the scenes. Keeping it private reduces exposure and better reflects how database resources are handled in production-style environments.

Bringing the Application Online

After the infrastructure was in place, I installed Joomla on the EC2 instance and connected it to the RDS database.

This was the point where everything had to work together:

• networking
• security groups
• database configuration
• application setup

Once the Joomla installer successfully connected to the database, it confirmed that the architecture was functioning the way it was intended to.

That was the point where the build moved from infrastructure setup into a working application environment.

The Final Result

The final site itself is simple, but complete.

• The site is accessible through the EC2 public IP
• The admin panel is functional
• Content can be created and managed
• Data is being handled through the RDS database layer

That simplicity does not take away from the value of the build. In fact, it reinforces the point. The goal here was not visual complexity. The goal was solid architecture.

What This Project Reinforced

This build reinforced a few key things:

• Architecture matters more than individual services
• Security should be intentional, not assumed
• Public and private boundaries must be clearly defined
• Services should only have the access they actually need

More than anything, it highlighted the difference between:

Launching resources vs. designing systems

That is where the real value of this project lives.

A Quick Note on Scalability

Although this project focused on the foundational implementation, I also wanted the design to reflect where it can go next.

The current setup establishes a clean starting point, but it also leaves room for architectural growth. The next logical step is to introduce a load balancer, remove direct public access to the EC2 instance, and distribute traffic across multiple Availability Zones.

That progression would improve both security and availability while moving the environment closer to a more scalable production-style design.

I wanted to include this view as a reminder that even foundational builds can and should be approached with future-state thinking.

Closing Thoughts

This project was about building a strong and functional baseline.

Using EC2 and RDS in a properly structured two-tier architecture helped reinforce how web and database layers should be separated, secured, and connected.

It also created a clear path for what comes next: better traffic distribution, tighter access control, and higher availability through more scalable design choices.

For me, this project represents the kind of intentional architecture thinking that becomes more important as environments grow.

Still building. Still learning. Still leaning into Comfort in the Cloud. ☁️