VPC, Subnet, NACL, Security Group: Create your own Network on AWS from Scratch [Part 2]

Amazon Virtual Private Cloud (Amazon VPC) enables you to launch AWS resources in a logically isolated virtual network that you have created. This virtual network closely resembles a traditional network that you’d operate in your own data centre, with the benefits of using the scalable infrastructure of AWS. Please see how to Build a Scalable VPC for Your AWS Environment [Part 1], how to Hide or Block Wi-Fi Networks on Windows, and how to Improve Website Response Using Traffic Manager.

Why You Should Create Your Own VPC?

Creating your own virtual private cloud (VPC) offers a lot of benefits within a cloud infrastructure. This allows you to design a networking architecture that aligns with your organization’s requirements. You can define subnets, configure routing tables, and implement various network configurations to optimize performance, reliability, and data flow within your virtual network.

Amongst numerous reasons to create your own VPC. With a dedicated VPC, you can isolate your resources from other users in the cloud environment. This isolation enhances the privacy and confidentiality of your data, ensuring that your resources operate independently and securely within your defined network boundaries.

Also, see Complete Guide on TestRail as a Test Management Tool, how to configure Windows LAPS, and how to Set up Veeam Backup for Microsoft Azure.

You can delete a default subnet or default VPC just as you can delete any other subnet or VPC. However, if you delete your default subnets or default VPC, you must explicitly specify a subnet in one of your VPCs when you launch instances. If you do not have another VPC, you must create a VPC with a subnet in at least one Availability Zone. If you delete your default VPC, you can create a new one. So also with the subnet.

IP Subnet Calculator

The IP Subnet Calculator performs subnet calculations for the given network address block, subnet mask, and maximum required hosts per subnet and determines the resulting broadcast address, subnet, wildcard mask and host range. Here is the Subnet calculator I found very useful.

Enter your network Address Block and let the Subnet Calculator complete the rest tasks for you. If you are good in subnetting, you can manually do this. In subsequent guides, we will visit this topic again.

The CIDR block 192.168.0.0/21 represents a block of 32 contiguous IPv4 addresses. To determine the individual CIDR blocks within this range, you can divide it further. For example, here are the eight subnets within the 192.168.0.0/21 CIDR block as shown above or below 🙂

192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
192.168.4.0/24
192.168.5.0/24
192.168.6.0/24
192.168.7.0/24
Each of these subnets includes 256 IPv4 addresses.

Create Your VPC

Navigate to AWS VPC Console and under services, search for Networking and Content Delivery.

Select VPC as shown below.

On the VPC dashboard, choose Create VPC.

Here is How to Download and Use KiTTY SSH Client on Windows, how to Enable Find My Device on Windows 11, and how to Resolve “no pg_hba.conf entry for host on PostgreSQL.

Option 1: Select VPC and more

The VPC and more options will ensure the creation of your VPC, Subnets, Route tables and Internet Gateway etc. This is not the method I wish to employ here.

Option 2: Select VPC Only

From the Create VPC Dashboard, select VPC only

Alternatively, you cal click Create VPC if you do not select create VPC on the fly from the image above. In this case, click on Your VPC and then, click Create VPC.

IPv4 VPC CIDR blocks

Note: When you create a VPC, you must specify an IPv4 CIDR block for the VPC. The allowed block size is between a /16 netmask (65,536 IP addresses) and /28 netmask (16 IP addresses). After you’ve created your VPC, you can associate additional IPv4 CIDR blocks with the VPC.

Private IPv4 addresses (also referred to as private IP addresses in this topic) are not reachable over the internet (routable). But can be used for communication between the instances in your VPC. When you launch an instance into a VPC, a primary private IP address from the IPv4 address range of the subnet is assigned to the default network interface (eth0) of the instance.

Each instance is also given a private (internal) DNS hostname that resolves to the private IP address of the instance. The hostname can be of two types: resource-based or IP-based. For more information, see EC2 instance naming. If you don’t specify a primary private IP address, AWS will select an available IP address in the subnet range for you. For more information about network interfaces, see Elastic Network Interfaces in the Amazon EC2 User Guide for Linux Instances.

Note: You can assign additional private IP addresses, known as secondary private IP addresses, to instances that are running in a VPC. Unlike a primary private IP address, you can reassign a secondary private IP address from one network interface to another. A private IP address remains associated with the network interface when the instance is stopped and restarted, and is released when the instance is terminated.

Create VPC Only

Select VPC only and populate the Create VPC field. I will not be creating an IPv6 CIDR yet. I will edit this VPC and create an IPv6 CIDR in the future. Please see IPv6 on AWS | Amazon Web Services.

Note: The IP addresses for your virtual private cloud (VPC) are represented using Classless Inter-Domain Routing (CIDR) notation. A VPC must have an associated IPv4 CIDR block. You can optionally associate additional IPv4 CIDR blocks and one or more IPv6 CIDR blocks.

Create Subnets

A subnet in your Virtual Private Cloud (VPC) defines a specific range of IP addresses. This enables you to allocate AWS resources, such as EC2 instances, within designated subnets to effectively organize and manage your network infrastructure in AWS.

When you create a subnet,. You must specify its IP addresses, depending on the configuration of the VPC:

• IPv4 only – The subnet has an IPv4 CIDR block but does not have an IPv6 CIDR block. Resources in an IPv4-only subnet must communicate over IPv4.
• Dual stack – The subnet has both an IPv4 CIDR block and an IPv6 CIDR block. The VPC must have both an IPv4 CIDR block and an IPv6 CIDR block. Resources in a dual-stack subnet can communicate over IPv4 and IPv6.
• IPv6 only – The subnet has an IPv6 CIDR block but does not have an IPv4 CIDR block. The VPC must have an IPv6 CIDR block. Resources in an IPv6-only subnet must communicate over IPv6.

Open the Amazon VPC console, and navigate to the Subnet menu. Choose Create subnet.

Populate the subnet fields as such below by selecting the VPC you have created.

Instead of clicking on “Create Subnet”. We will be clicking on “Add New Subnet”.

Note: Implementing multiple subnets across availability zones serves as a robust strategy for safeguarding our applications against downtime and failures, enhancing resilience and ensuring continuous availability.

Populate the Subnet fields as shown below.

Let’s do the same for the third (3rd) subnet as shown below.

Note: You can also add a subnet to your VPC using the AWS CLI. All desired subnets are created as shown below.

Private Subnet

If a subnet is associated with a route table that has a route to an internet gateway, it’s referred to as a public subnet.

If a subnet is associated with a route table that does not have a route to an internet gateway, this is called a private subnet. In the next article, I will be showing you all that is needed to create a Private Subnet

Create Internet Gateway

According to AWS, an internet gateway is a horizontally scaled, redundant, and highly available VPC component that allows communication between your VPC and the internet. IGW supports IPv4 and IPv6 traffic. It does not cause availability risks or bandwidth constraints on your network traffic.

Internet Gateway enables resources in your public subnets (such as EC2 instances) to connect to the internet if the resource has a public IPv4 address or an IPv6 address associated with it. To enable your instances to receive or send traffic from the Internet, you will need to create an Internet Gateway and associate it with a VPC.

Open the AWS VPC console as shown below. In the navigation pane, choose Internet gateways. Then click on “Create Internet Gateway”.

 Enter a name for your internet gateway. You can optionally choose a Tag and hit the Create Internet Gateway button.

Now, we have successfully created our TechDA IGW.

Attach Internet Gateway to VPC

To attach the internet gateway to a VPC now, choose Attach to a VPC from the banner at the top of the screen.

Select the VPC we created above, and then choose Attach Internet gateway. Otherwise, you can attach your internet gateway to a VPC at a later time.

The Internet Gateway has been attached successfully.

Note: If you no longer need an internet gateway, you can delete it. You can't delete an internet gateway if it's still attached to a VPC.

Create Route Tables

A route table contains a set of rules, called routes. This determines where the network traffic from your subnet or gateway is directed.

The route table for the public subnet has a route that sends all internet-bound IPv4 traffic to the internet gateway. The instances in the public subnet must have public IP addresses or Elastic IP addresses to enable communication with the internet over the internet gateway. 

Any subnet that does not have an explicit association defaults to the main route table. The Main route table comes automatically with your VPC. We have to create a route table for our public subnet and our private subnet (later time).

Open the Amazon VPC console and on the navigation pane, select Route Tables. Click create Route Table.

Enter the Route Table name which is optional and select your desired VPC. Then hit the Create Route table button.

Route table created successfully.

Create a Private Route Table

Note: Private subnet because its route table does not have a route to the internet gateway. Instances in the private subnet can’t communicate with the internet over the internet gateway, even if they have public IP addresses.

Follow the same steps as above to create your private Route Table.

Private Route table created.

Associate Subnet to Route Tables

Every subnet in your VPC must be associated with a route table. A subnet can be explicitly associated with the custom route table, or implicitly or explicitly associated with the main route table as discussed above.

To associate our subnets with the Route Table, select your custom route table. Click on Subnet Association, and select Edit Association.

Lastly, do not forget to save associations.

As shown below, our public subnets are associated with our Route Table.

Assign Public Route (Gateway Route Table)

You can associate a route table with an internet gateway or a virtual private gateway.

Note: When a route table is associated with a gateway, it’s referred to as a gateway route table. You can create a gateway route table for fine-grain control over the routing path of traffic entering your VPC. For example, you can intercept the traffic that enters your VPC through an internet gateway by redirecting that traffic to a middlebox appliance (such as a security appliance) in your VPC.

To do this, on the navigation pane, select Route Table. Select the Public Route Table, and click on the Edit Routes

Click Add Route

Below are the available targets. Choose “Internet Gateway”.

I am fine with sending all traffic to the internet gateway. Save changes when complete.

Internet Gateway Route Created successfully.

Network Access Control (NACL)

Note: In Amazon Web Services (AWS), you are responsible for defining and configuring security rules through security groups and network access control lists (NACLs) to control inbound and outbound traffic for your resources.

Network access control lists (ACLs) are stateless and allow or deny specific inbound or outbound traffic at the subnet level. You can use the default network ACL for your VPC, or you can create a custom network ACL for your VPC with rules similar to those for your security groups to add a layer of security to your VPC.

Note: Each subnet in your VPC must be associated with a network ACL. If you don't explicitly associate a subnet with a network ACL, the subnet is automatically associated with the default network ACL.You can associate a network ACL with multiple subnets. However, a subnet can be associated with only one network ACL at a time

Note: When traffic enters the VPC, the router sends the traffic to its destination. Network ACL rules evaluate when traffic enters and leaves the subnet, not as it is routed within a subnet.

The default network ACL is configured to allow all traffic to flow in and out of the subnets with which it is associated. Each network ACL also includes a rule whose rule number is an asterisk (*). This rule ensures that if a packet doesn’t match any of the other numbered rules, it’s denied. You can’t modify or remove this rule.

In this guide, I will not be creating a new NACL. I am fine with the default. The image below shows the inbound rules

Note: A network ACL has inbound rules and outbound rules. Each rule can either allow or deny traffic. Each rule has a number from 1 to 32766. This rule is evaluated in order, starting with the lowest numbered rule, when deciding whether to allow or deny traffic. If the traffic matches a rule, the rule is applied and we do not evaluate any additional rules.

AWS recommend that you start by creating rules in increments (for example, increments of 10 or 100) so that you can insert new rules later on if need be. The image below shows the outbound rules.

Below are the subnet associations of this NACL.

Security Group

Security groups act as virtual firewalls for your Amazon EC2 instances, controlling inbound and outbound traffic at the instance level. You can specify rules that allow traffic to and from specific IP addresses, other security groups, or CIDR blocks.

Your default VPCs and any VPCs that you create come with a default security group. The name of the default security group is “default” as shown below.

AWS recommends creating security groups for specific resources or groups of resources instead of using the default security group. However, if you don’t associate a security group with some resources at creation time, AWS will associate them with the default security group.

For example, if you don’t specify a security group when you launch an EC2 instance, AWS will associate the instance with the default security group for its VPC. From experience, I recommend creating a Security Group for each customer. This way, you can define the security need (rule) for this customer.

Note: Security Groups are applied on a per-instance level within an Amazon Virtual Private Cloud (VPC). You assign a Security Group to a VPC to ensure that every instance running in that VPC can be associated with the designated Security Group, effectively managing and controlling their network traffic and security settings.

Create a Security Group

Open the Amazon VPC console and in the navigation pane. Select Security Group, and Choose Create security group.

Note: Rules with source of 0.0.0.0/0 or ::/0 allow all IP addresses to access your instance. AWS recommensd setting security group rules to allow access from known IP addresses only. Since this is for demonstration only for now, I will create a custom rule allowing all traffic from all sources.

Enter a name and description for the security group. You cannot change the name and description of a security group after it is created. From VPC, choose a VPC. The security group can be used only in the VPC for which it is created.

Click Create Security Group

Our custom security group has been created.

We have our custom VPC in addition to the default for each VPC.

Modify Security Group Rules

When you launch an instance or create other AWS resources, you have the flexibility to specify the rules governing traffic to and from those resources. This includes setting up rules for:

• Inbound Traffic: Traffic coming into your AWS resources.
• Outbound Traffic: Traffic leaving your AWS resources.

These security measures are crucial for ensuring the security and integrity of your AWS infrastructure. It allows you to define who or what can communicate with your resources, enhancing the overall security posture of your applications and data in the cloud.

Note: Always adhere to the principle of least privilege, allowing only the necessary traffic required for the functioning of your applications and services.

Edit inbound rules

To edit your inbound Security Group Rules, click on the Security group select the Inbound Rule tab and click “Edit inbound rules”.

You can now starting adding individual inbound rules.

Below are the various traffic rule types.

When you are done creating your rule, click on Save rules.

As you can see, we have our inbound rules created successfully.

Edit Outbound rules

Let’s do the same for our Outbound rules.

Delete Security Group

You can delete a security group only if it is not associated with any resources. You can’t delete a default security group.

Note: Since we can change the rules for a default security group, and cannot delete the default security group. If you wish to delete the above security group, select the SG, click on Actions and select “Delete Security Group”.

Note: As recommended by AWS, I will not be deleting this rule but just showing you the steps to delete a Security Group.

Open the Amazon VPC console, and in the navigation pane, choose Security Groups. Select the security group and choose Actions, Delete security groups. When prompted for confirmation, choose Delete.

Private Subnet

As mentioned above, we will create a dedicated post on Private Subnet. Here is a teaser and all that to do to work with the Private Subnet.

NAT Gateway

AWS NAT Gateway facilitates outbound internet connectivity for your instances within a Virtual Private Cloud (VPC), allowing them to access external resources. Simultaneously, it acts as a barrier preventing inbound traffic from the internet to services within the VPC, enhancing the security of your infrastructure.

Resource Map

The resource map shows relationships between resources inside a VPC and how traffic flows from subnets to NAT gateways, internet gateways and gateway endpoints.

You can use the resource map to understand the architecture of a VPC, see how many subnets it has in it, which subnets are associated with which route tables, and which route tables have routes to NAT gateways, internet gateways, and gateway endpoints.

This feature is under development and may change at the time of writing this article. You can also use the resource map to spot undesirable or incorrect configurations, such as private subnets disconnected from NAT gateways or private subnets with a route directly to the internet gateway. You can choose resources within the resource map, such as route tables, and edit the configurations for those resources.

Solid lines represent relationships between resources in your VPC. Dotted lines represent network paths to network functions. The following resources are visible in the resource map:

• VPCs
• Subnets
• Route tables
• Internet gateways
• Egress-only internet gateways
• NAT gateways
• Endpoints (Gateway only)

Soon, we shall perform regular backups for sensitive data that are stored in our VPC via Veeam Backup for AWS. This will ensure the data can be restored in case of deletion, corruption, or other issues.

Conclusion on creating your own Network on AWS from Scratch

Creating your own network on AWS from scratch is a rewarding and strategic endeavour that provides flexibility, scalability, and control over your infrastructure.

Starting with the establishment of a Virtual Private Cloud (VPC), carefully designing subnets, configuring security groups, and implementing route tables empower you to tailor the network to your specific requirements.

FAQs on how to create your own Network on AWS from Scratch

I hope you found this article useful on “VPC, Subnet, NACL, Security Group: Create your own Network on AWS from Scratch [Part 2]”. Please feel free to leave a comment below.