Inside AWS VPC: The Backbone of Cloud Infrastructure
Part -1
In Aws networking is one of the most important concepts to understand. Anyone working in Cloud or DevOps should know how traffic flows inside the AWS environment, because every service communicates through networking.
At the core of AWS networking is VPC (Virtual Private Cloud). A VPC is your logically isolated network inside AWS where you launch resources such as EC2 instances, databases, load balancers, and more.
Many times, while launching an Amazon EC2 instance, users select default options and may not pay much attention to the networking section. But an EC2 instance cannot be created without a network. AWS automatically provides a default VPC in each region, which is why instances can be launched quickly without manual network setup.
Each AWS account gets its own default VPC in a region. Even if multiple users create instances, they are not sharing one common VPC across accounts. Each account has a separate default VPC managed by AWS.
Then why do we create a custom VPC?
Because a custom VPC gives full control over network design, such as:
Choosing your own CIDR range
Creating public and private subnets
Selecting specific Availability Zones
Defining route tables
Configuring internet/NAT gateways
Applying custom security rules
Building production-grade architectures
In real-world projects, custom VPCs are preferred because they provide better security, scalability, and flexibility compared to the default VPC.
Let's Deep dive into Components of VPC
VPC
A VPC (Virtual Private Cloud) is a logically isolated network in AWS where we can design, customize, and manage the network based on project requirements. It allows us to create a secure and flexible environment to launch AWS resources according to our needs.
CIDR BLOCKS
A CIDR block is the IP address range assigned to your Amazon VPC. It defines how many private IP addresses are available inside the VPC and its subnets
CIDR = Classless Inter-domain Routing
Example : 10.0.0.0/16
10.0.0.0 = Network Base Address
16 = length
Smaller prefix number = larger network.
When you create a VPC, AWS asks for a CIDR block. That range becomes the private address space for:
Amazon EC2 instances
Amazon RDS databases
Amazon EKS nodes and pods (depending design)
Load balancers
Internal services
AWS reserves
10.0.1.0 Network address
10.0.1.1 Router
10.0.1.2 DNS
10.0.1.3 Future use
10.0.1.255 Broadcast reserved
Common Private IP Ranges
private ranges commonly used:
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
IP ranges (CIDR blocks) are useful because they determine where your resources live, how they communicate, how many resources you can create, and how traffic is controlled inside a network like Amazon VPC.
Every resource created inside a VPC needs a private IPv4 address so it can communicate with other resources within the network. These IP addresses allow services such as Amazon EC2 instances, databases, load balancers, and containers to send and receive traffic.
IPv4 calculation
IPv4 addresses are 32-bit numbers written as 4 octets
Each octet ranges from
0 to 255
Common CIDR Calculations 📘
/24
32−24=8
2(8)=256
256 total IPs
-------------
/25
32−25=7
2(7)=128
128 total IPs
-------------
/26
32−26=6
2(6)=64
64 total IPs
-------------
/16
32−16=16
2(16)=65536
65536 total IPs
SUBNETS
We created a VPC, is a logically isolated virtual network in AWS. To organize that network efficiently, we create subnets within the VPC. Subnets are smaller network segments created from the main VPC range.
We use subnets for several important reasons:
To divide a large network into manageable smaller networks
To improve security by placing sensitive resources in private subnets without direct internet access
To host public-facing resources in public subnets
To achieve high availability, we create multiple subnets across different Availability Zone
One subnet belongs to only one Az
To separate workloads such as web, application, and database tiers
For example, if we choose the VPC CIDR block:
10.0.0.0/16
It provides the IP range:
10.0.0.0to10.0.255.255Total IPs = 65,536
In real environments, we usually do not place all servers directly in one flat network. Instead, we divide the VPC into smaller subnets such as:
Subnet 1 →
10.0.1.0/24Subnet 2 →
10.0.2.0/24Subnet 3 →
10.0.3.0/24
Each subnet can then be assigned to different AZs or used for different purposes like public, private application, or database layers. This creates a more secure, scalable, and production-ready architecture.
Within subnets, we commonly have public and private subnets. Many people think we manually choose a subnet type, but that is not exactly how AWS works. A subnet is considered public or private mainly based on its route table configuration.
A public subnet has a route to an Internet Gateway, allowing internet-facing resources to connect directly when properly configured.
A private subnet does not have a direct route to the Internet Gateway.
If resources in a private subnet need outbound internet access for updates or downloads, they usually access the internet through a NAT Gateway deployed in a public subnet.
Public Subnets often host:
NAT Gateway
Internet-facing Elastic Load Balancing (ALB/NLB)
Bastion host (if used)
Private Subnets often host:
Amazon EKS worker nodes
Application servers
Amazon RDS database servers
Bastion Hosts Are Less Common Now
Many teams now use:
AWS Systems Manager Session Manager
AWS Systems Manager Session Manager is a modern way to connect to private Amazon EC2 instances without bastion host, without opening SSH port 22, and often without public IPs.
Internet GateWay
An Internet Gateway (IGW) is a component attached to a VPC that enables communication between resources inside the VPC and the internet. It acts as the entry and exit point for internet traffic.
We use an Internet Gateway mainly for public resources such as web servers, bastion hosts, or load balancers that need internet access.
When an Internet Gateway is attached to a VPC and the subnet’s route table has a route like
0.0.0.0/0 → Internet Gateway
Why it is needed:
Allows inbound internet traffic to public resources
Allows outbound internet access from public instances
Supports hosting websites, APIs, SSH access, etc.
Important point:
Private subnets do not use Internet Gateway directly. They usually access the internet through a NAT Gateway.
Route Table
A Route table is a set of rules defined it determines where network traffic should go from a subnet inside a Amazon Virtual Private Cloud.
When you create a VPC and subnets, resources need paths to reach
Local
Internet gate way
NAT Gateway
VPN
Another VPC
On-premise network
VPC Endpoints
Destination CIDR Target
10.0.0.0/16 local
0.0.0.0/0 Internet Gateway
10.0.0.0/16 local→ traffic inside same VPC stays internal0.0.0.0/0→ all other traffic goes to internet
Real time Example
VPC 10.0.0.0/16
Public Subnet:
10.0.1.0/24
Private Subnet:
10.0.11.0/24
-------------------
Public RT:
10.0.0.0/16 local
0.0.0.0/0 IGW
Private RT:
10.0.0.0/16 local
0.0.0.0/0 NAT
Public Subnet flow ( IN to OUT )
EC2 (public subnet) ↔ IGW ↔ Internet
Private Subnet flow ( IN to OUT )
EC2 (private subnet) → Route Table → NAT Gateway (in public subnet) → IGW → Internet
NAT Gateway
NAT = Network Address Translation
A NAT Gateway in Amazon Web Services is a managed network service that allows resources in a private subnet to access the internet outbound only, while preventing direct inbound internet connections.
It is one of the most important components in AWS VPC networking.
Generally why we use private subnets to make it secure right in that case how can we give direct public access to these . so we use NAT gateway only for outbound access in order to do
Download packages
Pull Docker images
Access APIs
Send logs/metrics
Traffic flow ( IN to OUT )
Private EC2 (10.0.11.25)
↓
Private Route Table
0.0.0.0/0 → NAT Gateway
↓
NAT translates source IP to Elastic IP
↓
IGW
↓
Internet
NAT Gateway and NAT Instance do the same job conceptually (give private subnet outbound internet access), but they are implemented differently.
NAT Instance is a normal Amazon EC2 instance configured to forward traffic.
we do need handle updates , patching and manual scalling earlier before nat gateway people used this nat instance