Launching VPC Resources

Ready... Set... Launch!

Introduction

⚡️ 30 second Summary

Welcome to your fourth AWS networking project!

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

☁️ An Amazon VPC (amazing!)
🥅 A public subnet (woohoo!)
🚪 An internet gateway (hot damn!)
🚏 A route table (so good!)
👮‍♀️ A security group (say whaaat!)
📋 A Network ACL, aka Network Access Control List (super cool!)
🚷 Create a private subnet (no way!)
🚧 Create a private route table (you superstar!)
🚔 Create a private network ACL (that's huuuuuuuuuuuge!)

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

In this project, Launching VPC Resources, we're going to level up by launching resources into our VPC - you'll also learn some handy EC2 concepts along the way!

Get ready to:

💻 Launch an EC2 instance in your public subnet.
🤐 Launch an EC2 instance in your private subnet.
⚡️ Use the Amazon VPC's wizard to create VPCs at a lightning fast pace.

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 three networking projects to set up our VPC, subnet, internet gateway, route table, security group, network ACLs and private resources too.

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.
Create private resources.

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

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.
Create a private subnet.
Create a dedicated route table for your private subnet.
Create a dedicated network ACL your private subnet.

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
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/neighborhoods 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
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.
Choose Save.

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.

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.

For the Target, select 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

A security group controls which traffic can enter or leave a resource based on its IP address, protocols and port numbers. Security groups don't attach to a VPC or a subnet, they attach to a specific resource within that VPC/subnet.

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!

In the left navigation pane, choose Security groups.
Choose Create security group.
Security group name: NextWork Public Security Group
Description: A Security Group for the NextWork VPC Public Subnet
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 the 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. 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.

In the left navigation pane, choose Network ACLs.
Choose the network ACLs that's associated with your Public 1 subnet, and rename it to NextWork Network ACL

Select the Inbound rules and Outbound rules tabs.

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.

Create a Private Subnet

We've just created a public subnet that's connected to the internet.

But what about resources that we want to keep private?

Let's set up your 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, enter 10.0.1.0/24
Select Create subnet.

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

Create a Dedicated Route Table for your Private Subnet

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

Head to the Route tables page in your console.
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).
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

Create a Dedicated Network ACL for your Private Subnet

The default network ACL associated with your private subnet 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!

Select Network ACLs from the left hand navigation panel.
Select Create network ACL on the top right.
For the name, enter NextWork Private NACL
Select NextWork VPC.
Select Create network ACL.
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 networking 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 in just a second...

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

Now let's dive into what's next for your network - it's time to see your VPC in action. 🤿

Launch a Public EC2 Instance

Let's kick things off by launching an EC2 instance in your public subnet.

In this step, get ready to:

Create a new EC2 instance (new AWS service alert!)
Find a way for you to access your EC2 instance (so many cool learnings here!)
Put your EC2 instance in you VPC (let's get your VPC to WORK 👏)

Head to the EC2 console - search for EC2 in the search bar at the top of screen.

Select Instances at the left hand navigation bar.

Select Launch instances.
Since your first EC2 instance will be launched in the public subnet, let's name it NextWork Public Server
For the Amazon Machine Image, select Amazon Linux 2023 AMI.
For the Instance type, select t2.micro.

What is AMI?

When you buy a new computer off the shelf, most computers already have some software and the operating system (e.g. MacOS, Windows) already configured and set up for you!

AMI stands for Amazon Machine Image, and it's very similar to those pre-built computers. An AMI is a template or blueprint used to create EC2 instances and contains the operating system along with the applications needed to launch the instance.

💡 What is instance type?

If AMIs give you pre-built software and operating systems, instance types cover the 'hardware' components.

CPU power, memory size, storage space and more!

So, while the AMI decides what operating system your server runs, the instance type determines how fast and powerful it performs.

For the Key pair (login) panel, select Create new key pair.

What is a key pair? Why do we need one?

Key pairs help engineers directly access their virtual machines, like EC2 instances.

How key pairs work is that they consist of two cryptographic keys: one private and one public. The public key is installed on the virtual machine, and the private key remains with the user. When you attempt to connect, the machine uses the public key to create an encrypted challenge that can only be decrypted with the private key. Key pairs make sure that access to your EC2 instances is secure and authenticated.

💡 Directly access a virtual machine? What does that mean?

Directly accessing a virtual machine means logging into and managing the operating system or software of the machine as if you were using it in front of you, but over the internet.

The AWS Management Console gives you a user-friendly interface to set up and manage AWS resources (we love it), but it doesn't typically provide direct access to the operating systems of your EC2 instances. For operations that require direct OS-level access, like installing software, editing configuration files, or running scripts, you'd use your key pair to connect directly. This method of access is essential for deeper administrative tasks or specific kinds of troubleshooting that can't be performed through the console.

In this project, we're learning to directly access your public server. You'll need this to run connectivity tests on your server's terminal in the next project of this series.

💡 Psstt... just so you know 👀

We're later going to use an EC2 tool that lets us get direct access to your EC2 instance without having to create your own key pair. Buttttt we're creating one in this step so you can learn about key pairs!

For the Key pair name, use NextWork key pair
Keep the Key pair type as RSA, and the Private key file format as .pem

What is a key pair type? Why do we pick RSA?

The key pair type determines the algorithm used for generating the key pair's cryptographic keys.

We use RSA (Rivest-Shamir-Adleman), which is one of the most common cryptographic algorithms used due to its strength and security. RSA is widely supported and trusted for creating digital signatures and encrypting data.

💡 What is a Private key file format? Why do we pick .pem?

Just like how documents can be saved in various file formats like PDF, DOCX, or TXT, each suited for different applications or systems, private keys also come in different file formats. Not every system or application can process all these formats, so choosing the right one is crucial.

The .pem format, which stands for Privacy Enhanced Mail, started off as a way to secure emails but has since become the go-to format for managing cryptographic keys because it is supported by many different types of servers e.g. EC2 instances!

Select Create key pair.

Woah something started downloading straight away! What was that file? Do I need to keep it?

The file that started downloading is the private key (.pem) i.e. your half of the new key pair! It's usually very important to save it securely. Losing this file means losing the ability to securely access your instances, and it cannot be downloaded again from AWS. But, for this project we're using a simpler technique to access your EC2 instance that doesn't need this .pem key, so it's safe to delete and you can always generate a new key pair for your next project.

At the Network settings panel, select Edit at the right hand corner.

Why are we editing the Network settings?

By default, all resources are launched into the default VPC that AWS has set up for your account. We need to tell AWS that we actually want to launch this instance in NextWork VPC and the NextWork Public Subnet!

Select NextWork VPC from the drop-down in the VPC list.
Select your public subnet.
For the Firewall (security groups), we've already created the security group for your public subnet's resources. Choose Select existing security group.
Select NextWork Public Security Group.

Select Launch instance.
Click into your instance once it's successfully launched.

Head back to the Instances page.
Select the checkbox next to your instance, and a Details panel pops up!
Switch the tab to Networking.
Notice how your public server has a Public IPv4 address, a subnet it's associated with, an Availability zone it's launched in, and a VPC ID that links it with NextWork VPC too.

What do all this information mean?

As a quick recap:

The Availability Zone is the specific area within your AWS Region that your instance is hosted.
The VPC ID identifies that within the AWS Region you're using, the Public Server belongs in your NextWork VPC.
The NextWork Public Subnet determines the range of IP addresses within NextWork VPC that can be assigned to your EC2 instance. Because this subnet has a route to an internet gateway, your VPC has opened up communication between all resources in the subnet and the internet.
The Public IPv4 address is the external IP address assigned to your EC2 instance. This address is globally unique, so no other server has the same public IPv4 address on the internet! Having a public IPv4 address means your instance can communicate with the internet and be accessible from outside your private AWS network.

Launch a Private EC2 Instance

Let's follow similar steps to launch your private server!

In this step, get ready to:

Launch another EC2 instance (practice makes perfect!)
Protect your EC2 instance (love this step!)
Set up a way for your EC2 instances to speak to each other (huuuuge!)

Select Launch instances again.
Name: NextWork Private Server
Amazon Machine Image (AMI): Amazon Linux 2023 AMI
Instance type: t2.micro
Key pair: NextWork key pair

I can use the same key pair between multiple instances?

Yup, you can use the same key pair for more than one EC2 instance! This means you can use the same private key (i.e. the .pem file) to log into any of your instances using this key pair, making it easier to manage.

From a security point of view, anyone with that key can access all the instances it's connected to - making it even more important to keep your private key safe.

At the Network settings panel, select Edit at the right hand corner.
Network: NextWork VPC
Subnet: NextWork Private Subnet
Firewall (security groups): we said we'd use an alternative way to set up security groups for your private subnet's resources, and here we are!
- Select Create security group.
- For Security group name, let's use NextWork Private Security Group
- For Description, we'll replace the default value with Security group for NextWork Private Subnet.
- Notice the default Inbound Security Groups, the Type is set to ssh.

What is SSH?

Remember how we created a new key pair to get direct access to our EC2 instance? SSH, or Secure Shell, is the protocol we use for this secure access to a remote machine. When you connect to the instance, SSH verifies you possess the correct private key corresponding to the public key on the server, ensuring only authorized users can access the instance.

In terms of network communication, SSH is also as a type of network traffic. Once SSH has established a secure connection between you and the EC2 instance, all data transmitted (including your commands and the responses from the instance) is encrypted. This encryption makes SSH an ideal method for securely exchanging confidential data e.g. login credentials!

💡 How common is it for developers to use SSH?

SSH is extremely common and is the standard way for developers to securely log in from their computer to another remote computer (e.g., an EC2 instance).

More and more organizations try to reduce the use of SSH and prefer infrastructure as code (IaC) and automated deployments to reduce the need for direct access (and minimize human error and security risks), but SSH access is still essential for many administrative, testing, and troubleshooting scenarios. For example, developers today use SSH to troubleshoot a live issue, perform manual updates, or configure system settings that are not easily automated.

💡 What is this yellow banner saying?

This popup says "Rules with source of 0.0.0.0/0 allow all IP addresses to access your instance. We recommend setting security group rules to allow access from known IP addresses only."

AWS is concerned that the default security rule, i.e. with the source being 0.0.0.0/0, allows any IP address to access your resource using SSH.

We were okay with allowing HTTP traffic from 0.0.0.0/0 for our public subnet, but the private subnet is a different story!

Change the Source type from Anywhere to Custom.
In the Source drop down, scroll down and select NextWork Public Security Group.

What does it mean to select NextWork Public Security Group instead of Anywhere as our source?

Choosing the NextWork Public Security Group as the source means only resources that are part of the NextWork Public Security Group can communicate with your instance. This restricts access to a much smaller group of trusted resources, rather than allowing potentially any IP address on the internet (0.0.0.0/0) to access your instance. A great move for securing a private subnet!

Select Launch instance.

Congratulations!! That was a massive effort in getting your private and public subnets warmed up with an EC2 instance in each.

Launch your VPC setup in minutes

We'll come back to your VPC setup in the next project, and in the meantime... are you ready to level up your VPC creation skills?

In this step, get ready to:

Create your entire VPC setup in a new way (it's a time saver 🥳)

Head back to your VPC console.
From the left hand navigation bar, select Your VPCs.
Select Create VPC.
We previously stuck to creating a VPC only, but this time select VPC and more.
Woah! A visual flow diagram pops up that shows us other VPC resources. This is called a VPC resource map!

Wow, what's going on in this resource map?

With VPC resource map, you can quickly understand the architectural layout of a VPC, like the number of subnets, which subnets are associated with which route table, and which route tables have routes to an internet gateway.

Fun fact: The VPC resource map is a pretty new feature that just launched in Feb 2023!

Now with this handy VPC resource map, you get to see that selecting the VPC and more option will also help you create VPC resources in the exact same page. No more jumping between pages in your VPC console!

Scroll to view the entire VPC resource map, and take note of the resources listed.
See if you can answer these questions:
1. How many subnets are being created in your VPC?
2. How many of those subnets are public, how many are private?
3. How many route tables are being created in your VPC? Why?
4. Is there an internet gateway being created?

Here are the answers!
- There are 4 subnets being created.
- 2 of those subnets are public, 2 are private.
- There are 3 route tables being created - 1 for both public subnets to share, and 1 for each private subnet.
- There is an internet gateway being created - you can spot it under the fourth panel, Network connections!

Why are resource maps helpful?

Resource maps help you understand how different components in your setup are connected and interact with each other. This makes it easier to design, manage, and troubleshoot your architecture because you can see everything at a glance, rather than sifting through lists and configurations.

Our resource map looks straightforward since we have a nice and simple VPC architecture, but imagine how useful this tool would be for complex VPC setups with many subnets!

Scroll back to the left hand side of the screen to see the VPC's set up.
Under Name tag auto-generation, enter nextwork

What does name tag auto-generation do?

Name tag auto-generation is a nifty feature that tags all your VPC resources with a name based on what you enter.

If you type in nextwork, all your resources will have that in their name tags, making it super easy to track and manage everything linked to your VPC. You'll see this in action soon!

The VPC's IPv4 CIDR block is already pre-filled to 10.0.0.0/16

Doesn't my NextWork VPC already have that CIDR block, how could they share the same CIDR block?

Actually, you can have multiple VPCs with the same IPv4 CIDR block in the same AWS region and account. AWS VPCs are isolated from each other by default, so there won't be any IP conflicts unless you explicitly connect them using VPC peering (which you'll learn more about later in this networking project series).

Bottom line, it's possible for your new VPC to share the same CIDR block as an existing one, but this set up will mean your overlapping VPCs can't talk to each other directly. That's why it'd be best practice to have completely unique CIDR blocks for each VPC in your account!

💡 How is it that subnets can't have overlapping CIDR blocks, but VPCs can?

Great question! VPCs are isolated networks within AWS, meaning they don’t interact with each other unless you explicitly set up connectivity between them.

On the other hand, subnets within a VPC are part of the same network and can directly communicate with each other. Overlapping CIDR blocks within a VPC would create IP address conflicts, making it impossible to route traffic correctly. So, subnets need unique CIDR blocks to ensure smooth internal networking.

For IPv6 CIDR block, we'll leave in the default option of No IPv6 CIDR block.

What is an IPv6 CIDR block, why don't we need one?

IPv6 is the latest version of IP addresses with a lot more IP addresses than IPv4. If you’re mostly working with IPv4, you can skip IPv6 for now to keep things simple. You usually don't need IPv6 unless your applications or users specifically need it.

Fun fact: IPv4 has about 4.3 billion possible addresses, while IPv6 has around 340 undecillion addresses – that's a number with 36 zeros!

For Tenancy, we'll keep the selection of Default.

What does tenancy mean?

Tenancy in AWS refers to the type of hardware your instances run on. You have two main options:

Default: Your instances share hardware with other AWS customers. This is the standard option and is cost-effective because you’re sharing resources.
Dedicated: Your instances run on hardware that's dedicated to you only. For example, imagine a healthcare company that needs to ensure the highest level of security for patient data. They might choose dedicated tenancy to make sure their servers are completely isolated from other customers, helping them meet compliance standards and keep sensitive information secure. Dedicated does come at a higher cost!

For Number of Availability Zones (AZs), we'll leave the default value of 2 for now and come back to this soon.
Expand the Customize AZs arrow. Ooo you can even configure which two Availability Zones you'd like to set up for this VPC!

Next, notice that Number of public subnets only gives you two options - 0 or 2.

Why can't I create just one public subnet?

This is AWS' best practice advice at work! When you pick 2 Availability Zones, the wizard makes sure you have a public subnet in each one. This way, your public resources stay up even if one of the two Availaiblity Zones goes down.

This setup is called redundancy (having backups in different places) and high availability (making sure your resources are always accessible). Just one public subnet wouldn’t offer this kind of reliability, so AWS doesn't let you create just one!

💡 Why can't I create more than two public subnets?

The VPC wizard limits you to two public subnets to keep things straightforward. If you need more, you can always add them manually later - you can have up to 200 subnets total in a VPC!

After all, this VPC set up page’s aim is to get you up and running quickly without overwhelming you with options.

Similar to this, Number of private subnets only gives you three options - 0, 2 or 4.

How is it that we can create up to 4 private subnets, but only 2 public subnets?

AWS's best practice advice is at work again! Having more private subnets can help with organizing your resources and isolating them for security purposes, whereas public subnets are limited to ensure manageable exposure to the internet.

Try selecting the option for 4 private subnets, and watch your resource map update itself!

Why do we have 5 route tables?

In a VPC, public subnets usually share a single route table because they all need to route traffic to the internet through the same internet gateway. This simplifies management since all public subnets follow the same rules for internet access.

You can see this in action if you hover over the public route table in your resource map!

For private subnets, each one often has its own route table to control and customize traffic routing more precisely. This allows for different routing rules and security controls for each private subnet.

✋ PAUSE - what do you think will happen if you change the number of Availability Zones from 2 to 1?
Make your prediction on how this resource map will look differently...
Scroll back to the Availability Zone field, and change the selection from 2 to 1!

Why did the number of subnets and route tables change?

Changing the number of availability zones updates the number of subnets and route tables to keep things balanced and reliable. Fewer zones mean fewer resources are needed to maintain that balance and reliability.

Change the Number of private subnets from 2 to 1. Now we have just two subnets total - one public and one private subnet!
Update your public and private subnets' CIDR blocks:
- Update your public subnet CIDR block to 10.0.0.0/24
- Update your private subnet CIDR block to 10.0.1.0/24

Why do the subnets' default CIDR blocks finish in /20 by default?

Great observation! The default /20 subnet provides 4,096 IP addresses, which is a good middle ground for most use cases. Typically the norm is to use 8 /16 /24 /32:

/8: Provides 16,777,216 IP addresses (usually for very large networks, not subnets).
/16: Provides 65,536 IP addresses (often used for VPCs).
/24: Provides 256 IP addresses (commonly used for smaller subnets).
/32: Provides just one IP address (used for specific instances).
The /20 size offers a balance between too few and too many IP addresses, making it useful for most network setups without overwhelming you with an excessive number of IPs.

Next, for the NAT gateways ($) option, make sure you've selected None. As the dollar sign suggests, NAT gateways cost money!

What are NAT gateways, how are they different from internet gateways?

NAT gateways let instances in private subnets access the internet for updates and patches, while blocking inbound traffic.

For example, your private server in your private subnet might need to download security updates. By using a NAT gateway, the server can access these updates securely while remaining protected from external threats!

On the other hand, internet gateways let instances in public subnets communicate with the internet both ways i.e. both inbound and outbound traffic.

💡 Why would I use a NAT gateway? Couldn't I just set up an internet gateway with no public inbound traffic but allow outbound traffic?

Great question! Instances in public subnets using an internet gateway still need public IP addresses to communicate with the internet.

Assigning public IP addresses to your instances makes them accessible from the internet, increasing the attack surface. Even with strict security group rules, there's always a risk of misconfiguration or vulnerabilities being exploited.Private subnets are meant to keep your instances isolated from the public internet, so using public IP addresses for instances in private subnets would not be ideal.

That's where NAT gateways come in! Instances in private subnets using a NAT gateway do not need public IP addresses. The NAT gateway handles a translation to a public IP, keeping your instances' private IPs hidden.

Next, for the VPC endpoints option, select None.

What are VPC endpoints?

Normally, to access some AWS services like S3 from your VPC, your traffic would go out to the public internet.

But, VPC endpoints let you connect your VPC privately to AWS services without using the public internet. This means your data stays within the AWS network, which can improve security and reduce data transfer costs.

There are many types of VPC endpoints, and the S3 Gateway endpoint is the most common and useful one - many applications need to access S3 for storing or retrieving data after all! The endpoints for other AWS services can be added later, but this setup tool simplifies the initial setup by focusing on S3.

💡 Why does traffic to some services like S3 go out to the public internet by default?

Not all AWS resources are automatically placed inside your VPC! While your compute resources (like EC2 instances) reside within your VPC, S3 buckets and some other AWS services exist outside your VPC because they're designed to be highly available and accessible from anywhere.

That's why VPC endpoints, like the S3 Gateway endpoint, exist to create a private connection between your VPC and S3. Having a VPC endpoint means your instances can now access services like S3 directly without routing through the public internet, which makes sure your data stays within the AWS network for security.

That's your teaser on VPC endpoints, we will get into them in detail we learn about VPC peering later in this series! 👀

You can leave the DNS options checked.

What are DNS hostnames and resolution?

When you enable DNS hostnames, your EC2 instances can have human-readable names, like denzelnextwork.compute-1.amazonaws.com, instead of just numeric IP addresses. This makes it simpler to identify and connect to your instances.

When you enable DNS resolution, AWS takes care of translating these hostnames to their corresponding IP addresses so that network requests can find the correct instance. This is particularly useful in environments where IP addresses might change - hostnames can stay consistent, so references to your resource would still point to the right thing.

Select Create VPC.
Super satisfying to see this loading bar of your VPC and its resources getting created!

Select View VPC.
Select the checkbox next to nextwork-vpc.
Select the Resource map tab.

Note how name tag auto-generation, which you enabled in the set up page, is at work now - all of your VPC's resources have nextwork at the start of the name!
Within your resource map, click on your public subnet.
Oooo, now you get to see how your public subnet is connected to a public route table and your internet gateway.

Now uncheck nextwork-vpc, and select your original NextWork VPC.
Select the Resource map tab again.
Woohoo! There's a resource map for VPCs we create from scratch too.

If you'd like, take 30 seconds to visit the pages for each of your VPC's resources - you'll notice that all of these have been created for ya!
- Subnets
- Internet gateway
- Route tables
- Network ACLs

How goooood and efficient - handy for the next time we're setting up our VPC 😎

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.

In your EC2 console, select the checkboxes next to both instances.
Select the Instance state dropdown, and select Terminate instance.
Select Terminate.

In your VPC console, select the checkbox next to NextWork VPC.
Select the Actions dropdown.
Select Delete VPC.
- If you get stopped from deleting your VPC because network interfaces are still attached to your VPC - delete all the attached network interfaces first!

What is a network interface?

Network interfaces get created automatically when you launch an EC2 instance. Think of them as a component that attaches to an EC2 instance on one end and your VPC on another - so that your EC2 instance is connected to your network and can send and receive data! Network interfaces are usually deleted automatically with your EC2 instance, but on some occassions it'd be faster to delete them manually.

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

DONE!!!!! 🥳

Today you've learnt how to:

💻 Launch a public EC2 instance You launched an EC2 instance in your public subnet, set up the appropriate AMI and instance type, and configured key pairs for secure access.
🤐 Launch a private EC2 instance You launched an EC2 instance in your private subnet, created a security group within the same flow, and used the same key pair for access.
⚡️ Launch your VPC setup in minutes: You explored a new way to create VPCs and used the VPC's resource map to visualize how different components like subnets and route tables are connected.

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 Testing VPC Connectivity!

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!