Building a Secure and Scalable Web Architecture on AWS: A Step-by-Step Guide

In the rapidly evolving cloud landscape, establishing a robust and secure infrastructure is paramount. This project demonstrates a hands-on approach to constructing a highly secure, scalable, and professional-grade web architecture on Amazon Web Services (AWS). Our goal was to design an environment where public-facing web resources can coexist safely with private backend services, ensuring controlled internet access and stringent security.

This architecture leverages fundamental cloud security principles such as network isolation, controlled routing, and secure connectivity. Every component is designed to contribute to a resilient and secure operational environment.

Project Overview: Securing Your Cloud Presence

The primary objective was to build a secure AWS network with distinct public and private segments. A web server residing in the public section is made accessible to the internet, while a database server in the private section remains shielded from direct external access. Crucially, the private database server maintains secure outbound internet connectivity through a NAT Gateway for updates and patches without exposing itself to inbound threats.

Final Architecture Highlights:

• Virtual Private Cloud (VPC): A logically isolated virtual network dedicated to our AWS resources.
• Public Subnet: Hosts public-facing resources like web servers, allowing direct internet access.
• Private Subnet: Dedicated to backend resources like database servers, isolated from direct internet access.
• Internet Gateway (IGW): Enables public subnets to connect with the internet.
• NAT Gateway: Allows instances in private subnets to initiate outbound connections to the internet while preventing unsolicited inbound connections.
• Route Tables: Define network traffic flow within the VPC and to/from the internet.
• Security Groups: Act as virtual firewalls, controlling inbound and outbound traffic for EC2 instances.
• EC2 Instances: Hosts for our web application (public) and database (private).

Phase 1: Foundation Setup – Building Your Private Network (VPC)

The first step involved creating a Virtual Private Cloud (VPC) named My-Secure-VPC with an IPv4 CIDR block of 10.0.0.0/16, providing a large address space for our resources. Within this VPC, we established two key subnets:

• public-subnet-1: Configured for public-facing resources with a CIDR block of 10.0.1.0/24.
• private-subnet-1: Dedicated to private resources, using a CIDR block of 10.0.2.0/24. Both subnets were placed in the same Availability Zone for simplicity in this demonstration.

Phase 2: Routing & Security – Controlling Traffic Flow

With our VPC and subnets in place, the next phase focused on establishing controlled network traffic and security:

• Internet Gateway (IGW): An Internet Gateway named My-IGW was created and attached to My-Secure-VPC. This acts as the entry and exit point for internet traffic to and from the VPC.
• Public Route Table: A Public-Route-Table was configured to direct all internet-bound traffic (0.0.0.0/0) through My-IGW. This route table was then associated with public-subnet-1, ensuring instances within it could reach the internet.
• Security Group for Web Server: A Web-Server-SG security group was created to act as a firewall for our public web server. It was configured to allow inbound HTTP traffic from anywhere (0.0.0.0/0) and SSH access from a specific IP address (your computer’s IP), ensuring controlled administrative access.

Phase 3: NAT Gateway – Enabling Private Outbound Internet Access

To allow our private database server to access the internet for tasks like software updates without being publicly accessible, a NAT Gateway was implemented:

• Elastic IP Allocation: A static public IP address (Elastic IP) was allocated. This IP address will be associated with the NAT Gateway.
• NAT Gateway Creation: A My-NAT-Gateway was created and placed within public-subnet-1, associating it with the previously allocated Elastic IP. This gateway serves as a conduit for outbound traffic from the private subnet.
• Private Route Table: A Private-Route-Table was established. All internet-bound traffic (0.0.0.0/0) from instances associated with this table is routed through My-NAT-Gateway. This route table was then associated with private-subnet-1, ensuring private instances can securely access the internet.

Phase 4: Resource Deployment – Launching Your Servers

With the network infrastructure fully configured, we proceeded to deploy our application components:

• Web Server (Public Subnet): An EC2 instance named Web-Server was launched in public-subnet-1. It utilized an Amazon Linux AMI, t2.micro instance type, and was assigned Web-Server-SG for security. Crucially, “Auto-assign Public IP” was enabled, and a user data script was included to automatically install and start an Apache web server on boot, displaying a “Hello World” message.
• Database Server (Private Subnet): A DB-Server EC2 instance was launched in private-subnet-1. This instance also used an Amazon Linux AMI and t2.micro type. Critically, “Auto-assign Public IP” was disabled, ensuring it remained completely private. The same SSH key pair was used for both instances for consistent access.

Phase 5: Validation – Testing Your Setup

Thorough testing confirmed the architecture’s functionality and security:

• Web Access Test: By navigating to the Web-Server‘s Public IPv4 address in a web browser, the “Hello World” message was successfully displayed, confirming public accessibility.
• Private Instance Internet Access Test (via NAT):
  1. SSH was established to the Web-Server (public instance).
  2. From within the Web-Server, an SSH connection was initiated to the DB-Server‘s Private IPv4 address, confirming internal network connectivity.
  3. Finally, from the DB-Server, a `curl https://checkip.amazonaws.com` command was executed. The returned IP address was the Elastic IP of the NAT Gateway, conclusively proving that the private server could access the internet securely through the NAT Gateway, without exposing its own private IP.

Conclusion

This project successfully demonstrates the creation of a secure and professional-grade network architecture on AWS. The web server is publicly accessible, serving content to the internet, while the database remains securely isolated within a private network. Despite its privacy, the database server can still securely download necessary updates and patches via the NAT Gateway. This setup embodies best practices for cloud security and network design, providing a solid foundation for deploying robust applications in the cloud.