Forem: Nirmal Mahale

Public vs Private Subnets in AWS - What Finally Made It Click for Me

Nirmal Mahale — Tue, 06 Jan 2026 17:08:21 +0000

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.

Security Groups vs NACLs — What I Got Wrong at First

Nirmal Mahale — Thu, 25 Dec 2025 18:34:58 +0000

When I started working with AWS, I believed that security groups were enough.

My EC2 instances were running, ports were controlled, and nothing seemed exposed.
So naturally, when I came across Network ACLs (NACLs), I assumed they were optional or redundant.

That assumption turned out to be incomplete.

This article explains what I misunderstood initially, how security groups and NACLs actually differ, and how my approach to AWS network security changed once things clicked.

Why I Thought Security Groups Were Sufficient

Security groups are introduced early when launching EC2 instances.
They are simple to configure and immediately useful.

At the time, my thinking was:

Security groups control traffic
I can restrict ports and IPs
That should be enough

Because everything worked as expected, I didn’t question this setup further.
NACLs felt like something “advanced” that I could ignore for now.

What NACLs Actually Do

A Network ACL works at the subnet level, not the instance level.

Instead of protecting a single EC2 instance, a NACL controls:

What traffic is allowed into a subnet
What traffic is allowed out of a subnet

One key difference I didn’t understand early on:

NACLs are stateless
You must explicitly allow both inbound and outbound traffic

This was very different from security groups.

The Confusion I Had Initially

The main confusion came from overlap.

Both security groups and NACLs:

Control traffic
Use rules
Sit inside a VPC

So my question was:

“Why would I need both?”

The answer is layered security — but that only makes sense once you understand where each one operates.

The Key Differences That Finally Made It Clear

Here’s what helped everything click for me:

Security Groups

Applied at EC2 instance level

Stateful (responses are automatically allowed)

Easier to manage

Ideal for application-level control

Network ACLs

Applied at subnet level

Stateless (inbound and outbound rules required)

Act as a first line of defence

Useful for broad network restrictions

Once I saw this as layers, not duplicates, it made sense.

When Security Groups Are Usually Enough

For small projects or learning environments:

Single EC2 instance
Limited exposure
Controlled IP access

Security groups alone can be sufficient if configured properly.

This is why many beginners never touch NACLs — and that’s okay initially.

When NACLs Start to Matter

NACLs become important when:

You have multiple instances in a subnet
You want a baseline security rule for the network
You need to block or allow traffic at a broader level
You want defence in depth

Instead of trusting every instance configuration, the subnet itself enforces rules.

How I Approach Network Security Now

After understanding both, my approach changed:

Use NACLs for high-level subnet controls
Use security groups for fine-grained instance access
Avoid relying on only one layer
Review rules periodically, not just at setup

Security stopped being something I “set once” and started being something I designed intentionally.

Who This Is Useful For

This lesson is especially relevant if you are:

Learning AWS networking
Confused by overlapping security concepts
Preparing for real-world cloud roles
Moving from tutorials to actual architectures

Understanding this early prevents fragile designs later.

Final Thoughts

Security groups and NACLs are not competitors.
They solve different problems at different layers.

What I got wrong at first wasn’t a configuration mistake —
it was how I thought about security boundaries.

Once that changed, my AWS architectures became clearer, safer, and easier to reason about.

I Thought My AWS EC2 Was Secure — Until I Checked My Security Groups

Nirmal Mahale — Sun, 21 Dec 2025 13:52:03 +0000

When I launched my first EC2 instance on AWS, I felt confident.
The instance was running, I could connect to it, and nothing seemed wrong.

In my mind, that meant one thing: it must be secure.

I was wrong.

It was only when I actually reviewed my security group rules that I realised how exposed my instance really was — and how easily this mistake could be repeated by beginners.

This article documents what I assumed, what I discovered, and what I fixed — so others don’t make the same mistake.

Why I Thought My EC2 Instance Was Secure

Like many beginners, I focused on getting things to work:

The EC2 instance launched successfully
SSH access worked
The application was reachable

At that point, I moved on — assuming security was “handled”.

What I didn’t do initially was question the default and convenience-driven choices I had made while configuring the instance.

That’s where the problem started.

The Security Group Configuration I Initially Used

When creating the EC2 instance, I allowed inbound traffic with rules similar to:

SSH (port 22) → Source: 0.0.0.0/0
HTTP (port 80) → Source: 0.0.0.0/0

At the time, this felt reasonable:

I needed to access the instance
I wanted to test connectivity
AWS allowed it without warnings

But what this actually meant was something much more serious.

What I Realised After Reviewing Security Groups

Security groups are stateful virtual firewalls that control inbound and outbound traffic to EC2 instances.

By allowing traffic from 0.0.0.0/0, I had effectively said:

“Anyone on the internet can try to connect to my instance.”

This includes:

Automated scanners
Bots probing open ports
Malicious actors looking for misconfigured systems

The EC2 instance itself hadn’t changed — but my understanding had.

The Key Mistakes I Made

Looking back, there were three main issues.

1. Overly permissive inbound rules

Allowing SSH from anywhere is one of the most common beginner mistakes.
Even if no one attacks you immediately, the risk is always present.

2. Treating security groups as a setup form

I treated the security group configuration as a checkbox exercise instead of a security boundary.

3. No principle of least privilege

I allowed more access than was actually needed — simply for convenience.

What I Changed to Secure My EC2 Instance

Once I understood the implications, I reworked the configuration.

Restricted SSH access

SSH allowed only from my specific IP address

No global access

Reviewed inbound rules carefully

Only necessary ports were open

Removed unused or temporary rules

Treated security groups as living controls

Regularly reviewed instead of “set and forget”

Adjusted rules based on actual usage

These changes immediately reduced the exposure of the instance.

The Bigger Lesson: AWS Doesn’t Secure Things For You

One important realisation I had is this:

AWS provides the tools — you are responsible for how securely you use them.

EC2 is powerful, but it assumes the user understands:

Networking basics
Access control
Exposure risks

Security groups are not advanced features — they are foundational.

Who This Matters For

This lesson is especially important if you are:

New to AWS
Learning cloud through hands-on projects
Deploying EC2 for the first time
Preparing for real-world cloud roles

Understanding security groups early will save you from bigger problems later.

What I’ll Improve Next

This experience pushed me to think beyond basic setup:

Using bastion hosts instead of direct SSH
Automating security checks
Adding monitoring and logging
Designing architectures that reduce public exposure entirely

Security is not a one-time task — it’s an ongoing practice.

Final Thoughts

My EC2 instance wasn’t insecure because AWS failed.
It was insecure because I hadn’t fully understood what I was allowing.

Checking your security groups takes minutes — but it can prevent serious issues.

If you’re learning AWS, start there.