From VLANs to Amazon VPC: Understanding AWS Networking from an Infrastructure Perspective
A practical introduction to Amazon VPC for infrastructure professionals, connecting traditional networking concepts such as subnets, routing and firewalls with networking in AWS.
From VLANs to Amazon VPC: Understanding AWS Networking from an Infrastructure Perspective
When I started learning AWS networking, one of the first services I wanted to understand was Amazon Virtual Private Cloud (Amazon VPC).
Coming from traditional infrastructure environments, I was already familiar with concepts such as IP addressing, VLANs, subnets, routing, firewalls and network segmentation.
Amazon VPC uses many of the same networking principles, but applies them to a cloud environment.
Understanding this relationship helped me connect my existing infrastructure knowledge with the way networking works in AWS.
What is Amazon VPC?
Amazon VPC allows us to create a logically isolated virtual network within AWS.
When creating a VPC, one of the first decisions is defining its IPv4 CIDR block.
For example:
10.0.0.0/16
From there, the network can be divided into smaller subnets depending on the architecture.
For example:
Public Subnet: 10.0.1.0/24
Private Subnet: 10.0.2.0/24
Database Subnet: 10.0.3.0/24
This immediately felt familiar because subnet planning is also an important part of traditional network design.
VLANs and VPCs: Are They the Same?
Not exactly.
A VLAN provides Layer 2 network segmentation, while an Amazon VPC represents a virtual network environment in AWS.
Therefore, a VPC should not simply be considered "a VLAN in AWS."
However, from an infrastructure learning perspective, both concepts help us understand the importance of separating workloads and controlling communication between different parts of an environment.
Inside a VPC, subnets are one of the main mechanisms used to organize resources.
Public and Private Subnets
One concept that becomes especially important in AWS is the distinction between public and private subnets.
A public subnet has a route to an Internet Gateway.
A simplified architecture could look like this:
Internet
|
Internet Gateway
|
Amazon VPC
|
Public Subnet
|
EC2 Instance
|
Internet Gateway
|
Amazon VPC
|
Public Subnet
|
EC2 Instance
A private subnet, on the other hand, does not have a direct route to an Internet Gateway.
For example:
Amazon VPC
|
Private Subnet
|
Application Server
|
Database
|
Private Subnet
|
Application Server
|
Database
This allows infrastructure architects to avoid exposing resources directly to the Internet when they do not require public access.
Route Tables
Route tables determine where network traffic is directed.
This is another concept that is very familiar to anyone who has worked with traditional networking.
For example, a public subnet might contain a route similar to:
10.0.0.0/16 → Local
0.0.0.0/0 → Internet Gateway
The local route enables communication within the VPC, while the default route can provide connectivity toward the Internet through an Internet Gateway.
Private subnets can use different routing depending on the requirements of the architecture.
The important point is that connectivity does not happen simply because two resources exist in AWS. Routing and security still need to be designed correctly.
Security Groups
Another important component is the Security Group.
Security Groups act as virtual firewalls associated with resources such as EC2 instances.
For example, a web server may need:
TCP 443 → HTTPS
But that does not mean administrative ports should also be exposed publicly.
This is where the principle of least privilege becomes important.
Only the traffic required by the workload should be allowed.
Network ACLs
AWS also provides Network Access Control Lists (NACLs).
While Security Groups operate at the resource level, Network ACLs provide controls at the subnet level.
Another important difference is that Security Groups are stateful, while Network ACLs are stateless.
Understanding this distinction is important when troubleshooting connectivity problems in a VPC.
A connectivity issue may not necessarily be caused by the operating system or the application. It could involve:
- Security Groups
- Network ACLs
- Route tables
- Subnet configuration
- Internet Gateway
- IP addressing
This makes troubleshooting in AWS very similar in principle to troubleshooting traditional infrastructure: analyze the communication path layer by layer.
A Simple Three-Tier Architecture
A common example is an application composed of different layers.
Internet
|
Internet Gateway
|
Public Subnet
|
Load Balancer
|
Private Subnet
|
Application Servers
|
Private Database Subnet
|
Database
|
Internet Gateway
|
Public Subnet
|
Load Balancer
|
Private Subnet
|
Application Servers
|
Private Database Subnet
|
Database
Instead of placing every resource directly on the Internet, the architecture separates components according to their function.
Only the components that require public connectivity should be exposed.
This improves network segmentation and reduces unnecessary exposure.
Connecting Traditional Networking Knowledge with AWS
One thing I find interesting while learning AWS is that traditional networking knowledge remains extremely valuable.
Concepts such as:
- TCP/IP
- CIDR
- Subnetting
- Routing
- Firewalls
- NAT
- DNS
- VPN
- Network segmentation
do not disappear when moving to the cloud.
What changes is how these components are implemented and managed.
For someone coming from infrastructure and data center environments, understanding these relationships makes AWS networking much easier to approach.
Final Thoughts
Amazon VPC is one of the AWS services that I consider fundamental for infrastructure professionals.
Before deploying multiple EC2 instances or applications, it is important to understand where those resources will be located, how they will communicate and what traffic should be permitted.
Learning VPC is therefore not only about learning another AWS service.
It is about applying networking fundamentals to cloud architecture.
For infrastructure professionals transitioning toward AWS, existing knowledge of networking provides a strong foundation for understanding VPC, subnets, routing, security and hybrid connectivity.
My next step is to continue exploring more advanced networking scenarios, including NAT Gateway, VPC Peering, VPN connectivity and architectures that connect on-premises infrastructure with AWS.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article