In this project, a basic cloud architecture was deployed using two virtual servers on AWS. One server hosts a web application using Apache and PHP, while the other hosts a MySQL database. The goal is to understand what happens behind the scenes when a user enters a web server’s IP address in a browser and how different systems communicate to deliver a response.
1. What Happens When a User Enters an IP Address in a Browser
When a user enters the public IP address of a web server into a browser, several layers of communication are triggered before any content is displayed.
At a high level, the process involves:
- IP addressing to locate the server
- A TCP connection to establish communication
- An HTTP request sent from the browser
- An HTTP response returned by the server
Each of these layers plays a critical role in delivering a working web application.
2. IP Addressing: Locating the Server
An IP address acts as the unique identifier of a machine on a network.
When a user enters something like:
http://<web-server-public-ip>
the browser uses that IP address to locate the server directly over the internet. Unlike domain-based systems that require DNS resolution, this setup communicates directly with the server using its public IPv4 address.
In this architecture, the web server is hosted on an AWS EC2 instance with a public IP, making it accessible over the internet through properly configured security group rules.
3. TCP Connection: Establishing Communication
Before any web data is exchanged, a TCP (Transmission Control Protocol) connection must be established between the client (browser) and the server.
This happens through a process called the TCP three-way handshake:
- The browser sends a SYN request to the server
- The server responds with SYN-ACK
- The browser replies with ACK
Once this handshake is complete, a stable connection is established between both systems, allowing data transfer to begin.
This ensures reliability, ordering, and error checking during communication.
4. HTTP Request and Response Cycle
After the TCP connection is established, the browser sends an HTTP request to the web server.
Example:
GET / HTTP/1.1
Host: <server-ip>
The Apache web server receives this request and processes it. Since the application is built using PHP, the server passes the request to the PHP interpreter.
The PHP script then executes logic that may include database queries and dynamic content generation.
Finally, the server returns an HTTP response such as:
- HTML content
- Text output
- Database-driven data
This response is rendered in the user’s browser.
5. Architecture Overview of the System
The deployed architecture consists of the following components:
- User (Browser)
- Internet
- Web Server (Apache + PHP on EC2)
- Database Server (MySQL on EC2)
Architecture Flow:
User Browser
↓
Internet
↓
Web Server (EC2 - Apache + PHP)
↓
Database Server (EC2 - MySQL via private IP)
A key design decision in this architecture is that the database server is not publicly accessible. It only communicates with the web server using its private IP address over port 3306.
This ensures better security and separation of concerns.
6. How the Web Server Connects to the Database
The web application running on the web server uses PHP to connect to the MySQL database hosted on a separate EC2 instance.
The connection is established using:
- Database private IP address
- MySQL username and password
- Database name (
studentdb)
Example flow:
- PHP script runs on web server
- Script initiates MySQL connection using private IP
- Database server validates credentials
- SQL query is executed
- Results are returned to the web server
- Output is displayed in the browser
If no records exist in the database, a manual insertion is performed to ensure output is visible.
This separation ensures that the database is never exposed to the public internet.
7. Benefits of This Architecture
This setup provides several advantages:
1. Security
The database is isolated in a private network and cannot be accessed directly from the internet.
2. Separation of Concerns
The web server handles application logic while the database server handles data storage.
3. Scalability
Additional web servers can be added behind a load balancer without modifying the database layer.
4. Reliability
Failure in the web layer does not directly affect the database layer.
8. How Ansible Was Used for Automation
Ansible was used to automate the configuration of the web server.
Instead of manually installing Apache and PHP, an Ansible playbook was created to:
- Install Apache
- Install PHP modules
- Start and enable Apache service
This ensured consistency and reduced human error during setup.
Using SSH-based automation, the web server was configured in a repeatable and efficient manner.
9. Challenges Faced and Solutions
Challenge 1: SSH Connection Issues
Initially, SSH access to the EC2 instance failed due to incorrect key permissions.
Solution: File permissions were corrected using:
chmod 400 key.pem
Challenge 2: Database Connection Failure
The web server could not initially connect to MySQL.
Solution: The issue was resolved by:
- Allowing port 3306 access from the web server security group
- Using the correct private IP of the database server
Challenge 3: Apache Not Serving PHP Files
PHP files were not being executed correctly.
Solution: PHP module for Apache was installed and the service restarted.
10. Architecture Diagram
The architecture of the system is shown below:
┌───────────────┐
│ User │
└──────┬────────┘
│
┌──────▼────────┐
│ Internet │
└──────┬────────┘
│
┌─────────────▼─────────────┐
│ Web Server (EC2) │
│ Apache + PHP + Ansible │
└──────┬─────────┬──────────┘
│ │
│ │
(HTTP 80) │ SSH (22)
│ │
▼ ▼
┌──────────────┐ ┌────────────────┐
│ Database │ │ Ansible Node │
│ Server EC2 │ │ (Local Machine)│
│ MySQL 3306 │ └────────────────┘
└──────────────┘
Conclusion
This project demonstrates how modern web applications are structured in cloud environments. By separating the web and database layers, enforcing secure networking rules, and automating configuration using Ansible, a scalable and secure architecture was achieved.
Understanding how requests flow from a browser through the network layers down to the database is fundamental to cloud engineering and system design.
