AWS Multi-Tier Network

The Vision: Deep Defense in the Cloud

Standard single-tier architectures often leave web servers exposed directly to the public internet, creating an unnecessarily large attack surface. I designed this **Multi-Tier Secure Network** to implement the 'Defense in Depth' strategy. By isolating the application logic in a completely private layer and controlling all ingress/egress traffic, I created an environment where the most critical assets are invisible to the public eye.

Architectural Components & Logic

The system leverages AWS native services to create a tiered isolation model within a custom VPC (10.0.0.0/16):

Public Ingress Layer: Utilizes an Application Load Balancer (ALB) to handle all incoming HTTP traffic, shielding the backend from direct connections.
Isolated Private Layer: The Apache Web Server resides in a Private Subnet with no Public IP, making it immune to direct external scans.
Security Group Chaining: A dynamic security model where rules reference Security Group IDs rather than static IP ranges, enforcing a strict "Follow the Chain" policy.
Controlled Egress: A custom NAT Instance manages outbound connectivity for system updates, ensuring the private server can reach the internet without being reached by it.

Mistakes & Roadblocks (The Hard Way)

Building high-assurance network isolation on AWS requires precise coordination between routing and security rules.

Route Table Blackhole: Initially, the private instance couldn't fetch updates because the private route table wasn't correctly pointing to the NAT Instance's ENI.

The Fix: Reconfigured the 0.0.0.0/0 route in the private subnet to use the NAT Instance's Network Interface as the target and disabled 'Source/Dest Check' on the instance.

Circular SG Dependency: I locked myself out of the management flow by applying overly restrictive Security Group rules before the NAT Instance was fully configured.

The Fix: Implemented a "Management First" approach—establishing the Bastion/NAT connectivity before tightening the web tier's inbound rules.

Key Management Risk: Trying to manage a private server usually tempts users to upload private keys to a Bastion host, which is a major security risk.

The Fix: Employed SSH Agent Forwarding. This allowed me to "jump" through the NAT instance using my local keys without ever exposing them to the cloud environment.

Health Check Failures: The ALB was marking the healthy server as 'Unhealthy' because the Web Server SG was blocking the ALB's internal IP range.

The Fix: Transitioned to pure Security Group Chaining, allowing port 80 traffic specifically from the ALB's SG ID, ensuring seamless health checks.

Key Takeaways

Identity over IP: Using Security Group IDs instead of IP ranges makes the infrastructure more resilient to scaling and internal changes.
Visibility is Vulnerability: If a hacker cannot see an IP, they cannot exploit its services. Private subnets are the ultimate perimeter defense.
The Jumpbox Protocol: I mastered the art of managing isolated systems securely using SSH Agent Forwarding and Bastion hosts.
Cost vs. Control: Building a custom NAT Instance instead of a NAT Gateway provided deeper insight into how traffic flows and routing tables interact.

The Final Result

A fully validated, production-ready multi-tier network. The infrastructure successfully serves traffic via a public ALB while keeping the web server completely isolated in a private subnet. The design passed all validation tests for connectivity, health checks, and administrative jumpbox access.