Build Your Own Cloud Network on AWS

Build a custom VPC with subnets and deploy a live web server on AWS.

Introduction

30 Second Summary

Every website you visit and every app you open runs on a network somewhere in the cloud. Someone had to build that network, decide what faces the public internet, and control what traffic gets through.

In this project, you will build your own cloud network on AWS from scratch and deploy a live web server into it. By the end, you'll have a web page that anyone in the world can visit by typing an IP address into their browser.

What You'll Build

Picture pasting an IP address into your browser and watching a web page appear, served from a cloud network you designed and secured yourself.

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

A live web server running inside your own Virtual Private Cloud on AWS, serving a page anyone can open from their browser.
Hands-on understanding of how a public subnet connects to the internet while a private subnet stays completely isolated.
Real experience debugging a blocked connection by configuring a security group to allow web traffic through.
An optional Secret Mission to push your skills further.

Are there any prerequisites?

You'll need an AWS account with free tier access. No terminal or coding experience is required. All work is done in the AWS Management Console using your web browser.

Before We Start

Before we dive in, let's lock in what you're about to build and why it matters.

Set Up Your AWS Console

Every resource you create on AWS lives in a specific geographic region. Choosing the right region before you start building ensures all your networking components end up in the same place.

In this step, you'll sign into the AWS Management Console and set your region. You'll also visit the two dashboards you'll use throughout this project: VPC and EC2.

In this step, get ready to:

Sign into the AWS Management Console and set your region to us-east-1.
Visit the VPC dashboard where you'll build your cloud network.
Confirm access to the EC2 dashboard where you'll launch your web server.

Log into the AWS Management Console

Open https://console.aws.amazon.com/ in your browser.
Sign in with your AWS account credentials.
In the top-right corner of the console, click the region selector dropdown.
Choose US East (N. Virginia) us-east-1.

The region selector now shows US East (N. Virginia). Every resource you create in this project will live in this region.

Why US East (N. Virginia)?

The us-east-1 region is the most commonly used AWS region and has the widest free tier support. Picking a single region now keeps all your resources in one place so they can communicate with each other.

Having trouble signing in?

Double-check whether you're using your root account email or an IAM user. If you've forgotten your password, click Forgot your password? on the sign-in page to reset it.

Help me sign into the AWS Management Console.

Navigate to the VPC dashboard

In the search bar at the top of the console, type VPC.
Select VPC from the search results.

You should see the VPC dashboard. Look at the Your VPCs section. You'll see one VPC already listed.

This is the default VPC that AWS creates automatically for every account. You will not use this default VPC. You'll create your own from scratch so you understand every piece.

What is the default VPC?

Every AWS account comes with a default Virtual Private Cloud in each region. It has a subnet in each Availability Zone, an internet gateway, and DNS settings already configured.

The default VPC is designed for quick experimentation. Building your own VPC teaches you how each networking piece works and gives you full control over your network architecture.

Visit the EC2 dashboard

One quick stop before you start building. You'll need the EC2 dashboard later to launch your web server, so let's confirm you can reach it.

In the search bar at the top of the console, type EC2.
Select EC2 from the search results.

You should see the EC2 dashboard. Confirm the region selector in the top-right still shows US East (N. Virginia). You'll return here in Step 3 to launch your web server.

Your console is set up. You're signed in, your region is locked to us-east-1, and you know where to find both the VPC and EC2 dashboards.

Your AWS console is ready to go. Next up, you'll create your own Virtual Private Cloud with public and private subnets.

Create Your Virtual Private Cloud

Your console is ready with the right region selected. Now you need a network where your servers will live.

A Virtual Private Cloud is your own isolated network inside AWS. In this step, you will create a custom VPC with a public subnet and a private subnet, controlling which resources face the internet and which stay hidden.

In this step, get ready to:

Create a custom VPC with public and private subnets using the AWS wizard.
Explore the Resource Map to see how your networking components connect.
Examine route tables to understand why public and private subnets behave differently.

Create a VPC using the "VPC and more" wizard

The AWS console offers a wizard that creates your VPC along with subnets, route tables, and an internet gateway in one step.

In the console search bar at the top, type VPC.
Select VPC from the results to return to the VPC dashboard.
Click Create VPC.
Under Resources to create, select VPC and more.
For Name tag auto-generation, enter my-vpc.

Why use the "VPC and more" option?

Building each networking component individually would take much longer without teaching additional concepts. The wizard creates your VPC, subnets, route tables, and internet gateway all at once.

AWS uses the name you enter as a prefix for all resources. You will see names like my-vpc-vpc, my-vpc-subnet-public1, and my-vpc-rtb-public throughout the project.

For IPv4 CIDR block, keep the default 10.0.0.0/16.
For Number of Availability Zones, choose 1.
For Number of public subnets, choose 1.
For Number of private subnets, choose 1.
For NAT gateways, choose None.
For VPC endpoints, choose None.

What is a CIDR block?

A CIDR block defines the range of IP addresses your VPC can use. 10.0.0.0/16 gives your network up to 65,536 private IP addresses.

Every resource you launch inside this VPC gets an IP address from this range.

Click Create VPC.
Wait for all resources to show a green Success status.

Seeing an error during creation?

AWS accounts have a default limit of 5 VPCs per region. If you have existing VPCs from other projects, you may need to delete one first.
Make sure you selected VPC and more under Resources to create, not VPC only.

Help me troubleshoot my VPC creation error.

Explore the Resource Map

Click View VPC to go to your new VPC's detail page.
Click the Resource map tab.

The Resource Map shows every networking component the wizard created: your VPC, one public subnet, one private subnet, route tables, and the internet gateway.

The public subnet's route table connects to the internet gateway. The private subnet's route table does not.

What is an internet gateway?

An internet gateway is a VPC component that allows communication between your network and the public internet. Without one, nothing inside your VPC can reach the outside world.

The public subnet connects to the internet gateway, making its resources reachable from the internet. The private subnet does not, keeping its resources isolated. This is the fundamental difference between public and private subnets.

Examine the route tables

The Resource Map gives you a visual overview. Now let's look at the actual route entries to see exactly how traffic flows.

In the left sidebar of the VPC console, click Route tables.
Find the route table named my-vpc-rtb-public.
Click on it.
Select the Routes tab.

You should see two routes: 10.0.0.0/16 with target local, and 0.0.0.0/0 with target pointing to your internet gateway.

What do these routes mean?

The 10.0.0.0/16 -> local route keeps all traffic within your VPC's IP range inside the network. Any resource talking to another resource in the VPC stays local.

The 0.0.0.0/0 -> internet gateway route sends everything else to the internet. This is the route that makes a subnet public.

Before you look at the private subnet's route table, what do you think will be different?

Find the route table associated with your private subnet in the list.
Click on it.
Select the Routes tab.

The private route table only has the 10.0.0.0/16 with target local route. There is no route to the internet gateway.

Without that internet gateway route, instances in the private subnet cannot send or receive traffic from the public internet.

Can't find the right route table?

The VPC console may show route tables from your default VPC as well. Look for tables with the my-vpc prefix in their name.
If you do not see two routes in the public table, make sure you selected the route table associated with my-vpc-subnet-public1, not the private subnet.

Help me find the correct route table for my VPC.

Your network is built and you understand how every piece connects. Next up, you will launch a web server into the public subnet and put this network to the test.

Launch a Web Server

In Step 2, you built a complete cloud network with a public subnet connected to an internet gateway, and a private subnet with no internet route at all. Right now though, your network is an empty shell with nothing running inside it.

In this step, you'll launch an EC2 instance inside your public subnet and install Apache on it. Apache is a web server that serves pages to anyone who visits your instance's public IP address.

In this step, get ready to:

Launch an EC2 instance in your public subnet.
Install Apache web server using a user data script.
Test your web server by visiting its public IP in a browser.

Launch an EC2 instance

EC2 instances are virtual servers you can launch inside your VPC. You'll configure one step by step using the EC2 launch wizard.

In the search bar at the top of the console, type EC2.
Select EC2 from the results to return to the EC2 dashboard.
Click Launch instance.
For Name, enter my-web-server.
Under Application and OS Images (Amazon Machine Image), keep Amazon Linux 2023 AMI selected. You'll see it labeled Free tier eligible under Quick Start.
Under Instance type, choose t3.micro. It is also labeled Free tier eligible.
Under Key pair (login), select Proceed without a key pair (not recommended).

Why no key pair?

A key pair lets you SSH into your instance from a terminal. You won't need that for this project because you'll verify your web server by visiting it in the browser instead.

Configure network settings

Now you'll connect your instance to the VPC and public subnet you built in Step 2. This is what places your server inside your custom network instead of the default one.

Under Network settings, click Edit.
For VPC, select your VPC (my-vpc-vpc).
For Subnet, select your public subnet (my-vpc-subnet-public1).
For Auto-assign public IP, select Enable.

Why enable Auto-assign public IP?

Instances launched in non-default subnets don't get a public IP address automatically. Without a public IP, nobody on the internet can reach your web server, even with the internet gateway in place.

Under Firewall (security groups), select Create security group.
For Security group name, enter my-web-server-sg.
For Description, enter Security group for web server.
Leave the default SSH inbound rule as-is.

What is a security group?

A security group acts as a virtual firewall for your EC2 instance. It controls which traffic is allowed to reach your instance (inbound rules) and which traffic can leave it (outbound rules).

Add user data and launch

User data is a script that runs automatically the first time your instance boots. You'll use it to install Apache and create a web page without ever logging into the instance.

Scroll down and expand the Advanced details section at the bottom of the page.
Scroll down to the User data field.
Paste the following script into the User data field:

#!/bin/bash
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from my VPC!</h1><p>This web server is running inside a custom AWS network that I built from scratch.</p>" > /var/www/html/index.html

What does this script do?

yum install -y httpd installs Apache, a popular web server, on the instance.
systemctl start httpd starts the web server immediately.
systemctl enable httpd makes sure Apache restarts automatically if the instance reboots.
The echo line creates a simple HTML page at /var/www/html/index.html, which is Apache's default document root.

Click Launch instance.
Wait for the success message, then click View all instances.
Click on your my-web-server instance.
In the details panel at the bottom, find the Public IPv4 address field and copy the IP address.

Your instance should show a Running status with a green check mark in the Instance state column. It may take 1-2 minutes to move from Pending to Running.

Instance not showing as Running?

If the status still says Pending, wait another minute and click the refresh icon at the top of the instances table.
Make sure you selected my-vpc-subnet-public1 as your subnet, not the private subnet.

Help me troubleshoot my EC2 instance that is not reaching Running status.

Your instance is running and has a public IP address. Before you visit it in the browser, what do you think will happen when you paste that IP address into the address bar?

Open a new browser tab.
In the address bar, type http:// followed by the IP address you just copied, then press Enter.

The page does not load. Your browser spins and eventually times out or shows a connection error.

Why is the page timing out?

Your EC2 instance has a public IP. Apache is installed and running. The internet gateway provides a route to the internet. So what's missing?

The security group. Right now, my-web-server-sg only allows SSH traffic on port 22. It has no rule for HTTP traffic on port 80. Security groups are deny-by-default. Any traffic you don't explicitly allow is silently dropped.

Your web server is running but invisible to the outside world. Next, you'll crack open the security group and watch your page come to life.

Open the Door with Security Groups

In the last step, you launched a web server running Apache inside your public subnet, gave it a public IP address, and tried to visit it in your browser. The page timed out.

The culprit is your security group. Security groups act as firewalls for EC2 instances, controlling exactly which traffic is allowed in and out. Your security group currently only permits SSH connections on port 22, so HTTP traffic on port 80 is silently blocked.

In this step, get ready to:

Edit the security group to allow inbound HTTP traffic on port 80.
Test your web server by refreshing the browser and seeing the page load.
Understand how security groups, route tables, and the internet gateway work together.

Edit the security group to allow HTTP

Until you explicitly allow HTTP on port 80, your web server is invisible to anyone trying to reach it. Let's open that door.

Switch back to the AWS Management Console tab in your browser.
In the EC2 console, click on your my-web-server instance.
Click the Security tab in the lower details panel.
Click the security group link my-web-server-sg. This opens the security group detail page.
Click Edit inbound rules.
Click Add rule.
For Type, select HTTP. This automatically sets the port to 80.
For Source, select Anywhere-IPv4 (0.0.0.0/0). This allows anyone on the internet to reach your web server on port 80.

Click Save rules.

What did you just change?

Security groups are deny-by-default. Any traffic that is not explicitly allowed by a rule is silently dropped.

Before this change, your security group only had an SSH rule (port 22). When your browser sent an HTTP request on port 80, the security group had no matching rule and dropped it. By adding the HTTP rule, you told the security group to let web traffic through.

Can't find my-web-server-sg?

Make sure you clicked on the my-web-server instance first, then opened the Security tab. The security group link appears there.
If you are on the Security Groups page but see multiple groups, look for the one with the name my-web-server-sg and the description "Security group for web server".

Still stuck? Ask for help.

Test your live web server

Before you refresh the page, think about what you expect to happen. The security group now allows HTTP on port 80. Do you think the page will load this time, or will it still time out?

Switch to the browser tab where you pasted your public IP address earlier (the one that timed out).
Refresh the page.

You should now see a page that says "Hello from my VPC!" with the message "This web server is running inside a custom AWS network that I built from scratch." underneath.

Why does the page load now?

Three pieces are working together to make this happen:

The internet gateway provides a path between your VPC and the public internet.
The public subnet's route table has a rule (0.0.0.0/0 pointing to the internet gateway) that directs traffic through that gateway.
The security group now allows inbound HTTP traffic on port 80, so your browser's request is no longer dropped.

Remove any one of these three pieces and the page would stop loading.

Page still not loading?

Make sure the URL starts with http:// (not https://). Your server only listens on HTTP.
Confirm the inbound rule you added has Type set to HTTP and Source set to 0.0.0.0/0.
Check that your instance status shows Running with a green check in the EC2 console. If the instance is stopped, Apache is not running.

Need more help?

Understand why this works

Your page is live. Now let's trace exactly why the public subnet can reach the internet while the private subnet cannot.

Return to the VPC console. In the left sidebar, click Route tables.
Click on your public subnet's route table (my-vpc-rtb-public).
Click the Routes tab. Find the route 0.0.0.0/0 with the target pointing to your internet gateway. This is the rule that sends all non-local traffic out to the internet.
Go back to Route tables and click on your private subnet's route table.
Click the Routes tab. Notice it only has the local route (10.0.0.0/16). There is no 0.0.0.0/0 route to an internet gateway.

What is network-level isolation?

The private subnet's route table has no path to the internet gateway. Even if you gave an instance in that subnet the most permissive security group in the world, it still could not reach or be reached from the internet.

This is the power of network-level isolation. Security groups control traffic at the instance level, but route tables control traffic at the network level. Both layers must allow the traffic for a connection to work.

You now have a fully working cloud network with a live web server that anyone can visit. You also understand the three layers that make it possible: the internet gateway, the route table, and the security group.

Secret mission

Prove Your Private Subnet Is Isolated

You've seen the public subnet deliver a live web page. But is the private subnet truly cut off from the internet? Launch a second instance and find out.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The VPC, subnets, route tables, internet gateway, and security groups are always free, but your EC2 instances consume free tier credits while running.

Cost warning

If you leave your instances running beyond your free tier period or credits, you will be charged standard on-demand rates. Terminate your instances when you are done with this project.

Resources you used:

1 VPC (my-vpc-vpc).
2 subnets (my-vpc-subnet-public1 and my-vpc-subnet-private1).
1 internet gateway attached to my-vpc-vpc.
2 route tables (including my-vpc-rtb-public).
2 EC2 instances (my-web-server and my-private-server if you completed the Secret Mission).
2 security groups (my-web-server-sg and my-private-server-sg if you completed the Secret Mission).

Keep everything running

No action needed. Choose this if you are still actively building or experimenting with your cloud network.

Your EC2 instances will continue consuming free tier credits while running.
Monitor your usage in the AWS Billing dashboard to avoid unexpected charges.

Pause - I'll come back to this later

Shut down your running instances to stop consuming compute credits while keeping all your networking resources in place.

In the EC2 console, select your my-web-server instance.
Click Instance state.
Click Stop instance.
When prompted, click Stop to confirm.
If you completed the Secret Mission, repeat for my-private-server.

What happens when I stop an instance?

Stopped instances do not consume compute credits. The EBS storage continues at no charge under the free tier. You can restart your instances at any time from the EC2 console.

Delete - I don't want to use this again

Remove all project resources completely. Start by terminating the EC2 instances, then delete the VPC.

Terminate EC2 instances:

In the EC2 console, select your my-web-server instance.
Click Instance state.
Click Terminate (delete) instance.
Click Terminate (delete) to confirm.
If you completed the Secret Mission, select my-private-server and repeat the termination steps.
Wait for all instances to show a Terminated status.

Delete the VPC and all networking resources:

In the search bar at the top of the console, type VPC and select VPC.
In the left sidebar, click Your VPCs.
Select your VPC (my-vpc-vpc).
Click Actions.
Click Delete VPC.
Type delete when prompted for confirmation.
Click Delete to confirm.

What does Delete VPC remove?

The Delete VPC action automatically deletes all associated subnets, route tables, internet gateways, security groups, and network ACLs in one step. You do not need to delete these individually.

Nice Work!

You just built a cloud network from scratch on AWS and put a live web server inside it. Anyone with your public IP address can visit the page you created.

You've learned how to:

Build a custom VPC with public and private subnets, an internet gateway, and route tables that control how traffic flows through your network.
Launch an EC2 instance running Apache in your public subnet, serving a web page accessible from the internet.
Debug a security group that blocked all inbound HTTP traffic, then fix it by adding a rule on port 80 to make your web server reachable.
Completed an optional Secret Mission to push your cloud networking skills further.

Ready to quiz yourself?