VPC Traffic Flow and Security

Configure route tables, security groups, and network ACLs in AWS.

Introduction

30 Second Summary

Think about how a building controls who gets in. There's a main entrance (routing), a security desk checking IDs (resource-level access), and locked doors on each floor (subnet-level protection).

In this project, you will configure traffic flow and security for your existing VPC by setting up a route table, a security group, and a network ACL. These three layers work together to control how traffic moves in and out of your cloud network.

What You'll Build

A complete traffic flow and security configuration for your NextWork VPC, adding the three layers needed to serve public web traffic.

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

A custom route table directing internet-bound traffic from your public subnet through the internet gateway.
A security group allowing inbound HTTP traffic, providing stateful resource-level security.
A custom network ACL providing stateless subnet-level security as an additional layer of defense.
Secret Mission: Use the AWS CLI in CloudShell to create VPC resources in a new region and track them with EC2 Global View.

Are there any prerequisites?

Yes. This project builds directly on Part 1 (Build a Virtual Private Cloud). You need your NextWork VPC, Public 1 subnet, and NextWork IG still active in your AWS account before starting.

Verify Your Existing VPC Resources

Before adding any new networking layers, you need to confirm that your Part 1 resources are still in place.

In this step, you will log in to your AWS account and verify that the VPC, subnet, and internet gateway you created earlier all exist and are correctly connected.

In this step, get ready to:

Confirm your NextWork VPC and Public 1 subnet exist.
Verify your internet gateway is attached to the VPC.
Identify the main route table and its current routes.

Log in and find your VPC

Your NextWork VPC from Part 1 is the foundation for everything you build in this project. Let's confirm it still exists.

Sign in to the AWS Management Console with your IAM Admin User.
In the search bar at the top, type VPC and select VPC from the results.
In the left navigation pane, choose Your VPCs.
Confirm you can see NextWork VPC with the IPv4 CIDR 10.0.0.0/16.
Make sure you are in the same Region you used in Part 1 (check the Region dropdown in the top right corner of the console).

Don't see NextWork VPC?

If NextWork VPC is missing, check that you are in the correct AWS Region. The Region selector is in the top right corner of the console. If you completed Part 1 in a different Region, switch to that Region now.

If you still cannot find it, you may need to redo Part 1 (Build a Virtual Private Cloud) to recreate your VPC resources before continuing.

help me find my NextWork VPC from Part 1

Confirm your subnet and internet gateway

Your public subnet and internet gateway are the two resources that make internet connectivity possible. Both need to be in place before you add a route.

In the left navigation pane, choose Subnets.
Confirm you can see Public 1 with the IPv4 CIDR 10.0.0.0/24.
In the left navigation pane, choose Internet gateways.
Confirm NextWork IG exists and shows as Attached to your NextWork VPC.

Why does the internet gateway need to be attached?

An internet gateway is the door between your VPC and the public internet. If it exists but is not attached to your VPC, no traffic can flow in or out. The Attached status confirms the connection is live.

Check the main route table

A route table tells traffic where to go. Right now, your VPC's main route table only knows about internal traffic. It has no route to the internet.

In the left navigation pane, choose Route tables.
You should see at least two route tables: one for your default VPC and one that was automatically created with NextWork VPC.
Select the route table associated with NextWork VPC.
Select the Routes tab and confirm it has a single route with Destination 10.0.0.0/16 and Target local.

What does the local route do?

The 10.0.0.0/16 route with target local means any traffic destined for an IP address inside your VPC stays inside the VPC. It is the default route AWS creates for every VPC.

Notice there is no route for 0.0.0.0/0 (all other traffic). That means traffic cannot reach the internet yet. Fixing this is your next step.

How to identify the right route table

If both route tables look similar, select each one and check the Routes tab. The one associated with NextWork VPC will have destination 10.0.0.0/16 (your VPC's CIDR). Your default VPC's route table will show a different CIDR like 172.31.0.0/16.

All four resources are confirmed. Your VPC currently has no internet route, which means your public subnet is not yet truly public. Next up, you will create a route to the internet and make that connection live.

Create and Configure a Route Table

Your VPC resources are confirmed and ready. Now it's time to solve the first real networking problem: your subnet has no path to the internet.

A route table acts as a set of directions for network traffic. Right now, traffic inside your VPC can only travel between resources within the VPC itself. You'll add a route that sends internet-bound traffic through your internet gateway, then connect it to your Public 1 subnet.

In this step, get ready to:

Rename the main route table and add an internet route through your internet gateway.
Associate the route table with your Public 1 subnet to enable internet connectivity.

Rename your route table and add an internet route

Your VPC's main route table currently has a single route that keeps traffic inside the VPC. You'll give it a name and add a second route that sends all other traffic to the internet gateway.

In the left navigation pane, choose Route tables.
Select the route table associated with NextWork VPC. It has a single route with destination 10.0.0.0/16 and target local.
Select the pencil icon in the Name column.
Enter NextWork route table and select Save.

Now add the internet route.

Select the Routes tab.
Choose Edit routes.
Choose Add route.
For Destination, enter 0.0.0.0/0.
For Target, select Internet Gateway, then select NextWork IG.
Choose Save changes.

What does 0.0.0.0/0 mean?

The destination 0.0.0.0/0 represents all IPv4 addresses. It acts as a catch-all: any traffic that doesn't match a more specific route (like your 10.0.0.0/16 local route) gets sent to the internet gateway instead.

Together, your two routes create a simple decision: traffic destined for another resource inside the VPC stays local, and everything else goes to the internet.

Don't see NextWork IG in the target dropdown?

Make sure you selected Internet Gateway as the target type first. The dropdown for the specific gateway only appears after you choose the type.

If the list is empty, your internet gateway may not be attached to NextWork VPC. Return to Internet gateways in the left navigation pane and confirm NextWork IG shows Attached status.

help me troubleshoot why my internet gateway isn't showing up as a route target

Associate your route table with Public 1

A route table only applies to subnets that are explicitly associated with it. Without this association, your Public 1 subnet would still use the default implicit association and miss the internet route you just added.

Choose the Subnet associations tab.
Under Explicit subnet associations, choose Edit subnet associations.
Select the checkbox next to Public 1.
Choose Save associations.

Why is your subnet now truly public?

A public subnet needs three things: a VPC with an internet gateway, a route table with a route to that internet gateway, and the subnet explicitly associated with that route table. You now have all three.

Before this step, Public 1 had the internet gateway nearby but no directions telling traffic how to reach it. The route table is the missing piece that connects your subnet to the outside world.

Your Routes tab should now show two routes: 10.0.0.0/16 targeting local and 0.0.0.0/0 targeting your NextWork IG.

Only see one route?

Make sure you're looking at the Routes tab for NextWork route table (the one you just renamed). If you see only the 10.0.0.0/16 route, your Save changes may not have gone through. Select the route table again, choose Edit routes, and re-add the 0.0.0.0/0 route.

help me fix my route table so it has a route to the internet gateway

Your subnet now has a complete path to the internet. Next up, you'll create a security group to control which traffic is actually allowed to reach your resources.

Create a Security Group

Your route table is configured and Public 1 can now reach the internet through NextWork IG. The next challenge is controlling what type of traffic actually reaches the resources inside your subnet.

A security group acts as a virtual firewall at the resource level. In this step, you will create one that allows only HTTP web traffic to reach your future resources.

In this step, get ready to:

Create a security group in NextWork VPC.
Add an inbound rule allowing HTTP traffic from anywhere.

Create a new security group

Your VPC already has a default security group, but you will create a custom one with specific rules tailored for web traffic.

In the left navigation pane, choose Security groups.
You will see default security groups that AWS created for your VPCs.
Choose Create security group.
For Security group name, enter NextWork Security Group.
For Description, enter A Security Group for the NextWork VPC.
For VPC, remove the currently selected VPC by clicking the X, then select NextWork VPC.

What is a security group?

A security group is a virtual firewall that controls inbound and outbound traffic for individual resources like EC2 instances. You attach it directly to a resource, and it decides which traffic is allowed in and out.

Security groups are stateful. If you allow traffic in, the response traffic is automatically allowed out. You do not need to create a separate outbound rule for return traffic.

Add an inbound rule for HTTP traffic

Now you will tell the security group exactly which type of incoming traffic to allow. This rule permits HTTP web traffic from any IP address.

Under Inbound rules, choose Add rule.
For Type, select HTTP.
For Source, select Anywhere-IPv4.

You will see a yellow warning about allowing access from all IP addresses. This is expected for a public web server that needs to accept traffic from any visitor.

At the bottom of the screen, choose Create security group.

You should see a success banner confirming that NextWork Security Group was created. The Inbound rules tab shows one rule: Type HTTP, Port range 80, Source 0.0.0.0/0.

Why did you not need to add outbound rules?

New security groups start with a default outbound rule that allows all traffic to leave the resource. Since security groups are stateful, the response to any allowed inbound request is automatically permitted outbound.

This means your HTTP responses will flow back to visitors without any extra configuration.

Don't see NextWork VPC in the dropdown?

Make sure you are in the same Region you used in Part 1. Check the Region selector in the top-right corner of the console.

help me find NextWork VPC in the security group creation form

Your security group is ready to attach to resources. Next up, you will create a network ACL to add a second layer of security at the subnet level.

Create a Network ACL

Your security group is in place, protecting resources inside the VPC at the instance level. Now you'll add a second layer of defense that works at the subnet level.

A network ACL filters traffic entering and leaving an entire subnet. By combining it with the security group you just created, your VPC gains the layered security approach used in production AWS environments.

In this step, get ready to:

Create a custom network ACL and observe how it differs from the default.
Add inbound and outbound rules to allow traffic.
Associate the network ACL with your Public 1 subnet.

Create a custom network ACL

Before creating your own network ACL, you'll inspect the default one that AWS automatically attached to your subnet. This helps you see what changes when you switch to a custom ACL.

In the left navigation pane, choose Network ACLs.
You will see default network ACLs that AWS created for your VPCs.
Select the network ACL associated with your Public 1 subnet.
Select the Inbound rules tab.
Notice Rule 100 allowing all traffic.
Select the Outbound rules tab.
Notice Rule 100 allowing all traffic here too.

What is a network ACL?

A network ACL is a firewall that controls traffic at the subnet level. Every subnet must be associated with exactly one network ACL at a time.

The default network ACL allows all inbound and outbound traffic. A custom network ACL denies all traffic until you add rules, which gives you full control over what gets through.

Choose Create network ACL.
For Name, enter NextWork Network ACL.
For VPC, select NextWork VPC.
Choose Create network ACL.

Don't see NextWork VPC in the dropdown?

Make sure you are in the same Region you used in Part 1. The VPC dropdown only shows VPCs in your current Region.

help me find my NextWork VPC in the VPC console

Add inbound and outbound rules

Your custom network ACL currently denies all traffic because custom ACLs start with only a deny-all rule. You need to add allow rules so traffic can actually flow through your subnet.

Select the checkbox next to NextWork Network ACL.
Select the Inbound rules tab.
Notice it only has a deny-all rule marked with an asterisk (*).
Choose Edit inbound rules.
Choose Add new rule.
Set Rule number to 100.
Set Type to All traffic.
Set Source to 0.0.0.0/0.
Click Save changes.

Now repeat the process for outbound traffic.

Select the Outbound rules tab.
Choose Edit outbound rules.
Choose Add new rule.
Set Rule number to 100.
Set Type to All traffic.
Set Destination to 0.0.0.0/0.
Click Save changes.

Why do network ACLs need both inbound and outbound rules?

Network ACLs are stateless. This means response traffic is not automatically allowed. If you only add an inbound rule, traffic can enter the subnet but responses cannot leave.

This is different from security groups, which are stateful. With a security group, return traffic is automatically allowed regardless of outbound rules.

Why use Rule number 100?

Rules are evaluated in ascending order starting with the lowest numbered rule. The first matching rule is applied. Using 100 leaves room to insert more specific rules later (like Rule 50 to deny a specific IP) without renumbering everything.

Associate the network ACL with your subnet

Your network ACL has rules but is not protecting anything yet. You need to associate it with Public 1 to put it to work.

Select the Subnet associations tab.
Choose Edit subnet associations.
Select Public 1.
Choose Save changes.

What happened to the default network ACL?

A subnet can only be associated with one network ACL at a time. When you associated NextWork Network ACL with Public 1, the default network ACL was automatically removed from that subnet.

Your subnet is now protected by your custom ACL. If you ever need to revert, you can re-associate the default ACL through the same process.

Your NextWork Network ACL should now show Public 1 under the Subnet associations tab.

Don't see Public 1 in the subnet associations?

Make sure you selected the checkbox next to NextWork Network ACL before clicking the Subnet associations tab. If you were still viewing the default ACL, your changes went to the wrong resource.

help me associate my network ACL with my subnet

Secret mission

Track VPC Resources Across Regions with EC2 Global View

So far, you've built everything in a single region using the console. But what if you need resources in multiple regions? Use the AWS CLI to create VPC resources in a different region from a browser-based terminal, then track everything in one dashboard with EC2 Global View.

Clean Up Your Resources

All resources you created in this project are within the AWS free tier. VPCs, subnets, route tables, internet gateways, security groups, and network ACLs do not incur charges on their own.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

NextWork VPC (contains all associated resources below).
Public 1 subnet.
NextWork IG (internet gateway).
NextWork route table.
NextWork Security Group.
NextWork Network ACL.

Keep everything running

No action needed. Choose this if you are continuing to the next project in this series (Creating a Private Subnet) today.

No charges will accrue for any of these resources. They are all free-tier VPC components.
Your VPC is ready for the next project, which builds directly on top of this configuration.

Pause - I'll come back to this later

These are static cloud resources with no running processes to stop. There is nothing to pause.

Your VPC, subnet, route table, security group, and network ACL will remain in your account at no cost until you decide to continue or delete them.
When you are ready to pick back up, return to the VPC console and confirm your resources are still in place.

Delete - I don't want to use this again

Remove all project resources and start fresh. Deleting your VPC through the console also deletes all associated components (subnets, route tables, internet gateways, security groups, and network ACLs).

In the VPC console, choose Your VPCs in the left navigation pane.
Select NextWork VPC.
Choose Actions, then Delete VPC.
AWS displays a list of resources that will be deleted along with the VPC. Review the list to confirm it includes Public 1, NextWork IG, NextWork route table, NextWork Security Group, and NextWork Network ACL.
When prompted for confirmation, type delete and choose Delete.

What about the Secret Mission resources?

If you completed the Secret Mission, you already deleted the CLI-created VPC and subnet in us-west-2 as part of that section. No additional cleanup is needed for those resources.

Nice Work!

You just configured a complete traffic flow and security setup for your VPC. Your public subnet now has everything it needs to serve internet traffic through three distinct layers of control.

Here's what you accomplished:

Configured a route table with an internet gateway route, turning your subnet into a true public subnet.
Created a security group allowing HTTP traffic, providing stateful resource-level security.
Deployed a custom network ACL with allow rules, providing stateless subnet-level security.
Secret Mission: Used the AWS CLI in CloudShell to create VPC resources in another region and tracked them with EC2 Global View.

Ready to quiz yourself?