Build Your First Cloud Network on AWS

Build a VPC with public and private subnets and prove network isolation works.

Introduction

30 Second Summary

Every time you open a banking app, stream a video, or send a message, your data travels through cloud networks that separate public-facing services from private backend systems. This invisible architecture keeps your information safe.

In this project, you will build a real cloud network on AWS with public and private zones, launch virtual servers inside each zone, and prove that your security design works by watching a connection fail on purpose.

What You'll Build

You will connect to a virtual server running in the cloud directly from your web browser, then watch a second connection get blocked by the network isolation rules you designed yourself.

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

A running virtual server you can log into from your web browser, proving your public network routes traffic correctly.
A connection failure you caused on purpose, proving your private network blocks outside access exactly as designed.
A visual network map in the AWS console showing your entire architecture with subnets, gateways, and routing rules all connected.
Secret Mission: Prove that "private" does not mean "unreachable" by pinging your private server from inside the network.

Are there any prerequisites?

None. You just need a Windows computer with a Chrome or Edge browser. This project walks you through creating your AWS account from scratch, and everything runs in the browser with no software to install.

Before We Start

Before We Start...

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

Create Your AWS Account

To build your cloud network, you first need access to the cloud itself. AWS (Amazon Web Services) is where you will create your network, and the AWS Management Console is the web-based dashboard you will use to build and manage everything.

In this step, you will create a free AWS account, sign in to the console, and locate the VPC service where you will build your network in the next step.

In this step, get ready to:

Create a free AWS account.
Sign in to the AWS Management Console and set your region.
Find the VPC service.

Create a free AWS account

AWS offers a free plan that gives you $100 in credits and 6 months of access at no cost. You will not be charged unless you upgrade to a paid plan.

Open your browser and go to https://aws.amazon.com/free/.
Click Create a Free AWS Account.
Enter your email address in the Root user email address field.
Edit the AWS account name to something you will recognise (like your name).
Click Verify email address.

What happens next?

AWS sends a verification code to your email. Check your inbox (and spam folder) for an email from AWS containing a numeric code.

Enter the verification code from your email and click Verify.
Create a strong password. It must be at least 8 characters and include at least three of the following: uppercase letters, lowercase letters, numbers, and symbols.
Confirm your password and click Continue.
Choose your account plan. Select Free.
Select Personal for the account type.
Fill in your contact details (name, phone number, address) and click Continue.

Why do I need a payment method?

AWS requires a valid payment method to verify your identity and prevent abuse. AWS will not charge your payment method until you upgrade to a paid plan.

Enter your payment method details (credit or debit card) and click Verify and Add.
On the Confirm your identity page, choose Text message (SMS) or Voice call to receive a verification code.
Enter your phone number and complete the verification by entering the PIN you receive.
On the Select a support plan page, choose Basic Support - Free.
Click Complete sign up.

You will see a confirmation page indicating your account is being activated. Activation usually takes a few minutes but can sometimes take up to 24 hours.

Not receiving the activation email?

Check your spam or junk folder. If it has been more than a few minutes, try signing in at https://console.aws.amazon.com/ anyway. Some accounts activate before the email arrives.

Help me troubleshoot my AWS account activation

Sign in and set your region

Once your account is activated, you can sign in and configure the region where your network resources will live.

Go to https://console.aws.amazon.com/ and sign in with the email address and password you just created.

You will land on the Console Home dashboard. You should see a search bar at the top, a navigation bar, and a dashboard with widgets.

In the top-right corner of the navigation bar, click the Region name that is currently displayed (it may say something like US East (Ohio) or another region).
From the dropdown list, select US East (N. Virginia) us-east-1.

Why us-east-1?

US East (N. Virginia) is the most widely documented AWS region and has the broadest service availability. Using it means every step in this project works exactly as described.

Find the VPC service

A VPC (Virtual Private Cloud) is the networking service where you will build your custom cloud network. Let's navigate there now.

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

Before you continue, what do you expect to see on the VPC Dashboard? Think about whether AWS gives you a blank slate or something pre-built.

You will see the VPC Dashboard. Notice it already shows a default VPC that AWS created for you automatically. Every new account gets one.

What is the default VPC?

AWS creates a default VPC in every region so you can launch resources immediately without any setup. It is a flat network with no security separation.

In the next step, you will build your own custom VPC with public and private zones to create real network isolation.

Your AWS account is ready and you have found the VPC service. Next up, you will build your own custom cloud network with public and private subnets.

Build Your Cloud Network (VPC)

Your AWS account is live and you've found the VPC Dashboard. Now it's time to build your own network from scratch.

The default VPC that AWS created for you is a flat network with no security separation. Real companies create custom VPCs with distinct zones: a public zone accessible from the internet, and a private zone with no outside access.

In this step, get ready to:

Create a custom VPC with public and private subnets using the AWS wizard.
View the Resource Map to see your network's architecture.
Inspect route tables to understand what makes a subnet public or private.

Create a VPC with public and private subnets

AWS provides a wizard that creates your entire network in one go. It builds the VPC, subnets, route tables, and an internet gateway together so they are wired up correctly from the start.

On the VPC Dashboard, click Create VPC.
For Resources to create, choose VPC and more.
Under Name tag auto-generation, enter my-network.
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, keep None.

Look at the Preview pane on the right side of the screen. You can see a diagram of your network taking shape with solid lines showing how resources connect.

For VPC endpoints, choose None.
Click Create VPC.

You will see a success screen showing all the resources AWS created for you. This includes your VPC, two subnets, two route tables, and an Internet Gateway.

What did the wizard just create?

The VPC and more option created six resources in one step. Your VPC is the overall container. Inside it, you have a public subnet (like the lobby of a building, accessible from the street) and a private subnet (like a locked server room).

The wizard also attached an Internet Gateway to your VPC. This is the door between your network and the public internet. Only the public subnet's route table points to it.

What is a CIDR block?

The 10.0.0.0/16 value is a CIDR block that defines the range of IP addresses your VPC can use. The /16 means your network has 65,536 possible addresses. Think of it as the size of the building you just constructed.

Explore the Resource Map

The Resource Map is a visual diagram of everything in your VPC. It shows how subnets, route tables, and the Internet Gateway connect to each other.

On the success screen, click View VPC.
Click the Resource map tab.

You will see a visual diagram showing your VPC containing two subnets. The Internet Gateway is connected to the public subnet's route table. The private subnet has its own route table with no internet connection.

What does the Resource Map tell you?

The public subnet has a "door to the street" through the Internet Gateway. Traffic from the internet can reach it, and traffic from inside can reach the internet.

The private subnet has no door. It can only communicate within the VPC itself. This is exactly how companies protect databases and internal services.

Understand what just happened

You can see the diagram, but what actually controls whether a subnet is public or private? The answer is route tables. Each subnet has a route table that acts like a set of directions telling traffic where it can go.

In the left navigation pane, click Route tables.
You will see two route tables. Click on the one with "public" in its name.
Click the Routes tab at the bottom of the page.

You will see two routes. The first is 10.0.0.0/16 with a target of "local", which keeps VPC-internal traffic inside the network. The second is 0.0.0.0/0 pointing to your Internet Gateway. This route means "send all internet-bound traffic through the gateway."

What does 0.0.0.0/0 mean?

The 0.0.0.0/0 route is a catch-all. It matches any destination that is not already covered by a more specific route. Since the only other route is the local VPC range, this effectively says "everything outside the VPC goes to the Internet Gateway." This single route is what makes a subnet public.

Before you check the private route table, predict what you will find there. Will it have an Internet Gateway route?

Click Route tables in the left navigation pane to return to the list.
Click on the route table with "private" in its name.
Click the Routes tab.

You will see only one route: 10.0.0.0/16 with a target of "local". There is no 0.0.0.0/0 route. The private subnet has no way to send or receive traffic from the internet.

Why does this matter?

Route tables are the core mechanism that controls connectivity. A subnet with a route to an Internet Gateway is public. A subnet without one is private. It is that simple.

In a real company, databases and internal APIs live in private subnets. They are protected from direct internet access by design, not by accident.

Don't see two route tables?

Make sure you are looking at route tables for your custom VPC, not the default VPC. Check the VPC column in the route tables list. Your custom VPC will show the ID associated with my-network-vpc.

help me find my custom VPC's route tables in the AWS console

Your network is built. You have a public subnet with a path to the internet and a private subnet with no outside access. Next up, you will launch a virtual server inside the public subnet and connect to it from your browser.

Launch a Server in the Public Subnet

Your custom VPC is built with a public zone and a private zone, each with its own routing rules. But right now, your network is an empty building with no one inside.

In this step, you will launch a virtual server inside your public subnet and connect to it directly from your browser. This proves the network you built actually works and that internet traffic flows through the Internet Gateway as expected.

In this step, get ready to:

Launch an EC2 instance in the public subnet.
Connect to the instance from your browser using EC2 Instance Connect.
Run a command to verify internet access through the Internet Gateway.

Launch an EC2 instance in your public subnet

An EC2 instance is a virtual server that runs in the cloud. You will launch one inside your public subnet to give it a path to the internet.

In the search bar at the top of the console, type EC2 and click EC2 from the results.
On the EC2 Dashboard, click Launch instance.
Under Name and tags, enter Public Server.
Under Application and OS Images, keep the default Amazon Linux 2023 AMI (it is marked Free tier eligible).
Under Instance type, keep t2.micro (also marked Free tier eligible).
Under Key pair (login), select Proceed without a key pair (Not recommended).

Why skip the key pair?

Key pairs are used for SSH access from a local terminal. You will connect through the browser instead using EC2 Instance Connect, which requires zero setup on your machine.

Amazon Linux 2023 has the Instance Connect agent pre-installed, so browser-based access works out of the box.

Under Network settings, click Edit.
For VPC, select your VPC (the one named my-network-vpc).
For Subnet, select the public subnet (it will have "public" in the name).
For Auto-assign public IP, make sure it says Enable.
Under Firewall (security groups), keep Create security group selected.
Keep Allow SSH traffic from checked with Anywhere selected.

What do these network settings do?

You placed the instance in the public subnet so it inherits the route to the Internet Gateway. The public IP gives the internet a way to find your server.

The Security Group acts like a firewall attached to your instance. Allowing SSH (port 22) from anywhere is what lets EC2 Instance Connect reach the server from your browser.

Click Launch instance.

You will see a success message confirming your instance is launching.

Don't see your VPC in the dropdown?

Make sure your region is still set to US East (N. Virginia) us-east-1 in 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 launch wizard

Wait for the instance to start, then connect

Click View all instances (or navigate to Instances in the left pane).
Wait for Instance state to show Running and Status check to show 2/2 checks passed (takes 1-2 minutes, refresh the page if needed).
Select your Public Server instance by clicking its checkbox.
Click the Connect button at the top.
On the Connect page, click the EC2 Instance Connect tab.
Click Connect.

A terminal window opens in your browser. You are now logged into a virtual server running in the cloud.

What is EC2 Instance Connect?

EC2 Instance Connect gives you a browser-based terminal to your server. No SSH keys, no PuTTY, no local terminal configuration required.

It works because the Amazon Linux 2023 AMI has the Instance Connect agent pre-installed, and your security group allows inbound SSH traffic on port 22.

Connection failed or timed out?

Make sure your instance shows 2/2 checks passed before trying to connect. If you try too early, the agent may not be ready yet.

Also confirm that Auto-assign public IP was set to Enable during launch. Without a public IP, EC2 Instance Connect cannot reach the server.

Help me troubleshoot my EC2 Instance Connect failure

Run a quick test to prove internet access

Your public subnet has a route that sends internet-bound traffic through the Internet Gateway. Time to prove it actually works.

Before you run the next command, think about this: do you expect this server to reach the internet? Why or why not?

In the terminal window, type the following command and press Enter:

ping -c 3 google.com

You should see three responses coming back (lines starting with "64 bytes from..."). This confirms your public server can reach the internet through the Internet Gateway you set up in Step 2.

What does this prove?

The ping command sends a small packet to google.com and waits for a reply. A successful response means your server sent traffic out to the internet and got an answer back.

This works because of the chain you built: instance in public subnet, public subnet has a route to the Internet Gateway, and the security group allows outbound traffic. Remove any one of those links and the ping would fail.

Type exit and press Enter to close the terminal connection.

Not seeing ping responses?

Make sure you typed the command exactly as shown, including the space between -c and 3.

If you see "Name or service not known", your route table may not have the Internet Gateway route. Go back to the VPC console and confirm your public route table has a 0.0.0.0/0 route pointing to your Internet Gateway.

Help me debug why ping is not working from my EC2 instance

Your public server is live and connected to the internet. Next up, you will launch a second server in the private subnet and watch what happens when it has no door to the outside world.

Launch a Server in the Private Subnet

In the last step, you proved your public subnet works. You connected to a server from your browser and even pinged google.com from inside the cloud.

Now for the real test. You will launch an identical server in your private subnet and try to connect to it the same way. If your network is configured correctly, the connection should fail. That failure is exactly what proves your security is working.

In this step, get ready to:

Launch a second EC2 instance in the private subnet.
Attempt to connect via EC2 Instance Connect and observe the result.
Understand why the connection was blocked.

Launch a second EC2 instance in the private subnet

You will create another virtual server with the exact same specs as before. The only difference is the subnet you place it in.

Return to the EC2 Dashboard. In the search bar at the top of the console, type EC2 and click EC2 from the results.
Click Launch instance.
Under Name and tags, enter Private Server.
Under Application and OS Images, keep the default Amazon Linux 2023 AMI (it is marked Free tier eligible).
Under Instance type, keep t2.micro (also marked Free tier eligible).
Under Key pair (login), select Proceed without a key pair (Not recommended).

Now configure the network settings. This is where things differ from the public server.

Under Network settings, click Edit.
For VPC, select your VPC (the one named my-network-vpc).
For Subnet, select the private subnet (it will have private in the name).
For Auto-assign public IP, notice it says Disable. The private subnet does not hand out public IPs.
Keep the security group settings as default.
Click Launch instance.

You should see a success message confirming the instance is launching.

Click View all instances or navigate to Instances in the left navigation pane.
Wait for the Private Server to show Running under Instance state. This takes 1-2 minutes. Refresh the page if needed.

You should now see both Public Server and Private Server listed with a Running state.

Instance stuck in Pending?

Wait a full 2 minutes, then click the refresh icon in the top-right of the instances table. If it still shows Pending after 3 minutes, check that you selected your my-network-vpc VPC and not the default VPC.

Help me troubleshoot why my EC2 instance is not reaching Running state.

Try to connect to the private instance

Your private server is running. Time to connect to it the same way you connected to your public server.

Select the Private Server instance by clicking its checkbox.
Click the Connect button at the top.
On the Connect page, click the EC2 Instance Connect tab.

Before you click Connect, pause for a moment. What do you think will happen? Will you get a terminal window like last time, or something else?

Click Connect.

The connection fails. You will see a timeout or an error message instead of a terminal. This is expected.

Why did this fail?

This is network isolation in action. EC2 Instance Connect needs to reach the server over the internet. The private subnet has no Internet Gateway route and no public IP address. There is literally no path from the internet to this server.

Understand why the connection failed

Think of it this way: the public server has both a street address (public IP) and a door to the street (Internet Gateway route). The private server has neither.

What is network isolation?

Network isolation means a resource is deliberately cut off from the public internet. No one outside the network can reach it directly.

In a real company, databases and internal systems live in private subnets. They are protected from direct internet access by design. Only other servers inside the same VPC can talk to them.

The failure you just saw is proof that your custom network is doing its job. The private subnet is truly private.

You have proven that network isolation works. Your private subnet blocks all internet access exactly as designed. Next up, you will trace the exact mechanisms (route tables and security groups) that make one subnet public and the other private.

Trace the Path and Understand the Rules

You proved that the public subnet works and the private subnet blocks internet access. But what exactly causes this difference?

Two mechanisms control network traffic in AWS: route tables decide where traffic CAN go, and security groups decide what traffic is ALLOWED through. In this step, you will inspect both and pinpoint the exact settings that separate "public" from "private."

In this step, get ready to:

Compare the public and private route tables to see the critical difference.
Inspect the security group rules that guard your public server.
Identify the three requirements for a server to be reachable from the internet.

Compare the two route tables side by side

A route table is a set of rules that tells your network where to send traffic. Each subnet in your VPC has one, and the routes it contains determine whether that subnet can reach the internet.

Return to the VPC console by typing VPC in the search bar at the top and clicking VPC from the results.
In the left navigation pane, click Route tables.
You will see two route tables listed. Click the one associated with your public subnet (it will have "public" in its name).
Click the Routes tab below.

You will see two routes listed:

10.0.0.0/16 with Target local (traffic within the VPC stays internal).
0.0.0.0/0 with Target igw-xxxxx (everything else goes to the Internet Gateway).

What does 0.0.0.0/0 mean?

The route 0.0.0.0/0 is a catch-all that means "any destination not matched by another route." Pointing it at the Internet Gateway means all internet-bound traffic gets sent out through the gateway.

This single route is what makes a subnet "public." Without it, traffic has nowhere to go.

Now go back to Route tables in the left navigation pane.
Click the route table associated with your private subnet (it will have "private" in its name).
Click the Routes tab.

You will see only one route:

10.0.0.0/16 with Target local.

There is no 0.0.0.0/0 route. The private subnet has no path to send or receive traffic from the internet. This is exactly why your connection attempt failed in the previous step.

Examine the security group rules

Route tables control where traffic can physically travel. Security groups add a second layer: even if a route exists, the security group decides whether specific traffic types are allowed through. Think of security groups as a bouncer at the door.

Switch to the EC2 console by typing EC2 in the search bar at the top and clicking EC2 from the results.
In the left navigation pane, click Security Groups.
Click on the security group attached to your "Public Server" (look at the Name or Description column to identify it).
Click the Inbound rules tab.

You will see a rule allowing SSH (port 22) from 0.0.0.0/0 (anywhere on the internet). This is what allowed you to connect via EC2 Instance Connect in Step 3.

Click the Outbound rules tab.

You will see a rule allowing all traffic out. This is why your ping google.com command worked earlier.

How are security groups different from route tables?

Route tables are like roads. They determine whether a path physically exists between two locations.

Security groups are like a bouncer at the door. Even if the road leads to the building, the bouncer checks whether your specific type of traffic (SSH, HTTP, ping) is on the guest list before letting it through.

Tie it all together

For a server to be reachable from the internet, it needs ALL three of these conditions met at the same time:

A public IP address so the internet knows where to send traffic.
A route table entry pointing to an Internet Gateway so the VPC knows how to send and receive internet traffic.
A security group inbound rule allowing the specific traffic type so the firewall permits it.

Your "Public Server" has all three. Your "Private Server" has none of them. That is cloud network security by design.

Why does this matter in the real world?

In a real company, databases and internal systems live in private subnets. They are protected from direct internet access by design. Application servers in public subnets handle user requests, then talk to private resources internally.

This separation is a foundational cloud security pattern. Every cloud role requires you to understand it.

Before you answer the next question, look back at the public route table one more time. Can you point to the single route that makes this subnet "public" and explain what it does?

Quick self-check

Navigate back to Route tables in the VPC console and click your public route table. The route 0.0.0.0/0 pointing to igw-xxxxx is the answer. Without it, the subnet would be just as isolated as the private one.

Secret mission

Prove Private Does Not Mean Unreachable

Your private server blocked all connections from the internet. But can it be reached from INSIDE the network? In production, web servers in public subnets need to talk to databases in private subnets all the time. Prove that internal VPC communication works by pinging the private server from your public server.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. Your AWS Free Plan credits cover these resources, so you will not be charged unless you upgrade to a paid plan.

Resources you used:

2 EC2 instances (Public Server and Private Server).
1 VPC (my-network-vpc).
2 subnets (public and private).
1 Internet Gateway.
2 route tables (public and private).
Security groups.

Will I be charged?

On the AWS Free Plan, you receive $100 in credits and will not incur any charges until you upgrade to a paid plan. Running a couple of t2.micro instances costs pennies per hour from your credit pool. Stopping or terminating them preserves credits for future learning projects.

Keep everything running

No action needed. Choose this if you are still actively building or want to keep practising with your network.

Your two EC2 instances will continue running and consuming a small amount of Free Plan credits (pennies per hour for t2.micro).
The VPC, subnets, route tables, Internet Gateway, and security groups are free and do not consume credits.
You can return to the EC2 console at any time to connect to your Public Server again.

Pause - I'll come back to this later

Stop your EC2 instances to preserve credits while keeping your entire network intact. You can restart the instances later and pick up where you left off.

In the AWS console search bar, type EC2 and click EC2 from the results.
Click Instances in the left navigation pane.
Select the checkbox next to Public Server.
Click Instance state, then click Stop instance.
Repeat for Private Server: select it, click Instance state, then Stop instance.
Stopped instances do not incur compute charges. A negligible storage charge remains but will not meaningfully affect your credits.

Delete - I don't want to use this again

Remove all project resources completely. This frees up your credits and leaves your account clean for future projects.

First, terminate both EC2 instances:

In the AWS console search bar, type EC2 and click EC2 from the results.
Click Instances in the left navigation pane.
Select the checkbox next to Public Server.
Click Instance state, then click Terminate instance.
Repeat for Private Server: select it, click Instance state, then Terminate instance.

Next, delete your VPC (this removes the subnets, route tables, Internet Gateway, and security groups along with it):

In the AWS console search bar, type VPC and click VPC from the results.
Click Your VPCs in the left navigation pane.
Select your VPC named my-network-vpc.
Click Actions, then click Delete VPC.
Confirm the deletion when prompted. This removes the VPC and all associated networking resources (subnets, route tables, Internet Gateway, and security groups).

Nice Work!

Nice work! You just built a real cloud network on AWS and proved how network isolation protects servers in production.

You've learned how to:

Build a custom VPC with public and private subnets using the "VPC and more" wizard, creating a network with separate security zones.
Launch an EC2 instance in a public subnet and connect to it directly from your browser using EC2 Instance Connect.
Prove network isolation works by watching a private subnet connection fail, then trace the exact mechanisms (route tables, security groups, public IPs) that control access.
Secret Mission: Proved that "private" means "no internet access," not "unreachable," by pinging the private server from inside the network using its private IP address.

Ready to quiz yourself?