Build a VPC Network on AWS

Build a complete AWS VPC with public and private subnets, routing, and firewalls.

Introduction

30 Second Summary

Every app you use online lives inside a network that controls who can reach it and how data flows between services. Cloud networking is the foundational skill behind every cloud and DevOps role.

In this project, you will build a complete Virtual Private Cloud (VPC) network from scratch on AWS. You'll create subnets, configure routing, and set up security controls that mirror how real companies architect their cloud infrastructure.

What You'll Build

A production-ready VPC network on AWS with public and private subnets, an internet gateway, route tables, and security groups.

By the end of this project, you'll have:

A custom VPC with public and private subnets spanning two Availability Zones.
An internet gateway and route tables that control how traffic flows in and out of your network.
A security group that acts as a virtual firewall with precise inbound and outbound access rules.
Secret Mission: Launch an EC2 instance into your public subnet and verify internet connectivity to prove your network works end-to-end.

Are there any prerequisites?

None. This project includes full setup for all required tools. You do not need an existing AWS account or any prior cloud experience.

Set Up Your AWS Account

To build your Virtual Private Cloud, you need access to AWS. AWS is the cloud platform where your network will live.

In this step, you'll create a free AWS account, sign in to the Management Console, and navigate to the VPC service where all your networking work happens.

In this step, get ready to:

Create a free AWS account.
Sign in and set your region to US East (N. Virginia).
Navigate to the VPC Dashboard.

Create a free AWS account

AWS offers a Free Tier that covers everything you need for this project at no cost.

Visit the AWS Free Tier page at https://aws.amazon.com/free/.
Click Create a Free Account.
Enter your email address and choose an AWS account name.
Verify your email with the code AWS sends you.
Create a strong root user password.
Select Personal for the account type and fill in your contact information.
Enter a payment method (credit or debit card).
Complete the identity verification step.
Choose the Basic support - Free plan.
Click Complete sign up.

Will I be charged?

No. AWS requires a payment method on file, but you will not be charged for this project. VPCs, subnets, route tables, internet gateways, and security groups are all completely free.

New AWS customers also receive $100 in credits at sign-up. Your Free Tier plan lasts up to 6 months.

Account activation taking a while?

AWS accounts can take up to 24 hours to fully activate, though most are ready within a few minutes. If you see a message about activation, wait a few minutes and try signing in again.

help me troubleshoot my AWS account activation

Sign in to the AWS Management Console

The AWS Management Console is the browser-based interface where you manage all your cloud resources.

Go to https://console.aws.amazon.com/.
Sign in with the email and password you just created.
Look at the top-right corner of the console for the region name.
If it does not say US East (N. Virginia), click the region name to open the dropdown.
Select US East (N. Virginia) from the list.

Why US East (N. Virginia)?

US East (N. Virginia), also known as us-east-1, has the most AWS services available and is the default region for many AWS operations. Using this region ensures every feature in this project works as expected.

Navigate to the VPC service

Click the search bar at the top of the console.
Type VPC and select VPC from the search results.

You should now see the VPC Dashboard. This is your home base for all networking configuration in AWS.

What is the VPC Dashboard?

The VPC Dashboard gives you an overview of all the networking resources in your account for the selected region. Right now it should show mostly zeros because you have not created anything yet.

From here, you can create and manage VPCs, subnets, route tables, internet gateways, and security groups.

Don't see the VPC Dashboard?

Make sure you clicked VPC in the search results (not a similar-sounding service like "VPN"). If you landed on a different page, click Dashboard in the left sidebar to get to the main VPC overview.

help me find the VPC Dashboard in the AWS console

Your AWS account is ready and you are in the right place. Next up, you'll create your VPC with public and private subnets spanning two Availability Zones.

Create Your VPC with Subnets

Your AWS account is ready and you're on the VPC Dashboard. Now it's time to build the actual network that will hold your cloud resources.

AWS provides a wizard called VPC and more that creates a VPC along with subnets, route tables, and an internet gateway in one step. This saves you from creating each component individually.

In this step, get ready to:

Create a VPC with a 10.0.0.0/16 CIDR block.
Create 2 public and 2 private subnets across 2 Availability Zones.
Attach an internet gateway to your VPC.

Start the VPC creation wizard

The VPC and more option lets you define your entire network in a single form. It automatically generates all the supporting resources (subnets, route tables, gateways) based on your selections.

On the VPC Dashboard, click Create VPC.
Under Resources to create, select VPC and more.
In the Name tag auto-generation field, clear the default text and enter my-network.
For IPv4 CIDR block, keep the default 10.0.0.0/16.

What is a CIDR block?

A CIDR block defines the range of IP addresses available inside your VPC. The 10.0.0.0/16 block gives you 65,536 IP addresses to work with.

Think of it like choosing the size of a building lot before you start constructing rooms. A larger CIDR block gives you more room to create subnets and place resources later.

Why is it called my-network?

AWS uses the name you enter to auto-generate names for all resources. It follows the pattern my-network-vpc, my-network-subnet-public1-us-east-1a, my-network-igw, and so on. This makes it easy to identify your resources later.

Configure your subnets

Subnets divide your VPC into smaller sections. Public subnets can reach the internet. Private subnets are isolated from the outside world.

Set Number of Availability Zones (AZs) to 2.
Set Number of public subnets to 2.
Set Number of private subnets to 2.
Keep the default CIDR blocks for each subnet.
For NAT gateways, select None.
For VPC endpoints, select None.
Keep both DNS options (Enable DNS hostnames and Enable DNS resolution) selected.

Why 2 Availability Zones?

Availability Zones are physically separate data centers within a region. Spreading your subnets across 2 AZs means your application stays running even if one data center has an outage.

This is the same pattern companies use for production workloads. You are learning the right architecture from the start.

Why no NAT gateway?

A NAT gateway lets resources in private subnets reach the internet (for software updates, for example). However, NAT gateways cost money. Since this is a learning project, selecting None keeps it completely free.

Create the VPC and review the results

Click Create VPC at the bottom of the page.
Wait for all resources to show a green Create complete status. This takes a few seconds.
Review the resource map that appears on the screen.

You should see a visual diagram showing your VPC with 4 subnets across 2 Availability Zones, route tables connecting each subnet, and an internet gateway at the top.

What did AWS just create for you?

1 VPC named my-network-vpc with the IP range 10.0.0.0/16.
2 public subnets (my-network-subnet-public1-us-east-1a and my-network-subnet-public2-us-east-1b) with routes to the internet gateway.
2 private subnets (my-network-subnet-private1-us-east-1a and my-network-subnet-private2-us-east-1b) with no internet route.
1 internet gateway named my-network-igw attached to your VPC.
Route tables that automatically direct traffic from public subnets to the internet gateway (0.0.0.0/0 route) and keep private subnets isolated (local route only).

Don't see all resources with green status?

If any resource shows a failed status, the most common cause is a service quota limit. Make sure you haven't already created VPCs in this region from a previous project. You can delete unused VPCs and try again.

Why is my VPC creation failing?

Your network is live. Next up, you'll explore each component in detail to understand how traffic flows through your VPC.

Explore Your Network Architecture

Your VPC is live with four subnets, route tables, and an internet gateway. Now it is time to explore what was created and understand how the pieces connect.

In this step, you will click through your network resources and see how route tables make the difference between a public subnet and a private one.

In this step, get ready to:

Inspect public subnet route tables and identify the internet gateway route.
Compare private subnet route tables and confirm they have no internet path.
Find the internet gateway and verify it is attached to your VPC.

Inspect your public subnets

A public subnet is a subnet whose route table includes a route to an internet gateway. This is the key detail that separates public from private.

In the VPC console left sidebar, click Subnets.
You should see 4 subnets listed.
Notice the naming pattern: my-network-subnet-public1-us-east-1a, my-network-subnet-private1-us-east-1a, and similar names for the second Availability Zone.
Click on my-network-subnet-public1-us-east-1a to open its details.
Click the Route table tab near the bottom of the page.

You should see two routes in the table. One is the local route (10.0.0.0/16) and the other sends all other traffic (0.0.0.0/0) to the internet gateway. This route to the internet gateway is what makes this subnet public.

What does 0.0.0.0/0 mean?

The route 0.0.0.0/0 is a catch-all destination. It means "any IP address that does not match another route in this table." When this route points to the internet gateway, it tells AWS to forward internet-bound traffic out of your VPC.

Compare with your private subnets

A private subnet has no route to an internet gateway. Resources inside it cannot be reached from the public internet.

Click Subnets in the left sidebar to go back to the full list.
Click on my-network-subnet-private1-us-east-1a.
Click the Route table tab.

This time you should see only one route: 10.0.0.0/16 pointing to local. There is no 0.0.0.0/0 route here. Resources in this subnet can talk to other resources inside the VPC, but they cannot reach the internet on their own.

Why use private subnets?

Private subnets are where you place resources that should never be directly accessible from the internet. Databases, internal APIs, and backend services all belong here.

Even though these resources cannot reach the internet by default, you could add a NAT gateway later if they need to pull software updates or call external APIs. For this project, we skip the NAT gateway to keep costs at zero.

Find your internet gateway

The internet gateway is the single connection point between your VPC and the public internet. Without it, nothing inside your VPC could communicate with the outside world.

In the left sidebar, click Internet gateways.
You should see one internet gateway named my-network-igw.
Check the State column. It should say Attached and reference your my-network-vpc.

What if the gateway was detached?

If an internet gateway is detached from a VPC, even subnets with a 0.0.0.0/0 route would lose internet access. The route would point to a gateway that is not connected to anything. Attachment is what completes the link.

How traffic flows through your network

Trace the path of a request from the internet to a resource in your public subnet. Traffic enters through the internet gateway, the route table in the public subnet directs it to the correct destination, and later (in Step 4) a security group will decide whether to allow or block it.

This layered system of gateway, routing, and access control is how all AWS networking works.

You now understand how your network routes traffic. Next up, you will create a security group that acts as a virtual firewall to control exactly which traffic is allowed in and out.

Configure Security Groups

Your network has routes and gateways that control where traffic flows. But you still need a way to control what kind of traffic is allowed in.

Security groups act as virtual firewalls for resources inside your VPC. They let you specify exactly which ports and IP addresses can reach your servers. In this step, you will create a security group that allows web traffic from anyone but restricts SSH access to only your computer.

In this step, get ready to:

Create a security group for web server traffic.
Configure inbound rules for HTTP and SSH access.
Understand how security groups act as firewalls for your resources.

Create a security group

A security group defines which traffic is allowed to reach a resource. You will create one designed for a web server that needs to accept HTTP requests and SSH connections.

In the VPC console left sidebar, click Security groups.
Click Create security group in the top-right area of the page.
In the Security group name field, enter web-server-sg.
In the Description field, enter Allows HTTP and SSH access.
In the VPC dropdown, remove the default VPC and select my-network-vpc.

Why create a new security group?

Every VPC comes with a default security group, but it allows all inbound traffic from other resources in the same group. Creating a custom security group gives you precise control over exactly which ports are open and who can connect.

Add inbound rules for HTTP and SSH

Inbound rules control what traffic can reach resources attached to this security group. You will open two ports: port 80 for web traffic from anyone, and port 22 for SSH from your IP only.

Scroll down to the Inbound rules section.
Click Add rule.
In the Type dropdown for the first rule, select HTTP. This auto-fills the port to 80 and the protocol to TCP.
In the Source dropdown, select Anywhere-IPv4 (0.0.0.0/0). This allows web traffic from any IP address on the internet.
Click Add rule again to add a second rule.
In the Type dropdown for the second rule, select SSH. This auto-fills the port to 22.
In the Source dropdown for the SSH rule, select My IP. This restricts SSH access to only your computer's current IP address.

Why restrict SSH to My IP?

SSH gives full command-line access to a server. Leaving it open to the entire internet (0.0.0.0/0) would let anyone attempt to log in. Restricting it to your IP means only your computer can connect over SSH.

Save and review your security group

Scroll down to the Outbound rules section. Leave the default rule in place. It allows all outbound traffic, meaning your server can reach anything on the internet.
Click Create security group at the bottom of the page.

You should see a green success banner at the top of the page confirming that web-server-sg was created. The details panel shows your two inbound rules (HTTP from anywhere, SSH from your IP) and the default outbound rule.

What does this security group do?

You have created a firewall rule that would allow web traffic (port 80) from anyone on the internet, but restricts SSH (port 22) to only your IP address. This is the standard pattern for a public-facing web server.

The security group is not attached to any resource yet. It is ready and waiting to be assigned to a server when you launch one.

Don't see your VPC in the dropdown?

Make sure you are in the US East (N. Virginia) region. Check the top-right corner of the console. Your VPC only exists in the region where you created it.

help me find my VPC in the security group creation form

Your security group is ready. You now have all three layers of network security in place: an internet gateway controls what enters your VPC, route tables decide which subnets can reach the internet, and security groups filter traffic at the resource level. Next, you will take a step back and review your complete network architecture.

Verify and Understand Your Network

Your security group is configured and ready to protect future resources. Now it's time to step back and verify the full picture of what you've built.

In this step, you'll confirm your VPC is correctly configured and trace how network traffic flows through your architecture. This is the key skill that separates someone who clicked buttons from someone who truly understands cloud networking.

In this step, get ready to:

Review your VPC details and confirm the configuration is correct.
Explore the Resource Map to visualize your full network topology.
Trace the three-layer path of a request through your network.

Review your VPC details

Before exploring the visual map, you'll confirm that the core VPC settings are correct. This is the same sanity check an engineer would do before deploying anything into a network.

In the VPC console left sidebar, click Your VPCs.
Click on my-network-vpc to open its details page.
Review the Details tab that appears.

What should I see?

The IPv4 CIDR field shows 10.0.0.0/16. This is the address space you chose when creating the VPC.
The State field shows Available. This confirms your VPC is active and ready for resources.
Scroll down or check the Main network ACL and DNS hostnames fields. DNS hostnames should show Enabled.

What is a CIDR block?

A CIDR block defines the range of IP addresses available inside your VPC. The 10.0.0.0/16 block gives you 65,536 possible addresses. Your subnets carve smaller slices out of this range for specific purposes.

Explore the Resource Map

AWS provides a visual diagram of your VPC that shows every resource and how they connect. This is the fastest way to confirm your network topology is correct.

While viewing your my-network-vpc details, click the Resource map tab.
Click Show details to expand additional information like CIDR ranges and route counts.

What does the Resource Map show?

The Resource Map is a visual diagram of your entire VPC architecture. Here is what to look for:

Your VPC contains 2 Availability Zones (us-east-1a and us-east-1b), each with a public and private subnet.
Public subnets appear in green. They connect through route tables to the internet gateway (my-network-igw).
Private subnets appear in blue. Their route tables have no path to the internet gateway.
Solid lines show resource relationships. Dotted lines show network traffic paths.

Hover for details

Hover over any resource in the map to highlight its connections. This makes it easy to trace which subnets connect to which route tables and gateways.

Don't see the Resource Map tab?

Make sure you clicked on my-network-vpc first, not just the Your VPCs page. The tab only appears after selecting a specific VPC.

Why can't I find my Resource Map tab?

Trace the path of a request

Now that you can see the full topology, take a moment to understand how traffic actually flows. This mental model is what interviewers and hiring managers expect cloud engineers to know.

Look at the Resource Map and imagine someone on the internet trying to reach a web server in your public subnet.
Trace the path from the internet, through the gateway, through the route table, and into the subnet.

How does a request reach your server?

Every request that enters your VPC passes through three layers of control:

The internet gateway is the single entry point. Without it, nothing from the outside world can reach your VPC.
The route table decides where traffic goes. Public subnets have a route (0.0.0.0/0) pointing to the internet gateway. Private subnets do not.
The security group decides whether to allow or block the traffic. Your web-server-sg allows HTTP on port 80 from anyone, but SSH only from your IP.

This three-layer system (gateway, routing, security) is how all AWS networking works. If any layer blocks the traffic, the request never arrives.

Why can't private subnets be reached from the internet?

Private subnets have no route to the internet gateway. Even if someone knew the IP address of a resource in a private subnet, there is no path for traffic to travel from the internet to that resource. This is exactly where you would place a database or backend service that should never be directly exposed.

Secret mission

Launch an EC2 Instance to Prove Your Network Works

Your VPC is built, but how do you know it actually works? The real test is launching a live server into your public subnet and proving it can reach the internet.

Clean Up Your Resources

This project's networking resources (VPC, subnets, route tables, internet gateway, and security groups) are completely free on AWS. There are no ongoing costs for keeping them.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

If you launched an EC2 instance for the Secret Mission, it will incur charges while running. Public IPv4 addresses cost $0.005/hour. The t2.micro instance type is free tier eligible for 750 hours/month during your first 12 months of AWS.

If you are past the free tier period, stop or terminate the instance when you are done testing.

Resources you used:

1 VPC (my-network-vpc) - free.
4 Subnets (2 public, 2 private) - free.
1 Internet Gateway (my-network-igw) - free.
Route tables - free.
1 Security Group (web-server-sg) - free.
1 EC2 instance (Secret Mission only) - free tier eligible.

Keep everything running

No action needed. Choose this if you are still actively building or plan to use this VPC for future projects.

All VPC networking resources (VPC, subnets, route tables, internet gateway, security groups) are completely free to keep.
This is actually recommended because you can launch servers into this VPC for future projects.
If you launched an EC2 instance for the Secret Mission, stop it to avoid charges. In the EC2 console, select your instance, choose Instance state, then Stop instance.

Pause - I'll come back to this later

Stop running processes to avoid charges, but keep your VPC and networking resources intact for later.

Your VPC, subnets, route tables, internet gateway, and security groups are free. No action needed for these.
If you launched an EC2 instance for the Secret Mission, stop it to pause billing.
In the EC2 console, click Instances in the left sidebar.
Select your instance, choose Instance state, then Stop instance.
A stopped instance does not incur compute charges. You can start it again later.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps in order.

If you launched an EC2 instance for the Secret Mission, terminate it first. In the EC2 console, click Instances in the left sidebar.
Select your instance, choose Instance state, then Terminate (delete) instance.
Choose Terminate (delete) when prompted for confirmation.
Now delete the VPC. In the VPC console, click Your VPCs in the left sidebar.
Select your my-network-vpc, choose Actions, then Delete VPC.
When prompted for confirmation, enter delete and choose Delete.
This deletes the VPC and all associated resources (subnets, route tables, internet gateway, and security groups) in one step.

Nice Work!

Congratulations! You just built a production-grade network from scratch on AWS.

You now have a complete Virtual Private Cloud that mirrors how real companies architect their cloud infrastructure.

Here's what you learned:

Built a custom VPC with public subnets and private subnets spanning two Availability Zones.
Connected your VPC to the internet with an internet gateway and configured route tables to control exactly where traffic flows.
Created a security group that acts as a virtual firewall with precise inbound and outbound access rules.
Launched a live EC2 instance into your network and proved end-to-end internet connectivity.

Ready to quiz yourself?