How I Deployed and Automated a Scalable 2-Tier Cloud Architecture on AWS

What Actually Happens When You Type My Server’s IP Into a Browser

Nobody tells you how uncomfortable it feels to stare at a blank AWS console with a task in front of you and genuinely not know which service to click first. There is a version of this story where everything went smoothly and I knew exactly what I was doing. This is not that version.

Starting With a Diagram Because I Had To

The first thing I did was open a blank document and start drawing. Not because I was being disciplined about architecture. Mostly because looking at the AWS console without a plan felt like walking into a supermarket hungry with no list. You will leave with something. Just not necessarily what you needed.

Two servers. Two jobs.

The web server sits on the public side. EC2 running Apache and PHP, facing the internet, handling every request that comes in. The database server sits behind it. EC2 running MySQL, no public access, only visible to the web server. Everything else stays outside.

I also drew where a load balancer and a second web server would eventually go. Dotted lines. Nothing built there. But the space exists in the design so when traffic grows the architecture does not have to be torn apart to accommodate it. That part felt like good thinking at the time. Still does.

IP Addressing: Where It Starts

Every device on the internet has an IP address. It is a numerical label that tells the network where to send information. When you type my server’s IP address into your browser, you are essentially writing a postal address on an envelope. The internet figures out how to deliver it.

In this setup two IP addresses matter. The web server has a public IP, which is the one you type. The database server has only a private IP, meaning it exists inside the network but cannot be reached from outside it. That distinction is the most important security decision in the entire architecture.

The TCP Connection: Before Anything Loads

Before your browser and my server exchange a single byte of useful data, they need to confirm they can actually talk to each other. This happens through a TCP handshake.

Your browser sends a SYN packet, essentially saying I want to connect. My server responds with SYN-ACK, confirming it received that and is ready. Your browser sends back an ACK, confirming it received the confirmation. Three packets. Milliseconds. Only after that handshake completes does any real communication begin.

The HTTP Request and What Happens Next

With the connection established, your browser sends an HTTP GET request asking for index.php. Apache receives it, hands it to PHP to process, and PHP figures out what data is needed to build the response. That is where the database comes in.

The Architecture: How the Two Servers Talk

Internet
    |
[Your Browser]
    |
    | (Public IP - Port 80)
    |
[Web Server - EC2]
Apache + PHP
    |
    | (Private IP - Port 3306)
    |
[Database Server - EC2]
MySQL

PHP reaches out to the database using its private IP address over port 3306. That request never touches the public internet. The database processes the query, sends the data back to PHP, PHP builds the HTML response, Apache sends it back to your browser, and the page loads.

The dotted lines below show where the architecture grows when traffic demands it.

Internet
    |
[Elastic Load Balancer]  <-- future
    |           |
[Web Server 1] [Web Server 2]  <-- future
         |
    [Database Server]

Nothing needs to be redesigned when that time comes. The space is already planned for.

Benefits of This Setup

Keeping the database off the public internet is the most important decision in this entire architecture. A database that cannot be reached from outside cannot be attacked from outside. Every query, every record, every piece of sensitive data stays inside the private network where it belongs.

The separation also means both servers can be scaled, updated, or replaced independently. If the web server needs more resources, the database is untouched. If the database needs to be migrated, the web layer keeps running. Nothing is coupled in a way that makes changes dangerous or unpredictable.

One Command Instead of Twenty

After configuring the first server manually, every package, every service, every config line, I was not excited about doing it again.

Ansible fixed that. One Playbook covering the full setup. Apache, PHP, services enabled on boot, everything in sequence. It runs with:

ansible-playbook install_lamp.yml

A brand new EC2 instance becomes a fully configured web server in seconds. Consistent output every time regardless of who runs it or when. That reliability is what made it worth the time it took to write.

Where It Got Uncomfortable

The SSH connection to the database server just hung. No error, no timeout message for a while, just nothing coming back. I checked the obvious things first. Then the less obvious things. Eventually traced it back to the Security Groups. Port rules that were not doing what I thought they were doing. Opened port 22 to my IP only, closed everything else properly this time, and it connected.

The MySQL situation was its own thing entirely. Access denied every time the application tried to connect. The credentials looked right. The user existed. Still nothing. I got into the root session through sudo mysql, fixed the user permissions from there, and the application finally pulled the student record through and displayed it.

Seeing that data on the page after everything was a quieter moment than I expected. Mostly just relief.

What the Project Left Me With

The architecture is straightforward on paper. Two servers, automation, security groups, a private subnet keeping the database out of reach.

Building it is where the understanding actually comes from. Why the database sits private instead of just that it does. What Ansible is solving for. What is happening in the network between a request and a response.

There is a gap between reading about something and having it work in front of you. This project sat in that gap the whole way through.