Harden VPC Traffic Flow and Security

Build a hardened VPC with public and private subnet traffic controls.

Introduction

30 Second Summary

A locked front door means little when a side entrance is left open. Cloud networks face the same problem when traffic has more paths than expected.

In this project, you will build a two-tier Amazon VPC that keeps its application area unreachable directly from the internet. You will audit four sample traffic flows across its layered controls.

What You'll Build

Your finished Resource map will show the public subnet in green with an internet gateway path while the private subnet stays blue with no path to the internet.

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

A visual traffic map that lets you demonstrate where public access ends before the private application tier.
Role-based security groups that admit HTTPS to the web role. The same policy limits application access to TCP port 8080 from that role.
Stateless network ACLs that let you trace request traffic plus its return path to an ALLOW or DENY result.
Secret Mission: Use a lower-numbered deny rule to quarantine the private subnet before safely restoring normal access.

Are there any prerequisites?

You need an AWS account with permission to create and delete Amazon VPC resources. A web browser is enough because this project uses the AWS Management Console.

Before We Start

Before the hands-on work begins, lock in the network you are building and the reason for its isolation. You are committing to a cost-controlled two-tier Amazon VPC whose private application tier has no direct path from the internet.

Create the Isolated Lab VPC

Every route and traffic filter in this project needs to belong to one dedicated regional boundary. That boundary keeps the lab isolated from other networks in your selected Region.

Amazon VPC provides that boundary. You will create an empty IPv4-only VPC so every later resource has one clear home.

In this step, get ready to:

Create an IPv4-only VPC named nw-hardening-vpc.
Confirm the VPC has its automatic default networking resources.
Record the selected Region and VPC ID from the Resource map.

Create the IPv4 VPC

An IPv4 CIDR block sets the private address range available to this VPC. The 10.0.0.0/16 range leaves room for the two subnets you add later.

Creating this empty VPC is a controlled cloud change. The VPC itself has no additional charge.

Choose Create VPC on the VPC dashboard.
Select VPC only.
Enter nw-hardening-vpc for Name tag.
Choose IPv4 CIDR manual input.
Enter 10.0.0.0/16 for the IPv4 CIDR.
Keep Default tenancy selected.
Leave the VPC without an IPv6 CIDR.
Choose Create VPC.

Good start. nw-hardening-vpc now gives every later network control a dedicated home.

What did AWS add with the VPC?

AWS creates three default networking resources with the VPC. They provide the starting behavior that you inspect throughout this project.

An automatically created main route table for subnet routing.
An automatically created default network ACL for subnet-level traffic filtering.
An automatically created default security group for resource-level traffic filtering.

Inspect and record the VPC

The Resource map shows how a VPC connects to subnets and routing resources. Your new boundary should still be empty because you created the VPC by itself.

Before you open the map, consider whether any subnet branches should exist yet.

Choose VPCs in the left navigation.
Select nw-hardening-vpc.
Choose the Resource map tab.
Choose Show details.
Read the selected AWS Region from the console header.
Record it here: your selected AWS Region.
Find the VPC ID in the displayed VPC details.
Record it here: your VPC ID.

You should see nw-hardening-vpc with IPv4 CIDR 10.0.0.0/16. You should see no subnet branches.

Checkpoint complete. The empty map proves that your isolated regional boundary exists before any subnet paths are added.

Can't find the VPC?

Check the Region shown in the AWS Management Console header. The VPC appears in the Region where you created it.
Refresh the VPC list and look for the exact name nw-hardening-vpc.

Ask for help checking the VPC location and configuration.

Your isolated VPC boundary is ready. Next, you add the public and private subnets to inspect what they inherit.

Create the Public and Private Subnets

Your Amazon VPC now gives the lab a dedicated address boundary. It still has no subnet tiers for future web or application roles.

Subnet names provide labels only. Traffic isolation comes from route table associations plus network ACL associations.

In this step, get ready to:

Create nw-public-subnet inside nw-hardening-vpc.
Create nw-private-subnet in the same Availability Zone.
Inspect the inherited traffic controls for both subnets.

Create the public subnet

An IPv4 CIDR range gives each subnet its own portion of the VPC address space. The public tier uses 10.0.1.0/24.

Select Subnets from the VPC console's left navigation.
Choose Create subnet.
Select nw-hardening-vpc from the VPC ID list.
Enter nw-public-subnet in the Subnet name field.
Select one option from Availability Zone.
Record the selected Availability Zone here: your selected Availability Zone.

How Does the CIDR Fit?

The VPC uses 10.0.0.0/16 as its complete address range. The 10.0.1.0/24 range reserves a smaller portion for the public tier.

Choose Manual input for IPv4 CIDR block.
Enter 10.0.1.0/24 as the subnet IPv4 CIDR.
Choose Create subnet.

Good. The subnet list now shows nw-public-subnet with CIDR 10.0.1.0/24.

Subnet Not Created?

Check that nw-hardening-vpc is still selected. The subnet CIDR must sit inside 10.0.0.0/16.

Check that you entered 10.0.1.0/24 exactly.

help me check why my public subnet was not created.

Create the private subnet

A separate CIDR gives the private tier its own address space. Using the same Availability Zone keeps this lab focused on traffic controls.

Choose Create subnet.
Select nw-hardening-vpc from the VPC ID list.
Enter nw-private-subnet in the Subnet name field.
Select your selected Availability Zone from Availability Zone.
Choose Manual input for IPv4 CIDR block.
Enter 10.0.2.0/24 as the subnet IPv4 CIDR.
Choose Create subnet.

You should now see nw-public-subnet plus nw-private-subnet with their respective CIDRs. The Availability Zone column should match for both rows.

Reveal the shared subnet defaults

Both subnet tiers now exist. The important lesson comes from the traffic controls that the console assigned automatically.

Before you inspect the tabs, do you expect the two subnet names to produce different traffic controls?

Select nw-public-subnet in the subnet list.
Choose the Route table tab.
Record the displayed route table ID here: your main route table ID.
Choose the Network ACL tab.
Record the displayed network ACL ID here: your default network ACL ID.
Select nw-private-subnet in the subnet list.
Choose the Route table tab.
Compare the displayed route table ID with your main route table ID.

You have now compared the routing side. One inherited filter remains to check.

Choose the Network ACL tab.
Compare the displayed network ACL ID with your default network ACL ID.

You'll see the same route table ID for both subnets. Both implicitly use the VPC main route table.

You'll also see the same network ACL ID for both subnets. Both are associated with the default network ACL.

This shared policy is the intended shortfall. Different subnet names still produce the same traffic controls.

Why Are the Controls Shared?

Amazon VPC implicitly associates a subnet with the main route table when no explicit route table association exists.

A newly created subnet uses the default network ACL until you associate a custom one.

These defaults keep initial behavior consistent. They do not express separate public or private roles.

Before you return to the map, which color do you expect both subnets to have without an internet route?

Return to VPCs using the left navigation.
Select nw-hardening-vpc.
Choose the Resource map tab.
Confirm Show details remains enabled.

You'll see nw-public-subnet plus nw-private-subnet as blue private subnets. No route to an internet gateway exists yet.

You have reached the first network milestone. The VPC Resource map now shows two distinct subnet address ranges with the same inherited controls.

Your public and private subnet tiers now exist. Next, you will give each tier an explicit route table that matches its intended role.

Separate Public and Private Routes

Your Amazon VPC now has two subnets that share its main route table. That shared path cannot express separate public and private intent.

You'll attach an internet gateway to provide a target for public internet routes. You'll then give each subnet its own explicit routing policy.

In this step, get ready to:

Attach nw-hardening-igw to nw-hardening-vpc.
Create separate route tables for the public and private subnets.
Associate each subnet with its matching route table.

Attach the internet gateway

An internet gateway gives the public route table a target outside the VPC. Creating this gateway adds no charge to this empty lab.

Choose Internet gateways in the left navigation pane.
Choose Create internet gateway.
Enter nw-hardening-igw as the internet gateway name.
Choose Create internet gateway.

You'll see confirmation that nw-hardening-igw exists. It is ready to be attached to your VPC.

Select nw-hardening-igw from the internet gateway list.
Choose Actions.
Choose Attach to VPC.
Select nw-hardening-vpc.
Choose Attach internet gateway.

The gateway now shows nw-hardening-vpc as its attached VPC. Your VPC can now use the gateway as a route target.

What Makes a Subnet Public?

An attached gateway is an available route target. A subnet becomes public when its route table sends 0.0.0.0/0 to that gateway.

This lab has no workloads or public IPv4 addresses. The map demonstrates the network design without claiming live internet connectivity.

Can't Attach the Internet Gateway?

Confirm that nw-hardening-vpc appears in the VPC selector.
Confirm that the console still shows the Region you selected earlier.

Ask for help if the attachment still fails: help me attach the internet gateway to my VPC.

Create separate route tables

A new custom route table starts with a local route for its VPC. That route keeps traffic between addresses inside 10.0.0.0/16 available.

Choose Route tables in the left navigation pane.
Choose Create route table.
Enter nw-public-rt for Name.
Select nw-hardening-vpc for VPC.
Choose Create route table.

The creation confirmation proves that nw-public-rt now exists inside your lab VPC.

Return to Route tables in the left navigation pane.
Choose Create route table.
Enter nw-private-rt for Name.
Select nw-hardening-vpc for VPC.
Choose Create route table.

You now have one custom route table for each subnet role. Both begin with the automatically created local route.

Return to Route tables in the left navigation pane.
Select nw-public-rt.
Choose Edit routes.
Choose Add route.
Enter 0.0.0.0/0 for Destination.
Select nw-hardening-igw for Target.
Choose Save changes.

The public route table now lists its local route plus 0.0.0.0/0 targeting nw-hardening-igw.

Return to the route-table list.
Select nw-private-rt.
Review the routes listed for the private route table.

You'll see only the automatically created local route for 10.0.0.0/16. This table has no internet-gateway route.

Why Leave Out a NAT Gateway?

The private route table keeps only its local route, so the private subnet has no internet path. A NAT Gateway would introduce a paid resource.

Leaving it out preserves the isolation lesson. It also protects the project's $0 target.

Don't See the Gateway as a Target?

Return to Internet gateways in the left navigation pane.
Confirm that nw-hardening-igw is attached to nw-hardening-vpc.
Return to nw-public-rt after confirming the attachment.

Use this if the target remains unavailable: help me find my internet gateway in the route target list.

Complete the routing split

Each subnet still inherits the main route table until you create an explicit association. The associations turn your public and private names into real routing behavior.

Return to Route tables in the left navigation pane.
Select nw-public-rt.
Choose the Subnet associations tab.
Choose Edit subnet associations.
Select nw-public-subnet.
Choose Save associations.

The public route table now lists nw-public-subnet as an explicit subnet association.

Return to the route-table list.
Select nw-private-rt.
Choose the Subnet associations tab.
Choose Edit subnet associations.
Select nw-private-subnet.
Choose Save associations.

Both subnets now use explicit route-table associations. The main route table has no explicit subnet associations.

Before you check the map, which subnet do you expect to turn green?

Return to VPCs in the left navigation pane.
Select nw-hardening-vpc.
Choose the Resource map tab.
Choose Show details.

You'll see nw-public-subnet in green with a path through nw-public-rt to nw-hardening-igw.

You'll see nw-private-subnet in blue with no internet-gateway path. Both subnets remain associated with the default network ACL.

You have turned the earlier routing shortfall into a visible public-private split. Each subnet now follows the policy that matches its role.

Map Still Shows Both Subnets as Private?

Confirm that nw-public-rt contains the 0.0.0.0/0 route.
Confirm that the route targets nw-hardening-igw.
Confirm that nw-public-subnet is explicitly associated with nw-public-rt.

Ask for a routing check if the map still looks unchanged: help me diagnose my VPC Resource map.

Your routes now express where traffic can travel. Next, you'll add stateful security groups to control which workload roles may use those paths.

Build Stateful Workload Policies

The Amazon VPC Resource map now shows separate public and private paths. Your routing layer directs traffic toward the correct subnet.

Route tables cannot decide which workload role may use a port. Stateful security groups add that resource-level intent.

This step creates the web role policy. It also creates the application role policy.

In this step, get ready to:

Create separate security groups for the web role and application role.
Allow public HTTPS traffic to reach the web role.
Allow only the web role to reach the application role on TCP port 8080.

Create the role-based security groups

A security group represents the policy for a workload role. This lab creates those policies without creating workloads.

Return to Security groups in the Amazon VPC console's left navigation.
Choose Create security group.
Enter nw-web-sg as the group name.
Enter Public web role for the VPC hardening lab as the description.
Select nw-hardening-vpc for VPC.
Choose Create security group.

That is the first policy shell ready. You will see nw-web-sg listed inside nw-hardening-vpc.

Return to Security groups in the left navigation.
Choose Create security group.
Enter nw-app-sg as the group name.
Enter Private app role for the VPC hardening lab as the description.
Select nw-hardening-vpc for VPC.
Choose Create security group.

You will see nw-app-sg listed beside nw-web-sg. Both role policies now exist in the project VPC.

What starts in a new security group?

A new custom security group starts with no inbound rules. It starts with one outbound rule that allows all traffic.

The next actions replace that broad outbound behavior with the narrow paths required by this network design.

Created a group in the wrong VPC?

Check that the VPC field shows nw-hardening-vpc before creating each group.
Delete the incorrectly placed group with the console's group deletion action.
Recreate the group inside nw-hardening-vpc.

Help me fix a security group created in the wrong VPC.

Restrict the web role

The web role needs one public entry point: HTTPS. Its only application path uses TCP port 8080 to reach nw-app-sg.

Select nw-web-sg from the Security groups list.
Choose the Inbound rules tab.
Choose Edit inbound rules.
Choose Add rule.
Select HTTPS for Type.
Select Anywhere-IPv4 for Source.
Confirm that the source shows 0.0.0.0/0.
Choose Save rules.

Your web role now has a narrow public doorway. The inbound table shows HTTPS on TCP port 443 from 0.0.0.0/0.

Choose the Outbound rules tab.
Choose Edit outbound rules.
Choose Delete on the existing rule that allows all outbound traffic.
Choose Add rule.
Select Custom TCP for Type.
Enter 8080 for Port range.
Select nw-app-sg for Destination.
Choose Save rules.

The outbound table now shows one Custom TCP rule on port 8080. Its destination is nw-app-sg.

Why reference another security group?

The nw-app-sg reference acts as the destination identity for this rule. Future resources must be associated with that group before the rule applies to their traffic.

This keeps the policy tied to the application role. It avoids depending on a fixed private IP address.

Cannot select the application group?

Confirm that nw-web-sg belongs to nw-hardening-vpc.
Confirm that nw-app-sg belongs to nw-hardening-vpc.
Remove the remaining all-traffic outbound rule if the table still shows it.

Help me configure the web security group's outbound reference.

Restrict the application role

The application role should accept requests only from the web role on port 8080. Removing its default outbound rule leaves no rules for newly initiated outbound traffic.

Select nw-app-sg from the Security groups list.
Choose the Inbound rules tab.
Choose Edit inbound rules.
Choose Add rule.
Select Custom TCP for Type.
Enter 8080 for Port range.
Select nw-web-sg for Source.
Choose Save rules.

The application inbound table now shows one Custom TCP rule on port 8080. Its source is nw-web-sg.

Choose the Outbound rules tab.
Choose Edit outbound rules.
Choose Delete on the existing rule that allows all outbound traffic.
Choose Save rules.

The outbound table for nw-app-sg now contains no rules. The application policy cannot start an unrelated outbound connection.

How does statefulness affect this policy?

An empty outbound table still permits response traffic for an allowed inbound connection. Security groups remember the connection state.

This lets a future application workload answer the web role's permitted request without adding a separate return rule.

Before you inspect both policies, which role do you expect to accept internet traffic?

Return to the Security groups list.
Select nw-web-sg.
Choose the Inbound rules tab.

You will see one HTTPS inbound rule on TCP port 443 from 0.0.0.0/0.

Choose the Outbound rules tab.

You will see one Custom TCP outbound rule on port 8080 to nw-app-sg.

Return to the Security groups list.
Select nw-app-sg.
Choose the Inbound rules tab.

You will see one Custom TCP inbound rule on port 8080 from nw-web-sg.

Choose the Outbound rules tab.

You will see no outbound rules for nw-app-sg. The two rule tables now match the intended web-to-application path.

Because this lab contains no workload network interfaces, both groups remain unattached. These rule tables verify the policy configuration only.

Return to the Security groups list.

You will see both nw-web-sg and nw-app-sg listed inside nw-hardening-vpc.

Rules do not match the policy?

Check that each selected group belongs to nw-hardening-vpc.
Remove any remaining all-traffic outbound rule.
Correct any source or destination that uses a CIDR where a security group reference is required.

Help me compare my security group rules with the intended policy.

Your web and application roles now have stateful port policies without running workloads. Next, you will add stateless subnet guardrails for a four-flow audit.

Add Stateless Guardrails and Audit Traffic

Your Amazon VPC now has separate public and private routes. Its security groups define the intended workload roles, even though no network interfaces are attached.

Those groups only protect resources associated with them. Custom network ACLs add a subnet-wide boundary through stateless rules.

In this step, get ready to:

Create two custom network ACLs inside nw-hardening-vpc.
Configure explicit request paths plus return paths for each subnet.
Prove the layered policy through subnet associations plus a four-flow audit.

Create the custom network ACLs

A new custom network ACL begins with unmatched traffic denied in both directions. It stays unattached until you associate it with a subnet.

Choose Network ACLs in the Amazon VPC console's left navigation.
Choose Create network ACL.
Enter nw-public-nacl in the Name field.
Select nw-hardening-vpc from the VPC field.
Choose Create network ACL.

You'll see nw-public-nacl in the ACL list. Its asterisk rules deny inbound traffic plus outbound traffic that no numbered rule matches.

Choose Create network ACL again.
Enter nw-private-nacl in the Name field.
Select nw-hardening-vpc from the VPC field.
Choose Create network ACL.

You'll now see both custom ACLs. Neither one has a subnet association yet.

Can't find your VPC?

Check that the Region selector still shows the Region you used earlier. VPC resources only appear in their selected Region.

If the VPC is still missing, confirm that its name is exactly nw-hardening-vpc.

help me locate nw-hardening-vpc in the Region I selected.

Configure the subnet guardrails

Stateless evaluation treats each traffic direction as a separate decision. Return traffic therefore needs its own matching rule.

How Network ACL Rules Decide

Lower rule numbers are evaluated first.
The first matching rule decides whether the traffic is allowed or denied.
Traffic without a numbered match reaches the implicit deny rule.
Response traffic must pass a separate rule in the opposite direction.

Select nw-public-nacl from the ACL list.
Choose the Inbound rules tab.
Choose Edit inbound rules.
Choose Add new rule.
Configure rule 100 as HTTPS on port 443 from 0.0.0.0/0 with action ALLOW.
Choose Add new rule.
Configure rule 110 as Custom TCP on ports 1024-65535 from 10.0.2.0/24 with action ALLOW.
Choose Save changes.

You'll see two numbered inbound rules above the unmatched-traffic deny rule. They admit public HTTPS requests plus return traffic from the private subnet.

Choose the Outbound rules tab.
Choose Edit outbound rules.
Choose Add new rule.
Configure rule 100 as Custom TCP on ports 1024-65535 to 0.0.0.0/0 with action ALLOW.
Choose Add new rule.
Configure rule 110 as Custom TCP on port 8080 to 10.0.2.0/24 with action ALLOW.
Choose Save changes.

The public ACL now admits internet return traffic on ephemeral ports. It also admits application requests to the private subnet on TCP port 8080.

Public Rules Missing?

Confirm that you selected nw-public-nacl before editing the rules. The ACL name appears above the rule table.

Return to the relevant direction if you placed a rule in the wrong table. Inbound sources belong under Inbound rules.

help me check my public network ACL rules.

Select nw-private-nacl from the ACL list.
Choose the Inbound rules tab.
Choose Edit inbound rules.
Choose Add new rule.
Configure rule 100 as Custom TCP on port 8080 from 10.0.1.0/24 with action ALLOW.
Choose Save changes.

The private inbound table now admits application requests only from the public subnet's CIDR.

Choose the Outbound rules tab.
Choose Edit outbound rules.
Choose Add new rule.
Configure rule 100 as Custom TCP on ports 1024-65535 to 10.0.1.0/24 with action ALLOW.
Choose Save changes.

The private outbound table now permits response traffic back to ephemeral ports in the public subnet.

The rules define the guardrails. Their subnet associations make those guardrails active.

Choose Subnets in the left navigation.
Select nw-public-subnet.
Choose Actions.
Choose Edit network ACL association.
Select nw-public-nacl for Network ACL ID.
Choose Save.

You'll see nw-public-subnet associated with nw-public-nacl.

Select nw-private-subnet.
Choose Actions.
Choose Edit network ACL association.
Select nw-private-nacl for Network ACL ID.
Choose Save.

You'll see nw-private-subnet associated with nw-private-nacl. The default network ACL now has neither subnet association.

Select nw-public-subnet.
Choose the Network ACL tab.

You'll see nw-public-nacl as the public subnet's active ACL.

Select nw-private-subnet.
Choose the Network ACL tab.

You'll see nw-private-nacl as the private subnet's active ACL.

Association Still Shows the Default ACL?

Return to the affected subnet's Actions menu. Confirm that you selected the custom ACL whose name matches that subnet.

Refresh the subnet list after saving if the details panel still shows the previous association.

help me correct my subnet network ACL association.

Audit the four traffic paths

That is the fiddly configuration finished. Both subnets now use the intended custom guardrails.

The final audit checks three policy layers for each hypothetical flow. This lab has no compute or live traffic, so each result is a configuration-based decision.

How to Trace a Flow

Start with the route table to determine whether a network path exists.
Check the relevant network ACL direction from the lowest rule number upward.
Check the security-group rule that would apply if the groups were attached to workloads.
Confirm the opposite network ACL direction for return traffic on an allowed path.

Before you start the audit, consider which flow routing alone will stop.

Choose Route tables in the left navigation.
Inspect the Routes tab for nw-public-rt.
Inspect the Routes tab for nw-private-rt.
Choose Network ACLs in the left navigation.
Inspect both rule directions for each custom ACL.
Choose Security groups in the left navigation.
Inspect the rules for nw-web-sg.
Inspect the rules for nw-app-sg.

You now have the route plus filter evidence needed for each decision. Apply that evidence to the four flows.

Trace internet traffic to the web role on TCP port 443.
Trace internet traffic to the web role on TCP port 22.
Trace internet traffic directly to the application role on TCP port 8080.
Trace web-role traffic to the application role on TCP port 8080.

Your Four Audit Results

Internet to the web role on TCP 443: ALLOW. The public route exists. Public inbound rule 100 permits HTTPS. Public outbound rule 100 covers ephemeral return traffic. nw-web-sg permits HTTPS if attached.
Internet to the web role on TCP 22: DENY. The public route exists. No numbered public inbound ACL rule permits port 22. nw-web-sg has no matching inbound rule.
Internet directly to the application role on TCP 8080: DENY. The private route table has no internet-gateway route. The private ACL does not permit an internet source. nw-app-sg accepts this port only from nw-web-sg if attached.
Web role to application role on TCP 8080: ALLOW. The VPC local route provides the path. Public outbound rule 110 permits the request. Private inbound rule 100 permits the request. Private outbound rule 100 plus public inbound rule 110 permit the return path. Both security-group references match if attached.

Strong finish. Your VPC now expresses a narrow HTTPS-to-application path through three inspectable layers without creating workloads or live packet traffic.

Secret mission

Quarantine and Restore the Private Subnet

Incident response sometimes requires one network path to be quarantined without rewriting the baseline policy. Add a temporary lower-numbered deny rule, prove that it takes priority, then restore the original application path.

Clean Up Your Resources

Choose whether to keep, pause, or delete the Amazon VPC lab. This lab has no ongoing project-resource charges because it contains no compute, public IPv4 addresses, NAT gateways, or test traffic.

Resources you used:

One lab VPC named nw-hardening-vpc.
Two subnets named nw-public-subnet and nw-private-subnet.
One attached internet gateway named nw-hardening-igw.
Three route tables: the automatically created main table, nw-public-rt, and nw-private-rt.
Three security groups: the automatically created default group, nw-web-sg, and nw-app-sg.
Three network ACLs: the automatically created default ACL, nw-public-nacl, and nw-private-nacl.

Keep everything running

No action is needed. Choose this option if you want to reuse the configuration for another traffic-flow audit.

Leave nw-hardening-vpc in the selected AWS Region.
Review AWS pricing before adding services or sending traffic.

Pause - I'll come back to this later

This lab has no compute, so there are no running processes to stop. The configuration remains available for a later return.

Save the AWS Region you recorded earlier here: your selected AWS Region.
Save the VPC ID you recorded earlier here: your VPC ID.
Sign out of the AWS Management Console.

Delete - I don't want to use this again

Remove the lab when you no longer need the audit. The console shows every dependent component before you confirm the permanent deletion.

Delete the lab VPC

In the Amazon VPC console from earlier, choose Your VPCs.
Select nw-hardening-vpc.
Choose Actions.
Choose Delete VPC.
Review the listed dependent components.
Enter delete in the confirmation field.
Choose Delete.
Refresh the Your VPCs list after deletion completes.

You will no longer see nw-hardening-vpc in the list. Its subnets, route tables, internet gateway, network ACLs, and security groups are removed with it.

Nice Work!

You made it! You built a console-auditable Amazon VPC design that separates one public subnet from one private subnet.

You've learned how to:

Turn an IPv4 CIDR plan into distinct subnet roles. Replace inherited routing with explicit route tables for each subnet. Route nw-public-subnet through the internet gateway named nw-hardening-igw. Keep nw-private-subnet on its local route.
Create stateful security groups for the web role plus application role. Permit TCP 8080 only from nw-web-sg to nw-app-sg. Layer stateless network ACLs around both subnets with explicit request paths plus return paths.
Complete a four-flow configuration audit that explains each expected ALLOW or DENY result. Distinguish policy reasoning from a live packet test.
Secret Mission: Insert a lower-numbered emergency deny rule to quarantine TCP 8080. Prove rule 90 takes priority over rule 100. Remove rule 90 to restore the original ALLOW result.

Ready to quiz yourself?