Nugroho

just notes

9 minute read

What is VPC?

Amazon Virtual Private Cloud (Amazon VPC) is a service that allows us to create our own isolated virtual network in AWS. It gives us full control over our network environment, including IP address ranges, subnets, routing, and security.

From Traditional On-Premises Network to the Cloud

In a traditional on-premises environment, organizations need to build and maintain their own physical network infrastructure. This includes purchasing networking devices, configuring cables, managing IP addresses, and ensuring the network remains secure and available.

With Amazon VPC, all of these networking capabilities are virtualized and managed through AWS. We can design our network architecture within minutes without worrying about the underlying physical hardware, while still maintaining a high level of control over connectivity and security.

VPC Building Blocks

A VPC is made up of several networking components that work together to control connectivity and security.

Component Purpose
VPC Creates an isolated virtual network.
Subnet Divides the VPC into smaller network segments.
Route Table Determines how network traffic is routed.
Internet Gateway (IGW) Enables communication between the VPC and the internet.
NAT Gateway Allows private resources to access the internet without being publicly accessible.
Security Group Acts as a virtual firewall for individual resources.
Network ACL (NACL) Provides subnet-level traffic filtering.
VPC Endpoint Enables private access to supported AWS services without using the public internet.

VPC CIDR

A CIDR (Classless Inter-Domain Routing) block defines the IP address range available within your VPC. Every resource launched inside the VPC, such as an EC2 instance or an RDS database, receives a private IP address from this range.

When creating a VPC, one of the first decisions we need to make is selecting an appropriate CIDR block. This choice determines the maximum number of private IP addresses the VPC can allocate.

CIDR Notation

A CIDR block consists of an IP address followed by a slash (/) and a number, for example:

10.0.0.0/16

The number after the slash is called the prefix length. It indicates how many bits are reserved for the network portion of the IP address, while the remaining bits are used for host addresses.

The number of available IP addresses can be calculated using the following formula:

Number of IP addresses = 2^(32 - prefix length)

For example:

CIDR Block Host Bits Total IP Addresses
/16 16 65,536
/20 12 4,096
/24 8 256
/28 4 16

As the prefix length increases, the network becomes smaller, resulting in fewer available IP addresses.

Calculating CIDR

Suppose we create a VPC with the following CIDR block:

10.0.0.0/16

32 - 16 = 16 host bits

2^16 = 65,536 IP addresses

This means our VPC owns all IP addresses from 10.0.0.0 to 10.0.255.255.

We can divide the VPC into multiple subnet, for example:

VPC: 10.0.0.0/16
│
├── Public Subnet
│   └── 10.0.1.0/24
│
└── Private Subnet
    └── 10.0.2.0/24

Each /24 subnet contains 256 IP addresses.

However, AWS reserves the first four IP addresses and the last IP address in every subnet, leaving 251 usable IP addresses for our resources.

Notes! A VPC CIDR block cannot overlap with the CIDR blocks of other VPCs or on-premises networks that we plan to connect using VPC Peering, Transit Gateway, or Site-to-Site VPN. Careful IP planning at the beginning helps avoid networking conflicts as our infrastructure grows.

VPC Secondary CIDR

When creating a VPC, we typically assign it a CIDR block.

For example:

10.0.0.0/16

This is known as the Primary CIDR Block.

All subnets inside the VPC are created from this CIDR.

Example:

VPC
10.0.0.0/16

├── Public Subnet
│   └── 10.0.1.0/24
│
├── Public Subnet
│   └── 10.0.2.0/24
│
├── Private Subnet
│   └── 10.0.10.0/24
│
└── Private Subnet
    └── 10.0.20.0/24

However, AWS allows us to associate additional CIDR blocks with the same VPC.

These are called Secondary CIDR Blocks.

Example:

Primary CIDR
10.0.0.0/16

Secondary CIDR
100.64.0.0/16

The VPC now owns both IP ranges.

Why Do We Need a Secondary CIDR?

Sometimes the primary CIDR doesn’t have enough available IP addresses.

For example:

  • More EC2 instances
  • More Kubernetes Pods
  • More subnets

Instead of recreating the VPC with a larger CIDR block, AWS lets us attach a secondary CIDR.

This expands the available address space without replacing the VPC.

Subnet

A subnet is a smaller network created by dividing a VPC’s CIDR block into multiple IP address ranges. Subnets help organize resources, improve security, and separate workloads with different networking requirements.

Here is the illustration when we divide VPC CiDR Block into multiple subnets:

VPC: 10.0.0.0/16
│
├── Public Subnet A
│   └── 10.0.1.0/24
│
├── Public Subnet B
│   └── 10.0.2.0/24
│
├── Private Subnet A
│   └── 10.0.11.0/24
│
└── Private Subnet B
    └── 10.0.12.0/24

Each subnet has its own range of IP addresses, allowing resources to be grouped based on their purpose.

Subnets are commonly categorized as:

  • Public Subnet – Contains resources that require direct internet access, such as web servers or load balancers.
  • Private Subnet – Contains internal resources, such as databases or application servers, that should not be directly accessible from the internet.

A subnet is not inherently public or private. Its behavior depends on the associated route table and whether traffic can reach an Internet Gateway.

Route Tables

A Route Table defines how network traffic is routed within a VPC. Every subnet must be associated with a route table, and AWS uses its routes to determine where packets should be sent.

Every route consists of two parts:

  • Destination – The IP address range for the traffic.
  • Target – Where the traffic should be forwarded.

For example: | Destination | Target | Description | | ————- | —————- | ———————————————————- | | 10.0.0.0/16 | Local | Routes traffic within the same VPC. | | 0.0.0.0/0 | Internet Gateway | Routes all internet-bound traffic to the Internet Gateway. |

A route table with only the local route means resources can communicate only with other resources inside the VPC.

AWS automatically creates the Local route when a VPC is created. This route cannot be removed because it enables communication between subnets within the same VPC.

Internet Gateway (IGW)

An Internet Gateway (IGW) is a highly available, managed AWS resource that enables communication between a VPC and the public internet.

By itself, attaching an Internet Gateway to a VPC does not make resources publicly accessible. Internet connectivity requires all of the following:

  • An Internet Gateway attached to the VPC.
  • A route table with a default route (0.0.0.0/0) pointing to the Internet Gateway.
  • A resource with a public IPv4 address or Elastic IP address.
  • Security Groups and Network ACLs that allow the required traffic.

The illustration will looks like:

Internet
    │
    ▼
Internet Gateway
    │
    ▼
Route Table
(0.0.0.0/0 → IGW)
    │
    ▼
Public Subnet
    │
    ▼
EC2 Instance
(Public IP)

Without an Internet Gateway, resources inside the VPC can still communicate with each other, but they cannot send or receive traffic from the public internet.

Firewalls in VPC

Amazon VPC provides two layers of firewall protection which is Security Groups and Network Access Control Lists (NACLs).

Security Groups

A Security Group acts as a virtual firewall for an individual AWS resource. It controls which inbound and outbound traffic is allowed to reach that resource.

Security Group only contains allow rules. Any traffic that is not explicitly allowed is automatically denied.

For example, the following Security Group allows SSH and HTTP traffic: | Type | Protocol | Port | Source | | —- | ——– | —- | —————– | | SSH | TCP | 22 | 203.0.113.10/32 | | HTTP | TCP | 80 | 0.0.0.0/0 |

Security Groups are stateful, which means we don’t have to specify the outbound rules to response to traffic.

Network ACL (NACL)

A Network Access Control List (NACL) provides firewall protection at the subnet level. Every resource inside the subnet is affected by the same NACL.

Unlike Security Groups, NACLs support both:

  • Allow rules
  • Deny rules
Rule # Type Protocol Port Source Action
100 HTTP TCP 80 0.0.0.0/0 Allow
110 SSH TCP 22 203.0.113.10/32 Allow
* All Traffic All All 0.0.0.0/0 Deny

Unlike Security Groups, NACLs are stateless.

If inbound traffic is allowed, the corresponding outbound response is not automatically allowed. So we must explicitly configure both inbound and outbound rules.

For example:

Inbound  : Allow TCP 80
Outbound : Must also allow ephemeral ports

If the outbound rule is missing, the response packet will be dropped even though the inbound request was accepted.

NAT Gateway

A NAT Gateway allows resources in a private subnet to access the internet while preventing the internet from initiating connections back to those resources.

Resources in a private subnet do not have public IP addresses, so they cannot communicate directly with the internet. However, they may still need outbound internet access for tasks such as:

  • Downloading operating system updates
  • Installing software packages
  • Pulling Docker images
  • Accessing external APIs

A NAT Gateway solves this problem by forwarding outbound traffic from private resources to the internet.

Internet
    ▲
    │
Internet Gateway
    ▲
    │
NAT Gateway
    ▲
    │
Private EC2

The EC2 instance sends a request to the NAT Gateway.

The NAT Gateway translates the private IP address into its own public IP address before forwarding the request to the internet.

When the response returns, the NAT Gateway translates the destination back to the original private IP and forwards the response to the EC2 instance.

Because of this process, private resources can access the internet without exposing themselves to inbound connections.

NAT Gateway Placement

A NAT Gateway must be deployed in a public subnet and created in specific AZ (but now there is NAT for Region also) and associated with an Elastic IP Address (EIP).

The private subnet’s route table should forward all internet-bound traffic to the NAT Gateway.

Example route table for a private subnet:

Destination Target
0.0.0.0/0 NAT Gateway

The public subnet containing the NAT Gateway should have a route to the Internet Gateway.

Destination Target
0.0.0.0/0 Internet Gateway

NAT Gateway Characteristics

  • Allows outbound internet access for private resources.
  • Blocks unsolicited inbound connections from the internet.
  • Performs Network Address Translation (NAT) by replacing private IP addresses with its own public IP address.
  • Is a fully managed AWS service.
  • Requires an Elastic IP Address (EIP).

Suppose an EC2 instance in a private subnet executes:

sudo apt update

The traffic flow is:

Private EC2
      │
      ▼
NAT Gateway
      │
      ▼
Internet Gateway
      │
      ▼
Ubuntu Package Repository

The package repository only sees the public IP address of the NAT Gateway.

When the response is received, the NAT Gateway forwards it back to the private EC2 instance.

Elastic Network Interface (ENI)

An Elastic Network Interface (ENI) is a virtual network card attached to an EC2 instance.

Just like a physical server needs a Network Interface Card (NIC) to communicate with a network, an EC2 instance uses an ENI to communicate within a VPC.

Every EC2 instance has at least one ENI, known as the Primary ENI.

Example:

VPC
│
└── EC2 Instance
     │
     └── eth0 (Primary ENI)
            │
            ├── Private IP: 10.0.1.10
            ├── Public IP (Optional)
            ├── Security Groups
            └── MAC Address

The ENI is responsible for handling all network traffic to and from the EC2 instance.

Primary and Secondary ENIs

An EC2 instance can have multiple ENIs attached.

For example:

EC2 Instance

├── eth0 (Primary ENI)
│      10.0.1.10
│
├── eth1 (Secondary ENI)
│      10.0.2.10
│
└── eth2 (Secondary ENI)
       10.0.3.10

Each ENI can belong to a different subnet within the same Availability Zone.

This allows an EC2 instance to communicate with multiple networks.

Tags: ,

Categories:

Updated:

You may also enjoy