VPC Traffic Flow and Security

Let's continue building our Amazon VPC!

Introduction

⚡️ 30 second Summary

Welcome to your second AWS networking project!

In your first networking project, you've created:

☁️ An Amazon VPC (amazing!)
🥅 A public subnet (woohoo!)
🚪 An internet gateway (go you!)

If you haven't done the first project in our networking series, Build a Virtual Private Cloud, we'd highly recommend doing that first. This project starts right where the previous one leaves off!

In VPC Traffic Flow and Security let's keep diving into the core essentials of building an Amazon Virtual Private Cloud (VPC).

Get ready to:

🚏 Create a route table.
👮‍♀️ Create a security group.
📋 Create a Network ACL (Network Access Control List).

Want a complete demo of how to do this project, from start to finish? Check out our 🎬 walkthrough with Natasha 🎬

If you're up for a bit of a challenge, quiz yourself on the key concepts up ahead in this project.

This project is part of a series:

Before we start Step #1...

Before we get started, it's important that you know what we're trying to do today.

Set up your VPC basics

We need to set up our VPC, subnet and internet gateway. Let's go!

In this step, get ready to:

Create a VPC.
Create subnets.
Create an internet gateway.

Have you completed the first project in the Networking Series?

Yes, and I have all my resources.

Great, we're ready to go!

Yes, but I deleted my resources.

No problem! Try setting up your resources:

Create a VPC.
Create subnets.
Create an internet gateway.

Make sure you're logged in to the AWS Management Console with your IAM Admin User.

Nope...

No problem! Let's set up our VPC, subnet and internet gateway.

Create a VPC.

Your VPC is the foundation for the rest of this project, and represents your corner of the AWS Cloud.

Log in to your AWS Account with your IAM user.
In your AWS Management Console's search bar, search for VPC.
In the left navigation pane, choose Your VPCs.

What is a VPC?

When you create a new resource on AWS, these resources exist "somewhere on the cloud," but you might wonder where exactly on the cloud they're located.

AWS organizes every single resource created into Regions (the only exceptions to this are global resources, like IAM users and roles). You can check which Region you're in by looking at the top right hand corner of your AWS Management Console.

So if we imagine your AWS Region as a country, a Virtual Private Cloud (VPC) is like managing your own city inside that country. You can design neighborhoods (i.e. subnets, which you'll learn about in a second), traffic rules, and security measures to control how the different resources, like EC2 instances and S3 buckets, are connected and work together inside your VPC.

Your city is isolated from other cities (i.e. other AWS Accounts' VPCs), giving you full privacy and control over your VPC's layout and rules.

Make sure you're on the Region that's closest to you. Use the dropdown on the top right hand corner to switch Regions.
Choose Create VPC.
Choose VPC Only.
Name tag: NextWork VPC
IPv4 CIDR: 10.0.0.0/16

What is an IPv4 CIDR?

An IP address is like a street address or coordinates for the resources in your city.

CIDR is a way to assign a whole block of IP addresses, kind of like creating a zone/area in a city.

💡 How does an IPv4 CIDR represent a block of IPs?

To understand how big a CIDR block is, look at the number after the slash - the smaller the number, the larger the CIDR block!

10.0.0.0/16 means the first 16 bits of your IP address (10.0) are fixed, but the remaining 16 bits (i.e. the second half of the IP address) can be allocated however you like. This means IP addresses within this CIDR block range from 10.0.0.0 to 10.0.255.255! There are 2^16 (65,536) possible IP addresses within this subnet.

A smaller CIDR block like 10.0.0.0/24 has the first 24 bits fixed, meaning only the last 8 bits can vary. This provides 2^8 (256) possible addresses.

A larger CIDR block like 10.0.0.0/8 has only the first 8 bits fixed which gives you 2^24 (16,777,216) possible addresses.

Select Create VPC.

Create subnets.

Nice! We've created our VPC, so it's time for the next step...creating a public subnet.

Quick recap: Subnets are subdivisions within your VPC where you can launch AWS resources.

In the VPC Dashboard, under Virtual Private Cloud, choose Subnets.
Choose Create subnet.
Configure your subnet settings:
- VPC ID: NextWork VPC
- Subnet name: Public 1
- Availability Zone: Select the first Availability Zone in the list.
- IPv4 VPC CIDR block: 10.0.0.0/16
- IPv4 subnet CIDR block: 10.0.0.0/24

Is my Public 1 subnet a public subnet?

Even though your subnet is labeled Public 1, it isn't a public subnet yet. A public subnet must have a route to an internet gateway, which you'll attach in a minute.

Choose Create subnet.

Select the checkbox next to Public 1.
In the Actions menu, select Edit subnet settings.
Check the box next to Enable auto-assign public IPv4 address.

What does it mean to enable auto-assign public IPv4 address?

When you enable auto-assign public IPv4 address for a subnet, any EC2 instance launched in that subnet will automatically receive a public IP address. This makes the instance accessible from the internet without needing to manually assign a public IP - a huge time saver!

Choose Save.

Create an internet gateway.

Time to connect our VPC to the internet... with an internet gateway:

In the left navigation pane, choose Internet gateways.
Choose Create internet gateway.
Configure your internet gateway settings:
- Name tag: NextWork IG
Choose Create internet gateway.
Select your newly created internet gateway and choose Actions, then Attach to VPC.
Select NextWork VPC.
Select Attach internet gateway.

What does attaching an internet gateway to a VPC mean?

Attaching an internet gateway means resources in your VPC can now access the internet. The EC2 instances with public IP addresses become accessible to users, so any application you host on those instances become public too.

Nice!

Set up work is allll done...

Let's dive into what's next for your VPC. 🤿

Create a route table

Even though you've created an internet gateway and attached it to your VPC, you still have to tell the resource in your public subnet how to get to the internet.

You'll have to set up route tables to direct traffic from your resource to your internet gateway!

In this step, get ready to:

Create a route table.

In the left navigation pane, choose Route tables.

What is a route table?

Think of a route table as a GPS for the resources in your subnet. Just like a GPS helps people get to their destination in a city, a route table is a table of rules, called routes, that decide where the data in your network should go.

Every subnet in your VPC needs to be linked to a route table, because the table tells your subnet's traffic where to travel to send and receive data. For example, if you have a web server (i.e. an EC2 instance) hosting a website, the EC2 instance's subnet needs a route table that knows how to direct incoming traffic to the website.

💡 What's the link between internet gateways and route tables?

When a subnet's route table has a route that directs internet-bound traffic to the internet gateway, the subnet becomes a public subnet. This means your subnet can communicate with the internet.

Refresh your page.
Ooo, two route tables! Why are there two?
- Note: If you see more than two route tables, those route tables would've been set up in other projects that you've completed. Check the VPC column in the far right side of the table to see where each route table belongs. Focus on the default route table and your VPC's route table.
Let's investigate. Select one of the two route tables and select the Routes tab.
Uncheck that route table, and switch to the other route table.
Select the Routes tab again.
Aha, the two tables have different routes!

Why do I have two route tables? What do they do?

As you might guess, one of your route tables was created with your AWS account's default VPC! This is a route table with two routes inside:

Let's decode the routes inside this table:

Route 0.0.0.0/0 | igw- directs traffic to the default internet gateway.
Route 172.31.0.0/16 | local manages internal traffic within the VPC.
- Note that the CIDR block might not be 172.31.0.0/16 exactly for your unique default route table, and that's totally okay!
- The important part is that the CIDR block in the route e.g. 172.31.0.0/16 is the entire IP address space allocated to your default VPC. This means this route applies to all traffic that is bound for another resource within the VPC.
- The target being local means the traffic should be routed to the correct resource inside the VPC.

AWS also created the other route table automatically when you set up NextWork VPC.

This route table has a single route that allows traffic within the 10.0.0.0/16 CIDR block to flow within the network.
There is no route with an internet gateway as the target! This means there is no route for traffic to leave your VPC.

💡 So what do the destination and target columns mean in a route table?

Destination: The IP address range that traffic wants to reach.
Target: The road or path that the traffic will have to take to get to its destination.
- igw-xxxxxx: Means the traffic is routed to the internet via the Internet Gateway.
- local: Means the traffic stays within the VPC, allowing internal communication between resources.

Let's rename your NextWork VPC route table so it's easier to recognise.
Make sure you have your NextWork VPC route table selected - this is the route table with a single route to 10.0.0.0/16.
Select the pencil icon in the Name column of your route table.
Enter the name NextWork route table.
Select Save.

Select the Routes tab.
Choose Edit routes.
Choose Add route near the bottom of the page.

Destination: 0.0.0.0/0

Why is the destination 0.0.0.0/0?

0.0.0.0/0 means all IPv4 addresses! When you set 0.0.0.0/0 as the destination in a route table, you are creating a default route that sends any traffic that doesn't match more specific routes on your route table.

In your case, since the the only other route has a destination of 10.0.0.0/16, this means all traffic that is not bound for another resource within your VPC is bound for the internet gateway!

The internet gateway then forwards this traffic to the internet, allowing your resources to communicate with external networks and users.

Extra for Experts: Routing rules are evaluated from the most restrictive (i.e. destinations with the bigger number after the slash) through to the least restrictive (which is 0.0.0.0/0 since it refers to all IPv4 addresses). This means your route table will first try to send traffic within the VPC if the destination falls within the VPC's CIDR block, otherwise it is send to the Internet.

Target: Internet Gateway.
Select NextWork IG.

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

Ayyy nice! Your subnet is now public because it is connected to the Internet via the internet gateway!

Create a security group

In this task, let's add a security group so that users can access resources in your VPC.

In this step, get ready to:

Create a security group.

Note that we won't be creating EC2 instance in this project, but we're adding it to this diagram to illustrate a security group's scope!

What is a security group?

If VPCs are cities and subnets are neighbourhoods, a security group is a security checkpoint, or security guard, at the entrance for each building (resource) in that neighbourhood (subnet).

Every resource must be associated with a security group. This means security groups don't attach to a VPC or a subnet, they attach to a specific resource within that VPC/subnet. If you don't specify a security group when you launch a resource, it will use the default security group that AWS creates whenever you set up a VPC.

Security groups are responsible for checking who comes in and out. They have strict rules about what kind of traffic can enter or leave the resource based on its IP address, protocols and port numbers.

💡 Protocols and port numbers? What do they mean?

Protocols: With VPCs as our city and every resource as a building, think of protocols as different vehicles, like buses, taxis and trucks, to deliver data in different ways. Protocols are special rules that help data move across the internet, each designed to send data for a specific kind of task. Here are some protocols you might come across:
- HTTP (Hypertext Transfer Protocol): This is the standard protocol for sending web pages over the internet. Just like buses carry passengers, HTTP carries web page data to your browser. Most website links start with HTTP, for example, http://www.nextwork.org/.
- SMTP (Simple Mail Transfer Protocol): SMTP is the standard protocol used for sending emails across the Internet! It acts as a mailman, ensuring that your email reaches the correct inbox without errors.
- FTP (File Transfer Protocol): FTP is like a delivery truck that is used for transporting large loads of files between computers on a network. It's a popular tool for uploading and downloading bulky items to and from servers, and developers often use FTP to upload website files directly to a hosting server from their local computers.
- SSH (Secure Shell Protocol): SSH is like a secure, private car that allows encrypted communication directly with a server for private tasks such as managing software or configuring settings. In AWS and other cloud environments, SSH is widely used for securely accessing and managing virtual servers like EC2 instances! You'll eventually come across SSH in more advanced projects.
Port numbers: Think of port numbers as specific doors on a building where data will enter or exit. Each door is designed for a specific protocol, helping servers (i.e. EC2 instances) direct incoming and outgoing traffic to the right application/process to process that protocol. Without port numbers, an EC2 instance would struggle to manage incoming data correctly. It wouldn't know which application or service each piece of data should be directed to. Some common port numbers are:
- Port 80: for HTTP protocols delivering web pages.
- Port 25: for SMTP protocols delivering email.
- Port 21: for FTP protocols delivering files.

In the left navigation pane, choose Security groups. Note that this is further down the navigation pane than our other pages so far!

Woah! Why do we already have existing security groups?

AWS automatically creates a default security group for each new VPC, which allows all traffic between resources within the same VPC. This default rule enables secure communication between resources without exposing them to external threats!

Extra for Experts: Can you tell which security group belongs to your NextWork VPC? Click into the VPC ID of the security groups to find out!

💡 Is it free to keep this many security groups?

Yup! AWS does not charge for creating and maintaining security groups.

Choose Create security group.

Security group name: NextWork Security Group
Description: A Security Group for the NextWork VPC.
VPC: NextWork VPC
Under the Inbound rules panel, choose Add rule.

What's the difference between inbound and outbound rules?

Inbound rules control the data that can enter the resources in your security group, while outbound rules control that data that your resources can send out. In this scenario, setting up inbound rules is important for allowing users to access your public website, while outbound rules help manage how your server interacts with other parts of the internet.

Examples of inbound data: Visitors and form submissions to your website.
Examples of outbound data: Your server requests data from another service; your app sends out an email notification.

Type: HTTP
Source: Anywhere-IPv4

What is that yellow popup about?

The yellow popup in your image is a warning from AWS. AWS is concerned that the security rule you've just set, i.e. setting the source to "0.0.0.0/0", allows any IP address to access your resource.

This wide-open access can be risky, exposing your server to potential threats from any location. AWS suggests tightening your security by restricting access to only known IP addresses, which would limit who can reach your server and help keep it safe from unwanted or malicious traffic.

But, setting the inbound rule to allow HTTP traffic from "0.0.0.0/0" (meaning any IP address) is typical and necessary for public subnets, since this setting makes sure that anyone on the internet can access your public resources.

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

Wait, what about outbound rules? We only created an inbound rule.

By default, AWS security groups already allow all outbound traffic. So unless you specify otherwise, any resource associated with the security group can access and send data to any IP address - whether it's in your VPC, other VPCs (if you have the right permissions) and on the public internet!

Create a Network ACL

Nice, that's your traffic flow (route table) and basic security (security groups) sorted for your VPC!

To level up your VPC's security, let's add a network ACL i.e. network access control list.

In this step, get ready to:

Create a network ACL.

In the left navigation pane, choose Network ACLs.

What are Network ACLs?

Think of Network ACLs as traffic cops stationed at every entry and exit point of your subnet, checking each data packet against a table of ACL rules before allowing them through.

💡 Data packets? What's that?

When we talk about "traffic" moving through your VPC in AWS, we're actually talking about data packets! For example, when a user types your website's URL into their browser and presses enter, the "inbound traffic" entering your EC2 instance is actually data packets that represent your user's request to see your website.

Data packets travel across the internet or within networks, and each packet contains a piece of the data being sent, e.g the user's request, or a part of a web page or a file. Network ACLs are responsible for inspecting and managing these data packets as they enter and exit your VPC's subnets, making sure only authorized data moves in and out.

💡 What's the difference between security groups and network ACLs?

Network ACLs are used to set broad traffic rules that apply to an entire subnet. For example, blocking incoming traffic from a particular range of IP addresses or denying all outbound traffic to certain ports.
Security groups allow for more granular control, managing access to individual resource. You can specify which ports and protocols are allowed for each connected resource.

Having both is a great security practice! You can set broad restrictions at the subnet level with ACLs, and more specific limits at the resource level through security groups. This dual layer takes security to the next level as traffic must pass through multiple checks, which reduces the chances of unwanted access.

Extra for Experts: Imagine if we added extra subnets and security groups to our VPC! Note how the network ACLs work at the subnet level, while security groups work at the resource level.

Oooo existing ACLs!

Why are there ACLs in my account already?

AWS sets up a default network ACL for every VPC in your account. This default is designed to allow all traffic to move freely until you decide to customize the rules to fit your needs.

Choose the network ACL that's associated with your Public 1 subnet, and check out the tabs for Inbound rules and Outbound rules.

What do the rules under the Inbound and Outbound rules tabs mean?

Just like security groups, network ACLs use inbound and outbound rules to decide which data packets are allowed to enter or leave subnets:

Rule 100 Inbound allows all inbound traffic into the Public Subnet.
Rule 100 Outbound allows all traffic out of the Public Subnet.
The second line in each ruleset shows an asterisk (*) that acts as a catch-all rule in case traffic does not match any of the earlier rules. In our case, since Rule 100 already allows all traffic, the asterisk rule won't actually come into play.

This means default network ACLs allow all inbound and outbound traffic, unless customized.

To solidify our learnings, let's recreate this set up ourselves in the console! Your default ACL has everything we need, but it's great practice to set up everything from scratch.

Select Create new network ACL.
Name: NextWork Network ACL
VPC: NextWork VPC
Select Create network ACL.

Uncheck the default network ACL you've selected.
Select the checkbox next to NextWork Network ACL
Select the Inbound rules tab.

There is only one rule that denies all traffic!

Good spotting! The default network ACLs that AWS creates allow all inbound and outbound traffic. But for custom network ACLs that we create, all inbound and outbound traffic are denied until you add rules about the kind of traffic you'll allow.

Select Edit inbound rules.
Select Add new rule.
Rule number: 100

Why is 100 the rule number?

In network ACLs, rule numbers decide the order that rules are checked - lower numbers go first. Starting at 100 gives you room to add new rules before it if you need to. For example, if you you later want to block a specific protocol, you can slip in a rule with a lower number to make sure it gets checked first. Otherwise, it's standard to start from 100 and add rules with higher numbers.

Type: All traffic.

Why did the Protocol and Port range fields grey out?

When you selected "All traffic" for the traffic type, this choice implies that your rule will apply to all protocols and port ranges, so there's no need to specify them anymore. Easy as!

Source: 0.0.0.0/0

Click Save changes.

✋ Challenge: Do you think you could set up the same for your Network ACL's outbound rules?

👇 Here are the steps again if you get stuck!

Select the Outbound rules tab.
Select Edit outbound rules.
Select Add new rule.
Rule number: 100
Type: All traffic.
Destination: 0.0.0.0/0

Hmmmm... are we finished?

Select the Subnet associations tab, which should be right next to the Outbound rules tab.
Aha, we're not finished. The subnet associations tab is empty!

What does an empty subnet associations tab mean?

Just like attaching internet gateways to VPCs, you need to associate network ACLs with subnets.

If your network ACL isn't associated with any subnets, all the rules you define won't affect your VPC's traffic. Your network ACL isn't actually securing your network!

Under the Subnet associations tab, select Edit subnet associations.

Select your Public 1 subnet.
Select Save changes.

My subnet already has an ACL, can I associate another?

Only one ACL can be associated with a subnet at a time. Once you associate your Public 1 subnet with a new ACL, the default ACL that AWS created for you gets replaced.

Now check: do you have an Allow rule for both your inbound and outbound rules? Do you have a subnet association to Public 1?

Fantastic! You've done an incredible job setting up a functioning VPC. Adding a route table, security group and network ACL is a great move for controlling security and traffic flow.

As a bonus, here's a recap of your VPC set up. If you were to set up an EC2 instance and host a web app in a public subnet:

💻 Client/User: A user enters the URL of your website into their web browser and hits enter.
🚪 Internet Gateway: The request is sent from the user's browser through the internet and reaches your internet gateway, NextWork IG.
🌐 VPC: The internet gateway forwards the user's request to the VPC it's attached to, NextWork VPC.
🚏 Route Table: Your VPC has a route table for your public subnet (called NextWork route table), which directs traffic to your EC2 instance hosting the website. The user's request get put on the local route in the route table.
📋 Network ACL: While en route to your EC2 instance, the request has to pass through the network ACL associated with your public subnet. The network ACL has an inbound rule (rule 100) that lets in traffic from anywhere (0.0.0.0/0), so your request is let through.
🥅 Public Subnet: The request enters your public subnet Public 1 and travels to your EC2 instance within the subnet.
👮‍♀️ Security Group: The request reaches the security group NextWork Security Group attached to the EC2 instance. The security group has an inbound rule that allows HTTP traffic (Port 80) from anywhere (0.0.0.0/0), so the request can pass through.
😮‍💨 EC2 Instance: The request reaches your EC2 instance hosting the website. The web server on the EC2 instance processes the request and prepares the response.
💻 Data gets sent back: Website content is sent back to the user. The outbound traffic goes through the security group, public subnet, network ACL, route table, VPC, and internet gateway, and user gets to see website content load on their page.

Amazing work - that's heaps of resources that you've created.

Secret mission

Welcome to your 🤫 exclusive 🤫 secret mission!

Your mission, should you choose to accept it, is to use EC2 Global View to gather allllll VPC resources in your account across every region.

💎 In this secret mission, get ready to:

Use the AWS CLI to create VPC resources in a new region.
Use EC2 Global View to track all your resources across every region.
Showcase your secret mission in your project documentation.

Track VPC resources across regions

Delete Your Resources

Important

Deleting resources that are not actively being used stops you getting charged and is a best practice. Not deleting your resources will result in charges to your account.

👀 Do you have time for another project today?

Yep, let's go!

Note

You don't need to delete your resources if you're doing the next project in this series today.

Get your documentation and head straight to the next project!

Nope, not today.

Before you read the steps on deleting your resources, do you think you can challenge yourself to try delete everything in this project without any guidance?

Keeping track of your resources, and deleting them at the end, is absolutely a skill that will help you reduce waste in your account.

Delete VPC:

In your VPC console, select the checkbox next to NextWork VPC.
Select the Actions dropdown.
Select Delete VPC.
- Note down the VPC ID of the VPC you are deleting - you might need this when deleting the other resources!

Now visit each of the pages below! Refresh your the page before checking if the resource you created today is still in your account. They should be automatically deleted with your VPC, but it's always a good idea to check anyway:

Subnets
Route tables
Internet gateways
Network ACLs
Security groups

Nice Work!

AYYYY

THAT'S NETWORKING PROJECT TWO...

DONE!!!!! 🥳

Today you've learnt how to:

🚏 Set up route tables: You configured a route table in your VPC to send Internet-bound traffic to your internet gateway, turning your subnet into a public subnet.
👮‍♀️ Implement security groups: You created a security group to control inbound and outbound traffic at a resource level, specifying allowed IP addresses, protocols, and ports.
📋 Deploy network ACLs: You set up network ACLs as an additional layer of security, managing both incoming and outgoing traffic at the subnet level.

Ready to quiz yourself? You got this! 💪

It's wild that all these learnings are packed in one project.

Keep it up in the next project of this series on Creating a Private Subnet!

p.s. Does it say "Still tasks to complete!" at the bottom of the screen?

This means you still have screenshots left to upload, or questions left to answer!

Press Ctrl+F (Windows) or Command+F (Mac) on your keyboard.
Search for the text Return to later.
Jump straight to your incomplete tasks!
🙋‍♀️ Still stuck? Ask the community!