How to Create an AWS VPC From Scratch (Step-by-Step): A Guide to Public and Private Subnets


Hello!

If you're starting your journey with AWS, you've definitely heard the term "VPC." For many beginners, it can seem like a complex and intimidating topic. But in reality, a VPC (Virtual Private Cloud) is just the secure "foundation" for almost everything you'll ever build on AWS.

In this article, I'll walk you through what a VPC is and how to build a secure one from scratch, step-by-step, using the AWS Console.

What is a VPC?

In the simplest terms, think of a VPC as your very own private, isolated piece of land in the AWS cloud. It's your personal network that no one else can access, and you have complete control over it.

Why Do We Need Public and Private Subnets?

Okay, so you have your piece of land (the VPC). Now, imagine you put your Application Server and your Database (like a secure safe) right in the middle of this open land. If you build a "main gate" (an Internet Gateway) and leave it open for users to come in, that means anyone (good or bad) can walk right up to your database.

That's not secure.

The solution is "Subnetting," which is just a fancy word for "building rooms" on your land.

  1. Public Subnet (The Lobby): This is the "front room" of your house. We connect the main gate (Internet Gateway) only to this room. This is where we place resources that are meant to talk to the public, like a "receptionist" (a Load Balancer).

  2. Private Subnet (The Secure Back-Office): This is the "secure vault" deep inside the house. It has no direct doors to the outside world. This is where we keep our most valuable assets: our Application Servers and our Databases. The only way to talk to them is by going through the receptionist in the lobby first.

This design keeps our database and application logic completely safe and isolated from the internet.


Building Our Secure VPC Foundation (Step-by-Step)

Here's our plan:

  • VPC CIDR (Our Land): 10.0.0.0/24 (Gives us 256 total IP addresses)

  • Public Subnet (Room 1): 10.0.0.0/25 (Uses the first 128 IPs)

  • Private Subnet (Room 2): 10.0.0.128/25 (Uses the second 128 IPs)

Step 1: Create the VPC (The Land)

  1. In the AWS Console, navigate to the VPC dashboard.

  2. Click "Create VPC".

  3. For "Resources to create," select VPC only.

  4. Name tag: Give it a name, like my-first-vpc.

  5. IPv4 CIDR block: Type in 10.0.0.0/24.

  6. Leave all other options (IPv6, Tenancy) as default and click "Create VPC".

Step 2: Create the Subnets (The Rooms)

  1. In the left-hand menu, click on "Subnets".

  2. Click "Create subnet".

  3. VPC ID: Select your my-first-vpc from the dropdown list.

  4. Subnet 1 (Public):

    • Subnet name: my-public-subnet

    • Availability Zone: Select any one (e.g., us-east-1a).

    • IPv4 CIDR block: 10.0.0.0/25

    • Click "Create subnet".

  5. Click "Create subnet" again to make the second one.

  6. Subnet 2 (Private):

    • VPC ID: Select your my-first-vpc again.

    • Subnet name: my-private-subnet

    • Availability Zone: Select a different one (e.g., us-east-1b). This is a best practice for High Availability.

    • IPv4 CIDR block: 10.0.0.128/25

    • Click "Create subnet".

Step 3: Create the Internet Gateway (The Main Door)

  1. In the left-hand menu, click on "Internet gateways".

  2. Click "Create internet gateway".

  3. Name tag: Give it a name, like my-igw, and click "Create".

  4. It will now say "Detached." Select your new my-igw, click the "Actions" menu, and choose "Attach to VPC".

  5. Select my-first-vpc from the list and click "Attach internet gateway".

Step 4: Configure the Route Tables (The Pathways)

This is the most important step. We will tell our Public Subnet how to reach the internet, and we will not tell our Private Subnet.

  1. In the left-hand menu, click on "Route tables".

  2. Click "Create route table".

  3. Name tag: my-public-route-table

  4. VPC: Select your my-first-vpc and click "Create".

  5. Now, select your new my-public-route-table from the list.

  6. In the tabs below, click the "Routes" tab.

  7. Click "Edit routes" $\rightarrow$ "Add route".

  8. Destination: Type 0.0.0.0/0 (This means "anywhere on the internet").

  9. Target: Select "Internet Gateway" and then choose your my-igw.

  10. Click "Save changes".

  11. Now, click the "Subnet associations" tab (for the same public route table).

  12. Click "Edit subnet associations", check the box next to my-public-subnet, and click "Save".

  13. Now for the Private Route Table:

  14. Click "Create route table" again.

  15. Name tag: my-private-route-table

  16. VPC: Select your my-first-vpc and click "Create".

  17. Select this new private route table. Look at its "Routes" tab. We will not add a 0.0.0.0/0 route here. We leave it as is (with only the local route).

  18. Click the "Subnet associations" tab, click "Edit", check the box next to my-private-subnet, and click "Save".

Congratulations! 🎉

You have successfully built a secure AWS VPC foundation. You now have:

  • A Public Subnet that can communicate with the internet.

  • A Private Subnet that is completely isolated and secure from the internet.

What's Next?

This is just the foundation. To build a full application, we still need a few more parts:

  1. NAT Gateway: To allow servers in the Private Subnet to access the internet for outbound traffic only (like for software updates), without letting the internet in.

  2. Security Groups: These act as "virtual firewalls" or locks on the doors of each server.

  3. EC2 Instances & RDS: The actual Application Servers and Databases that we will place inside our subnets.

  4. Application Load Balancer (ALB): The "receptionist" that will sit in the Public Subnet and distribute traffic to our application servers in the Private Subnet.

We can cover those in a future post!

If you learned something from this guide, please share it. If you have any questions, feel free to leave a comment.

Thanks for reading!

Comments

Popular posts from this blog

Bridging the Gap: A Scalable Workflow for Figma and React with AWS Amplify

AWS Best Practice: Securely Connecting EC2 to RDS with Security Group Referencing