There Is No Such Attribute as "Public Subnet"

In one line

There is no "public" setting on a subnet. If the route table has a default route to an internet gateway, it is public, and if not, it is private. That is all.

Why it was needed

To answer the question "I put it in a public subnet and the internet doesn't work," you need to know this fact. Naming it public-subnet-a does not make it public.

For an instance to reach the internet, all four things must be right.

1. The subnet's route table has 0.0.0.0/0 → igw-xxx
2. The instance has a public IP attached
3. The security group's outbound allows it
4. The network ACL allows both inbound and outbound

If even one is missing, it fails. And because every symptom is the same "it doesn't work," you need the habit of checking in order.

The standard 3-tier layout

VPC 10.0.0.0/16
├─ 퍼블릭 서브넷   10.0.0.0/24,  10.0.1.0/24    (AZ-a, AZ-b)
│   └ 로드밸런서, NAT 게이트웨이, 배스천
├─ 앱 서브넷       10.0.16.0/20, 10.0.32.0/20
│   └ 애플리케이션 서버 — 공인 IP 없음
└─ 데이터 서브넷   10.0.48.0/24, 10.0.49.0/24
    └ DB — 인터넷으로 나가는 경로 자체가 없음

There is one principle — minimize what can be reached directly from the internet. Put only the load balancer in front and hide everything else behind it.

Making the subnet sizes different is also intentional. Only a few things go into public, and the app tier grows a lot through autoscaling.

Why you create a separate subnet in each AZ

A subnet exists inside only one AZ. It cannot span several AZs. So to build a multi-AZ setup, you need as many subnets per tier as there are AZs. 3 tiers × 2 AZs = 6 subnets is the minimum.

How to read a route table

목적지            대상
10.0.0.0/16      local          ← VPC 내부. 지울 수 없다
0.0.0.0/0        igw-abc123     ← 나머지 전부 인터넷으로

The most specific route wins (longest prefix match). 10.0.0.0/16 is a /16, so it is more specific than 0.0.0.0/0, and traffic inside the VPC does not go out to the internet. If you know this rule, it also explains why an on-premises connection behaves the way it does.

Outbound from a private subnet

The DB must not be exposed to the internet, but it still has to receive package updates. So you use a NAT gateway.

프라이빗 라우팅 테이블
0.0.0.0/0  →  nat-xyz   (퍼블릭 서브넷에 있는 NAT)

NAT allows only outgoing traffic. Nothing outside can start a connection first. This asymmetry is the heart of a private subnet.

Note — a NAT gateway has an hourly charge plus a data processing charge. If a private subnet keeps downloading large volumes, the cost becomes significant here. We cover this again in the next course.

The order to check when a connection fails

1. 보안그룹      — 가장 흔하다. 인바운드 규칙 확인
2. 라우팅 테이블 — 그 목적지로 가는 경로가 있나
3. NACL          — 서브넷 수준. 아웃바운드도 확인(상태 비저장이라 양방향 필요)
4. 공인 IP       — 퍼블릭 접근이면 붙어 있나
5. 대상 자체     — 프로세스가 그 포트에서 듣고 있나

If you check in this order, the cause turns up within 3 steps in most cases.

Decisions that are hard to undo when choosing ranges

Subnet layout is very hard to fix later. A VPC's range cannot be shrunk after it is created, and a subnet cannot be deleted if it contains resources. What you decide in the first 30 minutes lasts for years.

If you overlap with someone else's range, from then on you pay a cost to work around it. The company's internal range, another team's VPC, an acquired company's network, a partner that will connect by VPN — if you overlap with anyone you will one day have to connect to, neither peering nor VPN works. RFC 1918 is wide, so avoid the common spots: 10.0.0.0/16 and 192.168.0.0/24 are ranges everyone picks first.

Make subnets large. IPs are free and running short is expensive. You start with a /24 (about 250 addresses), and it runs out the moment you add a container network where every Pod uses an IP. Also factor in that the cloud reserves five addresses per subnet.

Purpose	Recommended	Reason
VPC	/16	You can widen it later, but it is a hassle
Public subnet	/24	Only load balancers and NAT go in
Private subnet	/20 or larger	Pods and tasks eat IPs
Data subnet	/24	The number of instances is small

Split per AZ, and split regularly. If you decide, for example, to use the third octet as the AZ, you can tell where something is just from the address. Without a rule, a few months later you will look for the documentation every time you read a route table.

The order to check when a connection fails is always the same. The further down, the rarer.

1. Security group — it remembers state, so you don't need to open the return path
2. Network ACL — it does not remember state, so you must also open the ephemeral port range for replies
3. Route table — does that subnet have a route to the destination
4. The state of the target — is it actually listening on that port
5. The OS firewall on the target

Confusing 1 and 2 is the most common incident. If you open only inbound in the ACL and do not open outbound 1024-65535, requests get in but replies cannot get out. The symptom appears as "the connection works on and off," which makes the cause hard to find.

What it looks like in the field

• The name is public-subnet-a but the internet doesn't work. The route table had no default route to an IGW — the name has no effect.
• A load balancer was attached to just one subnet and everyone believed it was multi-AZ. A subnet exists in only one AZ, so that setup was single-AZ.
• Package updates do not work from a private subnet. A NAT had been created, but that subnet was associated with a different route table.
• A DB was placed in a public subnet and protected only by a security group, and on the day one rule was opened by mistake, it was exposed as it was. Separating tiers is a device that keeps a single mistake from becoming an incident.

What to look at next

Security groups and NACLs — the names are similar, but they work in fundamentally different ways.