Build a Multi-Tier VPC from Scratch

Design a production-grade VPC with public and private subnets on AWS.

Introduction

30 Second Summary

Every time you visit a website, your request travels through network layers that control where traffic can and cannot go. The engineer who designs those layers controls the security of the entire application.

In this project, you will build a multi-tier VPC on AWS from scratch. You will create public and private subnets, set up internet connectivity, and configure security groups that isolate traffic between tiers.

What You'll Build

You will build a production-style VPC with three network tiers (web, application, and database) spread across two Availability Zones, complete with route tables and chained security groups.

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

A custom VPC with a /16 CIDR block and 6 subnets organized into web, application, and database tiers across 2 Availability Zones.
An Internet Gateway and custom route tables that enforce traffic boundaries between public and private subnets.
Three chained security groups implementing layered access control, verified with a test EC2 instance that proves the network works.
A NAT Gateway that gives your private subnets outbound internet access in the Secret Mission.

Are there any prerequisites?

You need an AWS account with Free Tier access. No additional tools or software are required for this console-based project.

Log Into AWS and Create Your VPC

Every AWS deployment starts with a network. A VPC (Virtual Private Cloud) is your own isolated section of the AWS cloud where you define the IP addresses, subnets, and traffic rules.

Before you create anything, you need to understand how networks are sized. In this step, you'll learn how CIDR notation works, then create the VPC that holds your entire multi-tier architecture.

In this step, get ready to:

Learn how CIDR notation defines the size of your network.
Log into the AWS Console and navigate to the VPC Dashboard.
Create your custom VPC with a /16 CIDR block.

Understand IP addresses and CIDR notation

When you create a VPC, AWS asks you to define a CIDR block. This determines how many IP addresses your network can hold. Getting this right from the start matters because you cannot easily change the primary CIDR block after creation.

What is CIDR notation?

CIDR stands for Classless Inter-Domain Routing. It looks like an IP address followed by a slash and a number, such as 10.0.0.0/16.

The number after the slash controls how many IP addresses are available. The smaller the number, the more addresses you get.

/16 gives you 65,536 addresses. This is the maximum size for an AWS VPC.
/24 gives you 256 addresses. You'll use this size for individual subnets later.
/28 gives you 16 addresses. This is the minimum size AWS allows.

For this project, you'll use 10.0.0.0/16 for your VPC. That gives you 65,536 addresses, which is plenty of room to carve out subnets for your web, app, and database tiers.

Navigate to VPC in the AWS Console

Now that you understand how CIDR blocks size a network, it's time to build one. You'll start by logging into the AWS Console and selecting the right region.

Open your browser and go to aws.amazon.com/console.
Sign in with your AWS account credentials.
In the top-right corner of the console, click the region dropdown.
Select US East (N. Virginia) us-east-1.

Why us-east-1?

us-east-1 (N. Virginia) has the most Availability Zones and the broadest service availability of any AWS region. It also has the strongest Free Tier support. This project requires at least two Availability Zones, so us-east-1 is the safest choice.

Click the search bar at the top of the console.
Type VPC and select VPC from the results.

You should now see the VPC Dashboard. This is your home base for everything network-related in AWS.

Create the VPC

AWS offers two creation modes. The "VPC and more" wizard auto-generates subnets, route tables, and gateways for you. You'll use "VPC only" so you can build each component yourself and understand exactly what each one does.

Click Create VPC in the top-right corner of the VPC Dashboard.
Under Resources to create, select VPC only.
In the Name tag field, enter multi-tier-vpc.
In the IPv4 CIDR block field, enter 10.0.0.0/16.
Leave all other settings at their defaults.
Click Create VPC.

You should see a green success banner confirming your VPC was created. The console now shows your VPC details page.

What are the auto-created resources?

When you create a VPC, AWS automatically creates two resources for you:

A main route table. Route tables control where network traffic goes. The main route table only has a local route, which means traffic can flow within the VPC but has no path to the internet.
A default network ACL. Network ACLs are subnet-level firewalls. The default one allows all inbound and outbound traffic. You won't change it in this project, but it's good to know it exists.

Don't see your VPC?

Make sure you are in the correct region. Check the top-right corner of the console and confirm it shows N. Virginia (us-east-1).
If you see an error about VPC limits, your account may already have 5 VPCs in this region (the default limit). You can delete an unused VPC or choose a different region.
Still stuck? Help me troubleshoot why my VPC wasn't created.

Your VPC is live. Right now it's an empty network with 65,536 available IP addresses and no way to reach the internet. Next up, you'll carve that address space into six subnets across two Availability Zones to create your web, app, and database tiers.

Create Subnets for Three Tiers

Your custom VPC is live with 65,536 IP addresses ready to use. Right now though, it's one big undivided network with no internal structure.

You need to carve that space into smaller segments called subnets, each assigned to a specific tier and Availability Zone. By the end of this step, you'll have 6 subnets organized into web, app, and database tiers.

In this step, get ready to:

Create 2 public subnets for the web tier.
Create 2 private subnets for the app tier.
Create 2 private subnets for the database tier.

Create the public subnets (web tier)

The web tier holds resources that need direct internet access, like load balancers and web servers. You'll create two public subnets for this tier, one in each Availability Zone.

What is a subnet?

A subnet is a smaller segment of IP addresses within your VPC. Your VPC has the range 10.0.0.0/16, which covers 65,536 addresses.

Each subnet you create uses a /24 CIDR block, giving it 256 addresses. This is more than enough for most workloads, and it keeps the numbering clean and easy to read.

Why two subnets per tier?

Each tier gets one subnet in one Availability Zone and a second subnet in a different zone. If one zone experiences an outage, your resources in the other zone stay up.

This is how production architectures achieve high availability on AWS.

The instructions below use us-east-1a and us-east-1b as the Availability Zones. If you chose a different region in Step 1, select any two AZs available in your region.

In the left sidebar of the VPC Dashboard, click Subnets.
Click Create subnet.
In the VPC ID dropdown, select multi-tier-vpc.
Under Subnet settings, enter public-web-1a in the Subnet name field.
Select us-east-1a from the Availability Zone dropdown.
Enter 10.0.1.0/24 in the IPv4 subnet CIDR block field.
Click Add new subnet at the bottom of the page.
Enter public-web-1b in the Subnet name field.
Select us-east-1b from the Availability Zone dropdown.
Enter 10.0.2.0/24 in the IPv4 subnet CIDR block field.
Click Create subnet.

You should see public-web-1a and public-web-1b listed on the Subnets page with a State of Available.

Don't see your subnets?

Make sure you selected multi-tier-vpc in the VPC ID dropdown before filling in the subnet details. If your subnets ended up in the wrong VPC, delete them and try again.
If the Subnets page shows subnets from other VPCs, type multi-tier-vpc in the search bar to filter the list.
Seeing a CIDR overlap error? Double-check that each subnet uses a unique CIDR block. The two web subnets should be 10.0.1.0/24 and 10.0.2.0/24.

Help me troubleshoot my VPC subnets.

Create the private subnets (app tier)

The app tier holds your application servers. These should never be directly accessible from the internet, so they go in private subnets.

Click Create subnet on the Subnets page.
Select multi-tier-vpc from the VPC ID dropdown.
Enter private-app-1a in the Subnet name field.
Select us-east-1a from the Availability Zone dropdown.
Enter 10.0.3.0/24 in the IPv4 subnet CIDR block field.
Click Add new subnet at the bottom of the page.
Enter private-app-1b in the Subnet name field.
Select us-east-1b from the Availability Zone dropdown.
Enter 10.0.4.0/24 in the IPv4 subnet CIDR block field.
Click Create subnet.

The Subnets page now shows 4 subnets total, including private-app-1a and private-app-1b.

Create the private subnets (database tier)

The database tier is the most isolated layer in your network. Database servers here should only accept connections from the app tier, never from the internet or the web tier directly.

Click Create subnet on the Subnets page.
Select multi-tier-vpc from the VPC ID dropdown.
Enter private-db-1a in the Subnet name field.
Select us-east-1a from the Availability Zone dropdown.
Enter 10.0.5.0/24 in the IPv4 subnet CIDR block field.
Click Add new subnet at the bottom of the page.
Enter private-db-1b in the Subnet name field.
Select us-east-1b from the Availability Zone dropdown.
Enter 10.0.6.0/24 in the IPv4 subnet CIDR block field.
Click Create subnet.

All 6 subnets are now listed on the Subnets page. Filter by multi-tier-vpc in the search bar to confirm you see all of them.

Understanding your subnet layout

Notice the CIDR blocks you assigned follow a clean, sequential pattern. The web tier uses 10.0.1.0/24 and 10.0.2.0/24, the app tier uses 10.0.3.0/24 and 10.0.4.0/24, and the database tier uses 10.0.5.0/24 and 10.0.6.0/24.

This organized numbering scheme makes your network easier to read, debug, and expand later. You still have room for subnets 10.0.7.0/24 through 10.0.255.0/24 if you ever need to add more tiers.

Your VPC now has a clear internal structure with six subnets spanning three tiers. Next up, you'll connect the web tier to the internet using an Internet Gateway and route tables.

Set Up Internet Connectivity

Your VPC now has six subnets organized into web, app, and database tiers across two Availability Zones. None of them can reach the internet yet.

To fix this, you need an Internet Gateway that connects your VPC to the public internet. You also need a route table that tells AWS to send internet-bound traffic through the gateway.

In this step, get ready to:

Create and attach an Internet Gateway to your VPC.
Build a public route table with a route to the internet.
Associate your web tier subnets with the public route table.

Create and attach an Internet Gateway

An Internet Gateway is a VPC component that allows communication between instances in your VPC and the public internet. Each VPC can have only one Internet Gateway attached to it.

In the VPC Dashboard sidebar on the left, click Internet gateways.
Click Create internet gateway in the top-right corner.
Enter multi-tier-igw in the Name tag field.
Click Create internet gateway.

You should see a green success banner confirming the Internet Gateway was created. The gateway's state shows as Detached because it is not connected to any VPC yet.

Click Actions in the top-right corner of the detail page.
Select Attach to VPC.
In the Available VPCs field, search for and select multi-tier-vpc.
Click Attach internet gateway.

The gateway's state changes to Attached. Your VPC now has a door to the internet, but no subnet knows how to use it yet.

Why can only one Internet Gateway attach to a VPC?

An Internet Gateway is already highly available and redundant by design. AWS manages its scaling and failover automatically, so you never need more than one.

Traffic control happens at the route table level, not by adding more gateways. You decide which subnets get internet access by pointing their route tables at this single gateway.

Don't see multi-tier-vpc in the dropdown?

Make sure you are in the same AWS region where you created your VPC. Check the region selector in the top-right corner of the console.

If the VPC shows but is grayed out, it may already have an Internet Gateway attached. Each VPC can only have one.

Help me figure out why I can't attach my Internet Gateway.

Create a public route table

A route table contains a set of rules that determine where network traffic goes. Right now, your VPC only has a main route table with a single local route, which means traffic can flow between subnets but nowhere else.

You will create a new route table specifically for your public subnets. This table will include a route that sends internet-bound traffic to the Internet Gateway.

In the VPC sidebar, click Route tables.
Click Create route table.
Enter public-rt in the Name field.
In the VPC dropdown, select multi-tier-vpc.
Click Create route table.

You should see a success banner and the detail page for your new route table. Now you need to add the route that points to the Internet Gateway.

On the public-rt detail page, click the Routes tab.
Click Edit routes.
Click Add route.
Enter 0.0.0.0/0 in the Destination field.
Click the Target dropdown, select Internet Gateway, then select multi-tier-igw.
Click Save changes.

Your route table should now show two routes. The original local route (10.0.0.0/16) handles traffic within the VPC. The new route (0.0.0.0/0) sends everything else to the Internet Gateway.

What does 0.0.0.0/0 mean?

The destination 0.0.0.0/0 means "all IP addresses." It is a catch-all route for any traffic that does not match a more specific rule.

AWS evaluates routes from most specific to least specific. Traffic destined for 10.0.0.0/16 matches the local route first and stays inside the VPC. Traffic headed anywhere else (like google.com) matches 0.0.0.0/0 and goes out through the Internet Gateway.

Associate public subnets with the public route table

The route table exists, but no subnet is using it yet. All six subnets are still associated with the main route table, which has no route to the internet.

You need to explicitly associate your two web tier subnets with public-rt. This is what makes them "public."

On the public-rt detail page, click the Subnet associations tab.
Click Edit subnet associations.
Select the checkbox next to public-web-1a.
Select the checkbox next to public-web-1b.
Click Save associations.

You should see both subnets listed under Explicit subnet associations on the Subnet associations tab.

What actually makes a subnet public or private?

A subnet is "public" because its route table has a route to an Internet Gateway. There is no checkbox or setting on the subnet itself that makes it public.

Your four private subnets (private-app-1a, private-app-1b, private-db-1a, private-db-1b) remain associated with the main route table. The main route table has no route to the Internet Gateway, so those subnets have no path to the internet. This is how route tables enforce the boundary between public and private.

This is one of the most commonly tested networking concepts in cloud engineer interviews.

Don't see your subnets in the association list?

Make sure you are editing the public-rt route table, not the main route table. The main route table has a Yes value in the Main column on the Route tables page.

Also confirm that public-rt is in the multi-tier-vpc VPC. If you created it in the wrong VPC, delete it and create a new one.

Help me troubleshoot my subnet associations.

Your web tier now has a clear path to the internet through the Internet Gateway. Next up, you will configure security groups that control exactly which traffic can flow between your three tiers.

Configure Security Groups for Each Tier

Your route tables are doing the heavy lifting. Public subnets can reach the internet through the Internet Gateway, and private subnets have no internet route at all. The next layer of defense is security groups.

Security groups control which traffic is allowed to reach individual instances inside your VPC. You will create three security groups that chain together so that each tier only accepts traffic from the tier directly above it.

In this step, get ready to:

Create a web tier security group that allows internet traffic.
Create an app tier security group that only allows traffic from the web tier.
Create a database tier security group that only allows traffic from the app tier.

Create the web tier security group

The web tier is the front door of your architecture. Its security group needs to allow HTTP and HTTPS traffic from the public internet so that users can reach your website.

In the VPC Dashboard sidebar, click Security Groups.
Click Create security group.
Enter web-tier-sg in the Security group name field.
Enter Allow HTTP HTTPS and SSH from internet in the Description field.
In the VPC dropdown, select multi-tier-vpc.

Now scroll down to the Inbound rules section. You will add three rules here.

Click Add rule.
Set Type to HTTP. This auto-fills port 80.
Set Source to 0.0.0.0/0.
Click Add rule to create a second rule row.
Set Type to HTTPS. This auto-fills port 443.
Set Source to 0.0.0.0/0.
Click Add rule to create a third rule row.
Set Type to SSH. This auto-fills port 22.
Set Source to 0.0.0.0/0.
Leave the Outbound rules section at its default (all traffic allowed).
Click Create security group.

You should see a green banner confirming that web-tier-sg was created successfully.

What is a security group?

A security group is a virtual firewall that controls inbound and outbound traffic for individual instances. It is stateful, meaning if you allow inbound traffic on a port, the response traffic is automatically allowed without needing a separate outbound rule.

Security groups only have allow rules. There is no way to create a deny rule. If traffic does not match any allow rule, it is silently dropped.

Pro tip: SSH is temporary

The SSH rule is only here so you can connect to a test instance using EC2 Instance Connect in the next step. In a production environment, you would restrict SSH to specific IP addresses or remove it entirely.

Create the app tier security group

The app tier should never be reachable from the public internet. Its security group only allows traffic that originates from the web tier.

Navigate back to the Security Groups list in the VPC sidebar.
Click Create security group.
Enter app-tier-sg in the Security group name field.
Enter Allow traffic from web tier only in the Description field.
In the VPC dropdown, select multi-tier-vpc.

Now for the key difference. Instead of typing an IP address as the source, you will select a security group.

In the Inbound rules section, click Add rule.
Set Type to Custom TCP.
Enter 8080 in the Port range field.
Click the Source field.
Type web-tier-sg into the search box.
Select the web-tier-sg security group from the dropdown that appears.
Leave the Outbound rules at their default.
Click Create security group.

You should see a green banner confirming that app-tier-sg was created successfully.

What is security group chaining?

By setting the source of app-tier-sg to web-tier-sg (the security group itself, not an IP address), you created a dynamic rule. Any instance that gets added to the web tier security group automatically gains access to the app tier.

This is called security group chaining. It means you never have to update IP addresses when instances scale up or down. The chain maintains itself automatically.

Don't see web-tier-sg in the dropdown?

Make sure you selected multi-tier-vpc as the VPC for this new security group. Security groups from different VPCs do not appear in the dropdown. Double check the VPC field at the top of the form.

help me find my web-tier-sg security group when setting the source for app-tier-sg

Create the database tier security group

The database tier is the most protected layer. Only the app tier should be able to talk to it. Even if someone compromises the web tier, they cannot reach the database directly.

Navigate back to the Security Groups list in the VPC sidebar.
Click Create security group.
Enter db-tier-sg in the Security group name field.
Enter Allow traffic from app tier only in the Description field.
In the VPC dropdown, select multi-tier-vpc.
In the Inbound rules section, click Add rule.
Set Type to MySQL/Aurora. This auto-fills port 3306.
Click the Source field.
Type app-tier-sg and select the app-tier-sg security group from the dropdown.
Leave the Outbound rules at their default.
Click Create security group.

You should see a green banner confirming that db-tier-sg was created successfully.

What is blast radius containment?

Your three security groups form a chain: internet traffic enters through web-tier-sg, which can reach app-tier-sg, which can reach db-tier-sg. No tier can be skipped.

If an attacker compromises an instance in the web tier, they can only reach port 8080 on the app tier. They cannot touch the database at all. Each layer limits how far an attack can spread. This is blast radius containment, and it is one of the most common topics in cloud security interviews.

Why reference security groups instead of IP addresses?

When you set the source to a security group, the rule automatically applies to every instance attached to that group. Instances can be added, removed, or replaced without touching the firewall rules.

If you used IP addresses instead, you would have to manually update the rules every time an instance launched or terminated. Security group references make the rules dynamic and maintenance-free.

Navigate back to the Security Groups list in the VPC sidebar.
Filter by multi-tier-vpc in the VPC filter. You should see four security groups: the default group that was auto-created with the VPC, plus web-tier-sg, app-tier-sg, and db-tier-sg.

Your security groups are locked and loaded. The three-tier chain enforces strict traffic boundaries between every layer of your architecture. Next up, you will launch a test EC2 instance to prove that the entire network actually works.

Launch a Test EC2 Instance and Verify Connectivity

Your VPC now has subnets, an Internet Gateway, route tables, and chained security groups. The architecture is complete on paper.

In this step, you'll launch a test EC2 instance in your public subnet and prove that traffic flows correctly through your network. You'll also confirm that your private subnets are properly isolated.

In this step, get ready to:

Launch a test EC2 instance in the public web subnet.
Verify the instance can reach the internet through the Internet Gateway.
Confirm that private subnets have no internet access.

Launch an EC2 instance in the public web subnet

You'll connect to this instance using EC2 Instance Connect, a browser-based tool that lets you SSH into your instance without managing key pairs. It requires port 22 (SSH) to be open in your security group.

Your web-tier-sg currently only allows HTTP and HTTPS traffic. You need to add a temporary SSH rule before you can connect.

Navigate to Security Groups in the VPC sidebar.
Select web-tier-sg from the list.
Click the Inbound rules tab.
Click Edit inbound rules.
Click Add rule.
Set the Type to SSH.
Set the Source to 0.0.0.0/0.
Click Save rules.

Why 0.0.0.0/0 for SSH?

Using 0.0.0.0/0 means any IP address can attempt an SSH connection. In a production environment, you would restrict this to your specific IP address or use a VPC endpoint for private connectivity.

For this learning project, the open rule keeps things simple. You'll remove it after testing.

Now you're ready to launch the instance.

Type EC2 in the AWS search bar at the top of the console.
Click EC2 to open the EC2 Dashboard.
Click Launch instance.
Enter vpc-test-instance in the Name field.
Under Application and OS Images, select Amazon Linux 2023 AMI. It should be marked as Free tier eligible.
Under Instance type, select t2.micro (Free tier eligible).
Under Key pair (login), select Proceed without a key pair (Not recommended).

Why skip the key pair?

EC2 Instance Connect handles SSH authentication for you through the browser. It injects a temporary key each time you connect, so you don't need to create or manage a key pair file.

Next, configure the network settings to place this instance in your public subnet.

Under Network settings, click Edit.
Select multi-tier-vpc from the VPC dropdown.
Select public-web-1a from the Subnet dropdown.
Set Auto-assign public IP to Enable.
Under Firewall (security groups), select Select existing security group.
Choose web-tier-sg from the security groups dropdown.
Leave all other settings as default.
Click Launch instance.

You should see a success message confirming that your instance is launching. Click the instance ID link to go to the Instances page.

Wait for the Instance state column to show Running with a green circle. This may take 1-2 minutes.

Instance stuck in Pending?

Click the refresh icon above the instance list. It can take a minute or two for the state to change from Pending to Running.

If the instance moves to Terminated or Stopped instead, check that you selected multi-tier-vpc as the VPC and public-web-1a as the subnet during launch.

Still having trouble launching your instance?

Connect to your instance and verify internet access

Your instance is running in the public subnet with a public IP address. Time to connect and prove that traffic flows through the Internet Gateway to the open internet.

Select your vpc-test-instance in the Instances list.
Click Connect at the top of the page.
Select the EC2 Instance Connect tab.
Click Connect.

A browser-based terminal opens. You're now inside your EC2 instance.

Verify your instance can reach the internet by running this command:

ping -c 4 google.com

You should see four replies from google.com with response times in milliseconds. This confirms that your public subnet, route table, and Internet Gateway are all working together.

Ping timed out or can't connect?

If the Connect button fails, check that your web-tier-sg has the SSH (port 22) inbound rule you added earlier.

If the ping command shows no replies, check these three things:

Confirm Auto-assign public IP was set to Enable during launch. Check the instance details for a public IPv4 address.
Verify that public-web-1a is associated with public-rt (not the main route table).
Verify that public-rt has a route with destination 0.0.0.0/0 pointing to your Internet Gateway.

Help me debug why my EC2 instance can't reach the internet.

Verify private subnet isolation

Your public subnet can reach the internet. The next question is: can the private subnets reach it too? They should not be able to.

A subnet is "public" because its route table has a route to the Internet Gateway. The private subnets use the main route table, which has no such route.

Navigate back to the VPC Dashboard by typing VPC in the AWS search bar.
Click Route tables in the left sidebar.
Find the route table for multi-tier-vpc that has Yes in the Main column. This is the main route table.
Select it and click the Routes tab.

You should see only one route: 10.0.0.0/16 with a target of local. There is no 0.0.0.0/0 route pointing to the Internet Gateway.

This means any instance launched in the private subnets (app tier or database tier) has no path to the internet. The isolation is enforced by routing.

Why does routing matter more than security groups here?

Security groups control which ports and sources are allowed. Route tables control whether traffic can physically reach a destination at all.

Even if you added a permissive security group to a private subnet instance, it still could not reach the internet because the route table has no path to the Internet Gateway. This is a key concept that interviewers test when they ask about the difference between public and private subnets.

Click the Subnet associations tab on the main route table.
Under Subnets without explicit associations, confirm that all four private subnets (private-app-1a, private-app-1b, private-db-1a, private-db-1b) are listed here.

These subnets were never explicitly associated with public-rt, so they fall back to the main route table. That single missing route is what keeps them private.

Pro tip: clean up your SSH rule

Now that you've verified connectivity, go back to Security Groups, select web-tier-sg, and remove the SSH (port 22) inbound rule you added earlier. Leaving SSH open to 0.0.0.0/0 is a security risk you would never accept in production.

Secret mission

Deploy a NAT Gateway for Private Subnet Internet Access

In production, private subnet instances often need outbound internet access for software updates and API calls. A NAT Gateway makes this possible without exposing those instances to inbound internet traffic. Can you deploy a NAT Gateway, prove it works from inside a private subnet, and tear it all down before it costs more than a few cents?

Before you go

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The VPC infrastructure itself (VPC, subnets, route tables, Internet Gateway, and security groups) is always free. The EC2 test instance uses Free Tier hours at 750 hours per month for the first 12 months of your AWS account.

Cost warning

If you completed the Secret Mission, double-check that your NAT Gateway is deleted and your Elastic IP is released. NAT Gateways cost $0.045/hour and are not covered by the Free Tier. Elastic IPs cost $0.005/hour when not attached to a running instance.

If your AWS Free Tier has expired, the EC2 t2.micro instance and its public IPv4 address will also start incurring charges. Terminate the instance if you are no longer using it.

Resources you used:

1 VPC (multi-tier-vpc).
6 subnets across 2 Availability Zones (2 public web, 2 private app, 2 private database).
1 Internet Gateway (multi-tier-igw).
2 route tables (public-rt and the main route table).
3 security groups (web-tier-sg, app-tier-sg, db-tier-sg).
1 EC2 instance (vpc-test-instance, t2.micro).
Secret Mission only: 1 NAT Gateway, 1 Elastic IP, 1 private test EC2 instance.

Keep everything running

No action needed for the VPC infrastructure. Choose this if you are still actively building or plan to continue with the next project in the series. VPCs, subnets, route tables, Internet Gateways, and security groups are always free.

Consider terminating the vpc-test-instance EC2 instance to free up your Free Tier instance hours for other projects. You can always launch a new test instance later.
Keep the VPC and all networking components in place. They cost nothing.

Pause - I'll come back to this later

Terminate the EC2 instance to stop using Free Tier hours. Keep the VPC infrastructure since it is completely free.

Navigate to the EC2 Dashboard.
Select vpc-test-instance.
Click Instance state, then Terminate instance.
Leave the VPC, subnets, Internet Gateway, route tables, and security groups in place. They are free and ready for you when you come back.

Delete - I don't want to use this again

Remove all project resources completely. Delete them in this order to avoid dependency errors.

Terminate the EC2 instance. Navigate to EC2, select vpc-test-instance, click Instance state, then Terminate instance. Wait for the state to show Terminated.
Delete security groups in this order: db-tier-sg first, then app-tier-sg, then web-tier-sg. This order matters because each security group references the one before it.
Delete all 6 subnets. Navigate to Subnets in the VPC sidebar, select each subnet, and delete it.
Detach and delete the Internet Gateway. Navigate to Internet Gateways, select multi-tier-igw, click Actions, then Detach from VPC. Then delete it.
Delete the public-rt route table. You cannot delete the main route table separately. It will be removed automatically when you delete the VPC.
Delete the VPC. Navigate to Your VPCs, select multi-tier-vpc, and delete it. This automatically cleans up the main route table and the default network ACL.
If you completed the Secret Mission, confirm that the NAT Gateway shows Deleted, the Elastic IP is released, and the private test instance is terminated.

Mission accomplished

That's a Wrap!

Nice work! You just built a production-grade multi-tier VPC from scratch on AWS. This is the networking foundation that every AWS deployment sits on top of, and the most commonly asked VPC question in cloud engineer interviews.

Here's what you learned:

Built a custom VPC with 6 subnets across 2 Availability Zones, organized into public web, private app, and private database tiers.
Configured an Internet Gateway and route tables to control exactly which subnets can reach the internet and which stay isolated.
Implemented security group chaining to enforce blast radius containment, restricting traffic so each tier can only communicate with its direct neighbor.
Deployed a NAT Gateway to give private subnets outbound internet access, then tore it down to avoid costs.

Ready to quiz yourself?