VPC & 클라우드 네트워킹 — 라우팅 테이블 한 줄이 퍼블릭과 프라이빗을 가른다

“서브넷을 퍼블릭으로 만든 게 뭐였더라”

VPC를 처음 다루면 누구나 같은 곳에서 막힙니다. “퍼블릭 서브넷”이라는 체크박스를 찾다 못 찾습니다. 그런 건 없기 때문입니다. 서브넷을 퍼블릭으로 만드는 건 라우팅 테이블의 단 한 줄 — 0.0.0.0/0 → 인터넷 게이트웨이 — 입니다. 이 한 줄이 있으면 퍼블릭, 없으면 프라이빗입니다.

VPC는 마법이 아니라, 이 시리즈에서 쌓은 것들(IP/서브넷, 라우팅, NAT, 방화벽)을 소프트웨어로 다시 그린 것입니다. 그래서 라우팅 테이블만 읽을 줄 알면 VPC의 90%가 풀립니다.

VPC 한 장으로 보기 — 트래픽은 어디로 흐르나

VPC(예 10.0.0.0/16)는 클라우드 속 내 사설 네트워크입니다. 그 안을 서브넷으로 쪼개고, 각 서브넷이 어떤 라우팅 테이블을 보느냐로 성격이 정해집니다. 아래에서 초록은 인터넷으로 직접 나가는 퍼블릭 경로, 주황은 프라이빗 서브넷이 NAT GW를 거쳐 나가는 경로입니다.

프라이빗 서브넷의 인스턴스는 공인 IP가 없어 인터넷에서 직접 도달할 수 없습니다. 밖으로 나가는 트래픽(패키지 다운로드 등)만 NAT GW를 통해 나가고, 그 NAT GW가 퍼블릭 서브넷에서 IGW로 나갑니다. DB·내부 서비스를 이 프라이빗 서브넷에 두는 게 기본 보안 패턴입니다.

1. 서브넷을 가르는 건 라우팅 테이블 한 줄

각 서브넷은 정확히 하나의 라우팅 테이블에 연결됩니다. 그 테이블에 인터넷 게이트웨이(IGW)로 가는 기본 경로가 있느냐가 퍼블릭/프라이빗을 정의합니다.

local 경로는 자동 생성되어 지울 수 없습니다 — VPC 안끼리는 SG/NACL이 막지 않는 한 항상 통신됩니다(longest prefix match로 더 구체적인 local이 항상 우선). 외부 연결성은 오직 0.0.0.0/0의 타깃이 결정합니다.

서브넷	0.0.0.0/0 타깃	인터넷에서 들어옴	인터넷으로 나감
퍼블릭	IGW	가능(공인 IP/EIP 필요)	가능
프라이빗	NAT GW	불가	가능(아웃바운드만)
격리(isolated)	없음	불가	불가

퍼블릭 IP만으론 부족하다. 인스턴스에 공인 IP가 있어도 서브넷 라우팅 테이블에 IGW 경로가 없으면 인터넷이 안 됩니다. “EIP 붙였는데 안 돼요”의 90%가 IGW 라우트 누락입니다. 반대로, 프라이빗 서브넷에 실수로 IGW 라우트를 넣으면 내부용 자원이 통째로 노출됩니다.

2. VPC의 구성요소 지도

flowchart TD
    VPC["VPC (CIDR 10.0.0.0/16)"] --> AZ1["AZ-a"] & AZ2["AZ-c"]
    AZ1 --> PubA["퍼블릭 서브넷"] & PrvA["프라이빗 서브넷"]
    PubA --> IGW["인터넷 게이트웨이"]
    PrvA --> NAT["NAT 게이트웨이<br/>(퍼블릭 서브넷에 위치)"]
    NAT --> IGW
    PubA -.보안.-> SG["SG + NACL"]

• CIDR 블록: VPC 생성 시 10.0.0.0/16 같은 사설 대역을 잡고, 서브넷으로 쪼갭니다. 한 번 정하면 줄이기 어렵고 다른 VPC와 겹치면 피어링 불가하니 처음부터 넓고 안 겹치게.
• 가용영역(AZ): 서브넷은 하나의 AZ에 속합니다. 고가용성은 같은 역할의 서브넷을 여러 AZ에 두고 그 위에 로드밸런서를 얹어 얻습니다(로드밸런싱).
• IGW: VPC와 인터넷의 접점(수평 확장되는 관리형, 단일 장애점 아님). VPC당 하나.
• NAT GW: 프라이빗 서브넷의 아웃바운드 전용 출구. 퍼블릭 서브넷에 놓고 EIP를 붙입니다(시간·데이터 처리량 과금 — 비용 함정 단골).

3. VPC 바깥과 잇기: 피어링 · TGW · 엔드포인트

VPC는 기본적으로 고립돼 있습니다. 다른 네트워크와 잇는 방법이 곧 클라우드 네트워크 설계입니다.

방법	용도	특징 / 함정
VPC 피어링	VPC ↔ VPC 1:1	저렴·저지연. 비전이적(non-transitive): A–B, B–C가 있어도 A–C는 안 됨. CIDR 겹치면 불가
Transit Gateway	다수 VPC·온프레미스 허브	별 구조로 N:N을 한곳에서. 피어링 메시 폭발을 대체
게이트웨이 엔드포인트	S3·DynamoDB 접근	라우팅 테이블에 prefix-list 추가. NAT GW 없이 사설로, 무료
인터페이스 엔드포인트(PrivateLink)	그 외 AWS·SaaS	서브넷에 ENI 생성, 트래픽이 인터넷을 안 탐

피어링 비전이성은 시험과 장애의 단골. 허브-스포크로 여러 VPC를 엮으려고 피어링을 메시로 깔다 보면, “분명 연결했는데 두 단계 건너편이 안 된다”를 만납니다. 라우팅이 전파되지 않기 때문입니다. 규모가 커지면 Transit Gateway가 정답입니다.

4. 보안: SG + NACL은 VPC 위에서 동작

VPC는 무대, 트래픽 통제는 SG와 NACL이 합니다. 프라이빗 서브넷(라우팅상 격리) + SG(인스턴스 정밀 허용) + NACL(서브넷 광역 차단)의 3중 방어가 표준입니다. 프라이빗 서브넷에 DB를 두고, SG에서 “웹 서버 SG로부터의 5432 포트만” 허용하면 IP를 몰라도 최소 권한이 됩니다.

5. 디버깅: 연결이 안 될 때 보는 순서

# 1) 서브넷이 보는 라우팅 테이블에 올바른 경로가 있나
aws ec2 describe-route-tables --filters Name=association.subnet-id,Values=subnet-xxx

# 2) 어디서 막혔나 (SG/NACL vs 라우팅)
#    Flow Logs에 REJECT면 SG/NACL, 애초에 로그가 없으면 라우팅/도달 문제

체크 순서: 라우팅 테이블(경로 존재?) → SG(인바운드 허용?) → NACL(양방향·ephemeral?) → 공인 IP/NAT 경로. 이 순서로 좁히면 대부분의 “연결 안 됨”이 풀립니다. Flow Logs에 패킷이 아예 안 보이면 SG/NACL 이전, 즉 라우팅이나 도달성 문제입니다.

면접/리뷰 단골 질문

• Q. 서브넷을 퍼블릭으로 만드는 건 정확히 무엇인가? → 그 서브넷의 라우팅 테이블에 0.0.0.0/0 → IGW 경로가 있는 것. 체크박스가 아니라 라우트 한 줄.
• Q. 프라이빗 인스턴스가 외부 API를 호출하려면? → NAT GW를 통해 아웃바운드. 인바운드는 여전히 불가. AWS 서비스라면 PrivateLink/게이트웨이 엔드포인트가 더 낫다.
• Q. VPC 피어링으로 3개 이상을 엮을 때 주의점은? → 비전이성. 메시가 폭발하므로 Transit Gateway 허브로. CIDR 중첩 금지.
• Q. EIP를 붙였는데 인터넷이 안 된다? → 라우팅 테이블 IGW 경로, SG 인바운드/아웃바운드, NACL 순으로 점검. 대개 IGW 라우트 누락.

정리

• VPC는 IP·서브넷·라우팅·NAT·방화벽을 소프트웨어로 다시 그린 사설 네트워크다.
• 퍼블릭/프라이빗을 가르는 건 체크박스가 아니라 라우팅 테이블의 0.0.0.0/0 타깃(IGW냐 NAT GW냐).
• 서브넷은 AZ 단위, 고가용성은 다중 AZ + 로드밸런서. IGW는 VPC당 하나, NAT GW는 퍼블릭 서브넷에 두는 아웃바운드 출구.
• VPC 연결은 피어링(비전이·CIDR 비중첩) / Transit Gateway(허브) / 엔드포인트(PrivateLink). 통제는 그 위의 SG + NACL.
• 디버깅은 라우팅 → SG → NACL → 공인IP/NAT 순, 그리고 Flow Logs.

관련 글: 이 무대 위의 트래픽 통제 방화벽·SG·NACL, 주소 변환 NAT, 다중 AZ로 트래픽을 분산하는 로드밸런싱.