Build a Production-Ready AWS VPC

Build a real AWS VPC with subnets, routing, and security controls.

Introduction

30 Second Summary

Every time you visit a website, your request travels through carefully designed networks that route traffic, block threats, and keep applications available. Companies build these networks in the cloud to control exactly who can reach their servers.

In this project, you will build a production-style cloud network on AWS from scratch. You will create your own Virtual Private Cloud, configure subnets across multiple data centers, set up routing and firewalls, and launch a live server to prove it all works.

What You'll Build

A fully functional AWS VPC with public and private subnets, an Internet Gateway, route tables, Security Groups, and a running EC2 instance that you can reach from the internet.

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

A VPC with public and private subnets spanning two Availability Zones for reliability.
A working Internet Gateway and route tables that control exactly which subnets can reach the internet.
A Security Group acting as a virtual firewall, plus a live EC2 instance you can ping from your own computer to prove the network works.
Secret Mission: Create a private database tier Security Group that restricts access to only the web tier.

Do I need anything before starting?

You need an AWS account with Free Tier credits. No local software installations are required. All work happens in the browser-based AWS Management Console.

Explore the VPC Console and Create Your VPC

Every cloud application runs inside a network. On AWS, that network is called a VPC (Virtual Private Cloud). It gives you your own isolated section of the AWS cloud where you control the IP addresses, routing, and security rules.

In this step, you will navigate to the VPC console, plan the IP addressing for your network, and create the VPC itself. Think of this as drawing the property boundary before building anything on it.

In this step, get ready to:

Navigate to the VPC service in the AWS Management Console.
Understand the IP addressing plan for your network.
Create your VPC with a 10.0.0.0/16 CIDR block.

Navigate to the VPC console

The AWS Management Console is a browser-based dashboard where you manage all your cloud resources. The VPC service lives inside it.

Open your web browser and go to https://console.aws.amazon.com.
Sign into your AWS account.
In the search bar at the top, type VPC.
Select VPC from the search results.

You land on the VPC Dashboard. Take a moment to look at the left navigation pane.

What do I see in the left navigation pane?

The left pane lists the building blocks you will use throughout this project:

Your VPCs - the isolated networks you create.
Subnets - smaller address ranges inside a VPC.
Route tables - rules that direct traffic.
Internet gateways - doors that connect your VPC to the public internet.
Security groups - virtual firewalls controlling which traffic is allowed.

You will configure each of these throughout the project.

Understand your IP addressing plan

Before building anything, you need an addressing plan. Every device on a network needs a unique IP address, and a CIDR block defines the range of addresses available to you.

Your VPC will use the CIDR block 10.0.0.0/16. This gives you 65,536 IP addresses to work with.

What does /16 mean?

The number after the slash tells you how many bits are fixed in the address. A /16 means the first 16 bits (10.0) are locked, and the remaining 16 bits are yours to allocate. That is 2^16 = 65,536 addresses.

You will divide this space into four smaller /24 subnets, each with 256 addresses:

Public Subnet 1: 10.0.1.0/24
Public Subnet 2: 10.0.2.0/24
Private Subnet 1: 10.0.3.0/24
Private Subnet 2: 10.0.4.0/24

Each subnet will go in a different Availability Zone for reliability. You will create these subnets in the next step.

Create the VPC

Now that you have a plan, create the VPC itself. AWS offers a wizard that builds everything at once, but you will use the manual approach so you understand each piece.

In the left navigation pane, choose Your VPCs.
Choose Create VPC.
For Resources to create, select VPC only.
For Name tag, enter my-production-vpc.
For IPv4 CIDR block, choose IPv4 CIDR manual input and enter 10.0.0.0/16.
Leave IPv6 CIDR block set to No IPv6 CIDR block.
Leave Tenancy set to Default.
Choose Create VPC.

Why choose VPC only instead of VPC and more?

The "VPC and more" option creates subnets, route tables, and gateways automatically in one wizard. That is great for production speed, but it hides how each piece connects.

By building each component manually, you learn why each one exists and how they work together. This understanding is what separates someone who can troubleshoot network issues from someone who just clicks through wizards.

You should now see your new VPC listed with the CIDR 10.0.0.0/16 and State showing Available.

Don't see your VPC listed?

Make sure you are viewing the correct region in the top-right corner of the console. Your VPC only appears in the region where you created it.
Check that you selected VPC only (not "VPC and more") before entering your settings.
Confirm the CIDR block is exactly 10.0.0.0/16 with no typos or extra spaces.

Help me troubleshoot my VPC creation issue.

Your VPC boundary is set. Next up, you will divide this address space into public and private subnets spread across multiple Availability Zones for reliability.

Create Public and Private Subnets

Your VPC is live with 65,536 IP addresses ready to use. Now you need to divide that massive address space into smaller, purpose-built networks called subnets.

Without subnets, you can't separate public-facing resources (like web servers) from private ones (like databases). You'll create 4 subnets spread across 2 Availability Zones so your network stays up even if one data center fails.

In this step, get ready to:

Create 4 subnets (2 public, 2 private) across 2 Availability Zones.
Enable auto-assign public IPv4 addresses on your public subnets.
Verify that each subnet has the correct CIDR block and Availability Zone.

Create 4 subnets in your VPC

Each subnet carves out a chunk of your VPC's IP addresses and lives entirely within one Availability Zone. You'll create all four subnets at once using the AWS console's batch creation feature.

In the left navigation pane of the VPC console, click Subnets.
Click Create subnet.
In the VPC ID dropdown, select your VPC (my-production-vpc).

Now add the first subnet's details:

Enter public-subnet-1 in the Subnet name field.
For Availability Zone, select the first AZ in your region (e.g., us-east-1a).
For IPv4 subnet CIDR block, enter 10.0.1.0/24.
Click Add new subnet to add the second subnet.

Fill in the second subnet:

Enter public-subnet-2 in the Subnet name field.
For Availability Zone, select the second AZ in your region (e.g., us-east-1b).
For IPv4 subnet CIDR block, enter 10.0.2.0/24.
Click Add new subnet again.

Fill in the third subnet:

Enter private-subnet-1 in the Subnet name field.
For Availability Zone, select the first AZ (same as public-subnet-1, e.g., us-east-1a).
For IPv4 subnet CIDR block, enter 10.0.3.0/24.
Click Add new subnet one more time.

Fill in the fourth and final subnet:

Enter private-subnet-2 in the Subnet name field.
For Availability Zone, select the second AZ (same as public-subnet-2, e.g., us-east-1b).
For IPv4 subnet CIDR block, enter 10.0.4.0/24.
Click Create subnet.

What is a CIDR block?

A CIDR block defines a range of IP addresses. The /24 at the end means each subnet gets 256 IP addresses (though AWS reserves 5 in each, leaving 251 usable).

Your VPC has /16 (65,536 addresses), and you're dividing it into four /24 chunks. Think of it like dividing a large office building into individual floors.

Why spread subnets across two Availability Zones?

Each Availability Zone is a separate physical data center. If one zone goes down, resources in the other zone keep running. AWS recommends subnets in at least two Availability Zones for production workloads.

Don't see your VPC in the dropdown?

Make sure you're in the same AWS Region where you created your VPC. Check the region selector in the top-right corner of the console.

Help me find my VPC in the subnet creation page.

Enable auto-assign public IPv4 for the public subnets

By default, instances launched in any subnet don't get a public IP address. Your public subnets need this enabled so resources inside them are reachable from the internet.

In the Subnets list, select the checkbox next to public-subnet-1.
Click Actions, then Edit subnet settings.
Check the box for Enable auto-assign public IPv4 address.
Click Save.

Now repeat the same process for the second public subnet:

Select the checkbox next to public-subnet-2.
Click Actions, then Edit subnet settings.
Check the box for Enable auto-assign public IPv4 address.
Click Save.

Why only the public subnets?

Private subnets are designed to keep resources hidden from the internet. Giving them public IP addresses would defeat their purpose. Only resources that need to be directly reachable (like web servers) should have public IPs.

Verify your subnets

Return to the Subnets page in the left navigation pane.

You should now see 4 subnets listed. Confirm the following details for each:

public-subnet-1: CIDR 10.0.1.0/24, first AZ, Auto-assign public IPv4 shows Yes.
public-subnet-2: CIDR 10.0.2.0/24, second AZ, Auto-assign public IPv4 shows Yes.
private-subnet-1: CIDR 10.0.3.0/24, first AZ, Auto-assign public IPv4 shows No.
private-subnet-2: CIDR 10.0.4.0/24, second AZ, Auto-assign public IPv4 shows No.

Auto-assign column not showing Yes?

Make sure you clicked Save after checking the auto-assign box. If the column still shows No for a public subnet, select it again and repeat the edit.

Help me fix my subnet auto-assign settings.

Your network now has dedicated lanes for public and private traffic. Next up, you'll connect your public subnets to the internet with an Internet Gateway and route tables.

Connect to the Internet with an Internet Gateway and Route Tables

Your four subnets are in place, giving your VPC a clear structure of public and private zones. But right now, none of them can actually reach the internet.

To fix that, you need two things: an Internet Gateway (the door to the internet) and a route table (the map that tells traffic where to go). In this step, you will create both and wire them together so your public subnets can send and receive internet traffic.

In this step, get ready to:

Create an Internet Gateway and attach it to your VPC.
Create a custom route table with a route pointing all internet-bound traffic to the gateway.
Associate your public subnets with the route table so they can reach the internet.

Create and attach an Internet Gateway

An Internet Gateway is the component that allows communication between your VPC and the public internet. Without one attached, nothing inside your VPC can reach the outside world.

In the left navigation pane of the VPC console, choose Internet gateways.
Choose Create internet gateway.
Enter my-production-igw in the Name tag field.
Choose Create internet gateway.

You should see a green success banner at the top of the page confirming your Internet Gateway was created. Now you need to attach it to your VPC.

On the next screen, choose Actions, then Attach to VPC.
In the Available VPCs dropdown, select your my-production-vpc.
Choose Attach internet gateway.

The State column for your Internet Gateway should now show Attached. This means the gateway is connected to your VPC and ready to route traffic.

What is an Internet Gateway?

Think of an Internet Gateway as the front door of your building. Your VPC is the building, your subnets are the floors, and without a front door, nobody can enter or leave.

An Internet Gateway is horizontally scaled, redundant, and highly available by default. You never need to worry about bandwidth constraints or single points of failure on the gateway itself.

Don't see your VPC in the dropdown?

Make sure you are in the same AWS Region where you created your VPC. Check the region selector in the top-right corner of the console.

Each VPC can only have one Internet Gateway attached. If your VPC already has one (perhaps from a previous attempt), detach or delete it first.

Help me attach an Internet Gateway to my VPC.

Create a public route table and add a route to the Internet Gateway

The Internet Gateway is attached, but your subnets still do not know how to reach it. A route table contains a set of rules (called routes) that determine where network traffic is directed.

In the left navigation pane, choose Route tables.
Choose Create route table.
Enter public-route-table in the Name field.
Select your my-production-vpc from the VPC dropdown.
Choose Create route table.

Your route table is created, but it only has a local route (allowing traffic within the VPC). Now you need to add a route that sends internet-bound traffic to your Internet Gateway.

On the Routes tab, choose Edit routes.
Choose Add route.
For Destination, enter 0.0.0.0/0.
For Target, select Internet Gateway, then select your my-production-igw.
Choose Save changes.

What does 0.0.0.0/0 mean?

The destination 0.0.0.0/0 represents all IPv4 addresses. It is a catch-all that says "any traffic not matching a more specific route should go here."

Your route table already has a local route for 10.0.0.0/16 (traffic within the VPC). Because that is more specific than 0.0.0.0/0, internal VPC traffic stays internal. Only traffic destined for the public internet hits the new route.

Associate the public subnets with the public route table

By default, all subnets use the VPC's main route table, which has no internet route. You need to explicitly associate your two public subnets with the new route table so they can reach the internet.

On the Subnet associations tab of your public-route-table, choose Edit subnet associations.
Select the checkboxes for public-subnet-1 and public-subnet-2.
Choose Save associations.

You should now see both public subnets listed under Explicit subnet associations on the Subnet associations tab.

What about the private subnets?

Your private subnets (private-subnet-1 and private-subnet-2) remain on the main route table, which has no route to the Internet Gateway. This keeps them completely isolated from the internet.

This is exactly what you want for sensitive resources like databases. They can still communicate with other resources inside the VPC through the local route, but nothing on the internet can reach them directly.

Don't see your subnets in the associations list?

Make sure you are editing the public-route-table you just created, not the main route table. The main route table cannot be deleted or renamed, so look for the one with your custom name.

Also confirm that the route table belongs to my-production-vpc. Subnets from a different VPC will not appear in the list.

Help me associate subnets with my route table.

Your network now has a clear traffic path: public subnets can reach the internet through the Internet Gateway, while private subnets stay isolated. Next up, you will create Security Groups to control exactly what kind of traffic is allowed through.

Secure Your Network with Security Groups

Your route tables are now directing internet-bound traffic through the Internet Gateway for both public subnets. But right now, there is nothing controlling what traffic is allowed to reach resources inside those subnets.

This is where Security Groups come in. A Security Group acts as a virtual firewall for your cloud resources, letting you define exactly which traffic is allowed in and out. In this step, you will create one that allows web traffic and ping requests.

In this step, get ready to:

Create a Security Group for web servers in your VPC.
Configure inbound rules to allow HTTP and ICMP traffic.
Understand how Security Groups protect your resources.

Create a Security Group for web servers

Every resource you launch in a VPC needs at least one Security Group attached. You will create one specifically for web servers that will allow HTTP and ping traffic from anywhere on the internet.

In the left navigation pane of the VPC console, choose Security groups.
Choose Create security group.
In the Security group name field, enter web-server-sg.
In the Description field, enter Allow HTTP and ICMP from anywhere.
For VPC, remove the default VPC and select your my-production-vpc from the dropdown.

Why does the description matter?

The Security Group description cannot be changed after creation. A clear description helps you (and your team) quickly identify what each Security Group permits without opening its rules.

Add inbound rules

Inbound rules control what traffic is allowed to reach resources associated with this Security Group. You will add two rules: one for web traffic (HTTP on port 80) and one for ping requests (ICMP).

Scroll down to the Inbound rules section.
Choose Add rule.
For the first rule, set Type to HTTP.
Set Source to Anywhere-IPv4 (0.0.0.0/0).
Choose Add rule again to add a second rule.
For the second rule, set Type to All ICMP - IPv4.
Set Source to Anywhere-IPv4 (0.0.0.0/0).
Leave the Outbound rules section as the default (all traffic allowed).
Choose Create security group.

What do these rules allow?

The HTTP rule allows web browsers to reach any resource in this Security Group on port 80. The ICMP rule allows ping requests, which you will use later to verify your network works.

Setting the source to 0.0.0.0/0 means any IPv4 address on the internet can send this type of traffic. In a production environment, you would typically restrict sources to known IP ranges.

You should now see the web-server-sg Security Group listed with 2 inbound rules and the default outbound rule.

Don't see your Security Group?

Make sure you selected my-production-vpc as the VPC during creation. If you left the default VPC selected, the Security Group was created in the wrong network. Delete it and create a new one in the correct VPC.

Help me find my Security Group in the VPC console.

Understand what you just did

Security Groups behave differently from traditional firewalls in a few important ways.

How are Security Groups different from traditional firewalls?

Security Groups are stateful. If you allow traffic in, the response is automatically allowed back out. You do not need to create a separate outbound rule for reply traffic.

You can only specify allow rules. Security Groups cannot have deny rules. Anything not explicitly allowed is automatically denied.

This means your web-server-sg only permits HTTP and ICMP. Every other type of traffic (SSH, FTP, database connections) is silently blocked without you needing to write a single deny rule.

Your network now has a firewall layer protecting resources. Next up, you will launch a live EC2 instance inside your public subnet and use ping to prove the entire network works end-to-end.

Launch an EC2 Instance and Verify Your Network

Your VPC now has subnets, routing, and security controls fully configured. The only thing left is to prove it actually works.

In this step, you will launch a virtual server (an EC2 instance) inside your public subnet and ping it from your local machine. A successful ping confirms that every layer of your network is functioning correctly.

In this step, get ready to:

Launch an EC2 instance in your public subnet.
Ping the instance from your local machine to prove end-to-end connectivity.
Trace the full network path to understand how traffic flows through your VPC.

Launch an EC2 instance in your public subnet

An EC2 instance is a virtual server running in the cloud. You will place it inside public-subnet-1 and attach your web-server-sg Security Group so that ICMP (ping) traffic can reach it from the internet.

In the AWS search bar at the top of the console, type EC2 and select EC2 from the results.
On the EC2 Dashboard, click Launch instance.
Under Name and tags, enter network-test-server as the name.
Under Application and OS Images (Amazon Machine Image), choose Quick Start.
Select Amazon Linux and confirm the Amazon Linux 2023 AMI is selected (it should say Free tier eligible).
Under Instance type, select an instance type marked Free tier eligible (such as t2.micro or t3.micro).
Under Key pair (login), select Proceed without a key pair (Not recommended).

Why no key pair?

You only need to verify network connectivity via ping. SSH access would require configuring key pairs and additional Security Group rules, which is outside the scope of this project.

Under Network settings, click Edit.
For VPC, select your VPC (my-production-vpc).
For Subnet, select public-subnet-1.
Confirm that Auto-assign public IP is set to Enable.
For Firewall (security groups), choose Select existing security group.
Under Common security groups, select web-server-sg.
In the Summary panel on the right, click Launch instance.

You should see a success message confirming that your instance is launching.

Click View all instances (or navigate to Instances in the left nav).
Wait 1-2 minutes for the Instance state to change from Pending to Running.
Click the refresh icon if the state does not update automatically.

Instance stuck in Pending?

Give it up to 2 minutes. If it transitions to Terminated instead of Running, make sure you selected your custom VPC (not the default VPC) and that public-subnet-1 is in the same region where you created your VPC resources.

help me troubleshoot my EC2 instance that terminated immediately after launch

Test that your network works

Now that your instance is running, you will ping its public IP address from your local machine. A successful ping proves that traffic flows from the internet, through your Internet Gateway, into your public subnet, and past your Security Group to reach the instance.

Click on your network-test-server instance to open its details.
Find the Public IPv4 address field and copy the IP address.

Open a terminal or command prompt on your local machine.

Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal (macOS) or cmd (Windows) and press Enter to open it.
Ping your instance's public IP by running this command:

ping [[EC2_PUBLIC_IP="your instance public IPv4 address"]]

What should I see?

On Windows, you will see 4 reply lines that look like:

Reply from [IP]: bytes=32 time=XXms TTL=XXX

On macOS, replies appear continuously until you press Ctrl+C to stop. Each line looks like:

64 bytes from [IP]: icmp_seq=N ttl=XX time=XX ms

If you see reply lines with round-trip times, your network is working end to end.

Not getting any replies?

Make sure the instance state is Running (not Pending or Stopped).

Verify you copied the Public IPv4 address (not the Private one). The public address starts with a number other than 10.

Confirm that your web-server-sg Security Group has an inbound rule for All ICMP - IPv4 with source 0.0.0.0/0.

help me debug why my EC2 instance is not responding to ping

Verify the full network path

Your successful ping just proved that every component of your VPC is working together. Let's trace the path that traffic takes to understand why.

Switch back to the VPC console (type VPC in the AWS search bar).
In the left nav, choose Route tables.
Select your public-route-table and click the Routes tab.

How does traffic reach your instance?

Here is the full path your ping took:

Your ping packet arrives at the Internet Gateway attached to your VPC.
The route table entry 0.0.0.0/0 directs internet-bound traffic through the gateway.
The packet reaches public-subnet-1 because this subnet is associated with the public route table.
The Security Group web-server-sg checks its inbound rules and allows ICMP traffic through to your instance.

This is the same architecture that routes traffic to production web servers at real companies.

Your network is live. Every building block you configured is now working together to deliver traffic securely to your instance.

Secret mission

Create a Private Database Tier Security Group

Your VPC has public and private subnets, but nothing stops a resource in the public subnet from talking to anything in the private subnet. Real production networks add another layer of control. Can you create a Security Group that only allows your web servers to reach the database tier?

Clean Up Your Resources

This project runs on AWS infrastructure. Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Cost warning

The EC2 instance uses Free Tier credits while running. If you exhaust your credits and leave the instance running, you will be charged for compute time. VPC, subnets, Internet Gateways, route tables, and Security Groups are free resources and do not incur charges on their own.

Resources you used:

1 EC2 instance (network-test-server).
1 VPC (my-production-vpc).
4 subnets (public-subnet-1, public-subnet-2, private-subnet-1, private-subnet-2).
1 Internet Gateway (my-production-igw).
1 custom route table (public-route-table).
2 Security Groups (web-server-sg and database-sg).

Keep everything running

No action needed. Choose this if you are still actively building or exploring your VPC.

Your EC2 instance continues using Free Tier credits. Monitor your remaining credits in the Billing and Cost Management dashboard.
VPC, subnets, Internet Gateway, route tables, and Security Groups are free and cost nothing while they exist.

Pause - I'll come back to this later

Stop the EC2 instance to stop using compute credits. Your network configuration stays intact so you can resume later.

Navigate to the EC2 service by typing EC2 in the search bar and selecting it.
In the left nav, choose Instances.
Select network-test-server.
Choose Instance state, then Stop instance.
Confirm by clicking Stop.
You will not be charged for compute while the instance is stopped. The EBS volume remains but is covered under Free Tier storage.

Delete - I don't want to use this again

Remove all project resources completely. Delete in this specific order because some resources depend on others.

Step 1: Terminate the EC2 instance.

Navigate to the EC2 service by typing EC2 in the search bar and selecting it.
In the left nav, choose Instances.
Select network-test-server.
Choose Instance state, then Terminate (delete) instance.
Confirm by clicking Terminate (delete).
Wait until the instance state shows Terminated before continuing.

Step 2: Delete the Security Groups.

Navigate to the VPC service by typing VPC in the search bar and selecting it.
In the left nav, choose Security groups.
Select database-sg, choose Actions, then Delete security groups. Confirm the deletion.
Select web-server-sg, choose Actions, then Delete security groups. Confirm the deletion.

Why delete database-sg first?

The database-sg Security Group references web-server-sg as its inbound source. You must delete the referencing group first, then the referenced group.

Step 3: Delete the Subnets.

In the left nav, choose Subnets.
Select all 4 subnets (public-subnet-1, public-subnet-2, private-subnet-1, private-subnet-2).
Choose Actions, then Delete subnet. Confirm the deletion.

Step 4: Delete the custom route table.

In the left nav, choose Route tables.
Select public-route-table.
Choose Actions, then Delete route table. Confirm the deletion.
You cannot delete the main route table separately. It will be removed when you delete the VPC.

Step 5: Detach and delete the Internet Gateway.

In the left nav, choose Internet gateways.
Select my-production-igw.
Choose Actions, then Detach from VPC. Confirm the detachment.
With the gateway still selected, choose Actions, then Delete internet gateway. Confirm the deletion.

Step 6: Delete the VPC.

In the left nav, choose Your VPCs.
Select my-production-vpc.
Choose Actions, then Delete VPC. Confirm the deletion.
This also removes the main route table and the default Security Group that were automatically created with the VPC.

That's a Wrap!

Nice work! You just built a production-style cloud network on AWS from scratch.

You now understand how VPCs, subnets, routing, and security controls work together to form the backbone of every cloud application.

You learned how to:

Build a VPC with public and private subnets across two Availability Zones, giving your network high availability and 65,536 IP addresses.
Attach an Internet Gateway and configure route tables to control exactly which subnets can reach the internet.
Create Security Groups that act as stateful firewalls, then launch a live EC2 instance and prove the entire network works by pinging it from your computer.
Secret Mission: Created a database-tier Security Group that restricts access to only the web tier, implementing a real defense-in-depth pattern used in production.

Ready to quiz yourself?