When I first started learning AWS networking, the idea of public and private subnets sounded simple.
Public means “internet-facing.”
Private means “not internet-facing.”
Yet, when I actually started building VPCs, everything felt confusing.
Instances behaved in ways I didn’t expect, and I couldn’t clearly explain why something was public or private.
It wasn’t until I understood what really defines a subnet that the concept finally clicked.
This article explains that moment of clarity.
Why Public vs Private Subnets Confused Me Initially
In the beginning, I associated subnets with visibility:
- Public subnet → visible to the internet
- Private subnet → hidden from the internet
But AWS doesn’t label subnets this way.
There is no checkbox called “public” or “private” when you create a subnet.
That alone should have been a hint that something deeper was happening.
Why Everything Felt “Public” at First
Early on, my EC2 instances were reachable from the internet, even when I thought they shouldn’t be.
I had:
- An Internet Gateway attached to the VPC
- EC2 instances with public IPs
- Security groups allowing access
Because things worked, I assumed the subnet was public by default.
What I didn’t realise was that internet access is not about the subnet name — it’s about routing.
The Moment the Concept Finally Clicked
The realisation came when I looked closely at route tables.
A subnet is considered public if:
Its route table has a route to an Internet Gateway
A subnet is considered private if:Its route table does not have a route to an Internet Gateway
That’s it.
Nothing else decides it.
Once I understood that, everything else made sense.
How Routing Tables Actually Define a Subnet
Each subnet in a VPC is associated with a route table.
That route table determines:
- Where traffic can go
- Whether it can reach the internet
- How external traffic returns
If traffic can go directly to the Internet Gateway, the subnet is public.
If it can’t, the subnet is private — even if instances inside it can still access the internet indirectly.
This changed how I thought about subnet design entirely.
Where Internet Gateways and NAT Gateways Belong
Understanding routing also clarified the role of gateways.
Internet Gateway
- Attached at the VPC level
- Used by public subnets
- Allows inbound and outbound internet traffic
NAT Gateway
- Placed in a public subnet
- Used by private subnets for outbound access only
- Prevents inbound internet traffic to private instances
This design allows private resources to reach the internet without being exposed to it.
How This Changed My Architecture Decisions
Once the concept clicked, I stopped placing resources randomly.
Now:
Load balancers and bastion hosts go into public subnets
Application servers and databases go into private subnets
Routing is designed before launching instances
Instead of reacting to connectivity issues, I started designing intentionally.
Top comments (0)