What Actually Happens When You Type “google.com” Into a Browser? I Built a Web Application to Find Out
Hi there,
As part of my AltSchool Cloud Engineering second semester project, I was given a practical task: deploy a basic web application using PHP, backed by a MySQL database, on real cloud infrastructure.
The assessment involved setting up two EC2 instances, configuring a Web Server and Database Server, connecting the application to the database, automating part of the server setup with Bash, and setting up a cron job for automated logging.
If you’ve read my previous article, you already know I’m currently on a learning journey to become a Cloud Engineer. Semester 2 is about to come to an end, and honestly, there’s still so much to learn! 😅
For one of my Semester 2 assessments, I worked with Amazon S3, where I deployed a simple website and made it publicly accessible.
If you haven’t read it yet, you can check it out here: Deploying a Simple Website Using Amazon S3.
This time, things got a little more interesting.
So, what actually happens when a user enters my IP address?
What I Built
For this assessment, I worked with two EC2 instances.
The first was my Web Server, where I installed Apache and PHP.
The second was my Database Server, where I installed MySQL.
The goal was to get these two servers working together while keeping the database separate from the part of the application that users could access.
The basic flow was:
User → Web Server → Database Server
I also configured the security groups so that MySQL traffic on Port 3306 could only come from my Web Server.
Here’s what the architecture looked like:
So, What Actually Happens When a User Enters My IP Address?
When I enter my Web Server’s IP address into a browser and press enter, the browser needs to communicate with that server and request my webpage.
Because I’m entering the IP address directly, DNS isn’t needed to find the server.
The browser connects to my Web Server through Port 80, since my application is using HTTP.
Apache receives the request and processes my PHP application.
My PHP application then connects to the MySQL Database Server using its private IP address and retrieves the student record I stored there.
PHP uses that information to generate the webpage, and the finished page is sent back to my browser.
The browser then displays the result.
In simple terms:
Browser → Apache/PHP → MySQL → PHP/Apache → Browser
And that’s what is happening behind the scenes when I enter my Web Server’s IP address and see my application.
#!/bin/bash — Automating My Web Server Setup
Instead of manually installing everything on my Web Server, I created a Bash script called setup-web.sh to automate the initial setup.
The script handles:
- Updating the system packages
- Installing Apache
- Installing PHP
- Starting Apache
- Making sure Apache starts automatically when the server boots
- Logging a successful setup to
/var/log/setup.log
setup-web.shAfter creating the script, I made it executable using:chmod +x setup-web.sh
Get Sophiatfakoya’s stories in your inbox
Join Medium for free to get updates from this writer.
I then ran the script and checked the log to confirm that the setup was completed successfully.
setup-web.shThe idea was simple: instead of typing the same commands manually, I could put them into a script and run them whenever I needed to set up a Web Server.
That’s one thing I’m beginning to understand about automation: do it once, make it repeatable.
Connecting My PHP Application to MySQL
Once my Web Server was ready, I set up MySQL on the Database Server.
I created a database called studentdb and a students table with an id and name. I also added a student record to the table.
The next step was getting my PHP application to communicate with MySQL.
My PHP application connects to the Database Server using its private IP address and retrieves the student record from the students table.
At first, I ran into a “Could not find driver” error. After checking the issue, I found that the PHP MySQL package wasn’t installed on my Web Server.
I installed php-mysql, restarted Apache, and tried the connection again.
This time, it worked, and the student information from MySQL appeared on my webpage.
This was a good reminder that all the different pieces of the application have to work together. The Web Server, PHP, and Database Server each have their own role, but the application needs all of them working together to display the final result.
The Cron Job
I also set up a cron job to run every minute and record the current date, time, and server uptime in /var/log/uptime.log.
I checked the scheduled task with crontab -l and confirmed that new entries were being added to the log automatically.
crontab -lThis showed me a simple but useful way of automating repetitive server tasks.
What If the Application Gets More Traffic?
For this assessment, I only deployed one Web Server. But if the application needed to handle more traffic, I could add another Web Server and a Load Balancer.
The Load Balancer would sit in front of the Web Servers and distribute incoming requests between them.
I included both in my architecture diagram as Future Deployment to show how the setup could be expanded.
Challenges I Ran Into
It wasn’t completely smooth sailing. A few things went wrong along the way:
- Apache showed the default page: I removed the default
index.htmlso my PHP application could load. - PHP couldn’t connect to MySQL: I got a “Could not find driver” error, which was fixed by installing
php-mysql. - My Database Server ran out of memory: I initially used a
t3.microinstance, but MySQL kept running out of memory. I increased the Database Server to at3.small, and MySQL ran properly afterwards.
Each problem gave me a chance to troubleshoot and understand what was actually happening instead of just following steps.
What I Learned From This Project
This project was more than just getting a website to load.
I got to see how a Web Server and Database Server communicate, how PHP connects the two, and how automation can make server setup easier and more repeatable.
I also learned that things don’t always work on the first try. From troubleshooting the PHP connection to dealing with the Database Server running out of memory, I had to actually investigate the problems and figure out what needed to change.
There’s still a lot I’m learning, but I’m starting to understand the bigger picture of how the different pieces of cloud infrastructure fit together.
One project at a time. One problem at a time. And hopefully, a little less confusion each time.
That’s it for this one.
Thanks for reading, and I’ll see you in the next one! 👋🏽






