Build Your Own Cloud Network on AWS

Build a custom VPC with public and private subnets on AWS.

Introduction

30 Second Summary

Every time you visit a website, your request travels through layers of networks, firewalls, and routing rules that decide where traffic can and cannot go. Companies use these same networking building blocks to protect their data and control who can access their servers.

In this project, you will build your own cloud network from scratch on AWS. You'll create isolated sections of the cloud, connect them to the internet, and prove it all works with a live web server.

What You'll Build

You'll create a fully functional Virtual Private Cloud on AWS with public and private subnets, internet connectivity, firewall rules, and a running web server that you can reach from your browser.

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

  • A custom VPC with public and private subnets that separate internet-facing resources from isolated ones.
  • An Internet Gateway and route table directing traffic between your network and the public internet.
  • A security group acting as a virtual firewall to control exactly what traffic can reach your server.
  • Secret Mission: Launch a second server in the private subnet and prove it cannot be reached from the internet, demonstrating true network isolation.

Are there any prerequisites?

No prior cloud or networking experience is needed. Everything is done in a web browser through the AWS Management Console.

You will need a credit or debit card to create your AWS account. You will not be charged for this project because it is fully covered by the AWS Free Tier.

Create Your AWS Account

Every cloud project starts with an AWS account. This is your gateway to hundreds of cloud services, including the networking tools you'll use to build your own virtual network.

In this step, you'll create a free AWS account and sign into the AWS Management Console. This is the control panel where you'll build and manage your entire cloud network.

In this step, get ready to:
  • Sign up for a free AWS account.
  • Sign in to the AWS Management Console.
  • Set your region to US East (N. Virginia).
Sign up for an AWS account

The sign-up wizard walks you through several screens. You'll need your email address, a phone number for verification, and a credit or debit card to complete it.

  • Navigate to the AWS sign-up page in your web browser.
  • Enter your email address in the Root user email address field.
  • Type a name for your account in the AWS account name field, then choose Verify email address.
  • Check your email inbox for a verification code from AWS and enter it on the next screen.
  • Create a strong password for your root user and choose Continue.
  • Choose Personal as your account type.
  • Enter your contact information and accept the AWS Customer Agreement.
  • Enter your credit or debit card details on the billing information screen.
  • Verify your phone number. AWS will send you a PIN via text or call. Enter the PIN to continue.
  • On the support plan screen, select Basic support - Free.
  • Choose Complete sign up.

What is the AWS Free plan?

The Free plan gives you $100 in credits at sign-up and access to 30+ always-free services for up to 6 months. You won't be charged unless you upgrade to a Paid plan.

Your credit or debit card is required to verify your identity and prevent fraud. It will not be charged for anything you do in this project.

Sign in and set your region

Account activation usually takes a few minutes. Once you receive a confirmation email, you're ready to sign in.

  • Go to the AWS Management Console and sign in with the email and password you just created.
  • Look at the top-right corner of the navigation bar. You'll see a region name displayed there.
  • Click the region name to open the region selector dropdown.
  • Select US East (N. Virginia) from the list. This sets your region to us-east-1.

Why US East (N. Virginia)?

This region has the widest service availability and is the default for most AWS tutorials. All resources you create in this project will live in this region.

Can't sign in yet?

Account activation usually takes a few minutes but can sometimes take up to 24 hours in rare cases. Check your email (including spam) for the activation confirmation before trying again.

If you're stuck, help me troubleshoot my AWS account activation.

Verify you're in the right place
  • Confirm you see the AWS Management Console homepage with a search bar at the top of the page.
  • Check the top-right navigation bar. It should display N. Virginia as your selected region.

This is your home base for the rest of the project. Every service and resource you create will be accessed from this console.

Your AWS account is ready to go. Next up, you'll create your very own VPC and claim your own private section of the AWS cloud.

Create Your VPC

Your AWS account is ready. Now it's time to build the foundation of your cloud network.

On AWS, every network starts with a VPC. In this step, you'll create one from scratch to give your project its own isolated corner of the cloud.

In this step, get ready to:
  • Create a custom VPC named my-cloud-network.
  • Understand how VPCs and CIDR blocks define your network's size.
  • Note your VPC ID for use in later steps.
Create your VPC in the AWS Console
  • In the search bar at the top of the AWS Management Console, type VPC.
  • Select VPC from the search results to open the VPC dashboard.
  • Click Create VPC.
  • Under Resources to create, select VPC only.
  • In the Name tag field, enter my-cloud-network.
  • In the IPv4 CIDR block field, enter 10.0.0.0/16.
  • Leave Tenancy set to Default.
  • Click Create VPC.

Why VPC only instead of VPC and more?

The VPC and more option creates a VPC plus subnets, route tables, internet gateways, and NAT gateways in a single workflow. It's faster, but it skips the learning.

You're choosing VPC only so you can build each component yourself and understand how they connect.

Understand what you just created

What is a VPC?

A VPC (Virtual Private Cloud) is your own isolated section of the AWS cloud. No other AWS customer can see or access the resources you place inside it.

The CIDR block 10.0.0.0/16 defines your network's size. It gives you 65,536 private IP addresses to assign to resources inside your network.

Right now, no traffic can enter or leave your VPC because it has no Internet Gateway. You'll add one in a later step.

Verify your VPC and note the VPC ID

After clicking Create VPC, you'll land on the VPC details page. Confirm the following details:

  • The Name shows my-cloud-network.
  • The IPv4 CIDR shows 10.0.0.0/16.
  • The State shows Available.
  • Find the VPC ID at the top of the details page (it starts with vpc-).
  • Copy or write down this VPC ID. You'll need it in upcoming steps.

Don't see your VPC?

Make sure your region is set to US East (N. Virginia) in the top-right navigation bar. Resources only appear in the region where they were created.

If the page looks empty, try clicking Your VPCs in the left sidebar to refresh the list.

Still stuck? Help me find my VPC in the AWS Console.

Your VPC is live, but it's completely sealed off from the internet. Next, you'll carve it into public and private subnets to organize where different types of resources will live.

Create Public and Private Subnets

Your VPC is live, but right now it's just an empty network with no structure inside it. To organize traffic and control what's exposed to the internet, you need to divide your VPC into subnets.

Think of subnets like rooms in a building. A public subnet is the lobby where visitors can walk in from the street. A private subnet is the back office where only authorized staff can go. In this step, you'll create both rooms inside your VPC.

In this step, get ready to:
  • Create a public subnet and a private subnet in different Availability Zones.
  • Enable auto-assign public IP on the public subnet.
  • Verify both subnets are configured correctly.
Create both subnets in your VPC

Each subnet must live entirely within one Availability Zone. By placing your subnets in different zones, you're building in resilience from the start.

  • In the VPC console left sidebar, click Subnets.
  • Click Create subnet.
  • In the VPC ID dropdown, select your VPC (my-cloud-network).

Now configure the first subnet:

  • Enter public-subnet in the Subnet name field.
  • For Availability Zone, select US East (N. Virginia) / us-east-1a.
  • For IPv4 subnet CIDR block, enter 10.0.1.0/24.

What does 10.0.1.0/24 mean?

The /24 at the end means this subnet gets 256 IP addresses (10.0.1.0 through 10.0.1.255). Your VPC's /16 block has 65,536 addresses total, so you're carving out a small slice for this subnet.

Now add the second subnet without leaving this page:

  • Click Add new subnet at the bottom of the page.
  • Enter private-subnet in the Subnet name field.
  • For Availability Zone, select US East (N. Virginia) / us-east-1b.
  • For IPv4 subnet CIDR block, enter 10.0.2.0/24.
  • Click Create subnet.

Why different Availability Zones?

Each Availability Zone is a physically separate data center. Placing your subnets in us-east-1a and us-east-1b means if one data center goes down, the other subnet keeps running.

Enable auto-assign public IP for the public subnet

Right now, both subnets are identical in behavior. To make the public subnet actually public, you need instances launched in it to automatically receive a public IP address.

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

What does auto-assign public IP do?

Any instance you launch in this subnet will automatically get a public IP address that the internet can reach. The private subnet does not have this enabled, so instances there stay hidden from the outside world.

Verify both subnets are configured correctly
  • Return to the Subnets list in the left sidebar.
  • Confirm you see public-subnet with CIDR 10.0.1.0/24 in us-east-1a.
  • Confirm you see private-subnet with CIDR 10.0.2.0/24 in us-east-1b.

Neither subnet can reach the internet yet. That's expected. Without an Internet Gateway and a route table pointing to it, all traffic stays trapped inside your VPC.

Don't see your subnets?

Make sure you're filtering by the correct VPC. The Subnets list may show subnets from the default VPC too. Look for the ones associated with my-cloud-network in the VPC column.

If you see only one subnet, you may have missed the Add new subnet button during creation. Delete the single subnet and repeat the steps above, making sure to add both before clicking Create subnet.

Help me troubleshoot my subnets

Your network now has structure. Two rooms are ready, but the front door to the internet is still missing. In the next step, you'll attach an Internet Gateway and create a route table so your public subnet can send and receive traffic from the outside world.

Connect Your Network to the Internet

Your VPC has subnets ready to host resources, but right now the network is completely sealed off. No traffic can enter or leave because there's no door to the outside world.

In this step, you'll build that door. You'll create an Internet Gateway and wire it up with a route table so your public subnet 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 that directs internet traffic through the gateway.
  • Associate the route table with your public subnet so it can reach the internet.
Create and attach an Internet Gateway

An Internet Gateway is the component that connects your VPC to the public internet. Without it, resources inside your network have no way to communicate with the outside world.

  • In the VPC console left sidebar, choose Internet gateways.
  • Choose Create internet gateway.
  • Enter my-igw in the Name tag field.
  • Choose Create internet gateway.

Your gateway exists now, but it isn't connected to anything yet. You need to attach it to your VPC.

  • On the confirmation page, choose Actions, then Attach to VPC.
  • Select your VPC (my-cloud-network) from the dropdown.
  • Choose Attach internet gateway.

You should see the state change to Attached next to your Internet Gateway. Your VPC now has a door to the internet.

What is an Internet Gateway?

Think of your VPC as a building with no doors. An Internet Gateway is like installing a front entrance. It allows traffic to flow between your VPC and the public internet.

However, just having the door doesn't mean anyone can walk through it. You still need a route table (directions) to tell traffic which way to go, and a security group (a bouncer) to decide who gets in.

Create a route table with an internet route

A route table contains rules (called routes) that determine where network traffic goes. You need a custom route table that sends internet-bound traffic to your new gateway.

  • In the left sidebar, choose Route tables.
  • Choose Create route table.
  • Enter public-route-table in the Name tag field.
  • Select your VPC (my-cloud-network) from the VPC dropdown.
  • Choose Create route table.

Now you need to add a route that sends internet traffic to your gateway.

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

What does 0.0.0.0/0 mean?

The destination 0.0.0.0/0 means "all IP addresses" or "anywhere on the internet." This route tells AWS: any traffic heading to the internet should go through the Internet Gateway.

Your route table already has a local route (10.0.0.0/16 targeting "local") that handles traffic within the VPC. The new route handles everything else.

Don't see your Internet Gateway in the Target dropdown?

Make sure you attached the gateway to your VPC in the previous substep. An unattached gateway won't appear as a target option.

Also confirm you selected my-cloud-network as the VPC when creating the route table. A route table can only reference gateways attached to its own VPC.

Help me troubleshoot my Internet Gateway target not appearing.

Associate the route table with your public subnet

The route table exists with the right route, but it isn't connected to any subnet yet. You need to explicitly associate it with your public subnet.

  • On the same route table page, choose the Subnet associations tab.
  • Choose Edit subnet associations.
  • Check the box next to public-subnet.
  • Choose Save associations.

Your public subnet now has a complete path to the internet. The private subnet still uses the main route table, which has no internet route. This keeps it isolated.

Why does the private subnet stay isolated?

Every VPC comes with a "main" route table that only has a local route. Any subnet not explicitly associated with a custom route table uses the main one by default.

Since you only associated public-route-table with public-subnet, your private-subnet has no route to the Internet Gateway. Traffic from the private subnet simply has nowhere to go.

Your network now has a clear path to the internet for the public subnet while keeping the private subnet locked down. Next up, you'll configure a security group to act as a firewall and control exactly what traffic is allowed in.

Configure Your Security Group

Your public subnet now has a clear path to the internet through the route table and internet gateway. But right now, there's nothing controlling what traffic can actually reach your resources.

In this step, you'll create a security group. This is a virtual firewall that decides which traffic is allowed in and which traffic is blocked.

In this step, get ready to:
  • Create a security group in your VPC.
  • Add inbound rules for HTTP and SSH traffic.
  • Understand how stateful firewalls protect your resources.
Create a security group

A security group controls inbound and outbound traffic for any resource inside your VPC. You need one before you can launch any instances.

  • In the VPC console left sidebar, click Security groups.
  • Click Create security group.
  • In the Security group name field, enter web-server-sg.
  • In the Description field, enter Allow HTTP and SSH access.
  • In the VPC dropdown, remove the default VPC and select your my-cloud-network VPC.

Why remove the default VPC first?

AWS pre-selects your account's default VPC in the dropdown. You need to clear it and pick my-cloud-network so your security group is created inside the custom network you built.

Add inbound firewall rules

Inbound rules control what traffic is allowed to reach your resources from the outside world. You'll add two rules: one for web traffic and one for secure shell access.

  • Scroll down to the Inbound rules section.
  • Click Add rule.
  • For the first rule, set Type to HTTP.
  • Set Source to Anywhere-IPv4 (0.0.0.0/0).
  • Click Add rule again to add a second rule.
  • For the second rule, set Type to SSH.
  • Set Source to My IP. The console auto-fills your current IP address.
  • Leave the Outbound rules section as the default (all traffic allowed).
  • Click Create security group at the bottom of the page.

Why 'My IP' for SSH?

HTTP is set to Anywhere-IPv4 because you want anyone on the internet to view your web page.

SSH is restricted to My IP because SSH gives direct command-line access to your server. Limiting it to your current IP address means only your computer can connect this way.

You should see a green success banner confirming the security group was created. Your web-server-sg security group now appears in the security groups list.

Don't see your VPC in the dropdown?

Make sure you're still in the US East (N. Virginia) region. Check the top-right of the navigation bar. If your region changed, switch it back to us-east-1 and try again.

Help me find my VPC when creating a security group in the AWS console.

Understand how stateful firewalls work

You just configured two inbound rules, but you didn't touch the outbound rules. So how will your server send responses back to visitors?

What does 'stateful' mean?

Security groups are stateful firewalls. "Stateful" means if you allow traffic in on a port, the response traffic is automatically allowed back out. You don't need a separate outbound rule for it.

In your setup, HTTP traffic arrives on port 80. The security group remembers that connection and automatically lets your server's response flow back to the visitor. The same applies to SSH on port 22.

Here's what your two rules do in plain terms:

  • HTTP (port 80) from 0.0.0.0/0: anyone on the internet can view a web page hosted on your server.
  • SSH (port 22) from your IP: only your computer can connect directly to the server's command line.

Your virtual firewall is in place. Next up, you'll launch an EC2 instance inside your network and prove that everything works together by loading a web page from the internet.

Launch an EC2 Instance and Test Your Network

Your network is fully wired. You have a VPC, subnets, an internet gateway, a route table, and a security group all working together.

Now it's time to put it to the test. You'll launch a virtual server (an EC2 instance) inside your public subnet and confirm that internet traffic can reach it through every layer you built.

In this step, get ready to:
  • Launch an EC2 instance in your public subnet with a web server startup script.
  • Verify that every layer of your network (VPC, subnet, route table, internet gateway, security group) delivers traffic from the internet to your instance.
Configure the basic instance settings

The EC2 launch wizard walks you through everything needed to spin up a virtual server. You'll start with the basics: a name, an operating system, an instance size, and a key pair choice.

  • In the AWS Console search bar at the top, type EC2 and select EC2 from the results.
  • On the EC2 Dashboard, click Launch instance.
  • Under Name and tags, enter my-web-server in the Name field.
  • Under Application and OS Images (Amazon Machine Image), confirm that Amazon Linux is selected in the Quick Start tab. This is a lightweight Linux distribution built for AWS.
  • Under Instance type, select t3.micro from the dropdown. This is Free Tier eligible.
  • Under Key pair (login), click the dropdown and choose Proceed without a key pair (Not recommended). You won't need SSH access for this project because you'll test the server through your browser instead.

What is an EC2 instance?

An EC2 instance is a virtual server running in the AWS cloud. You choose the operating system, the hardware size, and which network it lives in. Think of it like renting a computer that runs 24/7 in a data center.

The t3.micro instance type gives you 2 vCPUs and 1 GB of memory. It's small but perfect for testing a basic web page.

Configure network settings and launch

Now you'll point the instance at the network infrastructure you built in the previous steps. You'll also add a startup script that automatically installs a web server.

  • Under Network settings, click Edit.
  • For VPC, select my-cloud-network from the dropdown.
  • For Subnet, select public-subnet.
  • For Auto-assign public IP, verify it says Enable. This ensures your instance gets a public IP address that the internet can reach.
  • For Firewall (security groups), choose Select existing security group.
  • In the dropdown that appears, select web-server-sg.

Next, you'll add a User data script. This is a bash script that runs automatically when the instance first boots up.

  • Scroll down and expand the Advanced details section.
  • Scroll to the very bottom of Advanced details until you see the User data text box.
  • Paste the following script into the User data field:
#!/bin/bash
yum update -y
yum install -y httpd
systemctl start httpd
systemctl enable httpd
echo "<h1>Hello from my cloud network!</h1><p>This server is running in my custom VPC.</p>" > /var/www/html/index.html

What does this script do?

  • yum update -y updates all the system packages to the latest versions.
  • yum install -y httpd installs Apache, an open-source web server.
  • systemctl start httpd starts the web server immediately.
  • systemctl enable httpd ensures the web server restarts automatically if the instance reboots.
  • The last line creates a simple HTML page that you'll see in your browser when you visit the server's public IP.
  • Leave all other settings at their defaults.
  • Click Launch instance.

You should see a success banner confirming your instance is launching.

Seeing an error when launching?

  • If you see a permissions error, make sure you're signed in as the root user (the email you created the account with), not an IAM user.
  • If the instance type shows as unavailable, confirm your region is set to US East (N. Virginia) in the top-right navigation bar.
  • Double-check that you selected my-cloud-network as the VPC, not the default VPC.

Still stuck? Help me troubleshoot my EC2 launch error.

Test your network from the browser

Your instance needs about 60 seconds to boot up and run the User data script. After that, you can visit it in your browser to prove the full network stack is working.

  • Click View all instances (or go to Instances in the left sidebar).
  • Wait until the Instance state column shows Running for your my-web-server instance. This may take about 60 seconds. You can click the refresh icon to update the list.
  • Click on the instance name my-web-server to open its details panel.
  • Find the Public IPv4 address field in the instance details. Copy this IP address.
  • Open a new browser tab and paste the IP address into the address bar. Press Enter.

You should see a web page displaying "Hello from my cloud network!" along with "This server is running in my custom VPC."

Why does this prove your network works?

For that web page to appear in your browser, traffic had to flow through every layer you built in this project:

  • Your browser sent a request to the instance's public IP.
  • The Internet Gateway received the request and passed it into your VPC.
  • The Route Table directed the traffic to the correct subnet.
  • The Security Group checked that HTTP traffic on port 80 was allowed, and let it through.
  • The EC2 instance received the request and Apache served your HTML page back.

Page not loading?

  • Make sure you're using http:// (not https://) in your browser address bar. Your security group only allows HTTP on port 80, not HTTPS on port 443.
  • If the page times out, wait another 60 seconds. The User data script takes time to install Apache and start the web server.
  • Confirm that the Instance state shows Running (not Pending) before trying the IP address.
  • Verify that Auto-assign public IP shows Enable in the instance's networking details. If it's disabled, your instance has no public IP to reach.

Still stuck? Help me figure out why I can't reach my EC2 instance's web page.

Secret mission

Prove Network Isolation Works

Your public subnet works. But how do you know the private subnet is truly isolated? Launch a second instance and prove that network boundaries are real.

Clean Up Your Resources

Clean Up Your Resources

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

Your EC2 instances are covered by AWS Free Tier credits ($100 at sign-up). VPCs, subnets, route tables, security groups, and internet gateways have no additional charges.

Cost warning

Your t3.micro EC2 instances are covered by your Free Tier credits, but leaving them running for weeks will consume those credits faster.

If you're done experimenting, stop or terminate the instances to preserve your remaining credits for future projects.

Resources you used:

  • EC2 instances: my-web-server and private-server.
  • Security group: web-server-sg.
  • Internet gateway: my-igw.
  • Subnets: public-subnet and private-subnet.
  • Route table: public-route-table.
  • VPC: my-cloud-network.

Keep everything running

No action needed. Choose this if you're still actively experimenting with your cloud network.

  • Your t3.micro instances are covered by Free Tier credits. You can leave them running to continue testing.
  • Monitor your credit usage in the AWS Billing dashboard by searching Billing in the top search bar.
  • VPCs, subnets, route tables, security groups, and internet gateways have no ongoing charges regardless of how long they exist.

Pause - I'll come back to this later

Stop the EC2 instances to preserve your Free Tier credits. Your network configuration stays intact for when you return.

  • Search EC2 in the top search bar and select EC2.
  • In the left sidebar, choose Instances.
  • Select both my-web-server and private-server using the checkboxes.
  • Choose Instance state, then Stop instance.
  • Your VPC, subnets, route tables, security group, and internet gateway remain in place at no cost.

Delete - I don't want to use this again

Remove all project resources to ensure zero ongoing costs. Follow these steps in order, since some resources depend on others.

Terminate both EC2 instances:

  • Search EC2 in the top search bar and select EC2.
  • In the left sidebar, choose Instances.
  • Select both my-web-server and private-server.
  • Choose Instance state, then Terminate instance. Confirm when prompted.
  • Wait until both instances show a Terminated state before continuing.

Delete the security group:

  • Search VPC in the top search bar and select VPC.
  • In the left sidebar, choose Security groups.
  • Select web-server-sg, choose Actions, then Delete security groups. Confirm the deletion.

Detach and delete the internet gateway:

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

Delete both subnets:

  • In the left sidebar, choose Subnets.
  • Select public-subnet and private-subnet.
  • Choose Actions, then Delete subnet. Confirm the deletion.

Delete the route table:

  • In the left sidebar, choose Route tables.
  • Select public-route-table, choose Actions, then Delete route table. Confirm the deletion.
  • Do not delete the main route table. AWS removes it automatically when you delete the VPC.

Delete the VPC:

  • In the left sidebar, choose Your VPCs.
  • Select my-cloud-network, choose Actions, then Delete VPC. Confirm the deletion.
  • This removes the VPC and its main route table. All project resources are now deleted.

Nice Work!

Nice Work!

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

This is the same foundation that powers everything from startups to Fortune 500 companies.

You've learned how to:

  • Created a custom VPC with public and private subnets across different Availability Zones, giving you full control over your cloud network architecture.
  • Connected your network to the internet using an Internet Gateway and a custom route table, directing traffic exactly where it needs to go.
  • Launched a live EC2 web server protected by a security group and proved internet traffic flows through your custom network to reach it.
  • Proved that private subnets are truly isolated from the internet by launching a second instance with no public access.

Ready to quiz yourself?