Build Your First Cloud Network on AWS

Design and build a complete AWS VPC with subnets, routing, and security controls.

Introduction

30 Second Summary

Every time you open an app or load a website, your data travels through a network that decides what gets through and what gets blocked. Cloud engineers design these networks to keep services running and data protected.

In this project, you will build a complete cloud network on AWS from scratch. You'll design subnets, set up routing and security controls, then launch a test server to prove everything works.

What You'll Build

A custom Virtual Private Cloud on AWS with public and private subnets, an Internet Gateway, route tables, and security groups protecting a running EC2 instance.

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

A working Virtual Private Cloud with public and private subnets that you designed and built from scratch.
Configured routing and security controls that determine exactly which traffic can flow where in your network.
A running EC2 instance that proves your network works by successfully connecting to the internet from your public subnet.
Secret Mission: Add a Network ACL as a second firewall layer to block traffic from a specific IP range.

Are there any prerequisites?

No prior cloud experience is needed. All you need is a web browser, a credit or debit card, and a phone number for AWS account verification.

Create Your AWS Account

Every cloud network lives inside an AWS account. Before you can build anything in the cloud, you need access to the AWS Management Console, which is the web-based dashboard where you create and manage all your cloud resources.

In this step, you'll create a free AWS account, orient yourself in the console, and set up a safety net that alerts you if anything unexpectedly costs money.

In this step, get ready to:

Create an AWS Free account with email and phone verification.
Sign in to the AWS Management Console and open the VPC dashboard.
Set up a $1 billing alert to protect against accidental charges.

Create your AWS Free account

The AWS Free plan gives you $100 in credits on sign-up and no charges for 6 months. You will not be billed during this project.

In your web browser, navigate to the AWS Free account sign-up page.
Choose Create a free account.
Enter your email address in the Root user email address field.
Enter an AWS account name (e.g., yourname-learning) in the AWS account name field.
Choose Verify email address.

What happens next?

AWS sends a verification code to the email address you entered. Check your inbox (and spam folder) for a message from AWS containing a numeric code.

Enter the verification code from your email and choose Verify.
Create a strong root user password (minimum 8 characters, mix of uppercase, lowercase, numbers, and symbols).
Confirm your password and choose Continue.
Choose Personal for the account type.
Enter your contact information and accept the AWS Customer Agreement.
Add your credit or debit card as a payment method.

Will I be charged?

You will not incur any charges during the Free plan period until you upgrade to a paid account plan. AWS may place a temporary $1 authorization hold to verify your card, which is refunded automatically.

For phone verification, select your country code (+971 for UAE) and enter your mobile number.
Enter the CAPTCHA code and submit.
When the automated system contacts you, enter the PIN you receive and submit.
Select the Basic Support plan (free).
Choose Complete sign up.

How long does activation take?

Activation usually takes a few minutes but can sometimes take up to 24 hours. Check your email and spam folder for a confirmation message from AWS. You can sign in to your new account while activation is in progress.

Didn't receive the verification call?

Make sure the phone number you entered can receive calls. If the call never arrives, try again with a different number. If the issue persists, contact AWS Support by choosing Account and billing support and selecting Activation as the category.

Help me troubleshoot my AWS account activation

Sign in and navigate the console

Once your account is active, you need to sign in and set your region. The region determines which physical data centre your resources live in.

Navigate to the AWS Management Console sign-in page.
Choose Root user, enter your email address, and choose Next.
Enter your password and choose Sign in.
In the top-right corner of the console, click the region dropdown.
Select US East (N. Virginia) us-east-1.

Why us-east-1?

Most AWS documentation examples reference this region, and all services are available here. The concepts you learn apply identically to any region, including the AWS Middle East (UAE) region.

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

What is a VPC?

A Virtual Private Cloud (VPC) is your own isolated section of the AWS cloud. Think of it as your private plot of land in a massive data centre. You control who can enter, what routes traffic takes, and how resources communicate with each other.

In the next step, you'll create your VPC from scratch and carve out subnets inside it.

You should now see the VPC dashboard with sections like Your VPCs, Subnets, and Route tables in the navigation pane on the left.

Set up a billing alert

Even though the Free plan covers this entire project, a billing alert acts as an early warning system. If anything ever costs money by accident, you'll know immediately.

In the search bar at the top, type Budgets and select AWS Budgets from the results.
Choose Create budget.
Under Budget setup, choose Use a template (simplified).
Under Templates, select Monthly cost budget.
Set the budget amount to 1 (so you get an alert if anything costs money).
Enter your email address for notifications.
Choose Create budget.

What does this budget do?

AWS will email you if your monthly spending exceeds $1. Since everything in this project is free, you should never receive this alert. It exists purely as a safety net in case you accidentally leave resources running or create something outside the Free plan.

You should see your new budget listed on the Budgets dashboard with a status of OK.

Can't find Budgets?

Make sure you typed Budgets in the search bar at the very top of the console (not the VPC search). If the page shows an error, your account may still be activating. Wait a few minutes and try again.

Help me find AWS Budgets in the console

Your AWS account is live and protected by a billing alert. Next up, you'll create your first Virtual Private Cloud and carve out subnets inside it.

Create Your VPC and Subnets

Your AWS account is ready and the VPC console is waiting. Now it's time to build your own cloud network from scratch.

Every cloud application needs a network to live in. You'll create a Virtual Private Cloud and divide it into two subnets, one that faces the internet and one that stays completely isolated.

In this step, get ready to:

Create a custom VPC with 65,536 IP addresses.
Carve out a public subnet for internet-facing resources.
Carve out a private subnet for isolated resources.

Create the VPC

A VPC is your own private section of the AWS cloud. Think of it as renting an empty plot of land where you decide what gets built and who gets in.

In the VPC console, choose Create VPC on the VPC dashboard.
For Resources to create, choose VPC only.
For Name tag, enter my-cloud-network.
For IPv4 CIDR block, enter 10.0.0.0/16.
Leave IPv6 CIDR block as No IPv6 CIDR block.
Leave Tenancy as Default.
Choose Create VPC.

After creation, note your VPC ID shown at the top of the page. It starts with vpc-.

Why VPC only instead of VPC and more?

AWS offers a wizard that creates everything in one click. We're choosing VPC only so you can build each component manually.

Building manually teaches you how each piece connects. This is what interviewers test and what you'll need when troubleshooting real networks.

What does 10.0.0.0/16 mean?

This is CIDR notation. The /16 part means the first 16 bits of the address are fixed (10.0), and the remaining bits are yours to assign.

That gives you 65,536 IP addresses to distribute across your subnets. It's more than enough for a learning project and matches what many companies use in production.

Don't see Create VPC?

Make sure you're on the VPC dashboard, not inside another VPC's details page. Choose Your VPCs in the left navigation pane to get back to the list view.

Also confirm your region is set to US East (N. Virginia) us-east-1 in the top-right corner of the console.

Help me find the Create VPC button in the AWS console.

Create a public subnet

Your VPC is empty land. Subnets divide that land into smaller sections, each with its own purpose. The public subnet will hold resources that need internet access.

In the navigation pane on the left, choose Subnets.
Choose Create subnet.
For VPC ID, select your my-cloud-network VPC from the dropdown.
For Subnet name, enter public-subnet.
For Availability Zone, choose the first option in the list (us-east-1a).
For IPv4 subnet CIDR block, enter 10.0.1.0/24.
Choose Create subnet.

What is a subnet?

A subnet is a smaller range of IP addresses carved out of your VPC. The /24 gives you 256 addresses within the larger /16 block.

The public subnet uses the 10.0.1.0/24 range. Internet-facing resources like web servers will live here.

What is an Availability Zone?

An Availability Zone is a physically separate data centre within a region. Placing subnets in the same zone keeps network latency low.

In production, you'd spread subnets across multiple zones for resilience. For this learning project, one zone is enough to demonstrate the concepts.

Create a private subnet

The private subnet will hold resources that should never be directly reachable from the internet. Databases and internal services typically live in private subnets.

Choose Create subnet again.
For VPC ID, select your my-cloud-network VPC.
For Subnet name, enter private-subnet.
For Availability Zone, choose the same zone as your public subnet (us-east-1a).
For IPv4 subnet CIDR block, enter 10.0.2.0/24.
Choose Create subnet.

Why separate public and private subnets?

Separating resources by their internet exposure is a core security principle. A web server needs to be reachable from the internet, but the database behind it does not.

By placing them in different subnets, you can apply different routing and security rules to each. An attacker who reaches your public subnet still cannot directly access anything in the private subnet.

You should now see both subnets listed on the Subnets page in the VPC console.

Only see one subnet?

Make sure the VPC filter at the top of the Subnets page isn't hiding your second subnet. Clear any filters or select my-cloud-network in the VPC dropdown to show both subnets.

If you see subnets you didn't create, those belong to the default VPC that AWS creates automatically. Look for the ones with names public-subnet and private-subnet.

Help me find my subnets in the AWS VPC console.

Your VPC has its land divided. Next up, you'll connect it to the internet so the public subnet can actually reach the outside world.

Connect Your VPC to the Internet

You have a VPC with two subnets, but right now neither of them can reach the internet. Your subnets are like rooms in a building with no doors to the outside world.

In this step, you will create an Internet Gateway and connect it to your VPC. Then you will set up a route table that tells traffic in your public subnet how to reach the internet.

In this step, get ready to:

Create an Internet Gateway and attach it to your VPC.
Create a route table with an internet route.
Associate your public subnet with the new route table.

Create an Internet Gateway

An Internet Gateway is the component that allows communication between your VPC and the public internet. Without one, nothing inside your VPC can send or receive traffic from the outside world.

In the VPC console navigation pane on the left, choose Internet gateways.
Choose Create internet gateway.
For Name tag, enter my-igw.
Choose Create internet gateway.

After creation, you will see a green banner at the top of the page.

Choose Attach to a VPC from the banner.
Select your my-cloud-network VPC.
Choose Attach internet gateway.

What is an Internet Gateway?

An Internet Gateway is a horizontally scaled, redundant, and highly available VPC component. It serves as the bridge between your VPC and the public internet.

Attaching it to your VPC is just the first step. You also need a route table that tells traffic to use the gateway, which you will set up next.

Don't see the Attach to a VPC banner?

If the banner has disappeared, select my-igw from the Internet gateways list, then choose Actions and Attach to VPC.

Help me attach my Internet Gateway to my VPC.

Create a public route table

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

In the navigation pane, choose Route tables.
Choose Create route table.
For Name, enter public-rt.
For VPC, select your my-cloud-network VPC.
Choose Create route table.

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

With the public-rt route table selected, choose Actions, then Edit routes.
Choose Add route.
For Destination, enter 0.0.0.0/0.
For Target, select Internet Gateway, then select my-igw.
Choose Save changes.

What does 0.0.0.0/0 mean?

The destination 0.0.0.0/0 means "all traffic going anywhere on the internet." Any traffic that does not match the local route (10.0.0.0/16) will be sent to the Internet Gateway instead.

Your route table now has two routes: one for internal VPC traffic (handled locally) and one for everything else (sent to the gateway).

Associate the public subnet with the public route table

Creating a route table is not enough on its own. You need to explicitly associate your public subnet with this route table so it uses the internet route.

With the public-rt route table still selected, choose the Subnet associations tab.
Choose Edit subnet associations.
Select the check box next to public-subnet.
Choose Save associations.

Why does this make it a public subnet?

If a subnet is associated with a route table that has a route to an internet gateway, it is known as a public subnet. Your private-subnet still uses the main route table, which has no route to the internet.

This is the key difference between public and private subnets. It is not about the name you gave them. It is about whether their route table points to an Internet Gateway.

Confirm your setup by checking the Routes tab on your public-rt route table. You should see two routes: 10.0.0.0/16 targeting local, and 0.0.0.0/0 targeting your Internet Gateway (shown as igw- followed by a string of characters).

Only seeing the local route?

If you only see the 10.0.0.0/16 local route, make sure you saved your changes after adding the 0.0.0.0/0 route. Select the route table, choose Actions, then Edit routes to try again.

Help me add an internet route to my route table.

Your VPC now has a working path to the internet. Next up, you will add security controls that act as firewalls to protect the resources inside your network.

Secure Your Network with Security Groups

Your VPC can now reach the internet through the Internet Gateway and route table you configured in the previous step. But right now, there is nothing controlling which traffic is allowed in or out of your network.

In this step, you will create a security group that acts as a virtual firewall for your resources. You will also configure your public subnet to automatically give resources a public IP address so they can communicate with the internet.

In this step, get ready to:

Create a security group that allows SSH and HTTP traffic.
Enable public IP assignment for your public subnet.

Create a security group for web servers

A security group controls which traffic is allowed to reach your resources. You will create one that permits SSH connections (so you can log in remotely) and HTTP connections (so anyone can view a web page).

In the left navigation pane of the VPC console, choose Security groups.
Choose Create security group.
For Security group name, enter web-server-sg.
For Description, enter Allow SSH and HTTP access.
For VPC, remove the default VPC and select your my-cloud-network VPC.
Under Inbound rules, choose Add rule.
Set Type to SSH.
Set Source to My IP.
Choose Add rule again to add a second rule.
Set Type to HTTP.
Set Source to Anywhere-IPv4 (0.0.0.0/0).
Leave Outbound rules as the default (all traffic allowed).
Choose Create security group.

Why My IP for SSH?

When you select My IP as the source, AWS automatically detects your current public IP address and restricts SSH access to only that address. This means only YOU can log in remotely.

HTTP is set to Anywhere-IPv4 because a web page should be viewable by anyone on the internet.

Don't see your VPC in the dropdown?

The VPC field sometimes defaults to your account's default VPC. Click the X next to the pre-selected VPC to clear it, then search for my-cloud-network and select it.

Help me find my VPC when creating a security group.

Enable auto-assign public IP for the public subnet

By default, instances launched in a custom VPC subnet do not receive a public IP address. You need to enable this setting so that any server you launch in your public subnet can be reached from the internet.

In the left navigation pane, choose Subnets.
Select public-subnet.
Choose Actions.
Choose Edit subnet settings.
Under Auto-assign IP settings, check the box for Enable auto-assign public IPv4 address.
Choose Save.

Why enable auto-assign?

A public IP address is what makes a resource reachable from the internet. Without one, even a server in your public subnet with a route to the Internet Gateway would have no address for the outside world to contact.

Understand what you just built

How does your security group protect traffic?

Your security group acts as a virtual firewall at the instance level. It is stateful: if you allow inbound SSH on port 22, the response traffic is automatically allowed out without needing a separate outbound rule.

Your private subnet still has no route to the internet and no public IP assignment. Resources placed there are completely isolated from the outside world. That is the power of network architecture.

You should now see web-server-sg listed under Security groups with 2 inbound rules (SSH from your IP, HTTP from anywhere) and the default outbound rule (all traffic allowed).

You can verify the public IP setting by selecting Subnets in the navigation pane, clicking on public-subnet, and confirming that Auto-assign public IPv4 address shows Yes.

Only see 1 inbound rule?

Make sure you clicked Add rule a second time before setting the HTTP rule. You can edit the security group by selecting it, choosing the Inbound rules tab, then choosing Edit inbound rules.

Help me fix my security group inbound rules.

Your network is now protected by a security group that carefully controls who can access your resources. Next up, you will launch a test server inside your public subnet and prove that the entire network works end to end.

Launch a Test Instance and Verify

Your security groups are configured and your public subnet is ready to assign public IPs automatically. Everything is in place to test whether your network actually works.

The best way to prove a network is functional is to put something on it. In this step, you'll launch an EC2 instance (a virtual server) in your public subnet and verify it can reach the internet through the Internet Gateway you built.

In this step, get ready to:

Launch an EC2 instance in your public subnet.
Connect to the instance using EC2 Instance Connect.
Verify internet connectivity with a ping command.

Launch an EC2 instance in your public subnet

An EC2 instance is a virtual server that runs in your VPC. By placing one in your public subnet, you can test that the route table, Internet Gateway, and security group all work together to allow traffic.

In the search bar at the top of the AWS Management Console, type EC2 and select EC2 from the results.
Choose Launch instance from the EC2 dashboard.
Under Name and tags, for Name, enter test-web-server.
Under Application and OS Images (Amazon Machine Image), keep the default Amazon Linux selection (marked Free tier eligible).
Under Instance type, keep t2.micro selected (Free tier eligible).
Under Key pair (login), choose Proceed without a key pair. You will use EC2 Instance Connect from the browser instead.
Under Network settings, choose Edit.
For VPC, select my-cloud-network.
For Subnet, select public-subnet.
For Auto-assign public IP, verify it shows Enable.
For Firewall (security groups), choose Select existing security group and pick web-server-sg.
Leave all other settings as default.
Choose Launch instance.

Why proceed without a key pair?

EC2 Instance Connect pushes a temporary SSH key to your instance's metadata each time you connect from the browser. The key is only valid for 60 seconds. This means you do not need a permanent key pair stored on your computer.

Skipping the key pair keeps the project focused on networking rather than SSH client setup.

Launch failed or instance went to terminated?

Make sure you selected my-cloud-network as the VPC and public-subnet as the subnet. If you accidentally used the default VPC, your security group will not be available.

Also confirm the instance type is t2.micro. Some regions may not have this type available.

Help me troubleshoot why my EC2 instance failed to launch in my custom VPC.

Connect to your instance and verify internet access

Your instance needs 1-2 minutes to boot before you can connect. Once its state shows Running, you can open a browser-based terminal directly from the AWS Console.

Wait until the Instance state column shows Running. You may need to click the refresh icon.
Select the checkbox next to your test-web-server instance.
Choose Connect at the top of the page.
Choose the EC2 Instance Connect tab.
Choose Connect. A browser-based terminal window opens.

Test internet connectivity by running this command in the terminal:

ping -c 4 google.com

You should see 4 packets transmitted and 4 packets received. This proves your public subnet has working internet access through the Internet Gateway.

What does this prove?

A successful ping means traffic flows from your instance, through the route table (which sends 0.0.0.0/0 traffic to the Internet Gateway), out to the internet, and back. Every component you built in the previous steps is working together.

Cannot connect via EC2 Instance Connect?

Confirm your security group web-server-sg has an inbound SSH rule allowing traffic from your IP. If your IP address changed since you created the rule, update it.

Also check that Auto-assign public IP was enabled for your instance. Without a public IP, the browser-based connection cannot reach the instance.

Help me troubleshoot my EC2 Instance Connect connection issue.

Verify your private subnet is isolated

Your running instance proves the public subnet works. Now consider what would happen if you launched the same instance in private-subnet instead.

Back in the EC2 console, look at the Details tab for your instance. Note the Public IPv4 address field. Your instance received a public IP automatically.
Open a new browser tab and type http:// followed by your instance's public IP address.

You will not see a web page because you have not installed a web server. The connection attempt itself proves that HTTP traffic reaches your instance (allowed by your security group).

Why is the private subnet isolated?

If you launched an identical instance in private-subnet, two things would be different. It would get no public IP address (auto-assign is not enabled there). Its route table has no route to the Internet Gateway.

This means the instance would be completely unreachable from outside your VPC. That is the power of network architecture. You control exactly which resources can talk to the internet and which stay hidden.

Secret mission

Add a Network ACL as a Second Firewall Layer

Your security group is protecting your EC2 instance at the instance level. But what if you want to block entire IP ranges from even reaching your subnet? Network ACLs give you a second, subnet-level firewall that evaluates traffic before it ever hits your security group. In this secret mission, you will create a custom Network ACL, configure stateless rules, and block a simulated attacker's IP range.

Clean Up Your Resources

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

This project uses AWS Free plan credits. Your VPC, subnets, route tables, internet gateway, security groups, and Network ACLs are all free. The EC2 instance consumes credits while running.

Cost warning

Your EC2 instance uses Free plan credits while running. If you leave it running indefinitely, it will slowly consume your $100 in credits. Stopping or terminating the instance preserves your credits for future projects.

Resources you used:

1 VPC (my-cloud-network, free).
2 subnets (public-subnet and private-subnet, free).
1 Internet Gateway (my-igw, free).
2 route tables (public-rt and the main route table, free).
1 security group (web-server-sg, free).
1 EC2 instance (test-web-server, t2.micro, covered by Free plan credits).
1 Network ACL (public-nacl, free, if you completed the Secret Mission).

Keep everything running

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

Your VPC and all networking components remain active at no cost.
Your EC2 instance continues to consume Free plan credits while running.
Your $100 in credits covers approximately 8,600 hours of t2.micro runtime.

Pause - I'll come back to this later

Stop your EC2 instance to preserve your credits while keeping your entire network configuration intact.

In the search bar at the top of the AWS Console, type EC2 and select EC2.
In the navigation pane, choose Instances.
Select your test-web-server instance.
Choose Instance state, then Stop instance.
Choose Stop when prompted for confirmation.
Your VPC, subnets, route tables, internet gateway, and security groups all remain configured at no cost.
When you are ready to resume, select the instance and choose Instance state, then Start instance.

Delete - I don't want to use this again

Remove all project resources completely. Follow this order to avoid dependency errors.

Step 1: Terminate the EC2 instance.

In the search bar, type EC2 and select EC2.
In the navigation pane, choose Instances.
Select test-web-server, then choose Instance state, then Terminate (delete) instance.
Choose Terminate (delete) when prompted for confirmation.
Wait for the instance state to show terminated before continuing.

Step 2: Delete the VPC (this removes most resources automatically).

In the search bar, type VPC and select VPC.
In the navigation pane, choose Internet gateways.
Select the check box for my-igw.
Choose Actions, then Detach from VPC.
Choose Detach internet gateway when prompted for confirmation.
With my-igw still selected, choose Actions, then Delete internet gateway.
Enter delete when prompted, then choose Delete internet gateway.

In the navigation pane, choose Your VPCs.
Select my-cloud-network and choose Actions, then Delete VPC.
Enter delete when prompted, then choose Delete.
This automatically removes your subnets, route tables, security groups, and Network ACLs associated with the VPC.

Why delete in this order?

The EC2 instance has a public IP address. You cannot detach an internet gateway from a VPC that has instances with public IPs.

The internet gateway must be detached and deleted before the VPC can be deleted. The VPC console then handles removing subnets, route tables, security groups, and Network ACLs for you.

Nice Work!

You just built a complete cloud network on AWS from scratch. Your VPC is live with public and private subnets, routing, security controls, and a running server that proves it all works.

You've learned how to:

Built a Virtual Private Cloud from scratch with public and private subnets, giving you full control over network isolation and IP address allocation.
Configured an Internet Gateway, route tables, and security groups to control exactly which traffic flows where in your network.
Launched an EC2 instance in your public subnet and verified internet connectivity with a successful ping command.
Secret Mission: Added Network ACLs as a stateless second layer of defense, including blocking a specific IP range to simulate stopping an attacker.

Ready to quiz yourself?