Public vs Private Subnets: The AWS Networking Concept That Finally Clicked for Me

A beginner-friendly explanation of public and private subnets in AWS, how route tables determine network access, and why production architectures commonly keep application and database resources private.

Prince Malviya

Published Oct 2, 2026

Last modified Oct 2, 2026

After learning the basics of Amazon VPC, I came across a question that seemed simple:

What actually makes a subnet public or private?

At first, I thought it was a setting inside the subnet.

It isn't.

The answer comes down mainly to routing.

Once I understood that, AWS networking became much easier to visualize.

🏗️ First, What Is a Subnet?

A subnet is a smaller network inside a VPC.

For example, suppose my VPC uses:

1
10.0.0.0/16

I can divide it into smaller networks:

1
2
3
4
5
6
7
8
9
10
VPC: 10.0.0.0/16

├── Public Subnet
│   └── 10.0.1.0/24
│
├── Private Subnet
│   └── 10.0.2.0/24
│
└── Private Subnet
    └── 10.0.3.0/24

This gives me a way to organize resources and control how they communicate.

🌐 What Makes a Subnet Public?

Here's the key idea:

A subnet is considered public when its associated route table has a route to an Internet Gateway.

For example:

1
2
3
4
Destination       Target

10.0.0.0/16       local
0.0.0.0/0         Internet Gateway

The important route is:

1
0.0.0.0/0 → Internet Gateway

It means traffic destined outside the VPC can be sent toward the Internet Gateway.

🖥️ Example: Public Web Server

Imagine I launch an EC2 instance in a public subnet.

The architecture might look like:

1
2
3
4
5
6
7
8
9
10
                🌍 Internet
                     │
                     ▼
             Internet Gateway
                     │
                     ▼
              Public Subnet
                     │
                     ▼
                  EC2

But there's an important detail:

Having a public subnet doesn't automatically make every resource publicly accessible.

The resource's network configuration and security controls also matter.

For example, an EC2 instance intended to serve a website would generally need appropriate IP addressing and security-group rules.

🔒 What Is a Private Subnet?

A private subnet does not have a direct route to an Internet Gateway for internet access.

For example:

1
2
3
Destination       Target

10.0.0.0/16       local

There is no:

1
0.0.0.0/0 → Internet Gateway

route.

This makes private subnets useful for resources that shouldn't be directly reachable from the public internet.

🗄️ Why Put Databases in Private Subnets?

Consider a typical application:

1
2
3
4
5
6
7
8
9
10
11
                    🌍 Internet
                         │
                         ▼
                  Public Subnet
                         │
                    Web Server
                         │
                         ▼
                  Private Subnet
                         │
                     Database

Users need to reach the web application.

They generally don't need direct internet access to the database.

So separating the application and database layers provides a stronger network boundary.

The database can communicate with the application while avoiding direct exposure to the public internet.

🔄 But What If a Private Server Needs Internet Access?

This is where another AWS networking component becomes important:

NAT Gateway

A common architecture looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
                    🌍 Internet
                         │
                         ▼
                 Internet Gateway
                         │
                         ▼
                  Public Subnet
                         │
                    NAT Gateway
                         │
                         ▼
                  Private Subnet
                         │
                    EC2 / App

The private resource can initiate outbound internet connections through the NAT Gateway.

However, the internet cannot use that NAT Gateway to directly initiate a connection back to the private resource.

This pattern is useful when private workloads need things such as:

Software updates
Downloading packages
Accessing external APIs
Fetching other internet-based resources

🧭 Route Tables Are the Real Key

This was probably the most important concept I learned.

AWS doesn't simply label a subnet:

"PUBLIC"

"PRIVATE"

and magically handle everything.

Instead, routing determines where network traffic can go.

Public route table

1
2
3
4
Destination       Target
--------------------------------
10.0.0.0/16       local
0.0.0.0/0         Internet Gateway

Private route table

1
2
3
4
Destination       Target
--------------------------------
10.0.0.0/16       local
0.0.0.0/0         NAT Gateway

The second configuration provides outbound internet access through NAT while keeping the workload from having a direct route through an Internet Gateway.

🔐 Security Groups Still Matter

Here's another important lesson:

Routing and security are different things.

Even if a resource is in a public subnet, a Security Group can restrict which traffic is allowed to reach it.

For example:

1
2
3
4
5
6
7
8
9
Inbound

HTTPS
Port: 443
Source: Internet

SSH
Port: 22
Source: Trusted IP only

So when troubleshooting connectivity, I shouldn't only check the route table.

I also need to check:

Security Groups
Network ACLs
IP addressing
Route tables
Internet Gateway
NAT configuration
Application configuration

🏢 A Production-Style Architecture

Putting everything together:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
                         🌍 Internet
                              │
                              ▼
                     Internet Gateway
                              │
                              ▼
                   ┌─────────────────┐
                   │  Public Subnet  │
                   │                 │
                   │ Load Balancer   │
                   └────────┬────────┘
                            │
                            ▼
                   ┌─────────────────┐
                   │ Private Subnet  │
                   │                 │
                   │ Application     │
                   │ Servers         │
                   └────────┬────────┘
                            │
                            ▼
                   ┌─────────────────┐
                   │ Private Subnet  │
                   │                 │
                   │ Database        │
                   └─────────────────┘

For outbound internet access from the private application layer:

1
2
3
4
5
6
7
8
9
10
Private Subnet
      │
      ▼
 NAT Gateway
      │
      ▼
Internet Gateway
      │
      ▼
  Internet

This separates the public-facing components from internal application and database resources.

🧠 The Mental Model I Now Use

Whenever I see an AWS subnet, I ask three questions:

1️⃣ Where is the subnet?

Is it part of the VPC I expect?

2️⃣ What does its route table say?

Does it have a route to:

1
2
3
Internet Gateway?
NAT Gateway?
Another network?

3️⃣ What security rules apply?

Even if routing allows traffic, Security Groups and Network ACLs can still affect connectivity.

⚠️ Common Beginner Mistakes

Here are a few things I would check when building a VPC:

❌ Mistake 1: Assuming a subnet is public just because it has an EC2 instance

The subnet's routing matters.

❌ Mistake 2: Assuming an Internet Gateway alone gives internet access

The routing and resource configuration also need to be correct.

❌ Mistake 3: Putting databases directly in public subnets

Databases generally don't need direct public internet exposure.

❌ Mistake 4: Forgetting security rules

A correct route doesn't mean traffic is automatically allowed.

❌ Mistake 5: Forgetting NAT Gateway costs

NAT Gateways can incur charges, so I should clean them up when they're no longer needed for a lab.

🎯 Final Takeaway

The biggest lesson for me was simple:

Public vs private isn't just about where a resource is placed. It's about how traffic is routed.

My mental model now looks like this:

1
2
3
4
5
6
7
8
9
VPC
 │
 ├── Public Subnet
 │      │
 │      └── Internet Gateway
 │
 └── Private Subnet
        │
        └── NAT Gateway → Internet

Once I understood subnets + route tables + gateways, AWS networking started to feel much less mysterious.

Next, I'm diving deeper into another important AWS networking topic:

Security Groups vs Network ACLs.

# amazon-vpc # tutorials

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.

Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article

Builder Center

Public vs Private Subnets: The AWS Networking Concept That Finally Clicked for Me

Prince Malviya

🏗️ First, What Is a Subnet?

🌐 What Makes a Subnet Public?

🖥️ Example: Public Web Server

🔒 What Is a Private Subnet?

🗄️ Why Put Databases in Private Subnets?

🔄 But What If a Private Server Needs Internet Access?

🧭 Route Tables Are the Real Key

Public route table

Private route table

🔐 Security Groups Still Matter

🏢 A Production-Style Architecture

🧠 The Mental Model I Now Use

1️⃣ Where is the subnet?

2️⃣ What does its route table say?

3️⃣ What security rules apply?

⚠️ Common Beginner Mistakes

❌ Mistake 1: Assuming a subnet is public just because it has an EC2 instance

❌ Mistake 2: Assuming an Internet Gateway alone gives internet access

❌ Mistake 3: Putting databases directly in public subnets

❌ Mistake 4: Forgetting security rules

❌ Mistake 5: Forgetting NAT Gateway costs

🎯 Final Takeaway