VPC Traffic Flow and Security

VPC traffic flow and security control how data moves within and outside a Virtual Private Cloud. Key components include subnets, route tables, security groups, and NACLs, ensuring secure, filtered communication between resources.

Building a Virtual Private Cloud (VPC) is the first project in our networking series, and we strongly advise starting with it. This project picks up just where the last one left off!

Let's continue exploring the fundamentals of creating an Amazon Virtual Private Cloud (VPC) in VPC Traffic Flow and Security.

Prepare to:
Make a table of routes.
👮‍♀️ Establish a security group.
Make a network access control list, or ACL.

- Step 1
Configure the fundamentals of VPC.

To set up our VPC, subnet, and internet gateway, we are using the same procedures as in the first project. Come on!

Create a route table
You must still instruct the resource on your public subnet on how to access the internet, even after you have built an internet gateway and connected it to your VPC.

To route traffic from your resource to your internet gateway, you will need to set up route tables!

In your situation, any traffic that isn't bound for another resource within your VPC is bound for the internet gateway because the sole alternative route has the destination 10.0.0.0/16!

After that, the internet gateway sends this traffic to the internet, enabling communication between your resources and other networks and users.

💡 A route table: what is it?
Consider a route table to be your subnet's resources' GPS. A route table is a database of rules, or routes, that determine where the data in your network should travel, much like a GPS helps people find their way to their destination in a city.

Because the route table instructs each subnet's traffic where to send and receive data, each subnet in your VPC must be connected to it. For instance, the subnet of an EC2 instance hosting a web server (i.e., an EC2 instance) requires a route table that can determine how to route incoming traffic to the website.

💡 What connection exists between route tables and internet gateways?
A subnet is considered public when it has a route in its route table that routes internet-bound traffic to the internet gateway. This indicates that your subnet is able to connect to the internet.

- In the left navigation pane, choose Route tables.
A couple of route tables! Why are there two?

Note: If there are more than two route tables visible, they were probably put up in previous projects you worked on. To determine where each route table belongs, look to the VPC column on the far right side of the table. Pay attention to both your VPC's route table and the default one.

- 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

The destination is 0.0.0.0/0; why is that?
For all IPv4 addresses, use 0.0.0.0/0! Any traffic that doesn't match more specific routes in your route table will be sent via the default route created when you set 0.0.0.0/0 as the destination in your route table.

- 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.

Since the internet gateway has connected your subnet to the Internet, it is now public!

Step 2

Create a security group

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

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!

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

- 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.

- Type: HTTP
- Source: Anywhere-IPv4
- At the bottom of the screen, choose Create security group.

Step 3

Create a Network ACL

That's great that your VPC's traffic flow (route table) and fundamental security (security groups) are in order!

Let's add a network access control list, or ACL, to your VPC to increase its security.

- In the left navigation pane, choose Network ACLs.

Existing ACLs?

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

What are the meanings of the rules listed under the Inbound and Outbound rules tabs? Similar to security groups, network ACLs determine whether data packets are permitted to enter or exit subnets based on inbound and outgoing rules:

All incoming traffic is permitted to enter the Public Subnet under Rule 100 Inbound.

All traffic is permitted to leave the Public Subnet under Rule 100 Outbound.

Each ruleset's second line displays an asterisk (*), which serves as a catch-all rule in the event that traffic does not meet any of the preceding rules. The asterisk rule won't really apply in our situation because Rule 100 already permits all traffic.

This indicates that, unless otherwise specified, all incoming and outgoing traffic is permitted by default network ACLs.

Let's replicate this setup in the console to reinforce what we've learned! Everything we need is in your default ACL, but setting everything up from scratch is a fantastic practice.

- 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.

- Select Edit inbound rules.
- Select Add new rule.
- Rule number: 100
💡 For what reason is the rule number 100?
Rule numbers determine the sequence in which rules are checked in network ACLs; lower numbers are checked first. You can add new rules before it if necessary by starting at 100. For instance, you can include a rule with a lower number to ensure that a certain protocol is examined first if you later want to ban it. Otherwise, starting at 100 and adding rules with larger numbers is typical procedure.

- Type: All traffic.
The Protocol and Port range fields were grayed out; why?
You no longer need to specify protocols and port ranges because your rule will be applied to all of them when you choose "All traffic" as the traffic type. Simple as abc!

- Source: 0.0.0.0/0

- Click Save changes.

For the Network ACL's outbound rules?

- 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

Well, are we done yet?

- Next to the Outbound rules tab, you should see the Subnet associations tab. Click on it.

Well, we're not done yet. There is nothing on the subnet associations tab!

- Under the Subnet associations tab, select Edit subnet associations.

- Select your Public 1 subnet.

Select Save changes.

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

Wonderful! You've done a fantastic job configuring a working VPC. Adding a network ACL, security group, and route table is a smart way to manage traffic flow and security.

Here is a summary of your VPC setup as an added bonus. Setting up an EC2 instance and hosting a web application in a public subnet would entail:

💻 Client/User: A user hits enter after entering your website's URL in their browser.

🚪 Internet Gateway: The user's browser sends the request to your internet gateway, NextWork IG, via the internet.

🌐 VPC: The internet gateway sends the user's request to NextWork VPC, the VPC to which it is connected.

🚏 Route Table: Traffic is routed to your EC2 instance hosting the website via your VPC's NextWork route table for your public subnet. The user's request is added to the route table's local route.

📋 Network ACL: The request must go via the network ACL linked to your public subnet on its way to your EC2 instance. Your request is accepted because the network ACL includes an inbound rule (rule 100) that allows traffic from any location (0.0.0.0/0).

🥅 Public Subnet: The request proceeds to your EC2 instance within your public subnet, Public 1.

Security Group: NextWork Security Group, which is connected to the EC2 instance, receives the request. The request can go through because the security group contains an incoming rule that permits HTTP traffic (Port 80) from any location (0.0.0.0/0).

EC2 Instance: Your EC2 instance, which hosts the website, receives the request. The EC2 instance's web server prepares the response after processing the request.

💻 Data is returned: The user receives the content of the website. Outgoing traffic passes via the network ACL, route table, VPC, security group, public subnet, and intern

Well done!

You just finished the project for today and created your own VPC with network ACLs, security groups, and route tables.

Completed WOOOOOOOOOOOOOOO! 🙌 All hands up.