Build a Multi-Tier VPC Network

Design a public and private subnet network with routing and security groups.

Introduction

30 Second Summary

Every time you visit a website, your request passes through layers of network security before reaching the actual server. Some servers face the public internet directly, while others hide behind private walls that only internal systems can access.

In this project, you will build a multi-tier Virtual Private Cloud on AWS that separates public and private resources using subnets, route tables, and security groups. You'll prove network isolation works by launching instances and testing connectivity between them.

What You'll Build

A production-style VPC with public and private subnets, internet routing, security groups, and EC2 instances that prove network isolation works.

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

A custom VPC with public and private subnets, connected through an Internet Gateway and custom route tables that control where traffic flows.
Security groups that control exactly which traffic can reach each instance, following least-privilege access rules.
Two EC2 instances (one public, one private) with connectivity tests proving that network isolation actually works.
Secret Mission: Add a Network ACL that adds a second layer of defense to your private subnet, blocking traffic even if routing is misconfigured.

Are there any prerequisites?

You need an AWS account (free tier eligible). No prior networking experience is required. All VPC resources you create in this project (subnets, route tables, security groups, internet gateways) are free. The two EC2 instances are covered under the free tier as long as your account is within its free tier period.

Before We Start

Every cloud project starts with a secure connection between your machine and the cloud. The AWS CLI is the tool that makes this connection possible.

In this step, you will install the AWS CLI on your Mac and connect it to your AWS account. Once that is done, you can create and manage cloud resources directly from your Terminal.

In this step, get ready to:

Install AWS CLI v2 on macOS.
Configure the CLI with your AWS credentials.
Verify your connection to AWS works.

Install AWS CLI v2 on macOS

The AWS CLI is a command-line tool that lets you interact with AWS services from your Terminal. You need version 2 specifically for this project.

Press Cmd+Space (macOS) to open your search bar.
Type Terminal and press Enter to open it.
Check if you already have the AWS CLI by running this command:

aws --version

Look at the output in your Terminal and pick the tab below that matches what you see.

✔️ I see aws-cli/2.x.x

You already have AWS CLI v2 installed. You are good to skip ahead to the next substep.

ⓧ I see aws-cli/1.x.x

You have an older version of the AWS CLI. Version 1 is missing features this project needs. Install version 2 by running these commands one at a time:

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"

sudo installer -pkg AWSCLIV2.pkg -target /

What do these commands do?

The first command downloads the official AWS CLI v2 installer package from Amazon. The second command runs the macOS installer to put the CLI in the right place on your system.

The sudo part means you are running the command as an administrator. Your Mac will ask you to type your password. When you type it, nothing will appear on screen. That is normal. Press Enter after typing it.

Confirm the installation succeeded by running:

aws --version

You should see output starting with aws-cli/2. followed by a version number.

ⓧ Command not found

The AWS CLI is not installed on your machine yet. Install it by running these commands one at a time:

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"

sudo installer -pkg AWSCLIV2.pkg -target /

What do these commands do?

The first command downloads the official AWS CLI v2 installer package from Amazon. The second command runs the macOS installer to put the CLI in the right place on your system.

Confirm the installation succeeded by running:

aws --version

You should see output starting with aws-cli/2. followed by a version number.

Still seeing command not found after installing?

Try closing your Terminal window and opening a new one. The installer creates a link at /usr/local/bin/aws that your current session may not detect until you start a fresh window.

If that does not work, help me troubleshoot my AWS CLI installation.

Configure the CLI with your credentials

Now that the CLI is installed, you need to connect it to your AWS account. This is done by providing an Access Key ID and Secret Access Key from your IAM user.

Where do I get my access keys?

If you do not have access keys yet, sign in to the AWS Console. Search for IAM in the top search bar. Click Users, then select your username.

Go to the Security credentials tab and click Create access key. Copy both the Access Key ID and Secret Access Key. Store them somewhere safe. You will not be able to see the Secret Access Key again after closing the creation page.

Run the configuration command:

aws configure

The command will ask you for four pieces of information, one at a time. Enter each value and press Enter after each one:

AWS Access Key ID [None]: Paste your Access Key ID.
AWS Secret Access Key [None]: Paste your Secret Access Key.
Default region name [None]: Type us-east-1.
Default output format [None]: Type json.

What does each value do?

The Access Key ID and Secret Access Key prove to AWS that you are who you say you are. They are like a username and password for programmatic access.

The region (us-east-1) tells the CLI which AWS data center to use by default. The output format (json) means responses from AWS will come back in a structured, readable format.

Not sure which access key to use?

Use an IAM user's access key, not your root account credentials. Root credentials have unlimited access and are risky to use for CLI work.

If you are stuck, help me figure out which credentials to use for aws configure.

Verify your configuration works

The final check confirms that your CLI can actually talk to AWS using the credentials you just provided.

Test your connection by running:

aws sts get-caller-identity

What should I see?

You should see a JSON response containing three fields: your Account (a 12-digit number), your UserId, and your Arn (something like arn:aws:iam::123456789012:user/YourName).

This confirms the CLI is authenticated and ready to use.

Seeing an error about invalid credentials?

Run aws configure again and double check that you pasted the Access Key ID and Secret Access Key correctly. Make sure there are no extra spaces before or after the values.

If you still see errors, help me debug my aws sts get-caller-identity error.

Your CLI is connected and ready. Next up, you will use it alongside the AWS Console to build a multi-tier VPC from scratch.

Create Your VPC and Subnets

Your CLI is configured and ready to talk to AWS. Now it is time to build the actual network that your cloud resources will live inside.

Every cloud architecture starts with a VPC. Think of it as your own private section of the AWS cloud where you control the IP addresses, subnets, and who can talk to what. In this step, you will create a VPC and divide it into two subnets with different access levels.

In this step, get ready to:

Create a custom VPC with a /16 address space.
Create a public subnet that auto-assigns public IP addresses.
Create a private subnet with no public IP assignment.

Create your VPC

A VPC is a logically isolated virtual network that you define inside AWS. You choose which IP addresses it uses and how traffic flows between its parts.

Open the VPC Console at https://console.aws.amazon.com/vpc/.
On the VPC dashboard, click Create VPC.
For Resources to create, choose VPC only.
Enter my-vpc in the Name tag field.
For IPv4 CIDR block, choose IPv4 CIDR manual input and enter 10.0.0.0/16.
Leave IPv6 CIDR block set to No IPv6 CIDR block.
For Tenancy, keep Default.
Click Create VPC.

You should see a green success banner confirming your VPC has been created.

What is CIDR notation?

CIDR stands for Classless Inter-Domain Routing. The 10.0.0.0/16 block means your VPC owns all IP addresses from 10.0.0.0 to 10.0.255.255. That is 65,536 addresses you can carve into smaller subnets.

The /16 part is the prefix length. It tells AWS how many bits are fixed (the network portion) and how many are flexible (the host portion). A smaller number like /16 gives you more addresses. A larger number like /24 gives you fewer (256).

Don't see the Create VPC button?

Make sure you are on the VPC dashboard, not the EC2 dashboard. The URL should start with console.aws.amazon.com/vpc. Also confirm you are in the us-east-1 region by checking the region selector in the top-right corner of the console.

Help me find the VPC dashboard in the AWS Console

Create the public subnet

Subnets divide your VPC into smaller network segments. A public subnet is one where instances can receive public IP addresses and reach the internet (once routing is configured in the next step).

In the left navigation pane, click Subnets.
Click Create subnet.
In the VPC ID dropdown, select your VPC (my-vpc).
Enter public-subnet in the Subnet name field.
Choose an Availability Zone from the dropdown (for example, us-east-1a). Remember which one you pick.
For IPv4 subnet CIDR block, enter 10.0.1.0/24.
Click Create subnet.

Now you need to enable auto-assign public IPv4 addresses so that instances launched in this subnet automatically get a public IP.

Select your new public-subnet from the list by clicking its checkbox.
Click Actions, then Edit subnet settings.
Check the box for Enable auto-assign public IPv4 address.
Click Save.

Why enable auto-assign public IPv4?

By default, subnets in a custom VPC do not give instances a public IP address. Enabling this setting means any EC2 instance you launch into this subnet will automatically receive a public IP, making it reachable from the internet (once you add an Internet Gateway and route in the next step).

Don't see your VPC in the dropdown?

Make sure you are still in the us-east-1 region. If you created the VPC in a different region, it will not appear here. Check the region selector in the top-right corner of the console.

Help me find my VPC when creating a subnet

Create the private subnet

The private subnet will hold resources that should not be directly accessible from the internet. You will place it in the same Availability Zone as your public subnet.

Click Create subnet again.
Select your VPC (my-vpc) from the VPC ID dropdown.
Enter private-subnet in the Subnet name field.
Choose the same Availability Zone you used for public-subnet (for example, us-east-1a).
For IPv4 subnet CIDR block, enter 10.0.2.0/24.
Click Create subnet.

Do NOT enable auto-assign public IPv4 for this subnet. Keeping it disabled is what helps make it private.

What makes a subnet public or private?

Right now, neither subnet can actually reach the internet yet. What makes a subnet "public" is a route in its route table pointing to an Internet Gateway. You will set that up in the next step.

Enabling auto-assign public IPv4 is the first half of the puzzle. It gives instances an address the internet could reach. The route table provides the path for traffic to flow.

Your network foundation is in place. Next up, you will connect the public subnet to the internet by creating an Internet Gateway and configuring route tables.

Set Up Internet Access

Your VPC has two subnets, but right now neither can reach the internet. Both subnets are equally isolated because a custom VPC does not come with an Internet Gateway by default.

To make public-subnet actually public, you need two things: an Internet Gateway (the door to the internet) and a route table that tells traffic where to go. The private subnet stays private simply by not having that route.

In this step, get ready to:

Create an Internet Gateway and attach it to your VPC.
Configure a custom route table that sends internet-bound traffic through the gateway.
Verify that your private subnet has no internet route.

Create and attach an Internet Gateway

An Internet Gateway is a horizontally scaled, highly available VPC component that allows communication between your VPC and the public internet. You create it first, then attach it to your VPC.

In the VPC Console navigation pane on the left, click Internet gateways.
Click Create internet gateway.
In the Name tag field, enter my-igw.
Click Create internet gateway.

You should see a green success banner at the top of the page confirming your Internet Gateway was created.

While still on the my-igw details page, click Actions, then Attach to VPC.
In the Available VPCs dropdown, select my-vpc.
Click Attach internet gateway.

The State column for my-igw should now show Attached.

What is an Internet Gateway?

An Internet Gateway performs one-to-one NAT for instances with public IPv4 addresses. When traffic leaves your VPC, the gateway translates the instance's private IP to its public IP. When a response comes back, it translates the public IP back to the private one.

Without an Internet Gateway attached to your VPC, there is no path for traffic to enter or leave the VPC from the public internet.

Don't see my-vpc in the dropdown?

An Internet Gateway can only attach to one VPC at a time, and a VPC can only have one Internet Gateway. If your VPC is missing from the list, check that you did not accidentally create a duplicate Internet Gateway already attached to it.

help me attach my Internet Gateway to my VPC

Create a route table and add an internet route

A route table contains rules that determine where network traffic is directed. Right now, both subnets use the VPC's main route table, which only routes traffic within the VPC. You will create a custom route table that adds a route to the Internet Gateway, then associate it with your public subnet.

In the navigation pane, click Route tables.
Click Create route table.
In the Name field, enter public-rt.
In the VPC dropdown, select my-vpc.
Click Create route table.

You should see a success banner confirming your route table was created. Now you need to add a route that sends internet-bound traffic to your Internet Gateway.

With public-rt selected, click the Routes tab in the details pane below.
Click Edit routes.
Click Add route.
In the Destination field, enter 0.0.0.0/0.
In the Target dropdown, select Internet Gateway, then select my-igw.
Click Save changes.

Now associate this route table with your public subnet so the route applies to it.

Click the Subnet associations tab.
Click Edit subnet associations.
Select the checkbox next to public-subnet.
Click Save associations.

Your public subnet now has a route to the internet through the Internet Gateway.

What makes a subnet public or private?

A public subnet is simply a subnet whose route table has a route pointing to an Internet Gateway. A private subnet is one that does not have this route.

The 0.0.0.0/0 destination is a catch-all that matches any IP address not already covered by a more specific route. By pointing it at the Internet Gateway, you tell AWS to send all non-local traffic out to the internet.

Route table not saving?

Make sure you selected Internet Gateway as the target type before picking my-igw. If the Save changes button is grayed out, double-check that the Destination field contains exactly 0.0.0.0/0.

help me fix my route table configuration

Verify the private subnet has no internet route

Your private subnet should still be associated with the VPC's default (main) route table. This table has no route to the Internet Gateway, which is exactly what keeps the private subnet isolated.

In the Route tables list, find the route table with Yes in the Main column. This is your VPC's default route table.
Select it and click the Routes tab.
Confirm it only has one route: Destination 10.0.0.0/16 with Target local.

This single local route means traffic can only flow within the VPC. There is no path to the internet from the private subnet.

Why does this matter?

In production, databases and internal services live in private subnets specifically because they cannot be reached from the internet. Even if someone accidentally assigns a public IP to a private-subnet instance, the missing route means internet traffic still cannot reach it.

Your network now has a clear split: the public subnet can reach the internet, and the private subnet cannot. Next up, you will configure security groups to control exactly which traffic is allowed in and out of each subnet's instances.

Configure Security Groups

Your VPC now has proper routing. The public subnet can reach the internet, and the private subnet is shielded from it.

But routing alone doesn't control which traffic is allowed to reach your instances. That's the job of Security Groups. They act as virtual firewalls for each instance, deciding what gets in and what stays out.

In this step, get ready to:

Create a security group for your public instance that allows SSH from your IP and ICMP from anywhere.
Create a security group for your private instance that only allows traffic from within the VPC.

Create the public security group

Your public instance needs to accept SSH connections so you can log in, and ICMP traffic so you can test connectivity with ping. This security group opens those two doors while keeping everything else locked.

In the VPC Console, click Security Groups in the left sidebar.
Click Create security group.
Enter public-sg for the Security group name.
Enter Allow SSH and ICMP for public instance for the Description.
In the VPC dropdown, select my-vpc.

Now add the inbound rules that define what traffic can reach instances using this security group.

Scroll down to the Inbound rules section and click Add rule.
Set Type to SSH.
Set Source to My IP. This auto-fills your current IP address so only you can SSH in.
Click Add rule again to add a second rule.
Set Type to All ICMP - IPv4.
Set Source to Anywhere-IPv4 (0.0.0.0/0). This allows ping from any address.
Click Create security group.

You should see a success banner and your new public-sg listed with its two inbound rules.

Why My IP for SSH?

SSH gives full command-line access to your instance. Opening it to the entire internet (0.0.0.0/0) would let anyone attempt to log in.

Restricting SSH to My IP means only your current network can connect. This is the least-privilege approach that real cloud teams use in production.

Don't see my-vpc in the VPC dropdown?

Make sure you're in the same region (us-east-1) where you created the VPC. Check the region selector in the top-right corner of the AWS Console.

help me find my VPC in the security group creation page

Create the private security group

Your private instance should only be reachable from within the VPC. This means SSH and ICMP traffic are allowed from the 10.0.0.0/16 range (your VPC's address space) and nowhere else.

Click Security Groups in the left sidebar to return to the list.
Click Create security group.
Enter private-sg for the Security group name.
Enter Allow SSH and ICMP from VPC only for the Description.
In the VPC dropdown, select my-vpc.

Now add the inbound rules. Both rules restrict the source to your VPC's CIDR block.

In the Inbound rules section, click Add rule.
Set Type to SSH.
Set Source to Custom and enter 10.0.0.0/16. This means only instances inside the VPC can SSH in.
Click Add rule again.
Set Type to All ICMP - IPv4.
Set Source to Custom and enter 10.0.0.0/16.
Click Create security group.

You should see a success banner confirming private-sg was created with its two inbound rules.

What is the difference between these two security groups?

public-sg allows SSH from your personal IP and ping from anywhere on the internet. It's designed for an instance that faces the public internet.

private-sg only allows SSH and ping from the 10.0.0.0/16 CIDR block. The only way to reach an instance with this security group is from another instance inside the VPC.

Seeing an error when creating the security group?

Double-check that you selected my-vpc in the VPC dropdown. If you left the default VPC selected, the security group name might already exist.

Also confirm the CIDR source is typed exactly as 10.0.0.0/16 with no extra spaces.

help me troubleshoot my security group creation error

Your security groups are locked and loaded. Next up, you'll launch EC2 instances into each subnet and prove that your network isolation actually works.

Launch EC2 Instances and Test Network Isolation

Your network infrastructure is fully wired. You have a VPC with public and private subnets, proper routing, and security groups controlling access.

Now it is time to prove it actually works. In this step, you will launch two EC2 instances and run connectivity tests that demonstrate network isolation in action.

In this step, get ready to:

Launch a public instance that can reach the internet.
Launch a private instance that is shielded from the internet.
Test connectivity to prove that network isolation works.

Launch the public instance

The public instance sits in your public-subnet and gets a public IPv4 address. It represents a web server tier that needs internet access.

Open the EC2 Console at https://console.aws.amazon.com/ec2/.
From the EC2 dashboard, click Launch instance.
Under Name and tags, enter public-instance in the Name field.
Under Application and OS Images (Amazon Machine Image), choose Quick Start.
Select Amazon Linux. The Amazon Linux 2023 AMI should be selected by default and marked Free tier eligible.
Under Instance type, choose t2.micro (Free tier eligible).
Under Key pair (login), click Create new key pair.
Enter a name for the key pair (for example, my-vpc-key), keep the type as RSA and format as .pem, then click Create key pair.
A .pem file downloads automatically. Save it somewhere safe on your computer.
Under Network settings, click Edit.
For VPC, select my-vpc.
For Subnet, select public-subnet.
For Firewall (security groups), choose Select existing security group.
Under Common security groups, select public-sg.
In the Summary panel on the right, click Launch instance.
Wait for the success banner, then click the instance ID link to open the Instances page.

What is an AMI?

An AMI (Amazon Machine Image) is a template containing the operating system and software for your instance. Amazon Linux 2023 is a lightweight Linux distribution maintained by AWS that comes free-tier eligible.

Which instance type should I choose?

If your account was created before July 15, 2025, t2.micro is free for 750 hours per month. If t2.micro is not available in your region, select t3.micro instead.

Accounts created on or after July 15, 2025 receive free credits that cover t3.micro for 6 months.

Don't see your VPC in the dropdown?

Make sure you are in the same AWS Region where you created my-vpc. Check the Region selector in the top-right corner of the console.

help me find my VPC when launching an EC2 instance

Launch the private instance

The private instance goes into private-subnet with no public IP. It represents a database tier that should never be directly reachable from the internet.

Return to the EC2 dashboard and click Launch instance again.
Under Name and tags, enter private-instance in the Name field.
Under Application and OS Images, keep the same Amazon Linux 2023 AMI selected.
Under Instance type, choose the same type (t2.micro or t3.micro).
Under Key pair (login), select the same key pair you created earlier (for example, my-vpc-key).
Under Network settings, click Edit.
For VPC, select my-vpc.
For Subnet, select private-subnet.
For Firewall (security groups), choose Select existing security group.
Under Common security groups, select private-sg.
In the Summary panel, click Launch instance.

After the instance launches, navigate to Instances in the left navigation pane.
Select private-instance and note its Private IPv4 address from the Details tab (it will be something like 10.0.2.x).
Wait until both instances show Instance state as Running and Status check as 2/2 checks passed.

Why no public IP on the private instance?

You disabled auto-assign public IPv4 on private-subnet in Step 2. Combined with the fact that the private subnet's route table has no route to the Internet Gateway, this instance is completely shielded from the public internet.

Test network connectivity

The real proof of your network design is in the connectivity tests. You will SSH into the public instance and use it to probe the private instance and the internet.

First, find the public IP of your public-instance. Select it on the Instances page and copy the Public IPv4 address from the Details tab.
Open Terminal on your Mac.
Set the permissions on your key file by running this command:

chmod 400 [[PEMPATH="path/to/your-key.pem"]]

SSH into the public instance by running:

ssh -i [[PEMPATH="path/to/your-key.pem"]] ec2-user@[[EC2_PUBLIC_IP="your public-instance public IPv4 address"]]

What is happening here?

The ssh command connects you to the public instance using the private key (.pem file) you downloaded. The username ec2-user is the default login for Amazon Linux instances.

If prompted to confirm the host fingerprint, type yes and press Enter.
You should see a command prompt that looks like [ec2-user@ip-10-0-1-x ~]$. You are now inside the public instance.

Now test connectivity from inside the public instance.

Ping the private instance using its private IP by running:

ping -c 4 [[PRIVATE_INSTANCE_IP="private instance private IPv4 address (e.g. 10.0.2.x)"]]

You should see 4 successful replies. Both instances are in the same VPC, so traffic flows via the local route.

Now test internet access from the public instance by running:

ping -c 4 8.8.8.8

You should see 4 successful replies. The public instance has a route to the Internet Gateway, so it can reach the outside world.

What about the private instance?

If you could log into the private instance and run ping 8.8.8.8, it would fail. The private subnet's route table has no route to the Internet Gateway, so outbound internet traffic has nowhere to go.

This is network isolation in action. The routing layer decides who can reach the internet, not the instance itself.

Type exit and press Enter to disconnect from the public instance.

SSH connection timed out?

Check that your public-sg security group has an inbound rule allowing SSH (port 22) from your current IP address. If your IP has changed since you created the rule, update it.

Also confirm the instance is in Running state and that status checks have passed.

help me debug why my SSH connection to my EC2 instance is timing out

You have just proven that your multi-tier VPC works exactly as designed. The public subnet reaches the internet. The private subnet is isolated from it. Next up, you will take this security even further in the Secret Mission.

Secret mission

Add a Network ACL for Defense in Depth

Your private subnet blocks internet traffic through routing alone. But what happens if someone accidentally adds an internet route? Add a second layer of explicit protection with Network ACLs.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. All VPC networking resources (VPC, subnets, route tables, internet gateway, security groups, NACLs) are free. Your EC2 instances are covered by the free tier as long as your combined usage stays under 750 hours per month.

Cost warning

If your AWS account is older than 12 months (for accounts created before July 15, 2025) or you have exhausted your free tier credits, your two EC2 instances will incur charges while running. Stop or terminate them to avoid unexpected costs.

Resources you used:

1 VPC (my-vpc) with a 10.0.0.0/16 CIDR block.
2 subnets (public-subnet and private-subnet).
1 Internet Gateway (my-igw).
2 route tables (public-rt and the main route table).
2 security groups (public-sg and private-sg).
1 Network ACL (private-nacl).
2 EC2 instances (public-instance and private-instance).
AWS CLI v2 installed locally.
AWS credentials configured in ~/.aws/.

Keep everything running

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

Both EC2 instances consume free tier hours. As long as your combined EC2 usage stays under 750 hours per month, there are no charges.
All VPC networking resources (VPC, subnets, route tables, internet gateway, security groups, NACLs) are free regardless of how long they exist.
The AWS CLI and ~/.aws/ credentials remain on your machine for future projects.

Pause - I'll come back to this later

Stop your EC2 instances to stop consuming compute hours. Your VPC setup stays intact so you can resume later.

Go to the EC2 Console.
Select both public-instance and private-instance.
Click Instance state, then Stop instance.
Stopped instances do not consume compute hours. EBS storage continues but is covered by the free tier (up to 30 GB).

Delete - I don't want to use this again

Remove all project resources to ensure zero ongoing charges. Delete resources in this order to avoid dependency errors.

Go to the EC2 Console. Select both public-instance and private-instance. Click Instance state, then Terminate instance. Wait until both show a Terminated state.
Go to Security Groups in the VPC Console. Select public-sg, click Actions, then Delete security groups. Repeat for private-sg.
Go to Network ACLs. Select private-nacl. Click Actions, then Delete network ACL.
Go to Subnets. Select public-subnet, click Actions, then Delete subnet. Repeat for private-subnet.
Go to Route Tables. Select public-rt. Go to the Subnet associations tab and remove any associations. Then click Actions, then Delete route table.
Go to Internet Gateways. Select my-igw. Click Actions, then Detach from VPC. Then click Actions, then Delete internet gateway.
Go to Your VPCs. Select my-vpc. Click Actions, then Delete VPC. This also removes the main route table.
Go to the EC2 Console, then Key Pairs. Select the key pair you created for this project. Click Actions, then Delete. Delete the corresponding .pem file from your local machine.
To remove the AWS CLI, run these commands in Terminal:

sudo rm /usr/local/bin/aws
sudo rm /usr/local/bin/aws_completer
sudo rm -rf /usr/local/aws-cli

To remove your stored AWS credentials and configuration, run:

rm -rf ~/.aws

What does removing ~/.aws do?

The ~/.aws/ folder stores your AWS access keys and CLI configuration. Removing it means no AWS SDK or CLI on your machine can use those credentials. Only delete this if you do not plan to use the AWS CLI again.

Nice Work!

You just built the exact network architecture that runs behind every major cloud application. Your multi-tier VPC proves you can design secure, isolated cloud networks from scratch.

You've learned how to:

Build a custom VPC with public and private subnets, using CIDR blocks to allocate address space across network tiers.
Configure an Internet Gateway, custom route tables, and security groups to control exactly which traffic flows where.
Launch EC2 instances across both subnets and prove network isolation works through hands-on connectivity testing.
Add Network ACLs for defense-in-depth security, creating a second explicit layer of protection at the subnet boundary.

This is the mental model every cloud engineer carries. From here, you can layer on load balancers, NAT gateways, VPN connections, and VPC peering. They all plug into exactly what you just built.

Ready to quiz yourself?