AWS Networking
AWS Networking Hierarchy, Explained Easily
AWS networking becomes much less scary when you picture it as a city with boundaries, neighborhoods, roads, gates, and security checks.
The simple mental model
The VPC is the private city boundary. It defines the network space where your cloud resources live. Subnets are neighborhoods inside that city, usually split across Availability Zones so workloads can survive failures better.
A public subnet is a neighborhood with a route to the public internet. A private subnet is still inside the city, but it does not expose its residents directly. That separation is the first major design choice in most AWS architectures.
This diagram is intentionally simplified, but it captures the hierarchy most teams use: internet entry at the edge, application workloads protected in private networks, and data systems deeper inside the VPC. The exact services change by architecture, but the direction of exposure should stay deliberate.
Quick AWS networking glossary
VPC
A Virtual Private Cloud is your isolated network boundary inside AWS. It is where you define IP ranges, subnets, routing, and network access patterns.
Subnet
A subnet is a smaller IP range inside a VPC. Teams usually split subnets by availability zone and by purpose, such as public, private, or data.
Route Table
A route table tells traffic where to go next. It decides whether traffic stays local, goes to an Internet Gateway, NAT Gateway, peering connection, or another target.
Load Balancer
A load balancer receives traffic and spreads it across healthy application targets. It gives users one stable entry point while backend instances or pods can change.
Internet Gateway
An Internet Gateway connects a VPC to the public internet. Public subnets need a route to it before internet-facing resources can be reached.
NAT Gateway
A NAT Gateway lets private resources initiate outbound internet traffic. It is commonly used for patching, dependency downloads, and external API calls from private subnets.
Security Group
A Security Group is a stateful firewall attached to workloads. It controls allowed inbound and outbound traffic at the instance or interface level.
NACL
A Network ACL is a subnet-level firewall. It is stateless, so inbound and outbound rules both need to be considered carefully.
How traffic moves
- Route tables decide which road traffic should take.
- An Internet Gateway lets public subnets talk to the internet.
- A NAT Gateway lets private workloads go out to the internet without accepting inbound public traffic.
- VPC peering, Transit Gateway, and VPN/Direct Connect help connect this city with other networks.
The key is remembering that subnets do not become public just because they exist. They become public when their route table sends internet-bound traffic through an Internet Gateway and the workload has a reachable public address.
Where security fits
Security Groups are instance-level door rules: they decide what can enter or leave a workload. NACLs are subnet-level checkpoint rules: they add another layer at the neighborhood boundary.
In day-to-day engineering, Security Groups are usually where most application access is shaped. NACLs are useful for broad subnet-level guardrails, but they are stateless and easier to misconfigure if every inbound and outbound rule is not thought through.
A common production layout
- Public subnets hold load balancers, NAT Gateways, and other internet-facing entry points.
- Private application subnets hold APIs, workers, and services that should not be directly reachable from the internet.
- Isolated data subnets hold databases or internal systems that only selected app layers can reach.
- VPC endpoints keep traffic to AWS services private instead of sending it through the public internet.
Operational checks I like
When debugging network issues, I usually trace from the workload outward: Security Group, subnet route table, NACL, gateway, DNS, and then the destination. This prevents random changes and keeps the investigation grounded in the actual packet path.
For example, if an API in a private subnet cannot download dependencies, I would first check whether it has outbound Security Group rules, then verify the private subnet route table points internet-bound traffic to a NAT Gateway. After that, I would confirm the NAT Gateway sits in a public subnet with a route to the Internet Gateway.
The takeaway
Start with the flow: who needs to talk to whom, from where, and on which ports. Once that is clear, VPCs, subnets, routes, gateways, and firewall rules become design tools instead of confusing AWS names.