Build a Secure Multi-Tier VPC on AWS

Design a segmented VPC with public and private subnets and zero open ports.

Introduction

30 Second Summary

Every time you send a message, stream a video, or check your bank balance online, your data travels through carefully designed network layers that keep it safe from unauthorized access. The architects behind those layers decide exactly who gets in and who gets blocked.

In this project, you will build a production-style network architecture on AWS from scratch. You will design a custom Virtual Private Cloud with segmented subnets, configure layered security controls, and connect to a server without ever opening a single inbound port.

What You'll Build

A multi-tier VPC architecture on AWS with public and private subnets, an Internet Gateway, Security Groups, and a server accessible only through AWS Systems Manager Session Manager.

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

A custom VPC with public and private subnets spanning two Availability Zones, with properly configured route tables and an Internet Gateway.
Layered security controls using Security Groups and Network ACLs that enforce least-privilege access.
An EC2 instance connected through Session Manager with zero open inbound ports and a least-privilege IAM role.
Secret Mission: Add VPC Flow Logs to capture and analyze network traffic patterns for observability.

Are there any prerequisites?

You only need a web browser and an AWS account. Step 1 walks you through creating an AWS account if you do not already have one. No prior AWS experience is required.

Set Up Your AWS Account

Before you can build anything on AWS, you need access to the Management Console.

In this step, you will sign into your AWS account, navigate to the VPC Console, and set your region to us-east-1.

In this step, get ready to:

Sign into the AWS Management Console.
Navigate to the VPC Console.
Set your region to US East (N. Virginia).

Sign into your AWS account

AWS offers a Free plan that gives new customers up to $200 in credits. Everything you build in this project is covered by those credits or is entirely free.

✔️ I already have an AWS account

Go to https://console.aws.amazon.com/ and sign in with your existing credentials.

You should see the AWS Management Console home page after signing in.

ⓧ I need to create a new account

Go to https://aws.amazon.com/free/ in your browser.
Click Create a Free Account.
Enter your email address and choose an account name.
Follow the prompts to verify your email, set a password, and enter your contact details.
Enter a payment method when prompted. You will not be charged unless you upgrade to a Paid plan.
Select the Free plan when asked to choose a support plan.
Once your account is ready, sign in at https://console.aws.amazon.com/.

How much does the Free plan cost?

The Free plan lasts 6 months or until your credits run out. New customers receive $100 at sign-up plus up to $100 more by completing onboarding activities.

You will not incur any charges unless you manually upgrade to a Paid plan. Everything in this project stays well within free limits.

Having trouble creating your account?

Account verification can take a few minutes. If your account is not ready immediately, wait and try signing in again after 5 minutes.

If you see a verification email, check your spam folder.

help me troubleshoot my AWS account creation

Navigate to the VPC Console

The VPC Console is where you will build your entire network architecture. Every subnet, route table, and security group you create lives here.

Click the search bar at the top of the AWS Management Console.
Type VPC and press Enter.
Select VPC from the search results to open the VPC Dashboard.

You should see the VPC Dashboard with a summary of your VPC resources. The default VPC that AWS creates for every account will already be listed.

What is a VPC?

A VPC (Virtual Private Cloud) is your own isolated section of the AWS network. Think of it as a private data center that you design and control entirely.

You decide which IP address ranges to use, how to segment the network into subnets, and what traffic rules to enforce. In this project, you will build a VPC from scratch instead of using the default one.

Set your region to US East (N. Virginia)

AWS resources are created in a specific region. You need to make sure you are working in the correct region before creating anything.

Look at the top-right corner of the console, next to your account name. You will see a region name displayed (it might say something like Ohio or Oregon).
Click the region selector dropdown.
Select US East (N. Virginia) us-east-1.

The region selector should now display N. Virginia in the top-right corner.

Why us-east-1?

US East (N. Virginia) is the most commonly used AWS region. It has the widest range of available services and is the default region in most AWS documentation and tutorials.

Using us-east-1 means any screenshots or console paths you see in this project will match exactly what appears on your screen.

Don't see the VPC Dashboard?

Make sure you selected VPC from the search results (not a similarly named service like VPN or VPC Lattice).

If you changed regions after opening the VPC Console, the page may need a refresh. Click the browser refresh button to reload the dashboard for your selected region.

help me find the VPC Dashboard in the AWS Console

Your AWS environment is ready. Next up, you will create your custom VPC and divide it into public and private subnets across multiple Availability Zones.

Create Your Custom VPC and Subnets

Your AWS account is ready and you're in the VPC Console. Now it's time to build the foundation of your network architecture.

Every resource you launch on AWS lives inside a VPC (Virtual Private Cloud). Think of it as your own private section of the AWS network, completely isolated from everyone else's resources. In this step, you'll create a custom VPC and divide it into four subnets across two Availability Zones.

In this step, get ready to:

Create a custom VPC with a /16 CIDR block.
Create four subnets (two public, two private) across two Availability Zones.
Enable auto-assign public IPv4 on your public subnets.

Create your custom VPC

AWS gives every account a default VPC, but it's not designed for production workloads. You'll create a custom VPC so you have full control over the network design.

In the VPC Console, click Create VPC (the orange button near the top right).
Under Resources to create, select VPC only.
In the Name tag field, enter SecureArch-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.

What is CIDR notation?

CIDR notation defines how many IP addresses a network contains. The /16 in 10.0.0.0/16 means the first 16 bits are fixed, leaving 65,536 available IP addresses for your VPC.

Later, you'll carve this large block into smaller /24 subnets (256 addresses each). This gives you plenty of room to organize resources into separate network tiers.

Why VPC only instead of the wizard?

The "VPC and more" wizard creates everything at once. Building each component manually teaches you how the pieces connect. Solutions Architects need to explain routing, gateway attachment, and subnet association from first principles.

Don't see the Create VPC button?

Make sure you're in the VPC Console, not the EC2 Console. Search VPC in the top search bar and select VPC from the results.

help me find the Create VPC button in the AWS Console

Create four subnets across two Availability Zones

Subnets are smaller network segments within your VPC. You'll create two public subnets (for resources that need internet access) and two private subnets (for resources that should be isolated).

Spreading them across two Availability Zones provides redundancy. If one data center has an outage, the other keeps running.

In the left sidebar of the VPC Console, click Subnets.
Click Create subnet.
In the VPC ID dropdown, select your SecureArch-VPC.

Now you'll add all four subnets on this same page. Each one gets its own name, Availability Zone, and CIDR block.

Fill in the first subnet with these settings:

Set Subnet name to SecureArch-Public-1a.
Set Availability Zone to US East (N. Virginia) / us-east-1a.
Set IPv4 subnet CIDR block to 10.0.1.0/24.

Click Add new subnet to add the second subnet:

Set Subnet name to SecureArch-Public-1b.
Set Availability Zone to US East (N. Virginia) / us-east-1b.
Set IPv4 subnet CIDR block to 10.0.2.0/24.

Click Add new subnet to add the third subnet:

Set Subnet name to SecureArch-Private-1a.
Set Availability Zone to US East (N. Virginia) / us-east-1a.
Set IPv4 subnet CIDR block to 10.0.3.0/24.

Click Add new subnet to add the fourth subnet:

Set Subnet name to SecureArch-Private-1b.
Set Availability Zone to US East (N. Virginia) / us-east-1b.
Set IPv4 subnet CIDR block to 10.0.4.0/24.

Click Create subnet at the bottom of the page.

You should see a success banner confirming all four subnets were created. They will appear in the Subnets list.

Why two public and two private subnets?

Public subnets are for resources that need direct internet access (like web servers). Private subnets are for resources that should be shielded from the internet (like databases).

Having two of each across different Availability Zones means your architecture survives a data center failure. This is a core requirement for production workloads on AWS.

Seeing a CIDR overlap error?

Make sure each subnet has a unique CIDR block. Double-check that you entered 10.0.1.0/24, 10.0.2.0/24, 10.0.3.0/24, and 10.0.4.0/24 (not the same block twice).

Also confirm you selected your SecureArch-VPC in the VPC ID dropdown, not the default VPC.

help me fix a CIDR overlap error when creating subnets in AWS

Enable auto-assign public IPv4 on your public subnets

By default, instances launched into any subnet don't receive a public IP address. You need to enable this setting on your public subnets so that instances there can communicate with the internet.

In the Subnets list, select the checkbox next to SecureArch-Public-1a.
Click the Actions dropdown near the top of the page.
Select Edit subnet settings.
Check the box for Enable auto-assign public IPv4 address.
Click Save.

Now repeat the same process for your second public subnet.

Go back to the Subnets list and select the checkbox next to SecureArch-Public-1b.
Click Actions, then Edit subnet settings.
Check the box for Enable auto-assign public IPv4 address.
Click Save.

Why only the public subnets?

Private subnets are designed to keep resources hidden from the internet. Assigning public IPs to instances there would defeat their purpose. Only public subnets need this setting enabled.

Your network is taking shape. You have a VPC with four subnets, but right now none of them can actually reach the internet. Next up, you'll create an Internet Gateway and configure route tables to give your public subnets connectivity.

Configure Internet Connectivity and Routing

You have a VPC with four subnets, but none of them can reach the internet yet. A subnet becomes "public" only when it has a route to an Internet Gateway.

In this step, you will create an Internet Gateway, build a custom route table that points traffic to it, and associate that route table with your public subnets only. Your private subnets stay isolated because they never get a route to the gateway.

In this step, get ready to:

Create and attach an Internet Gateway to your VPC.
Build a public route table with an internet route and associate it with your public subnets.
Verify that your private subnets remain isolated with no internet route.

Create and attach an Internet Gateway

An Internet Gateway is the bridge between your VPC and the public internet. Without one attached, nothing inside your VPC can send or receive traffic from outside AWS.

In the VPC Console left sidebar, click Internet gateways.
Click Create internet gateway.
In the Name tag field, enter SecureArch-IGW.
Click Create internet gateway.

You should see a green success banner confirming the Internet Gateway was created. Notice the state shows "Detached". The gateway exists but is not connected to any VPC yet.

Click Actions in the top-right area of the page.
Select Attach to VPC.
In the Available VPCs search field, search for and select SecureArch-VPC.
Click Attach internet gateway.

The state should now show "Attached". Your VPC has a doorway to the internet.

What is an Internet Gateway?

An Internet Gateway is a horizontally scaled, redundant, and highly available VPC component. It performs network address translation for instances that have public IPv4 addresses.

Think of it as the front door of a building. The door exists, but you still need hallways (routes) leading to it. That is what route tables do.

Don't see SecureArch-VPC in the dropdown?

Confirm your region is set to US East (N. Virginia) us-east-1 in the top-right corner. VPCs are regional, so you must be in the same region where you created it.

help me attach my Internet Gateway to my VPC

Create a public route table and associate it with your public subnets

A route table contains rules that determine where network traffic is directed. You need a custom route table that sends internet-bound traffic to your Internet Gateway, and you need to associate it with only your public subnets.

In the VPC Console left sidebar, click Route tables.
Click Create route table.
In the Name field, enter SecureArch-Public-RT.
In the VPC dropdown, select SecureArch-VPC.
Click Create route table.

You should see a success banner and your new route table's detail page. Now you need to add the internet route.

On the route table detail page, click the Routes tab.
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 SecureArch-IGW.
Click Save changes.

What does 0.0.0.0/0 mean?

The destination 0.0.0.0/0 is a catch-all route. It matches any IP address that does not have a more specific route in the table.

Your route table already has a local route (10.0.0.0/16) for traffic within the VPC. The 0.0.0.0/0 route handles everything else by sending it to the Internet Gateway.

The route table has the internet route, but it is not connected to any subnets yet. You need to explicitly associate it with your two public subnets.

On the same route table detail page, click the Subnet associations tab.
Under Explicit subnet associations, click Edit subnet associations.
Select the checkboxes for SecureArch-Public-1a and SecureArch-Public-1b.
Click Save associations.

You should see both public subnets listed under Explicit subnet associations. Your public subnets now have a path to the internet.

Why does this make a subnet public?

A subnet is "public" when it has a route to an Internet Gateway. A subnet is "private" when it does not. The subnet itself does not have a "public" toggle. It is entirely determined by which route table is associated with it.

Don't see your subnets in the association list?

Make sure you selected SecureArch-VPC when creating the route table. A route table can only associate with subnets in the same VPC. If you selected the wrong VPC, delete this route table and create a new one.

help me associate my route table with my subnets

Verify that your private subnets have no internet route

Your private subnets should still be using the VPC's Main route table, which only has the local route. This means instances in private subnets cannot reach the internet directly.

In the VPC Console left sidebar, click Route tables.
Find the route table with Yes in the Main column that belongs to SecureArch-VPC.
Click on the Main route table to open its detail page.
Click the Routes tab and confirm there is only one route: 10.0.0.0/16 with target local.
Click the Subnet associations tab. Under Subnets without explicit associations, confirm that SecureArch-Private-1a and SecureArch-Private-1b are listed.

Why are private subnets on the Main route table?

Every VPC comes with a Main route table. Any subnet that is not explicitly associated with a custom route table automatically uses the Main route table.

Since the Main route table only has the local route (10.0.0.0/16), your private subnets can communicate within the VPC but cannot reach the internet. This is the isolation you want.

Your network plumbing is complete. Public subnets have a clear path to the internet, and private subnets are fully isolated. Next up, you will add security controls that determine exactly which traffic is allowed to flow through these paths.

Configure Security Groups with Least Privilege

Your network is built and segmented, but right now nothing stops traffic from flowing freely between resources. Security Groups act as stateful firewalls attached to individual resources, controlling exactly which traffic is allowed in and out.

In this step, you will create two Security Groups that follow the principle of least-privilege access. Your EC2 instance will have zero inbound ports open, and your private subnet resources will only accept traffic from known, trusted sources.

In this step, get ready to:

Create a Security Group for your EC2 instance with zero inbound rules.
Create a Security Group for private subnet resources that only accepts traffic from your EC2 Security Group.

Create the EC2 Security Group

This Security Group will be attached to your EC2 instance in the next step. It blocks all inbound traffic and allows outbound connections so the SSM Agent can reach AWS endpoints.

In the VPC Console left sidebar, click Security groups.
Click Create security group.
Enter SecureArch-EC2-SG in the Security group name field.
Enter Allow only outbound HTTPS for SSM in the Description field.
In the VPC dropdown, select SecureArch-VPC.

Now configure the inbound and outbound rules.

In the Inbound rules section, delete any existing rule by clicking Delete next to it. You want zero inbound rules.
In the Outbound rules section, keep the default rule that allows All traffic to destination 0.0.0.0/0. Session Manager requires HTTPS outbound on port 443.
Click Create security group.

You should see a green success banner confirming your Security Group was created.

Why does zero inbound rules still let you connect?

Session Manager works differently from SSH. Instead of you connecting inbound to the instance, the SSM Agent on the instance initiates an outbound HTTPS connection to AWS endpoints.

Because Security Groups are stateful, the response traffic from AWS is automatically allowed back in. No inbound port needs to be open because the connection is started by the instance, not by you.

Don't see SecureArch-VPC in the dropdown?

Make sure your region is set to US East (N. Virginia) us-east-1 in the top-right corner of the console. Security Groups are regional, so you must be in the same region where you created your VPC.

Help me find my VPC when creating a Security Group

Create the private subnet Security Group

This second Security Group demonstrates how resources in private subnets only accept traffic from known, trusted sources. It will only allow inbound traffic that originates from your EC2 Security Group.

Click Security groups in the left sidebar to return to the list.
Click Create security group.
Enter SecureArch-Private-SG in the Security group name field.
Enter Allow traffic from EC2 SG only in the Description field.
In the VPC dropdown, select SecureArch-VPC.

Now add an inbound rule that references your EC2 Security Group as the trusted source.

In the Inbound rules section, click Add rule.
Set Type to All traffic.
In the Source field, select Custom.
Click the search box that appears next to Custom and type SecureArch-EC2-SG. Select it from the dropdown results.
Keep the default Outbound rules (All traffic to 0.0.0.0/0).
Click Create security group.

You should see a green success banner confirming your second Security Group was created.

Why reference a Security Group instead of an IP address?

By setting the source to SecureArch-EC2-SG instead of a specific IP, you are saying "only accept traffic from any resource that has this Security Group attached." IP addresses can change, but the Security Group reference stays stable.

This pattern is how production architectures control inter-tier communication. Your web tier talks to your app tier, and your app tier talks to your database tier, all referenced by Security Group membership.

Can't find SecureArch-EC2-SG in the source dropdown?

Make sure you selected SecureArch-VPC as the VPC for this new Security Group. Security Groups can only reference other Security Groups within the same VPC.

Also confirm you successfully created SecureArch-EC2-SG in the previous substep. Go back to the Security Groups list and verify it appears there.

Help me troubleshoot my Security Group source reference

Your security layer is locked down. Next up, you will launch an EC2 instance and connect to it using Session Manager to prove that zero inbound ports actually works.

Launch an EC2 Instance with Session Manager Access

Your network is locked down with layered security controls. Now it is time to put a server inside that network and prove you can access it securely.

In this step, you will launch an EC2 instance and connect to it using AWS Systems Manager Session Manager. Session Manager lets you open a terminal session in your browser without opening any inbound ports, managing SSH keys, or setting up a bastion host.

In this step, get ready to:

Create an IAM role that grants your instance permission to use Session Manager.
Launch an EC2 instance in your public subnet with zero inbound ports open.
Connect to your instance through a browser-based terminal session.

Create an IAM role for EC2

For Session Manager to work, your EC2 instance needs permission to communicate with AWS Systems Manager endpoints. You grant this permission by attaching an IAM role to the instance.

In the AWS Console search bar at the top, type IAM and select IAM from the results.
In the left sidebar, click Roles.
Click Create role.

The role creation wizard has three stages: selecting who can use the role, attaching permissions, and naming it.

Under Trusted entity type, select AWS service.
Under Use case, select EC2.
Click Next.
In the search bar on the permissions page, type AmazonSSMManagedInstanceCore.
Check the box next to AmazonSSMManagedInstanceCore in the results.
Click Next.
In the Role name field, enter SecureArch-SSM-Role.
Click Create role.

You should see a green banner confirming the role was created successfully.

What is this IAM role doing?

The AmazonSSMManagedInstanceCore policy grants your EC2 instance permission to communicate with AWS Systems Manager. The SSM Agent on the instance initiates an outbound HTTPS connection to AWS endpoints.

This is why you do not need any inbound ports open. The instance reaches out to AWS, and AWS routes your terminal session back through that same connection.

Can't find the policy?

Make sure you type the full name AmazonSSMManagedInstanceCore in the search box. The policy list is long and the search is case-sensitive.

help me find the AmazonSSMManagedInstanceCore policy in the IAM Console

Launch an EC2 instance in your public subnet

Now you will launch an EC2 instance that uses your custom VPC, your security group, and the IAM role you just created. This instance will live in the public subnet but have zero inbound ports open.

In the AWS Console search bar, type EC2 and select EC2 from the results.
Click Launch instance.

The launch wizard has several sections. Work through each one from top to bottom.

Under Name and tags, enter SecureArch-Instance.
Under Application and OS Images, confirm that Amazon Linux 2023 AMI is already selected (it is the default). Look for the "Free tier eligible" badge.
Under Instance type, select t3.micro (Free tier eligible).
Under Key pair (login), click the dropdown and select Proceed without a key pair (Not recommended).

Why no key pair?

Key pairs are used for SSH access. Since you are connecting through Session Manager instead of SSH, you do not need one. This eliminates the need to manage private keys entirely.

Now configure the network settings to place this instance in your custom VPC.

Under Network settings, click Edit.
In the VPC dropdown, select SecureArch-VPC.
In the Subnet dropdown, select SecureArch-Public-1a.
Confirm that Auto-assign public IP is set to Enable. This should already be enabled because you configured it on the subnet earlier.
Under Firewall (security groups), select Select existing security group.
In the security group dropdown, select SecureArch-EC2-SG.

Finally, attach the IAM role so the instance can communicate with Systems Manager.

Expand the Advanced details section at the bottom of the page.
In the IAM instance profile dropdown, select SecureArch-SSM-Role.
Leave all other settings at their defaults.
Click Launch instance.

You should see a success page confirming that your instance is launching.

Don't see your VPC or security group in the dropdowns?

Make sure your region is still set to US East (N. Virginia) us-east-1 in the top-right corner. Resources only appear in the region where they were created.

help me troubleshoot why my VPC resources are not appearing in the EC2 launch wizard

Connect to your instance using Session Manager

Your instance needs 2-3 minutes to fully initialize before Session Manager becomes available. The SSM Agent on the instance must start up and register with AWS Systems Manager.

Click View all instances (or navigate to Instances in the EC2 left sidebar).
Wait until your instance shows 2/2 checks passed in the Status check column. Click the refresh icon if it still shows "Initializing".
Select the checkbox next to your SecureArch-Instance.
Click Connect at the top of the page.
Select the Session Manager tab.
Click Connect.

A new browser tab opens with a black terminal session. You are now logged into your EC2 instance without ever opening an inbound port or using an SSH key.

Why Session Manager instead of SSH?

Traditional SSH requires opening port 22 inbound, distributing private keys, and often setting up a bastion host. Session Manager eliminates all three.

The SSM Agent on the instance initiates an outbound HTTPS connection to AWS. Your terminal session rides that same connection back. Access is controlled entirely through IAM policies, not network rules.

Session Manager connect button is grayed out?

This usually means the SSM Agent has not registered yet. Wait a full 2-3 minutes after the status checks pass, then refresh the page and try again.

If it stays grayed out after 5 minutes, confirm that your instance has the SecureArch-SSM-Role attached. Select your instance, click Actions > Security > Modify IAM role and check that the role is listed.

Also confirm your security group allows outbound HTTPS traffic (port 443). The default "All traffic" outbound rule covers this.

help me troubleshoot why Session Manager won't connect to my EC2 instance

You now have a running server that you can access securely through your browser. Next up, you will put your entire architecture to the test by verifying that your security controls actually block unauthorized traffic.

Verify Your Security Controls

Your architecture is built and your EC2 instance is running with a Session Manager connection. Building security controls is only half the job though.

In this step, you will prove that your controls actually work. You will test that outbound internet access functions correctly, confirm that inbound traffic is blocked, verify that your private subnets are truly isolated, and review a visual map of everything you have built.

In this step, get ready to:

Confirm outbound internet access works from your instance.
Verify that inbound traffic is blocked by your Security Group.
Confirm private subnets are isolated and review your full architecture diagram.

Test outbound internet access and inbound blocking

Your Security Group has zero inbound rules and allows all outbound traffic. Time to prove that configuration does what you expect.

Switch to your Session Manager browser tab where you connected to your EC2 instance in the previous step.
Test outbound internet access by running this command:

curl https://checkip.amazonaws.com

You should see a public IP address printed in the terminal. This confirms your instance can reach the internet through the Internet Gateway.

What does this command do?

The curl command makes an HTTPS request to a service that returns your public IP address. If the Security Group blocked outbound traffic, this request would fail. The fact that it succeeds proves the outbound rule is working.

Now you will test that inbound traffic is blocked. You need the public IP address of your instance to do this.

Copy the IP address that the curl command returned. This is your instance's public IP.
Open a terminal on your local machine. Press Cmd+Space (macOS) or the Windows key (Windows) to open your search bar.
Type Terminal (macOS) or Command Prompt (Windows) and press Enter to open it.
Try to ping your instance's public IP by running this command:

ping -c 4 [[EC2_PUBLIC_IP="the public IP address from the curl output"]]

Using Windows?

On Windows, run ping followed by the IP address (no -c 4 needed). Windows sends 4 pings by default.

You should see the ping time out or show 100% packet loss. This confirms that your Security Group is blocking inbound ICMP traffic because you have no inbound rules allowing it.

Why does outbound work but inbound doesn't?

Security Groups are stateful. When your instance makes an outbound request (like the curl command), the return traffic is automatically allowed back in. That is what "stateful" means.

A ping from your local machine is a completely new inbound connection that the instance did not initiate. Since there is no inbound rule allowing ICMP, the Security Group drops it silently.

Ping is not timing out?

If ping returns replies, double check that your Security Group SecureArch-EC2-SG has zero inbound rules. Go to the EC2 Console, select your instance, click the Security tab, and check the inbound rules for your security group.

Help me figure out why ping is getting through to my EC2 instance.

Verify private subnet isolation

Your private subnets should have no route to the Internet Gateway. This means any instance launched in those subnets cannot reach or be reached from the internet.

Go back to the AWS Console browser tab.
Search for VPC in the top search bar and select VPC.
Click Route tables in the left sidebar.
Find the Main route table associated with your SecureArch-VPC. It will have "Yes" in the Main column.
Click on the Main route table to open its details.
Click the Routes tab at the bottom of the page.

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

Click the Subnet associations tab to confirm that SecureArch-Private-1a and SecureArch-Private-1b are listed under Subnets without explicit associations.

Why are they under 'without explicit associations'?

Any subnet that is not explicitly associated with a custom route table automatically uses the VPC's Main route table. Your private subnets were never associated with SecureArch-Public-RT, so they fall back to the Main route table. Since the Main route table has no internet route, these subnets are fully isolated.

Seeing an internet route in the Main route table?

If the Main route table has a 0.0.0.0/0 route pointing to your Internet Gateway, it was accidentally added to the wrong route table. Select that route, click Edit routes, and remove the 0.0.0.0/0 entry. The internet route should only exist on SecureArch-Public-RT.

Help me fix my route table configuration for private subnet isolation.

Review your architecture on the VPC Resource Map

The VPC Console includes a visual Resource Map that shows how all your networking components connect together. This is a great way to see your full architecture at a glance.

In the VPC Console left sidebar, click Your VPCs.
Click on SecureArch-VPC to open its details page.
Click the Resource map tab.

You should see a visual diagram showing your VPC, subnets, route tables, and the Internet Gateway all connected together. Your two public subnets connect to SecureArch-Public-RT (which routes to the Internet Gateway), while your two private subnets connect to the Main route table (with no internet route).

What does the Resource Map show?

The Resource Map visualizes the relationships between your VPC components. You can see the two-tier architecture you built: public subnets connected to the internet through the gateway, and private subnets completely isolated.

This is the kind of architecture diagram you would draw in a Solutions Architect interview to explain network segmentation and security boundaries.

Secret mission

Add VPC Flow Logs

Your architecture is secure, but can you see what's happening on the network? In this stretch challenge, you'll enable VPC Flow Logs to capture and analyze traffic metadata flowing through your VPC. This is how security teams detect suspicious patterns and troubleshoot connectivity issues in production.

Clean Up Your Resources

Decide whether to keep your resources running, pause them to come back later, or delete them entirely. The VPC, subnets, route tables, security groups, and internet gateway are all free. The EC2 instance consumes Free Tier credits while running.

Cost warning

If you are on the AWS Free plan, the t3.micro instance is covered by your credits. However, if your credits run out or your Free Tier period expires, a running instance will incur charges. Stop or terminate the instance if you are not actively using it.

Resources you used:

1 VPC with subnets, route tables, and an Internet Gateway (free).
1 EC2 instance (t3.micro, covered by Free Tier credits while running).
1 IAM Role (free).
Security Groups and Network ACLs (free).

Keep everything running

No action needed. Choose this if you are still actively building or plan to continue experimenting with your VPC architecture.

Your EC2 instance will continue consuming Free Tier credits while running.
All networking resources (VPC, subnets, route tables, security groups, Internet Gateway) remain free regardless of state.

Pause - I'll come back to this later

Stop the EC2 instance to preserve your architecture without consuming compute credits. Your VPC and all networking resources remain free.

Go to the EC2 Console and select your instance.
Click Instance state, then select Stop instance.
Your VPC, subnets, route tables, security groups, and Internet Gateway will remain in place at no cost.
When you are ready to resume, select the instance and choose Instance state > Start instance.

Delete - I don't want to use this again

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

Go to the EC2 Console, select your instance, click Instance state, then select Terminate instance.
Go to the VPC Console, select your SecureArch-VPC, click Actions, then select Delete VPC. This removes all subnets, route tables, the Internet Gateway, and security groups attached to the VPC.
Go to the IAM Console, select Roles, find SecureArch-SSM-Role, and delete it.
If you completed the Secret Mission, go to CloudWatch Console, select Log groups, and delete the SecureArch-FlowLogs log group. Also delete the Flow Logs IAM role in the IAM Console.

Nice Work!

You just built a production-grade network architecture from scratch on AWS. This is the same multi-tier VPC design that Solutions Architects use to secure real workloads in production.

Here's what you accomplished:

Designed a custom VPC with CIDR planning across multiple Availability Zones, segmenting traffic into public and private tiers using route table associations.
Applied layered security with Security Groups (stateful firewalls) and connected to an EC2 instance with zero inbound ports open using Session Manager.
Configured a least-privilege IAM role and verified that your security controls actually enforce the boundaries you designed.
Secret Mission: Added VPC Flow Logs for network traffic observability and analysis.

Ready to quiz yourself?