How does an AWS VPC work, and how would you design it to securely host a public-facing web application and a private database?

What’s AWS VPC?

An Amazon Virtual Private Cloud (VPC) is a logically isolated section of the AWS Cloud where you can launch AWS resources in a virtual network that you define. You have complete control over:

• IP address ranges

• Subnets

• Route tables

• Gateways

• Network ACLs and security groups

🔐 Key Components of a VPC:

• Subnets: Divide your VPC into public and private sections.

• Internet Gateway (IGW): Allows internet access for public subnets.

• NAT Gateway or NAT Instance: Lets private subnets access the internet for outbound traffic (e.g., OS updates) without exposing them.

• Route Tables: Define how traffic flows within the VPC and to/from the internet.

• Security Groups: Act as virtual firewalls for EC2 instances.

• Network ACLs: Provide stateless, subnet-level traffic control.

🧱 Designing a Secure VPC Architecture for a Web App + Database

Here’s how you’d design a secure and scalable VPC for hosting a public-facing web app with a private backend database:

🔹 1. Create the VPC

• CIDR block: 10.0.0.0/16 (you can adjust based on needs)

🔹 2. Create Subnets

• Public Subnets (e.g., 10.0.1.0/24, 10.0.2.0/24)

  • Host the web servers (EC2, ALB, etc.)

  • Placed in multiple Availability Zones for high availability

• Private Subnets (e.g., 10.0.3.0/24, 10.0.4.0/24)

  • Host backend resources like the RDS database

  • Also placed across multiple AZs

🔹 3. Set Up Internet Gateway (IGW)

• Attach it to the VPC

• Route public subnet traffic (0.0.0.0/0) through the IGW

🔹 4. Configure NAT Gateway

• Place NAT Gateway in a public subnet

• Allow instances in private subnets to make outbound connections to the internet (e.g., for patching or API calls)

🔹 5. Configure Route Tables

• Public Route Table:

  • Associate with public subnets

  • Route 0.0.0.0/0 → IGW

• Private Route Table:

  • Associate with private subnets

  • Route 0.0.0.0/0 → NAT Gateway

🔹 6. Security Groups

• Web Server SG (Public)

  • Inbound: Allow HTTP/HTTPS (ports 80/443) from anywhere

  • Outbound: Allow all traffic (or restrict as needed)

• Database SG (Private)

  • Inbound: Allow MySQL/PostgreSQL (port 3306/5432) only from web server SG

  • Outbound: Allow necessary traffic (e.g., outbound to S3 or NAT)

🔹 7. Other Best Practices

• Use ALB (Application Load Balancer) for handling public traffic and load distribution.

• Enable VPC Flow Logs for traffic monitoring and auditing.

• Enable RDS encryption and backups for your database.

• Use IAM roles for EC2 instances to securely access AWS resources (e.g., S3, SSM).

• Deploy bastion host in a separate public subnet for SSH access (or use Session Manager for a more secure setup).

🖼️ Diagram Summary:

VPC (10.0.0.0/16)
│
├── Public Subnets (Web Tier - EC2 / ALB)
│   └── Route to IGW
│
├── Private Subnets (DB Tier - RDS)
│   └── Route to NAT Gateway
│
├── NAT Gateway (in Public Subnet)
│
└── Internet Gateway

✅ Final Thoughts

By splitting resources into public and private subnets, using NAT Gateways, and enforcing strict security group rules, you create a secure and scalable environment within your VPC. This design pattern is widely used for production-grade web applications on AWS.

Reference:

https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html