There Is No Such Attribute as "Public Subnet"

한 줄 요약

서브넷에 '퍼블릭' 이라는 설정은 존재하지 않습니다. 라우팅 테이블에 인터넷 게이트웨이로 가는 기본 경로가 있으면 퍼블릭이고, 없으면 프라이빗입니다. 그게 전부입니다.

왜 이게 필요했나

"퍼블릭 서브넷에 넣었는데 인터넷이 안 돼요" 라는 질문에 답하려면 이 사실을 알아야 합니다. 이름을 public-subnet-a 로 지었다고 퍼블릭이 되지 않습니다.

인스턴스가 인터넷에 나가려면 네 가지가 전부 맞아야 합니다.

1. 서브넷의 라우팅 테이블에 0.0.0.0/0 → igw-xxx 가 있다
2. 인스턴스에 공인 IP 가 붙어 있다
3. 보안그룹의 아웃바운드가 허용한다
4. 네트워크 ACL 이 인바운드·아웃바운드 양쪽을 허용한다

하나라도 빠지면 안 됩니다. 그리고 증상이 전부 "안 된다" 로 같아서 순서대로 확인하는 습관이 필요합니다.

표준 3계층 배치

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 — 인터넷으로 나가는 경로 자체가 없음

원칙은 하나입니다 — 인터넷에서 직접 닿을 수 있는 것을 최소로. 로드밸런서만 앞에 두고 나머지는 전부 뒤에 숨깁니다.

서브넷 크기를 다르게 잡은 것도 의도적입니다. 퍼블릭에는 몇 개 안 들어가고, 앱 계층은 오토스케일링으로 많이 늘어납니다.

각 AZ 마다 서브넷을 따로 만드는 이유

서브넷은 하나의 AZ 안에만 존재합니다. 여러 AZ 에 걸칠 수 없습니다. 그래서 다중 AZ 구성을 하려면 계층마다 AZ 개수만큼 서브넷이 필요합니다. 3계층 × 2 AZ = 서브넷 6개가 최소입니다.

라우팅 테이블 읽는 법

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

가장 구체적인 경로가 이깁니다(longest prefix match). 10.0.0.0/16 은 /16 이라 0.0.0.0/0 보다 구체적이므로 VPC 내부 통신은 인터넷으로 나가지 않습니다. 이 규칙을 알면 온프레미스 연결이 왜 그렇게 동작하는지도 설명됩니다.

프라이빗 서브넷의 아웃바운드

DB 는 인터넷에 노출되면 안 되지만 패키지 업데이트는 받아야 합니다. 그래서 NAT 게이트웨이를 씁니다.

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

NAT 는 나가는 것만 허용합니다. 밖에서 먼저 연결을 시작할 수 없습니다. 이 비대칭이 프라이빗 서브넷의 핵심입니다.

주의 — NAT 게이트웨이는 시간당 요금 + 처리 데이터 요금이 붙습니다. 프라이빗 서브넷에서 대용량을 계속 내려받으면 여기서 비용이 크게 납니다. 다음 코스에서 다시 다룹니다.

연결이 안 될 때 보는 순서

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

이 순서로 보면 대부분 3단계 안에 원인이 나옵니다.

대역을 정할 때 되돌리기 어려운 결정

서브넷 나누기는 나중에 고치기가 매우 어렵다. VPC 의 대역은 만든 뒤에 줄일 수 없고, 서브넷은 안에 자원이 있으면 지울 수 없다. 처음 30분에 정한 것이 몇 년 간다.

남의 대역과 겹치면 그때부터 우회 비용이 붙는다. 사내 대역, 다른 팀의 VPC, 인수한 회사의 네트워크, VPN 으로 붙을 협력사 — 언젠가 이어야 할 상대와 겹치면 피어링도 VPN 도 안 된다. RFC 1918 은 넓으니 흔한 자리를 피한다: 10.0.0.0/16 과 192.168.0.0/24 는 누구나 먼저 고르는 대역이다.

서브넷은 크게 잡는다. IP 는 공짜이고 부족은 비싸다. /24(약 250개)로 시작했다가 파드마다 IP 를 쓰는 컨테이너 네트워크를 붙이는 순간 바닥난다. 클라우드가 서브넷마다 다섯 개를 예약해 간다는 것도 계산에 넣는다.

용도	권장	이유
VPC	/16	나중에 넓힐 수는 있어도 번거롭다
퍼블릭 서브넷	/24	로드밸런서와 NAT 정도만 들어간다
프라이빗 서브넷	/20 이상	파드·태스크가 IP 를 먹는다
데이터 서브넷	/24	인스턴스 수가 적다

AZ 마다 나누되 규칙적으로 나눈다. 세 번째 옥텟을 AZ 로 쓰는 식으로 정해 두면, 주소만 보고 어디인지 안다. 규칙이 없으면 몇 달 뒤 라우팅 표를 읽을 때마다 문서를 찾게 된다.

연결이 안 될 때 보는 순서는 언제나 같다. 아래로 갈수록 드물다.

1. 보안 그룹 — 상태를 기억하므로 돌아오는 길은 열지 않아도 된다
2. 네트워크 ACL — 상태를 기억하지 않으므로 응답용 임시 포트 범위도 열어야 한다
3. 라우팅 표 — 그 서브넷에 목적지로 가는 경로가 있는가
4. 대상의 상태 — 그 포트를 실제로 듣고 있는가
5. 대상 쪽 OS 방화벽

1번과 2번을 헷갈리는 것이 가장 흔한 사고다. ACL 에서 인바운드만 열고 아웃바운드 1024-65535 를 안 열면, 요청은 들어가는데 응답이 못 나온다. 증상은 "연결이 되다 말다 한다" 로 나타나서 원인을 찾기 어렵다.

현장에서 만나는 모습

• 이름이 public-subnet-a 인데 인터넷이 안 됩니다. 라우팅 테이블에 IGW 로 가는 기본 경로가 없었습니다 — 이름은 아무 효력이 없습니다.
• 로드밸런서를 서브넷 하나에만 붙여 두고 다중 AZ 라고 믿었습니다. 서브넷은 AZ 하나에만 존재하므로 그 구성은 단일 AZ 였습니다.
• 프라이빗 서브넷에서 패키지 업데이트가 안 됩니다. NAT 는 만들어 두었지만 그 서브넷이 다른 라우팅 테이블에 연결돼 있었습니다.
• DB 를 퍼블릭 서브넷에 두고 보안그룹으로만 막다가, 규칙 한 줄을 잘못 여는 날 그대로 노출됐습니다. 계층을 나누는 것은 실수 하나가 사고가 되지 않게 하는 장치입니다.

다음에 볼 것

보안그룹과 NACL — 이름이 비슷하지만 동작 방식이 근본적으로 다릅니다.