Build a Secure Multi-Subnet AWS VPC

Design and secure a cloud network with public and private subnets on AWS.

Introduction

30 Second Summary

Every company network has the same challenge: some servers need to talk to the internet, and others need to stay hidden. A hospital's patient records server and its public website might live on the same physical network, but careful segmentation keeps them worlds apart.

In this project, you will build a segmented cloud network on AWS from scratch. You'll carve a custom VPC into public and private subnets, then prove your network segmentation works by testing which subnets can reach the internet and which stay isolated.

What You'll Build

A live cloud network where you SSH into a public server from your browser, confirm it has internet access, then show that your private subnet is completely unreachable from the outside.

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

A custom VPC with public and private subnets you designed using CIDR addressing, mirroring real enterprise networks.
A browser-based SSH connection to your cloud server, proving your routing and security group firewall rules work.
Documented proof that route tables alone determine which subnet reaches the internet and which stays isolated.
Secret Mission: Add Network ACLs as a second firewall layer and compare stateful vs. stateless filtering.

Are there any prerequisites?

No prior networking or AWS experience is needed. This guide walks you through creating an AWS account from scratch, and all resources stay within the free tier.

Before We Start

Before diving into the AWS console, let's lock in what you're about to build and why it matters. This is your moment to commit to the goal so every step that follows has a clear purpose.

Create Your AWS Account and Navigate the VPC Console

To build a cloud network, you need a cloud platform to build it on. AWS (Amazon Web Services) provides the infrastructure services that enterprises use to run their networks, and it offers a generous free tier for learners.

In this step, you will create your free AWS account and orient yourself in the VPC (Virtual Private Cloud) console. You will see the default VPC that AWS creates automatically, then in the next step you will build your own from scratch.

In this step, get ready to:

Create a free AWS account with $100 in sign-up credits.
Navigate to the VPC service in the AWS Management Console.
View the default VPC and note its CIDR block.

Create your free AWS account

AWS requires an email address, a password, contact information, a payment method, and phone verification to create an account. The entire sign-up process takes about 10 minutes.

Will I be charged?

No. New AWS accounts receive $100 in free tier credits valid for 6 months. Everything you build in this project is covered by those credits. AWS places a small temporary hold on your card during sign-up (around $1 USD) and refunds it immediately.

Open your web browser and go to https://aws.amazon.com/free/.
Click Create an AWS Account.
Enter your email address and choose an account name, then click Verify email address.
Check your email for a verification code, enter it, and click Verify.
Create a strong root user password (must include uppercase, lowercase, numbers, and special characters) and click Continue.
Select Personal as the account type, fill in your contact information, and accept the AWS Customer Agreement.
Enter your payment method details and click Verify and Continue.
Verify your phone number via SMS or voice call by entering the PIN you receive.

What about the support plan?

When prompted to choose a support plan, select Basic Support (free). You can always upgrade later if needed.

Select Basic Support and click Complete sign up.
Wait for the activation confirmation email. Activation usually takes a few minutes but can take up to 24 hours.

Account not activating?

If you do not receive a confirmation email within a few minutes, check your spam folder. Make sure the phone number and payment method you entered are correct.

If activation takes longer than 24 hours, contact AWS Support by opening a case at https://aws.amazon.com/support.

Help me troubleshoot my AWS account activation.

Sign in and navigate to the VPC Dashboard

Once your account is activated, you can sign in and find the VPC service where all your networking work will happen.

Go to https://console.aws.amazon.com/ and sign in with the email and password you just created.
Choose Root user and enter your AWS account email address.
On the next page, enter your password and click Sign in.
In the search bar at the top of the console, type VPC and click the VPC service result.

You are now on the VPC Dashboard. This is where all your networking resources live.

What is the VPC Dashboard showing me?

The VPC Dashboard gives you an overview of all your VPC resources in the current region. AWS has already created a default VPC in each region for you, so you will see at least one VPC listed.

View the default VPC

AWS automatically creates a default VPC in every region so you can launch instances immediately. You need to see it to understand what comes pre-built before you create your own custom network.

In the left navigation pane, click Your VPCs.
Look at the list of VPCs. You will see one row where the Default VPC column shows Yes.
Note the value in the IPv4 CIDR column. It will be 172.31.0.0/16.

What is a CIDR block?

A CIDR block defines the range of IP addresses available inside a network. The default VPC uses 172.31.0.0/16, which provides up to 65,536 private IP addresses.

The /16 part is called the prefix length. It tells you how many addresses are in the range. A smaller number means more addresses.

You will NOT use this default VPC. In the next step, you will build your own VPC from scratch so you understand every piece of the network.

Why not use the default VPC?

The default VPC hides all the networking decisions that were made for you. It comes with subnets, route tables, and an internet gateway already configured.

Building from scratch forces you to make every decision a network engineer makes. That hands-on understanding is what employers and the Network+ exam test for.

Your AWS account is live and you know where the VPC console lives. Next up, you will build your own custom VPC from scratch with a public subnet and a private subnet.

Build Your Custom VPC with Public and Private Subnets

In the previous step, you signed into AWS and examined the default VPC on the dashboard. Now you will build your own network from scratch, making every decision that a network engineer makes.

The default VPC is pre-configured and hides the networking decisions from you. Building from scratch forces you to choose your address space, decide how to carve it into subnets, and control which segments can reach the internet.

In this step, get ready to:

Create a custom VPC with a 10.0.0.0/16 address space.
Configure a public subnet and a private subnet using CIDR notation.
Examine route tables to understand why one subnet has internet access and the other does not.

Create your custom VPC

The VPC and more wizard creates a VPC along with its subnets, route tables, and internet gateway in one step. You will examine each piece after creation so you understand every component.

On the VPC Dashboard, click Create VPC.
For Resources to create, select VPC and more.
For Name tag auto-generation, enter NetworkLab.
For IPv4 CIDR block, enter 10.0.0.0/16.

What is CIDR notation?

CIDR stands for Classless Inter-Domain Routing. The /16 means the first 16 bits of the address are fixed (the 10.0 part), and the remaining bits are yours to assign.

A /16 block gives you up to 65,536 IP addresses to split across your subnets. You will carve smaller /24 blocks (256 addresses each) for individual subnets.

For Number of Availability Zones, select 1.
For Number of public subnets, select 1.
For Number of private subnets, select 1.
For NAT gateways, select None.
For VPC endpoints, change the default from S3 Gateway to None.
Confirm both DNS options (Enable DNS hostnames and Enable DNS resolution) are selected.
Click Create VPC.

AWS displays a resource map showing everything it created: your VPC, subnets, route tables, and internet gateway.

Why no NAT gateway?

NAT gateways cost money and would give your private subnet outbound internet access. By setting it to None, your private subnet has no internet route at all.

This is intentional. In a later step, you will prove that the private subnet is truly isolated because it has no route to the internet. Routing determines connectivity.

Don't see the resource map?

If the creation fails, check that you selected VPC and more (not VPC only) in the first field. Also confirm your IPv4 CIDR block is exactly 10.0.0.0/16 with no typos.

help me troubleshoot my VPC creation failure in the AWS console

Find and rename your subnets

The wizard auto-generated names for your subnets using the format NetworkLab-subnet-public1 and NetworkLab-subnet-private1. You will rename them to something clearer.

In the left navigation pane, click Subnets.
Find the subnet named NetworkLab-subnet-public1 in the list.
Click the pencil icon next to its name and rename it to Public-Subnet.
Find the subnet named NetworkLab-subnet-private1.
Click the pencil icon next to its name and rename it to Private-Subnet.

Note the CIDR blocks listed for each subnet: 10.0.1.0/24 for the public subnet and 10.0.2.0/24 for the private subnet. Both are in the same Availability Zone.

What is subnetting?

Subnetting means dividing a larger network into smaller segments. Your /16 VPC has 65,536 addresses, and you carved two /24 subnets (256 addresses each) from it.

The public subnet holds resources that need internet access (like web servers). The private subnet holds resources that should be hidden from the outside world (like databases).

Examine the route tables

The wizard created two route tables: one for each subnet. The routes inside them are the single factor that makes one subnet public and the other private.

Before you look, predict: what route do you think the private subnet's route table is missing compared to the public one?

In the left navigation pane, click Route tables.
You will see two route tables associated with your NetworkLab VPC.
Click the first route table, then click the Routes tab at the bottom of the page.
Look for the route table that has two routes: 10.0.0.0/16 targeting local, and 0.0.0.0/0 targeting an internet gateway (igw- followed by a string of characters). This is the public route table.
Now click the other route table and check its Routes tab. It has only one route: 10.0.0.0/16 targeting local. This is the private route table.

Why does one route make all the difference?

The route 0.0.0.0/0 means "all traffic not destined for the local VPC." Pointing it at the internet gateway (igw-) tells AWS to send that traffic to the internet.

The private route table has no such route. Traffic from the private subnet that tries to reach the internet has nowhere to go. This single route difference is what separates a public subnet from a private subnet.

You now have a fully configured VPC with proper network segmentation. The public subnet can reach the internet through the internet gateway, and the private subnet is isolated.

Your network is built and segmented. Next up, you will place a server inside the public subnet and prove that your routing actually works by connecting to it from your browser.

Launch an EC2 Instance and Test Connectivity

Your network exists, but it is empty. A VPC with subnets and route tables is like a road system with no cars on it.

To prove your network actually works, you need to place a server on it and try to reach the internet. In this step, you will launch an EC2 instance in your public subnet, connect to it from your browser, and confirm that the routing and firewall rules you configured in the previous step deliver real internet access.

In this step, get ready to:

Launch an EC2 instance in your public subnet with a security group firewall.
Connect to the instance via browser-based SSH.
Verify internet connectivity and examine the network configuration from inside the instance.

Launch an EC2 instance in the public subnet

An EC2 instance is a virtual server running in the cloud. You will place one inside your Public-Subnet so it gets an IP address from the 10.0.1.0/24 range and inherits the route table that points to the internet gateway.

In the AWS Management Console, type EC2 in the top search bar and select the EC2 service.
Click Launch instance.
In the Name field, enter Public-Server.
Under Application and OS Images, select Amazon Linux. Confirm the AMI shown is marked Free Tier eligible.
Under Instance type, select t3.micro (marked Free Tier eligible).
Under Key pair (login), select Proceed without a key pair.

Why no key pair?

EC2 Instance Connect lets you open a terminal in your browser without managing SSH key files. AWS pushes a temporary key for each session via IAM, so you never need to download or store a .pem file.

Under Network settings, click Edit.
In the VPC dropdown, select your NetworkLab VPC.
In the Subnet dropdown, select Public-Subnet.
Set Auto-assign public IP to Enable.
Under Firewall (security groups), select Create security group.
In the Security group name field, enter SSH-Only-SG.
Confirm the inbound rule is set to Type = SSH, Source type = My IP. This allows only your computer to connect.
Click Launch instance.

What is a security group?

A security group is a stateful firewall that controls traffic at the instance level. "Stateful" means that if you allow inbound traffic on a port, the return traffic is automatically allowed. You do not need to add a separate outbound rule for responses.

By default, a security group denies all inbound traffic and allows all outbound traffic. You only added one inbound rule (SSH from your IP), so everything else is blocked.

AWS begins launching your instance. Wait for the Instance state column to show Running. This may take 30 to 60 seconds.

Click View all instances (or navigate to Instances in the left pane) to see your instance list.
Wait until Public-Server shows Running in the Instance state column.

Instance stuck on Pending?

It can take up to a minute for the instance to transition from Pending to Running. Click the refresh icon at the top of the instances table to update the status. If it stays Pending for more than two minutes, check that you selected the correct subnet and VPC.

help me troubleshoot my EC2 instance that is stuck in Pending state

Connect to the instance and test internet access

Your server is running, but you have not proven it can reach the internet yet. Time to open a terminal inside the instance and find out.

Select the Public-Server instance by clicking its checkbox.
Click Connect at the top of the page.
Choose the EC2 Instance Connect tab.
Click Connect.

A new browser tab opens with a terminal. You are now inside your cloud server. The prompt shows ec2-user, which is the default username for Amazon Linux instances.

Connection timed out?

If the connection fails, check two things. First, confirm that your security group SSH-Only-SG has an inbound rule allowing SSH from My IP. Second, confirm that Auto-assign public IP was set to Enable when you launched the instance. Without a public IP, EC2 Instance Connect cannot reach the instance.

help me fix my EC2 Instance Connect timeout

Before you run the next command, predict: do you think this instance can reach the internet? What evidence from your VPC setup supports your prediction?

Test internet connectivity by running this command in the EC2 Instance Connect terminal:

ping 8.8.8.8 -c 4

You should see four successful replies from 8.8.8.8 (Google's public DNS server). Each line shows the round-trip time in milliseconds. This proves your instance can send packets to the internet and receive responses.

Why does this work?

The ping succeeds because of the chain you built in Step 2. Your instance sits in Public-Subnet, which uses a route table that sends 0.0.0.0/0 (all non-local traffic) to the internet gateway. The internet gateway translates the instance's private IP to its public IP and forwards the packet to the internet.

See your instance's public IP address by running:

curl ifconfig.me

The output is a single IP address. This is the public IPv4 address that the internet sees when your instance sends traffic outbound. You can verify it matches the Public IPv4 address shown in the EC2 console for this instance.

Verify the full networking stack

You have confirmed outbound internet access. Now look at the networking configuration from inside the instance to see how all the pieces connect.

View the instance's network interfaces and IP addresses by running:

ip addr show

Look for the eth0 interface. You will see an IP address in the 10.0.1.x range. This is the private IP assigned from your Public-Subnet's CIDR block (10.0.1.0/24).

View the routing table inside the instance by running:

ip route show

You will see a default route pointing to a gateway (the first usable IP in your subnet). This is the internal path that sends traffic toward the internet gateway you attached in Step 2.

What does this confirm?

The full networking stack is working end-to-end. Your VPC provides the 10.0.0.0/16 address space. Your subnet carved out 10.0.1.0/24 and assigned a private IP to your instance. The route table directs outbound traffic to the internet gateway. The security group allowed your SSH session in.

Every layer you built in the previous step is now proven to work by real traffic flowing through it.

Your public subnet is fully operational. You have a server that receives traffic, reaches the internet, and sits behind a firewall you control. Next, you will test what happens when you change that firewall and see the immediate impact on connectivity.

Tighten the Firewall and Observe the Impact

Your instance is running and you connected to it over SSH in the last step. But right now, you are trusting that the firewall is doing its job. How do you actually know it is blocking unwanted traffic?

In this step, you will deliberately remove your SSH rule and watch the connection fail. Then you will add it back and watch the connection succeed again. This is how network engineers prove a security group is actively guarding an instance.

In this step, get ready to:

Remove the SSH inbound rule from your security group.
Observe the connection timeout when the firewall blocks all inbound traffic.
Restore the SSH rule and confirm access works again.

Remove the SSH inbound rule

Your security group currently has one inbound rule allowing SSH from your IP address. You are going to delete that rule entirely so the instance has zero inbound rules.

Return to the EC2 console in your browser.
Select your Public-Server instance.
Click the Security tab in the instance details panel below.
Click the security group link (SSH-Only-SG) to open the security group settings.
Under Inbound rules, click Edit inbound rules.
Click Delete next to the SSH rule to remove it.
Click Save rules.

What did this do?

Your instance now has zero inbound rules. Security groups deny all inbound traffic by default. With no rules to explicitly allow traffic, every inbound connection attempt is silently dropped.

The instance is still running and still has internet access outbound. But nobody on the internet can reach it anymore.

Attempt to connect with no inbound rules

Now you will try to reach your instance through EC2 Instance Connect and see what happens when the firewall blocks SSH.

Before you try, predict: do you think the connection will succeed or fail?

Navigate back to your Public-Server instance in the EC2 console.
Click Connect.
Choose the EC2 Instance Connect tab.
Click Connect.

The connection will time out and fail. You may see a message like "Failed to connect to your instance" after a wait of around 30 seconds.

Why did this fail?

Even though your instance is running and has internet access, the security group is blocking all inbound connections. EC2 Instance Connect needs to reach port 22 (SSH) on your instance. With zero inbound rules, that traffic is silently dropped and the connection times out.

This is the core principle of security groups: deny everything by default, then explicitly allow only what you need.

Connection did not fail?

Security group rule changes take effect almost immediately, but in rare cases there can be a short delay. Wait 30 seconds and try connecting again. If it still succeeds, double-check that you saved the rules after deleting the SSH entry.

help me understand why my instance is still reachable after I removed all inbound rules from my security group

Restore the SSH rule and verify access

You have proven the firewall blocks traffic. Now restore access so you can use the instance again.

Return to the SSH-Only-SG security group page.
Click Edit inbound rules.
Click Add rule.
Set Type to SSH.
Set Source to My IP.
Click Save rules.

Before you connect, predict: will it succeed this time?

Navigate back to your Public-Server instance.
Click Connect, choose EC2 Instance Connect, and click Connect.

The connection succeeds. A terminal opens in your browser and you are back inside your instance.

What is a stateful firewall?

You just demonstrated how security groups function as a stateful firewall. "Stateful" means the firewall remembers active connections. When you allow inbound SSH, the security group automatically allows the return traffic for that session without needing a separate outbound rule.

The key principle: explicitly allow what you need, and everything else is denied by default. You do not write "deny" rules. The absence of an "allow" rule is the deny.

Still timing out after adding the rule back?

Make sure the Source is set to My IP, not a custom IP you typed manually. If your IP changed (VPN, network switch), "My IP" fetches your current address automatically.

Also confirm you clicked Save rules after adding the entry. Unsaved changes do not take effect.

help me reconnect to my EC2 instance after restoring my SSH security group rule

You now have hands-on proof that security groups actively control access to your instance. Next up, you will prove that your private subnet is truly isolated from the internet by launching an instance there and watching it fail to connect.

Prove the Private Subnet Is Isolated

You just proved that security groups control who can reach your instance. But there's a bigger claim you haven't tested yet: your private subnet is supposed to be completely cut off from the internet.

In this step, you'll launch a second instance in the private subnet and attempt to connect to it. The failure you observe will prove that routing alone determines which subnets can reach the internet.

In this step, get ready to:

Launch an EC2 instance in the private subnet.
Attempt to connect and observe the connection failure.
Compare both route tables to identify the single difference that determines internet access.

Launch a second EC2 instance in the private subnet

Your private subnet exists, but it has no devices on it. A network without a server to test is just a theory. You need to place an instance in the private subnet so you can attempt to reach it from the internet.

In the AWS Console search bar at the top, type EC2 and select the EC2 service.
Click Launch instance.
In the Name field, enter Private-Server.
Under Application and OS Images, choose Amazon Linux and select an AMI marked Free Tier eligible.
Under Instance type, select t3.micro (marked Free Tier eligible).
Under Key pair (login), select Proceed without a key pair.
Under Network settings, click Edit.
In the VPC dropdown, select your NetworkLab VPC.

Halfway through the launch settings

You've set the same AMI, instance type, and key pair settings as your Public-Server. The next few settings are where this instance diverges: you'll place it in the private subnet instead.

In the Subnet dropdown, select Private-Subnet.
Confirm that Auto-assign public IP shows Disable. This is the default for nondefault subnets. Leave it as-is.
Under Firewall (security groups), choose Select existing security group.
Select SSH-Only-SG from the list.
Click Launch instance.

Why the same security group?

You're reusing SSH-Only-SG on purpose. Both instances have identical firewall rules. This means any difference in connectivity between them can only come from one thing: the route table attached to their subnet.

Wait for the Private-Server instance to show Running status in the Instances list.

Attempt to connect and observe the failure

Your Private-Server is running. It has the same AMI, the same instance type, and the same security group as your Public-Server. The only difference is which subnet it sits in.

Select the Private-Server instance and examine its details in the panel below.
Look at the Public IPv4 address field. It is empty. The instance only has a private IP in the 10.0.2.x range.

Before you try to connect, think about this: the instance is running, it has SSH allowed in its security group, and EC2 Instance Connect worked perfectly on your Public-Server. Do you think it will work here? Why or why not?

Click Connect at the top of the instance details.
Choose the EC2 Instance Connect tab.
Click Connect.

The connection fails. You may see a message like "Failed to connect to your instance" or a warning that the instance does not have a public IPv4 address. Either way, you cannot reach it.

Why does the connection fail?

The instance is unreachable from the internet because the private subnet's route table has no route to an internet gateway. Traffic from the internet has no path into the subnet, and traffic from the instance has no path out.

This is exactly what you want. The private subnet is working as designed. Even though the instance is running and the security group allows SSH, the missing route makes the instance invisible to the outside world.

Compare the route tables side-by-side

You've now seen that two instances with identical security groups have completely different connectivity. One reaches the internet and one does not. The only variable left is the route table. Let's look at the proof.

In the AWS Console search bar, type VPC and select the VPC service.
In the left navigation pane, click Route tables.
Click on the public route table (associated with your Public-Subnet).
Select the Routes tab and note what you see:

10.0.0.0/16 with target local (traffic within the VPC stays internal).
0.0.0.0/0 with target igw-xxx (all other traffic goes to the internet gateway).

Now click on the private route table (associated with your Private-Subnet).
Select the Routes tab and note what you see:

10.0.0.0/16 with target local (traffic within the VPC stays internal).
No 0.0.0.0/0 route. There is no path to the internet.

That single missing route is the entire difference between a public subnet and a private subnet.

What makes a subnet public or private?

A subnet is "public" only because its route table has a 0.0.0.0/0 route pointing to an internet gateway. Remove that route, and the subnet becomes private. The subnet itself has no inherent "public" or "private" property.

This is the fundamental concept that Network+ exams and employers expect you to explain. Routing determines connectivity.

Seeing the same routes in both tables?

Make sure you are clicking the correct route table for each subnet. Check the Subnet associations tab on each route table to confirm which subnet it is attached to.

If both route tables genuinely show the 0.0.0.0/0 route, your VPC may not have been created correctly. Help me figure out why both my route tables have an internet gateway route.

Secret mission

Add Network ACLs for Defense-in-Depth

Your security group controls traffic at the instance level. But real enterprise networks use multiple layers of defense. Can you add a subnet-level stateless firewall and prove it blocks traffic even when the security group allows it?

Clean Up Your Resources

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

Cost warning

Your two EC2 instances use your $100 free tier sign-up credits while running. These credits are valid for 6 months from account creation.

If you are not actively using the instances, stop or terminate them to conserve credits. VPC networking resources themselves have no charge.

Resources you used:

Public-Server EC2 instance (t3.micro, running in Public-Subnet).
Private-Server EC2 instance (t3.micro, running in Private-Subnet).
NetworkLab-VPC and all associated networking resources (subnets, route tables, internet gateway, security group, Network ACL).

Keep everything running

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

Your two EC2 instances will continue consuming free tier credits while in the "Running" state.
VPC, subnets, route tables, internet gateway, security groups, and NACLs have no ongoing charge.
Stop the instances when you are not using them to conserve credits (see the Pause tab for instructions).

Pause - I'll come back to this later

Stop your EC2 instances to pause compute billing. A small EBS storage charge continues but is covered by the free tier.

Navigate to the EC2 console.
Select the Public-Server instance.
Click Instance state, then Stop instance.
Repeat for the Private-Server instance.
Both instances will show "Stopped" status. You can restart them later by selecting Instance state > Start instance.

Delete - I don't want to use this again

Remove all project resources and start fresh. This is irreversible.

Navigate to the EC2 console.
Select the Public-Server instance.
Click Instance state, then Terminate instance.
Repeat for the Private-Server instance.
Wait for both instances to show "Terminated" status.
Navigate to the VPC console.
Click Your VPCs in the left navigation pane.
Select the NetworkLab-VPC.
Click Actions, then Delete VPC.
This deletes the VPC and all associated resources: subnets, route tables, internet gateway, security group (SSH-Only-SG), and Network ACL (Public-Subnet-NACL). Your cost drops to $0.

Nice Work!

You just designed, built, and secured a cloud network from scratch on AWS. That is the same work a network engineer does on day one of a new infrastructure project.

You've learned how to:

Build a custom VPC with public and private subnets using CIDR notation, and configure route tables that determine which subnets can reach the internet.
Launch EC2 instances, connect via browser-based SSH, and configure security group firewall rules that allow only the traffic you explicitly permit.
Prove network segmentation works by demonstrating that the private subnet is completely unreachable from the internet, with route tables as the single deciding factor.
Secret Mission: Added Network ACLs as a subnet-level stateless firewall and demonstrated defense-in-depth by showing that a NACL can block traffic even when the security group allows it.

Ready to quiz yourself?