Build Your First Secure AWS VPC: Public/Private Subnets, NAT Gateways & Web Servers!

Salome GithinjiSalome Githinji
5 min read

Introduction

As a cloud enthusiast and gaining more knowledge on the cloud, I recently built a production-ready VPC with public and private subnets, NAT gateways, and a secure web server. This guide walks you through the exact steps I used.

🎯 What We’ll Achieve

Secure Network Isolation: VPC with public/private subnets
Internet Access Control: NAT gateway for private resources
High Availability: Subnets across two Availability Zones (AZs)
Web Server Deployment: Apache/PHP app with auto-launch script

🔑 Key AWS Components Explained

1. VPC (Virtual Private Cloud)

  • What: Your private network in AWS (like a virtual data center).

  • Why: Isolate resources, control IP ranges (we used 10.0.0.0/16).

2. Subnets

  • Public Subnet: Routes traffic to the internet (web servers).

  • Private Subnet: No direct internet access (databases, internal apps).

  • Why: Security + scalability. We created:

    • Public Subnet 1 (10.0.0.0/24)

    • Private Subnet 1 (10.0.1.0/24)

    • Public Subnet 2 (10.0.2.0/24)

    • Private Subnet 2 (10.0.3.0/24)

3. Internet Gateway (IGW)

  • What: Gateway for public subnet internet access.

  • Why: Allows SSH/web traffic into public subnets.

4. NAT Gateway

  • What: Allows outbound internet access for private subnets.

  • Why: Private instances can download updates without exposing them to the internet.

5. Route Tables

  • Public Route Table: Sends 0.0.0.0/0 traffic → IGW.

  • Private Route Table: Sends 0.0.0.0/0 traffic → NAT Gateway.

6. Security Groups

  • What: Firewall at the instance level (stateful).

  • Why: We created Web Security Group allowing HTTP (port 80) from anywhere.

7. EC2 Instance

  • What: Virtual server hosting our web app.

  • Why: Deployed in Public Subnet 2 with auto-assigned public IP.

🚀 Step-by-Step Build Guide

Step 1: Create VPC with Subnets & NAT Gateway

The key difference between "VPC only" and "VPC and more" in AWS is automation—"VPC only" creates just the virtual network, requiring manual setup of subnets, route tables, and gateways, while "VPC and more" (the wizard) automates everything: it provisions a complete network stack including public/private subnets, an internet gateway, NAT gateway (for private subnets), and pre-configured route tables, making it ideal for rapid deployments with AWS best practices, whereas "VPC only" is better for custom architectures needing granular control.

  1. Go to VPC DashboardCreate VPC"VPC and more".

  2. Configure:

    • Name: Lab VPC

    • IPv4 CIDR: 10.0.0.0/16

    • AZs: 1 (we’ll add a second later)

    • Public Subnets: 110.0.0.0/24

    • Private Subnets: 110.0.1.0/24

    • NAT Gateway: In 1 AZ

  3. Name resources:

    • Subnets: Public Subnet 1, Private Subnet 1

    • Route Tables: Public Route Table, Private Route Table

💡 Why NAT in 1 AZ? Cost optimization (NAT gateways aren’t free).

Step 2: Add High Availability (Second AZ)

In the second task you create two additional subnets in a second Availability Zone. This option is useful for creating resources in multiple Availability Zones to provide high availability.

  1. Create a Subnet named Public Subnet 2:

    • CIDR: 10.0.2.0/24 → AZ: No preference

    • VPC ID: From the dropdown list, choose Lab VPC.

  2. Create Subnet Private Subnet 2 2:

    • CIDR: 10.0.3.0/24 → AZ: No preference

    • VPC ID: From the dropdown list, choose Lab VPC.

  3. Associate subnets with route tables:

    In the left navigation pane, select Route Tables, then choose the Public Route Table and navigate to the Subnet associations tab; under Subnets without explicit associations, click Edit subnet associations, check the box for Public Subnet 2, and save the changes. Next, configure the private subnets by selecting the Private Route Table, going to the Subnet associations tab, clicking Edit subnet associations, checking Private Subnet 2, and saving the associations—ensuring proper routing for both public and private subnets.

    • Public Subnet 2Public Route Table

    • Private Subnet 2Private Route Table

🌟 Pro Tip: Always deploy resources in ≥2 AZs for fault tolerance!

Step 3: Secure Web Traffic

In this task, you create a VPC security group, which acts as a virtual firewall for your instance. When you launch an instance, you associate one or more security groups with the instance.

  1. Create Security Group:

    • Name: Web Security Group

    • Type: Choose HTTP.

    • Source: Choose Anywhere IPv4.

    • Description: Enter Permit web requests

    • Choose Create security group.

Step 4: Launch Web Server

  1. In EC2 Console:

    • AMI: Amazon Linux 2 AMI (HVM)

    • Instance Type: t3.micro

    • Subnet: Public Subnet 2

    • VPC - required: Choose Lab VPC.

    • Auto-assign Public IP: ✅ Enable

    • Security Group: Web Security Group

    • Key Pair: You create and download a new key pair

  2. User Data (auto-installs Apache/PHP):

     #!/bin/bash
     yum install -y httpd mysql php
     wget https://aws-tc-largeobjects.s3.us-west-2.amazonaws.com/CUR-TF-100-RESTRT-1/267-lab-NF-build-vpc-web-server/s3/lab-app.zip
     unzip lab-app.zip -d /var/www/html/
     chkconfig httpd on && service httpd start
    

Step 5: Verify

  1. Wait for instance Status Checks2/2.

  2. Copy Public IPv4 DNS → Paste in browser.

  3. See "Web Server Ready" page! 🎉


🔐 Security Best Practices

  • Public Subnets: Only for resources needing internet access (load balancers, web servers).

  • Private Subnets: Use for databases/internal services (no direct internet exposure).

  • NAT Gateway: Critical for private subnet updates (but monitor costs).

  • Security Groups: Restrict access (e.g., only HTTP/80 for web servers).


💡 Why This Architecture Rocks

  1. Security: Database in private subnet → hackers can’t reach it.

  2. Scalability: Add more subnets/instances in minutes.

  3. High Availability: Multi-AZ deployment survives zone failures.

  4. Automation: User data scripts deploy apps instantly.

Happy Coding !!! 😊

1
Subscribe to my newsletter

Read articles from Salome Githinji directly inside your inbox. Subscribe to the newsletter, and don't miss out.

Written by

Salome Githinji
Salome Githinji