Creating a Private Subnet

Let's set up a private section in your VPC!

Introduction

⚡️ 30 second Summary

Welcome to your third AWS networking project!

In your first two networking projects, you've created:

☁️ An Amazon VPC (amazing!)
🥅 A public subnet (woohoo!)
🚪 An internet gateway (go you!)
🚏 A route table (so good!)
👮‍♀️ A security group (say whaaat!)
📋 A Network ACL, aka Network Access Control List (super cool!)

If you haven't done the previous project in our networking series, VPC Traffic Flow and Security), we'd highly recommend doing that first. This project starts right where the previous one leaves off.

In Creating a Private Subnet, we're going to level up by creating a private subnet in your VPC - you'll learn all about this in a minute!

Get ready to:

🚷 Create a private subnet.
🚧 Create a private route table.
🚔 Create a private network ACL.

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're repeating our steps from the first two networking projects to set up our VPC, subnet, internet gateway, route table, security group and network ACLs.

What a list, you're going to crush it!

In this step, get ready to:

Create a VPC.
Create subnets.
Create an internet gateway.
Create a route table.
Create a security group.
Create a network ACLs.

Have you completed the previous projects 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.
Create a route table.
Create a security group.
Create a network ACLs.

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:

Off we go! Your VPC is the foundation of this project and represents your corner of the AWS Cloud.

Log in to your AWS Account.
In your AWS Management Console's search bar, search for VPC.
Select VPC from the drop down menu.
In the left navigation pane, choose Your VPCs.
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 a CIDR block?

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

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 CIDR block ranges 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, allowing for a much larger number of varying bits - this 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. Subnets are subdivisions within your VPC where you can launch AWS resources, think of them as suburbs/neighbourhoods within your city.

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 subnet a public subnet now?

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:
Create an internet gateway:

Time to connect our VPC to the internet! Let's create 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 also become accessible to users, so any application you host on those instances become public too.

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 the left navigation pane, choose Route tables.
Refresh your page.
Ooo, two route tables!
Check out the Routes tab for both, and note that they 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 the route table with two routes inside. 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.

Select the checkbox next to your NextWork VPC's default route table - 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 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.

Target: Internet Gateway.
Select the only Internet Gateway id option.
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.

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

What is a security group?

A security group controls which traffic can enter or leave a resource based on its IP address, protocols and port numbers.

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.

In the left navigation pane, choose 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.

Examples of inbound data: Visitors to your website hosted on an EC2 instance in a public subnet, your website receives form submissions.
Examples of outbound data: Your server requests data from another service, sends out an email notification.

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

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 the left navigation pane, choose Network ACLs.

What are Network ACLs?

Think of Network ACLs as community guards 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.

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.

Name: NextWork Network ACL
VPC: NextWork VPC
Select Create network ACL.
Select the checkbox next to your NextWork Network ACL
Select the Inbound rules tab.

There is only one rule that denies all traffic! I thought all inbound and outbound traffic are allowed by default?

Good spotting! The default network ACLs that AWS creates for us 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 to specify that kind of traffic you'll allow.

Select Edit inbound rules.
Select Add new rule.
Rule number: 100
Type: All traffic.
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.
Source: 0.0.0.0/0

Switch tabs from Outbound rules to the Subnet associations tab.
Select Edit subnet associations.
Select your Public 1 subnet.
Select Save changes.

Fantastic! You've done an incredible job setting up a functioning VPC.

Now let's dive into what's next for your VPC. 🤿

Set up a private subnet

We've learnt about subnets and even created a public subnet that's connected to the internet.

But what about resources that we want to keep private?

For example, it's very common for engineers to set up an EC2 instance hosting their web app in a public subnet, but keep the database of customers and login details in a private subnet.

Let's set up your very first private subnet and learn its differences from a public subnet along the way.

In this step, get ready to:

Set up a private subnet.

Still in your VPC console, select the Subnets tab again.

Select Create subnet.
For the VPC ID, select NextWork VPC.
Set the Subnet name as NextWork Private Subnet
For the subnet's Availability Zone, use the second AZ on the dropdown (not the first!)
The IPv4 VPC CIDR block is already pre-set to 10.0.0.0/16
For the IPv4 subnet CIDR block, what do you think will happen if this new subnet has the exact same CIDR block as your Public subnet?
Let's investigate by entering 10.0.0.0/24 to start with.
Select Create subnet.
Aha! An error message.

What does this error message mean?

The error message says: CIDR Address overlaps with existing Subnet CIDR: 10.0.0.0/24. This error pops up when the CIDR block you're trying to assign to a new subnet is already being used by another subnet in the same VPC.

Imagine if you were to build a new suburb in your city with the exact same set of street names and post codes as another suburb. Navigation would become very confusing - some addresses in your city would have two possible locations!

For the same reason, every subnet in a VPC must have a unique CIDR block so traffic is routed correctly and there are no conflicts.

How would you fix this error?
Let's assign your new subnet a CIDR block that doesn't overlap with Public 1.
Replace the IPv4 subnet CIDR block with 10.0.1.0/24

How does this new CIDR block not overlap with Public 1's CIDR block?

By setting the CIDR block of your new private subnet to 10.0.1.0/24, you allocate a specific range of IP addresses from 10.0.1.0 to10.0.1.255.

The Public 1 subnet is defined with the CIDR block 10.0.0.0/24, which is a different range of IP addresses from 10.0.0.0 to 10.0.0.255.

Notice the small difference between these CIDR blocks - your private subnet's CIDR block is 10.0.1.0/24, whereas the public subnet's CIDR block is 10.0.0.0/24. That's what keeps each range complete separate from each other!

Select Create subnet.
Success!
To tidy up your subnets' naming conventions, let's retitle your Public 1 subnet to NextWork Public Subnet

Set up a private route table

Like your public subnet, a private subnet also needs to be associated with a route table.

In this step, get ready to:

Create a private route table.

Head to the Route tables page in your console.

Why are we revisiting the Route tables page?

Back when you set up NextWork route table, you renamed the default route table that AWS automatically created with your VPC.

This means NextWork route table is the default route table for your entire VPC. Subnets that aren't associated with another route table automatically use NextWork route table.

Should your private subnet use the same route table as your public subnet?

Probably not! NextWork route table has a route to an internet gateway, and having that route would make your subnet public! It's time to set up a new route table for your private subnet.

Select Create route table.
Name your new route table NextWork Private Route Table
Under VPC, select NextWork VPC.
Select Create route table.

Nice! With your private route table set up, let's make sure it can only direct traffic to another internal resource (instead of the public internet).
Select NextWork Private Route Table.
Check the Routes tab - does it only have one default route with a local target?

Switch tabs to Subnet associations.
Select Edit subnet associations under the Explicit subnet associations tab.
Select the checkbox next to NextWork Private Subnet.
Select Save associations.

To tidy up your Route tables' naming conventions, let's also retitle NextWork route table to NextWork Public Route Table

Set up a private network ACL

Your private subnet is set up!

A dedicated route table is all done too!

Now to round things off, let's set up a new network ACL.

In this step, get ready to:

Set up a private network ACL.

Select Network ACLs from the left hand navigation panel.
Select the checkbox next to the default ACL for your VPC.
- Note that this is NOT NextWork Network ACL - your default ACL isn't named!
Select the Inbound rules and Outbound rules tabs.

Why are we reviewing our default network ACL?

It's a very similar scenario to the route tables!

You might recall that there is a default network ACL set up for every VPC. This default network ACL is associated with your private subnet, since you haven't set up an explicit association between your private subnet and another network ACL.

A VPC's default network ACL allows all traffic, which exposes your private subnet to unrestricted access from the internet or other untrusted networks. Let's set up a new network ACL that restricts traffic and protects your private subnet!

💡 We've already removed the route to an internet gateway. Isn't that enough to prevent traffic from the internet?

Ooo great catch! Removing a route to the internet gateway does prevent direct internet access to and from the subnet. However, relying only on route table configurations might not be great for security.

If any part of your VPC (e.g. your public subnet) gets compromised, the attacker could take advantage of your permissive ACL setup to access or attack the resources in your private subnet!

So while the default ACL is very convenient in allowing all traffic types, we'll create a new custom network ACL to keep our private subnet safe.
Select Create network ACL on the top right.
For the name, enter NextWork Private NACL.
Select NextWork VPC.
Select Create network ACL.
Done!
Observe the Inbound rules and Outbound rules tabs for your private network ACL.

Why are they both denying all traffic?

Remember that custom network ACLs start with denying all inbound and outbound traffic! We'll leave these settings for now - let's customise them later in this project series, when we know exactly which traffic source we're wanting to allow.

Switch tabs to Subnet associations.
Select Edit subnet associations.
Select your private subnet.
Select Save changes.

To tidy up your Network ACLs' naming conventions, let's also rename NextWork Network ACL to NextWork Public NACL

All done! Your private subnet is set up and ready to goooooo.

What about security groups?

Remember how security groups are set at the resource level? This means you won't need to create security groups until there is a specific resource e.g. EC2 instance you're launching in your subnet! We'll be setting up security groups in an alternative way later in this series...

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!

THAT'S NETWORKING PROJECT THREE...

DONE!!!!! 🥳

Today you've learnt how to:

🚷 Create a private subnet: You created a new subnet and set its CIDR block to avoid an overlap with your public subnet.
🚧 Create a private route table: You also made this subnet private by assigning it to a dedicated route table that doesn't route traffic to an internet gateway!
🚔 Create a private network ACL: Then, you set up custom network ACLs to control inbound and outbound traffic for this private subnet - denying all traffic by default.

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 Launching VPC Resources!

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!