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 …). [[cloud-service-models]]의 Multi-AZ가 네트워크 레벨에서 이렇게 구현됩니다.
퍼블릭 vs 프라이빗 — 결정하는 건 라우팅
서브넷에 'public/private'이라는 이름은 관습일 뿐, 진짜 차이는 라우팅 테이블입니다.
- 퍼블릭 서브넷: 라우팅에
0.0.0.0/0 → 인터넷 게이트웨이(IGW). 인스턴스에 공인 IP가 있으면 인터넷과 양방향 통신. - 프라이빗 서브넷: 그 경로가 없음. 외부에서 직접 못 들어옴.
웹 서버·로드밸런서는 퍼블릭, 앱 서버·DB는 프라이빗에 두는 것이 기본입니다.
IGW vs NAT — 들어오기 vs 나가기
인터넷 게이트웨이(IGW) 는 VPC와 인터넷을 잇는 문입니다. 퍼블릭 서브넷이 양방향으로 인터넷과 통신하게 합니다.
NAT 게이트웨이는 프라이빗 서브넷 인스턴스의 나가는(아웃바운드) 통신만 대행합니다. 프라이빗 DB·앱 서버가 외부에서 직접 닿지는 못하되, OS 패치·외부 API 호출은 할 수 있게 해줍니다. NAT는 퍼블릭 서브넷에 두고, 프라이빗 라우팅이 0.0.0.0/0 → NAT를 향하게 합니다.
어떤 서브넷이 어느 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
+----------------+------------------+--------------+--------+
| 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진짜 판별 기준인 라우팅을 확인합니다. 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
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는 비용 누수([[cloud-cost-optimization]])
상황: 프라이빗 인스턴스가 외부(패키지 저장소)로 나가지 못함.
원인: 프라이빗 서브넷에 NAT 게이트웨이로 가는 아웃바운드 경로가 없음. 외부에서 들어오는 건 막는 게 맞지만, 나가는 길까지 없으면 패치·외부 호출이 안 됩니다. (DNS 해석 실패면 VPC의 DNS 설정도 점검.)
진단: 해당 서브넷의 라우팅 테이블에 0.0.0.0/0 → nat-...가 있는지 확인 → NAT 게이트웨이가 퍼블릭 서브넷에 정상 상태인지 확인.
해결: 프라이빗 서브넷 라우팅에 NAT 게이트웨이 경로 추가. NAT는 반드시 IGW가 있는 퍼블릭 서브넷에 위치해야 함. 패키지만 받으면 되는 경우 VPC 엔드포인트(인터넷 안 거치고 클라우드 서비스 직접 접근)로 NAT 비용을 줄이기도 합니다.
VPC 설계는 인프라 엔지니어의 핵심 역량입니다. 면접에서 "3티어 아키텍처를 VPC로 어떻게 구성하나요?"는 단골이고, 좋은 답은 "퍼블릭 서브넷에 LB·NAT, 프라이빗에 앱·DB, 각 계층을 여러 AZ에 분산, 보안그룹으로 계층 간 최소 포트만 허용"입니다.
실무에서 VPC를 콘솔로 손수 만들면 재현·복제가 어렵습니다. 그래서 VPC·서브넷·라우팅을 [[cloud-iac-terraform]]로 코드화해 환경(dev/stg/prod)마다 동일하게 찍어내는 것이 표준입니다. 온프레 네트워크 지식([[networking]] 트랙의 서브넷·라우팅)이 그대로 이어집니다.
다음 모듈에서는 이 VPC 앞에서 사용자를 가장 가까운 곳으로 빠르게 안내하는 DNS(Route 53)와 CDN(CloudFront) 을 다룹니다.