AWS Network Fundamentals for EC2 instance!

Have you ever launched an EC2 instance by following a tutorial, blindly inputting values without fully understanding their significance? While it might work at first glance, the magic behind EC2 lies in its networking fundamentals—Virtual Private Clouds (VPCs), subnets, gateways, route tables, and security groups all working together to ensure your instance is both functional and secure.

In this article, we’ll go beyond surface-level configurations. You’ll gain a clear understanding of the core networking concepts that power AWS EC2. We’ll explore how to create and configure VPCs, set up public and private subnets with appropriate CIDR ranges, manage gateways for connectivity, and secure your network using security groups and Network ACLs.

To make it even more engaging, we’ll include step-by-step YouTube embeds to show how to configure each component in the AWS Management Console. By the end, you won’t just know how to set up an EC2 instance—you’ll know why each step matters and how it impacts your cloud architecture.

Let’s dive in and master the backbone of AWS EC2 networking!

At the starting point we just have a AWS Cloud, so just go to https://aws.amazon.com and create your free account. After that we have something called VPCs (Virtual Private Cloud).

VPC

A VPC is a virtual private cloud, which works like a private network to isolate the resources within it. The solution described in these topics uses an AWS service called Amazon VPC.

It's like a fence around a bunch of resources, separating all of the resources within that fence from another VPC.

Here, while creating a VPC, we specified a CIDR of 10.0.0.0/16. But what exactly is a CIDR range, and how do /24 or /16 differ?

What is a CIDR Range?

CIDR (Classless Inter-Domain Routing) is a method used to allocate IP addresses efficiently. Instead of using fixed blocks of IPs, CIDR allows for flexible assignment of IP ranges. A CIDR block is expressed as an IP address, followed by a slash (/) and a number indicating how many bits are used for the network prefix.

For example, in the CIDR 10.0.0.0/16:

• 10.0.0.0 is the base IP address.
• /16 means that the first 16 bits are reserved for the network portion, leaving the remaining bits for defining individual hosts.

CIDR Block Size and Address Allocation

The number after the slash determines how many IP addresses are available in the range:

• /16: Reserves the first 16 bits for the network. This allows for 2^(32-16) = 65,536 IP addresses, which is suitable for large subnets. Example: 10.0.0.0 to 10.0.255.255.
• /24: Reserves the first 24 bits, leaving 8 bits for hosts. This provides 2^(32-24) = 256 IP addresses, which is common for smaller manageable subnets (e.g., public and private subnets). Example: 10.0.0.0 to 10.0.0.255.

Now within this VPC, we have isolated networks, with different CIDR ranges called subnets.

Subnets

A subnet is a defined set of network IP addresses that are used to increase the security and efficiency of network communications. You can think of them like postal codes, used for routing packages from one location to another. The Subnets list in the Amazon VPC console displays subnet IDs and also their associated VPC IDs, route tables, and network ACLs. You need to provide at least two subnets in different availability zones to create a VPC connection.

A subnet is a range of IP addresses in our VPC. We can create AWS resources, such as EC2 instances, in specific subnets.

Each subnet must reside within one Availability Zones. By launching AWS resources in different Availability zones, we can protect our application from failure of single zone.

Normally, for pet projects we can create 2 subnets, a public subnet and a private subnets, with different Availability zone.

• Public Subnet: The subnet has a direct route to an internet gateway (discussed further). Resources in a public cloud can access the public internet.
• Private Subnet: The subnet does not have a direct route to an internet gateway. Resources in a private subnet require a NAT gateway (discussed further) to access the public internet.

So, following is what we have now: a VPC with two subnets, PublicSubnet and PrivateSubnet. While creating these subnets, we assigned:

• PublicSubnet: IPv4 CIDR block 10.0.0.0/24
• PrivateSubnet: IPv4 CIDR block 10.0.1.0/24

Significance of Subnet CIDR Blocks

The CIDR blocks define the range of IP addresses available within each subnet. Here's the breakdown:

1. PublicSubnet (10.0.0.0/24)

   • This subnet can host resources that require internet access.
   • The /24 CIDR block means there are 256 available IPs (2^8) in this subnet, ranging from 10.0.0.0 to 10.0.0.255.
   • AWS reserves 5 IP addresses from this range for internal use, leaving 251 usable IPs for EC2 instances and other resources.

2. PrivateSubnet (10.0.1.0/24)

   • This subnet is meant for resources that don’t need direct internet access, such as databases or internal services.
   • The /24 CIDR block provides another 256 IPs, ranging from 10.0.1.0 to 10.0.1.255, with 251 usable IPs after AWS reservations.

By assigning distinct CIDR blocks to each subnet, we ensure that:

• Resources in the PublicSubnet and PrivateSubnet don’t overlap or conflict.
• We maintain clear separation for routing and security purposes.

Recap of Our Current Setup

We now have:

1. A VPC with a CIDR range of 10.0.0.0/16, giving us up to 65,536 IP addresses.
2. Two subnets within this VPC:
   • A PublicSubnet (10.0.0.0/24) for internet-facing resources.
   • A PrivateSubnet (10.0.1.0/24) for internal resources.

Now we are going to launch an EC2 instance into our public subnet.

Launching Public EC2

So, we launched the instance with basic configurations: naming it, selecting the AMI, choosing the instance type, and creating a key-pair for secure access. Then, in the Network Settings, we selected the VPC and public subnet we created earlier. To ensure our instance could communicate with the internet, we enabled public IP generation.

Next, we configured the Security Group, which acts as a virtual firewall for our instance to control incoming and outgoing traffic. We allowed SSH traffic (port 22) in the Security Group, which enables us to connect to the instance using our key-pair securely from our local machine.

But Wait, Was That Enough?

No! We encountered an error while trying to connect to our EC2 instance. This happened because our VPC doesn’t yet have an Internet Gateway (IGW). An IGW is essential to allow internet communication for resources within a public subnet. Without it, even instances with public IPs cannot connect to the internet.

What's Next?

Now, let’s resolve this issue!
We’ll add an Internet Gateway to our VPC to enable connectivity for our PublicSubnet.

Gateway

A gateway connects your VPC to another network. Example, An internet gateway is a VPC component that allows communication between instances in your VPC and the internet.

The Internet Gateway acts as a doorway, allowing traffic to flow between the internet and the instances in our public subnet. However, simply attaching the Internet Gateway to our VPC isn’t enough—we also need to provide a route for traffic to reach the gateway.

In the video, we successfully created an Internet Gateway and attached it to our VPC. Note: A VPC can only have one Internet Gateway at a time.

But Wait, Why Can’t We Connect Yet?

Even though the Internet Gateway is attached, the public subnet doesn’t know how to send traffic to the gateway. This happens because the Route Table associated with the subnet doesn’t include a route to the Internet Gateway. Without this, traffic to and from the internet has no defined path, leaving our instance unreachable.

What's Next?

Let’s fix this by updating the Route Table associated with our PublicSubnet. We’ll add a route to the Internet Gateway, enabling traffic to flow between the internet and our EC2 instance seamlessly.

Route Table

A route table contains a set of rules, called routes, that are used to determine where network traffic is directed. You can view the route table in the Amazon VPC console at https://console.aws.amazon.com/vpc/. The VPC details display the route table that the VPC is using. You can also see Route tables listed in the Amazon VPC console.

Think of a route table as a GPS system for your network traffic. It helps direct traffic to its intended destination, whether it’s within the VPC or outside to the internet.

In the VPC dashboard, under the "Route Table" section, you’ll notice that your VPC comes with a default Route Table—referred to as the main Route Table. This is used by all unassociated subnets by default.

The local route (10.0.0.0/16) in this table allows communication between resources within the VPC, such as the public and private subnets. However, it doesn’t direct traffic outside the VPC.

Creating Separate Route Tables

By default, both public and private subnets use the main Route Table. To ensure proper isolation and functionality:

• Create a dedicated Route Table for the public subnet.
• Create another Route Table for the private subnet.

This separation ensures public resources can communicate with the internet, while private resources remain secure and isolated.

Associating and Adding Routes

After creating the Route Tables, associate each table with its corresponding subnet—PublicSubnet and PrivateSubnet.

For the PublicSubnet Route Table:

• Add a route with the following details:
  • Destination: 0.0.0.0/0 (all internet traffic).
  • Target: Internet Gateway (IGW).

Save the changes, and now your public subnet has internet connectivity!

Success!

And just like that, our EC2 instance is connected to the internet. Now, we can SSH into it, update packages, and configure it further directly from the shell. Let’s launch an EC2 instance into our private subnet.

Private Instance and NAT Gateways

So, for the private subnet, we created another EC2 instance. While doing so, we selected the same VPC and ensured the instance was launched in the private subnet. We successfully connected to the private instance using SSH from the public instance, thanks to the route table configurations. Also, don’t forget to have your .pem file in the public instance with the correct permissions (chmod 400).

However, once inside the private instance, when we tried to update the packages, we encountered an issue—our private instance couldn’t access the internet. Why? Because the private subnet is isolated from direct internet access for security reasons.

Here’s where the NAT Gateway comes into play.

A NAT gateway is a Network Address Translation (NAT) service. You can use a NAT gateway so that instances in a private subnet can connect to services outside your VPC but external services cannot initiate a connection with those instances.

Think of it as your instance requesting updates or connecting to an external API—your NAT Gateway makes the request on behalf of your private instance, retrieves the response, and passes it back to the instance. This ensures your private subnet remains shielded from any unsolicited access.

Here are a few suggestions to refine and enhance your explanation about NAT Gateway and its role in enabling secure internet access for private subnets:

After creating our NAT Gateway in the public subnet, we configured the private subnet’s route table to direct outbound traffic to the NAT Gateway. Here’s how it works:

1. Why the NAT Gateway is in the Public Subnet:

   • The NAT Gateway itself needs internet access to route outbound traffic from the private subnet. By placing it in the public subnet, it can utilize the internet gateway already configured for public internet access.

2. Routing the Private Subnet through the NAT Gateway:

   • We updated the Private Route Table to include a new route:
     • Destination: 0.0.0.0/0 (all internet traffic)
     • Target: The NAT Gateway ID
   • This ensures all outbound traffic from the private subnet destined for the internet is routed via the NAT Gateway.

3. Testing the Connection:

   • After updating the route table, we SSH’d into the private instance using the public instance as a jump host.
   • We then successfully ran package updates (sudo yum update -y or sudo apt update), confirming that the private instance could access the internet.

NACLs and Security Group

A network access control list (ACL) allows or denies 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 that are similar to the rules for your security groups in order to add an additional layer of security to your VPC.

A security group is a set of rules that controls the network access to the resources it is associated with. Access is permitted only to and from the components defined in the security group's inbound and outbound rules. If no rules are defined, the security group prevents all access. You can view security groups from several different consoles, depending on which resource that a particular security group applies to. You can see all the security groups and their settings in one place in the VPC console.

The network is configured securely, and we understand the significance of each component in making this work.

Summary of What We've Accomplished:

1. VPC Creation: We built a secure Virtual Private Cloud with a CIDR range of 10.0.0.0/16, capable of hosting up to 65,536 IPs.
2. Subnet Configuration: Divided the VPC into two subnets:
   • PublicSubnet for internet-facing resources (10.0.0.0/24).
   • PrivateSubnet for internal resources (10.0.1.0/24).
3. Internet Gateway Setup: Attached an Internet Gateway to our VPC to allow internet traffic for public resources.
4. Route Table Management:
   • Configured a custom Route Table for the PublicSubnet with a route to the Internet Gateway for internet connectivity.
   • Left the PrivateSubnet secured without a direct route to the internet.

Understanding the networking fundamentals is a game-changer when working with AWS. It transforms the process of launching an EC2 instance from a simple "trial and error" into a deliberate and well-architected solution. By mastering these principles, you're not just deploying applications—you’re building robust, scalable, and secure cloud architectures.

Let me know if you'd like to dive deeper into any of these concepts or explore additional AWS networking components like NAT Gateways, VPNs, or security best practices!

References

• Docs: VPC terminology
• Docs: Amazon VPC
• YouTube: AWS Networking Fundamentals