[Cloud] VPC와 서브넷 — 퍼블릭·프라이빗을 가르는 법

🚨INCIDENT ALERT

HIGH

DB를 빨리 띄우려고 퍼블릭 서브넷에 공인 IP까지 붙여 만들었습니다. 일주일 뒤, 무차별 대입 로그가 폭주하고 누군가 5432 포트를 두드리고 있습니다. 알고 보니 DB가 인터넷에 그대로 노출돼 있던 것. VPC 설계는 "무엇을 인터넷에 보이게 하고, 무엇을 숨길 것인가"의 문제입니다. 라우팅 한 줄이 보안 경계가 됩니다.

이번 챕터에서 배울 것

1VPC가 '내 사설 네트워크'라는 개념을 설명할 수 있다
2서브넷을 IP 대역으로 쪼개고 AZ에 배치하는 구조를 안다
3퍼블릭/프라이빗을 가르는 진짜 기준이 라우팅임을 이해한다
4IGW와 NAT 게이트웨이의 역할 차이를 구분할 수 있다
53티어 구조에서 무엇을 어느 서브넷에 둘지 판단할 수 있다

내 사설 네트워크 짓기

💡개념

VPC와 서브넷 — 대지와 구획

VPC는 클라우드 안에 만드는 격리된 사설 네트워크입니다. 먼저 IP 대역(CIDR, 예: 10.0.0.0/16 = 약 6.5만 개 주소)을 정합니다. 그 대지를 서브넷으로 구획합니다(예: 10.0.1.0/24).

서브넷은 하나의 AZ에 속합니다. 그래서 고가용성을 위해 같은 역할의 서브넷을 여러 AZ에 하나씩 둡니다(퍼블릭-a, 퍼블릭-c, 프라이빗-a, 프라이빗-c …). IaaS·PaaS·SaaS와 리전·AZ의 Multi-AZ가 네트워크 레벨에서 이렇게 구현됩니다.

💡개념

퍼블릭 vs 프라이빗 — 라우팅과 주소·정책을 함께 확인

서브넷에 'public/private'이라는 이름은 관습일 뿐입니다. 라우팅 테이블의 IGW 경로, 인스턴스의 공인 주소, 보안그룹·NACL 정책을 함께 확인해야 실제 인터넷 통신 여부를 판단할 수 있습니다.

퍼블릭 경로: 라우팅에 0.0.0.0/0 → 인터넷 게이트웨이(IGW)가 있고, 인스턴스에 공인 IP/EIP와 허용 정책이 있어야 인터넷과 통신할 수 있습니다.
프라이빗 경로: IGW 직접 경로 대신 NAT 등 내부 경로를 사용하며, 외부에서 시작하는 직접 연결은 허용하지 않도록 구성합니다.

웹 서버·로드밸런서는 퍼블릭, 앱 서버·DB는 프라이빗에 두는 것이 기본입니다.

VPC 3티어 — 퍼블릭/프라이빗 서브넷, IGW, NAT 확대

보안 그룹 vs NACL — 인스턴스 방화벽 vs 서브넷 방화벽 확대 위 그림처럼 보안 그룹은 인스턴스 단위의 상태 기반 방화벽이고, NACL은 서브넷 단위의 무상태 방화벽입니다. 트래픽이 막히면 두 층을 모두 확인해야 합니다.

NAT 게이트웨이 — 프라이빗 인스턴스의 아웃바운드 흐름 확대 위 그림처럼 프라이빗 인스턴스는 NAT 게이트웨이를 통해 인터넷에 나갈 수 있지만, 인터넷에서 먼저 들어오는 것은 차단됩니다.

💡개념

IGW vs NAT — 들어오기 vs 나가기

인터넷 게이트웨이(IGW) 는 VPC와 인터넷을 잇는 문입니다. 퍼블릭 서브넷이 양방향으로 인터넷과 통신하게 합니다.

NAT 게이트웨이는 프라이빗 서브넷 인스턴스의 나가는(아웃바운드) 통신만 대행합니다. 프라이빗 DB·앱 서버가 외부에서 직접 닿지는 못하되, OS 패치·외부 API 호출은 할 수 있게 해줍니다. NAT는 퍼블릭 서브넷에 두고, 프라이빗 라우팅이 0.0.0.0/0 → NAT를 향하게 합니다.

패킷은 여섯 관문을 지난다 — 라우팅·보안그룹·NACL

💡개념

VPC 안에서 패킷이 목적지에 닿는 법 — 라우팅·보안그룹·NACL 평가

프라이빗 서브넷의 앱에서 외부 API를 호출했는데 응답이 없습니다. 라우트 테이블이 문제인지, 보안그룹인지, NACL인지 — 세 층 중 어디서 막혔는지 모르면 아무 데나 열어보다 보안 구멍만 냅니다. VPC 안에서 패킷 하나가 나갈 때는 라우트 조회 → 아웃바운드 보안그룹 → 아웃바운드 NACL → 다음 홉을 순서대로 지나고, 도착지에서는 인바운드 NACL → 인바운드 보안그룹을 다시 지납니다. 이 여섯 관문을 순서로 알면 "왜 막히나"를 한 층씩 좁힐 수 있습니다.

TEXT

[EC2 인스턴스]  10.0.11.20 → 8.8.8.8 로 패킷 송신
   │
   ① 서브넷의 라우트 테이블 조회          (목적지 대역 → 가장 구체적 경로 매칭)
   │    10.0.0.0/16 → local · 0.0.0.0/0 → NAT GW(퍼블릭 서브넷) 또는 IGW(퍼블릭)
   │
   ② 아웃바운드 보안그룹(SG) 평가         (stateful · 허용 규칙만 존재)
   │    → 나간 연결을 상태로 기억 → 돌아오는 응답은 자동 허용
   │
   ③ 서브넷 NACL 아웃바운드 평가          (stateless · 번호 낮은 규칙부터 · 허용/거부)
   │    → 인·아웃을 각각 따로 평가 → 응답 트래픽도 별도 규칙 필요
   │
   ④ 라우트가 정한 다음 홉으로 전달        (local · NAT GW · IGW · 피어링 · TGW …)
   ▼
[도착지 서브넷]  들어오는 패킷은 역순 두 관문
   ⑤ 인바운드 NACL(stateless) → ⑥ 인바운드 SG(stateful)
   ▼
[도착지 인스턴스]  여섯 관문을 모두 통과해야 도달

각 관문이 하는 일과, 막히면 나타나는 증상:

관문	하는 일	여기서 막히면
① 라우트 조회	목적지 IP가 어느 타깃(local·IGW·NAT·피어링)으로 갈지 가장 구체적 경로로 결정. 퍼블릭 서브넷은 `0.0.0.0/0 → IGW`, 프라이빗은 `0.0.0.0/0 → NAT GW`	경로 자체가 없음 → 나갈 길이 없어 타임아웃. 프라이빗에 NAT 경로 누락 → 아웃바운드 전부 실패
② 아웃바운드 SG	인스턴스 레벨 stateful 방화벽. 허용 규칙만 있고 거부 규칙은 없음. 나간 연결은 기억돼 응답이 자동 허용	아웃바운드를 좁혀둔 SG에서 대상 포트 미허용 → 나가는 첫 패킷부터 막힘(기본 아웃바운드는 all-allow라 드묾)
③ 아웃바운드 NACL	서브넷 레벨 stateless 방화벽. 번호 순 첫 매칭 규칙 적용, 허용·거부 모두 가능. 응답은 별도 규칙 필요	ephemeral 포트(1024-65535) 응답 허용 누락 → 나가긴 하는데 응답이 NACL에서 막혀 "간헐 실패"처럼 보임
④ 다음 홉	라우트가 정한 타깃으로 전달. NAT GW는 소스를 공인 IP로 치환, IGW는 공인 IP 가진 인스턴스만 통과	프라이빗 인스턴스가 공인 IP 없이 IGW로 라우팅 → 나가도 돌아올 주소가 없어 실패
⑤ 인바운드 NACL	도착 서브넷의 stateless 규칙을 인바운드 방향으로 평가	인바운드 규칙에 소스 대역·포트 누락 → 도착 직전 REJECT
⑥ 인바운드 SG	도착 인스턴스의 stateful 규칙. 소스(대역 또는 다른 SG)·포트가 허용돼야 도달	인바운드 SG에 소스·포트 미허용 → `Connection timed out`(SG는 조용히 드롭)

즉 "왜 막히나"는 이 여섯 관문 중 어디서 끊겼는지의 문제입니다. 진단의 갈림길은 보안그룹(stateful·허용 전용·인스턴스 레벨)과 NACL(stateless·허용/거부·서브넷 레벨)의 차이입니다 — SG는 나간 연결의 응답을 자동으로 허용하지만, NACL은 인·아웃을 따로 평가하므로 "나가는데 응답이 안 온다"면 NACL의 ephemeral 포트(응답용) 규칙을 먼저 봅니다. 확정 도구는 VPC Flow Logs의 ACCEPT/REJECT 기록입니다 — REJECT가 찍히면 SG·NACL에서 걸린 것이고, 기록 자체가 없으면 라우팅(①)에서 길을 못 찾은 것입니다.

무엇을 어느 서브넷에 둘까

로드밸런서, 배스천 호스트, NAT 게이트웨이퍼블릭 서브넷인터넷과 직접 통신 필요

애플리케이션 서버(LB 뒤)프라이빗 서브넷LB를 통해서만 트래픽 수신

데이터베이스, 캐시, 내부 큐프라이빗 서브넷인터넷 노출 차단, 앱에서만 접근

프라이빗 인스턴스의 OS 패치·외부 APINAT 게이트웨이 경유아웃바운드만 허용

1VPC와 서브넷 구조 한눈에 보기

어떤 서브넷이 어느 AZ에 있고 공인 IP 자동할당이 켜져 있는지 확인합니다.

로컬 터미널

aws ec2 describe-subnets --filters Name=vpc-id,Values=$VPC_ID \
  --query "Subnets[].{Sub:SubnetId,AZ:AvailabilityZone,Cidr:CidrBlock,PubIP:MapPublicIpOnLaunch}" --output table

OUTPUT

+----------------+------------------+--------------+--------+
|  subnet-0a..   |  ap-northeast-2a |  10.0.1.0/24 |  True  |  ← 퍼블릭
|  subnet-0b..   |  ap-northeast-2a |  10.0.11.0/24|  False |  ← 프라이빗
+----------------+------------------+--------------+--------+

aws ec2 describe-subnets

2라우팅 테이블로 퍼블릭/프라이빗 판별

진짜 판별 기준인 라우팅을 확인합니다. IGW 경로 유무로 성격이 갈립니다.

로컬 터미널

aws ec2 describe-route-tables --filters Name=vpc-id,Values=$VPC_ID \
  --query "RouteTables[].Routes[?DestinationCidrBlock=='0.0.0.0/0'].GatewayId" --output text

OUTPUT

igw-0abc123     # 이 라우팅 테이블 → 퍼블릭
nat-0def456     # 이 라우팅 테이블 → 프라이빗(아웃바운드만)

aws ec2 describe-route-tables

🔍실행 후 확인할 것

MapPublicIpOnLaunch=True인 서브넷에 DB/앱이 떠 있는지 — 노출되면 안 되는 자원이 퍼블릭이면 즉시 프라이빗으로 이전 검토
0.0.0.0/0이 igw로 가는 라우팅 테이블에 연결된 서브넷 목록 — 의도한 퍼블릭 서브넷만인지 확인
같은 역할의 서브넷이 2개 이상 AZ에 있는지 — 한 AZ에만 있으면 Multi-AZ 고가용성 불가
NAT 게이트웨이가 떠 있는지와 시간당 과금 — NAT는 상시 과금 + 데이터 처리 요금. 미사용 NAT는 비용 누수(클라우드 비용 최적화)

상황: 프라이빗 인스턴스가 외부(패키지 저장소)로 나가지 못함.

원인: 프라이빗 서브넷에 NAT 게이트웨이로 가는 아웃바운드 경로가 없음. 외부에서 들어오는 건 막는 게 맞지만, 나가는 길까지 없으면 패치·외부 호출이 안 됩니다. (DNS 해석 실패면 VPC의 DNS 설정도 점검.)

진단: 해당 서브넷의 라우팅 테이블에 0.0.0.0/0 → nat-...가 있는지 확인 → NAT 게이트웨이가 퍼블릭 서브넷에 정상 상태인지 확인.

해결: 프라이빗 서브넷 라우팅에 NAT 게이트웨이 경로 추가. NAT는 반드시 IGW가 있는 퍼블릭 서브넷에 위치해야 함. 패키지만 받으면 되는 경우 VPC 엔드포인트(인터넷 안 거치고 클라우드 서비스 직접 접근)로 NAT 비용을 줄이기도 합니다.

심화 — 오래 쓰는 VPC는 비용과 대역 계획이 가른다

💡개념

심화: NAT 요금의 두 축과 VPC 엔드포인트 — 아웃바운드에도 청구서가 붙는다

NAT 게이트웨이는 조용한 과금 장치입니다. 요금이 두 축이라는 것을 모르면 트래픽이 커진 뒤에 당합니다.

시간당 요금: 떠 있기만 해도 나가는 고정비 — 예측 가능한 쪽입니다.
데이터 처리 요금: NAT를 통과하는 GB마다 붙습니다(서울 리전 기준 시간당·GB당 각각 약 0.059달러). 프라이빗 서브넷의 앱이 S3에서 대용량 데이터를 읽으면 같은 리전인데도 그 전량에 처리 요금이 붙고, 트래픽이 커질수록 이 축이 청구서를 지배합니다.
탈출구 — VPC 엔드포인트의 두 종류: S3·DynamoDB용 게이트웨이 엔드포인트는 라우팅 테이블에 경로 한 줄을 추가하는 방식이고 무료입니다. 그 외 서비스는 인터페이스 엔드포인트(PrivateLink) — 시간당·GB당 과금이 있지만 NAT 처리 요금보다 쌉니다. 인터넷을 아예 거치지 않으니 보안 면에서도 이득입니다.
NAT 개수의 트레이드오프: AZ마다 두면 고정비가 배로 늘고, 하나만 두면 ① 다른 AZ의 트래픽이 AZ를 건너며 추가 전송료를 내고 ② 그 AZ 장애 시 프라이빗 서브넷 전체의 아웃바운드가 끊깁니다. 운영 환경은 AZ당 하나, 개발 환경은 하나로 절충하는 게 흔한 답입니다.

프라이빗 서브넷 설계의 완성은 "나가는 트래픽이 어떤 경로로, GB당 얼마에 나가는가"까지 그리는 것입니다(클라우드 비용 최적화).

상황: 서비스가 커져 다른 팀의 내부 API를 VPC 피어링으로 직접 연결하려는데 피어링 요청이 즉시 실패합니다. 얼마 뒤 온프레미스와 VPN을 잇던 프로젝트(하이브리드 연결)에서도 같은 문제가 튀어나왔습니다 — 사내망도 10.0.0.0/16이었던 것입니다.

원인: 모두가 튜토리얼 기본값 10.0.0.0/16을 복붙해 VPC를 만든 결과입니다. 라우팅은 목적지 IP 대역으로 길을 정하는데, 양쪽 대역이 겹치면 10.0.1.5가 우리 쪽인지 상대 쪽인지 구분할 수 없으므로 겹치는 VPC 간 피어링은 아예 거부됩니다.

진단: aws ec2 describe-vpcs --query "Vpcs[].CidrBlock"으로 연결할 양쪽 VPC(그리고 온프레 대역까지)의 CIDR을 목록화 → 겹치는 구간 확인.

해결: VPC의 기본 CIDR은 만든 뒤 바꿀 수 없습니다. 보조 CIDR을 추가해도 겹침 자체는 해소되지 않아, 실질적인 답은 한쪽 VPC를 새 대역으로 재구축해 자원을 이사시키는 것 — 자원이 많이 쌓인 뒤일수록 고통이 커집니다. 그래서 처음부터 조직 차원의 IP 주소 계획표(예: dev는 10.10.0.0/16, prod는 10.20.0.0/16, 온프레는 172.16.0.0/12처럼 겹치지 않게 할당)를 만들고, IaC 모듈의 입력값으로 강제합니다(IaC와 Terraform). 지금 연결할 계획이 없어도, 연결할 일은 반드시 생깁니다.

💼

실무 맥락

현업 패턴

VPC 설계는 인프라 엔지니어의 핵심 역량입니다. 면접에서 "3티어 아키텍처를 VPC로 어떻게 구성하나요?"는 단골이고, 좋은 답은 "퍼블릭 서브넷에 LB·NAT, 프라이빗에 앱·DB, 각 계층을 여러 AZ에 분산, 보안그룹으로 계층 간 최소 포트만 허용"입니다.

실무에서 VPC를 콘솔로 손수 만들면 재현·복제가 어렵습니다. 그래서 VPC·서브넷·라우팅을 IaC와 Terraform로 코드화해 환경(dev/stg/prod)마다 동일하게 찍어내는 것이 표준입니다. 온프레 네트워크 지식(Networking 트랙의 서브넷·라우팅)이 그대로 이어집니다.

관련 모듈로 더 깊이:

DNS와 CDN — VPC 앞단에서 사용자를 가장 가까운 곳으로 안내하는 DNS·CDN
하이브리드 연결 — VPC와 온프레미스를 잇는 VPN·Direct Connect 하이브리드 연결
계정과 IAM — 네트워크 자원에 대한 접근을 통제하는 권한·보안그룹

다음 모듈에서는 이 VPC 앞에서 사용자를 가장 가까운 곳으로 빠르게 안내하는 DNS(Route 53)와 CDN(CloudFront) 을 다룹니다.