AWS VPC 제대로 이해하기: 서브넷, 라우팅, 그리고 두 겹의 문지기

VPC는 클라우드 안의 내 전용 네트워크입니다

AWS 데이터센터에는 수많은 고객의 서버가 함께 돌아갑니다. 그 속에서 내 서버만 쓰는 울타리를 친 것이 VPC(Virtual Private Cloud)입니다. 다른 계정의 트래픽은 이 울타리를 넘어오지 못하고, 안에서 쓰는 IP 주소와 경로, 출입 규칙은 모두 내가 정합니다.

회사 사무실 네트워크를 떠올리면 쉽습니다. 건물(VPC) 안에 층(서브넷)을 나누고, 엘리베이터 안내판(라우팅 테이블)이 어디로 갈 수 있는지 알려 주며, 출입구마다 경비(보안 그룹, NACL)가 서 있습니다. 이 글은 이 네 가지가 어떻게 맞물리는지 차례로 살펴봅니다.

주소 범위는 처음부터 넓고 겹치지 않게

VPC를 만들 때 가장 먼저 정하는 것이 CIDR 블록, 즉 이 네트워크가 쓸 사설 IP 범위입니다. 흔히 10.0.0.0/16으로 잡는데, 앞 16비트를 고정하니 약 65,536개의 주소를 쓸 수 있습니다. 이를 /24 서브넷(각 256개, AWS가 5개를 예약해 251개 사용)으로 잘라 나눠 씁니다.

범위	주소 수	쓰임새
`10.0.0.0/16`	65,536	VPC 전체
`10.0.1.0/24`	256	퍼블릭 서브넷 (AZ-a)
`10.0.11.0/24`	256	앱 서브넷 (AZ-a)
`10.0.21.0/24`	256	DB 서브넷 (AZ-a)

두 가지를 기억하세요. 하나, VPC 범위는 나중에 늘리기 번거로우니 넝넉하게 잡습니다. 둘, 다른 VPC나 회사 내부망과 범위가 겹치면 나중에 서로 연결할 수 없습니다. 환경마다 10.0, 10.1, 10.2처럼 미리 나눠 두면 나중이 편합니다.

퍼블릭과 프라이빗을 가르는 것은 라우팅 테이블입니다

VPC는 리전 전체에 걸쳐 있지만, 서브넷은 반드시 하나의 가용 영역(AZ)에 속합니다. 그래서 장애에 대비하려면 같은 역할의 서브넷을 AZ마다 하나씩 만들어 둡니다.

흔히 퍼블릭 서브넷을 만드는 설정이 따로 있다고 생각하지만, 그런 스위치는 없습니다. 서브넷에 연결된 라우팅 테이블의 한 줄이 성격을 정합니다.

목적지	퍼블릭 서브넷의 다음 경유지	프라이빗 서브넷의 다음 경유지
`10.0.0.0/16` (VPC 내부)	local	local
`0.0.0.0/0` (그 밖의 모든 곳)	인터넷 게이트웨이	NAT 게이트웨이

local 경로는 자동으로 들어가 있어서, 같은 VPC 안의 서브넷끼리는 항상 서로 닿습니다. 차이는 오직 바깥으로 나가는 길이 어디로 연결되느냐입니다.

인터넷 게이트웨이는 양방향, NAT는 나가는 방향만

인터넷 게이트웨이(IGW)는 VPC와 인터넷을 잇는 문입니다. VPC에 하나만 붙이고, AWS가 알아서 이중화해 줍니다. 퍼블릭 IP를 가진 인스턴스는 이 문을 통해 나갈 수도, 요청을 받을 수도 있습니다.

프라이빗 서브넷의 앱 서버도 패키지 설치나 외부 API 호출처럼 밖으로 나갈 일은 있습니다. 이때 쓰는 것이 NAT 게이트웨이입니다. 내부 주소를 자기 퍼블릭 IP로 바꿔 내보내고 응답만 돌려주므로, 밖에서 먼저 들어오는 연결은 막힙니다.

NAT 게이트웨이 자신도 인터넷에 닿아야 하므로 퍼블릭 서브넷에 둡니다.
NAT 게이트웨이는 한 AZ에 묶여 있습니다. 하나만 두면 그 AZ가 멈출 때 다른 AZ의 서버도 밖으로 못 나갑니다. 그래서 AZ마다 하나씩 두고, 각 AZ의 프라이빗 라우팅 테이블이 자기 AZ의 NAT를 가리키게 합니다.

한 장으로 보는 3계층 구성

가장 흔한 구성은 인터넷에 노출되는 것을 로드 밸런서 하나로 줄이고, 나머지는 모두 프라이빗 서브넷에 숨기는 것입니다. 같은 배치를 두 AZ에 똑같이 반복해, 한쪽이 멈춰도 다른 쪽이 요청을 받습니다.

ALB와 NAT만 퍼블릭 서브넷에 있고, 앱 서버와 DB는 인터넷에서 직접 닿을 길이 없습니다. 앱의 외부 호출은 자기 AZ의 NAT를 거쳐 나갑니다.

두 겹의 문지기: 보안 그룹과 네트워크 ACL

라우팅이 "길이 있느냐"를 정한다면, 문지기는 "지나가도 되느냐"를 정합니다. 안쪽 문지기는 인스턴스마다 붙는 보안 그룹, 바깥 문지기는 서브넷 입구에 서는 네트워크 ACL입니다.

	보안 그룹	네트워크 ACL
붙는 곳	인스턴스(네트워크 인터페이스)	서브넷
상태	상태 저장: 들어온 요청의 응답은 자동 허용	상태 비저장: 응답 방향도 따로 열어야 함
규칙 종류	허용만	허용과 거부
평가 방식	모든 규칙을 함께 봄	번호 순서대로, 첫 일치에서 멈춤
대상 지정	IP 범위 또는 다른 보안 그룹	IP 범위만

상태 비저장이라는 말은 이렇습니다. NACL에서 443 포트 인바운드를 열었더라도, 응답이 나가는 임시 포트(1024~65535) 아웃바운드를 막아 두면 연결이 끝내 성사되지 않습니다.

실무에서는 보안 그룹이 주력입니다. 특히 보안 그룹 참조가 강력합니다. "DB 보안 그룹은 앱 보안 그룹에서 오는 3306만 허용"처럼 쓰면, 서버 IP가 바뀌거나 대수가 늘어도 규칙을 고칠 필요가 없습니다. NACL은 특정 IP 대역을 명시적으로 막아야 할 때 쓰는 보조 장치로 두면 됩니다.

VPC 엔드포인트: AWS 서비스까지 인터넷 없이

S3나 DynamoDB도 원래는 공개 엔드포인트로 부릅니다. 프라이빗 서버가 이를 호출하면 NAT를 거쳐 나가고, 그만큼 NAT 처리 비용과 병목이 생깁니다. VPC 엔드포인트는 이 호출을 AWS 내부망으로만 흘르게 합니다.

게이트웨이 엔드포인트: S3와 DynamoDB 전용입니다. 라우팅 테이블에 "S3 주소 목록은 엔드포인트로"라는 줄이 추가되는 방식이고, 추가 요금이 없습니다.
인터페이스 엔드포인트(PrivateLink): 서브넷 안에 사설 IP를 가진 네트워크 인터페이스가 생기고, DNS가 그 IP를 가리킵니다. SQS, Secrets Manager 등 대부분의 서비스는 물론 다른 회사가 공개한 서비스에도 씁니다. 시간당 요금이 있고 보안 그룹을 붙일 수 있습니다.

엔드포인트가 없을 때와 있을 때

프라이빗 서브넷의 앱 서버가 S3에서 파일을 읽는 경우를 비교해 봅니다.

엔드포인트 없음: 앱 서버 → NAT 게이트웨이 → 인터넷 게이트웨이 → S3 공개 주소. 트래픽이 실제로 공용 인터넷을 떠돌지는 않지만, NAT를 지나므로 GB당 처리 요금이 붙고 NAT 처리량이 한계가 됩니다. NAT가 없는 완전 격리 서브넷이라면 아예 S3에 닿지 못합니다.
엔드포인트 있음: 앱 서버 → 엔드포인트 → S3. NAT와 인터넷 게이트웨이를 거치지 않습니다. 인터넷으로 나가는 길이 전혀 없는 서브넷에서도 S3를 쓸 수 있습니다.

두 종류는 동작 방식이 다릅니다

게이트웨이 엔드포인트는 라우팅으로 동작합니다. 만들 때 고른 라우팅 테이블에 목적지가 S3의 IP 목록(prefix list)이고 다음 경유지가 엔드포인트인 줄이 자동으로 추가됩니다. 앱 코드나 주소는 그대로 두고, 패킷이 나가는 길만 바뀝니다. 라우팅 테이블에 의존하므로 같은 VPC 안에서만 쓸 수 있습니다. 피어링된 VPC나 VPN으로 연결된 회사 내부망에서는 이 길을 탈 수 없습니다.

인터페이스 엔드포인트는 DNS로 동작합니다. 서브넷마다 사설 IP를 가진 네트워크 인터페이스(ENI)가 하나씩 생기고, 프라이빗 DNS를 켜면 sqs.ap-northeast-2.amazonaws.com 같은 서비스 주소가 그 사설 IP로 풀립니다. 코드는 평소처럼 서비스 주소를 부르지만 실제로는 VPC 안의 IP로 갑니다. 진짜 IP가 있는 인터페이스라서 보안 그룹을 붙일 수 있고, 피어링·Transit Gateway·VPN·Direct Connect로 연결된 다른 네트워크에서도 닿습니다.

	게이트웨이 엔드포인트	인터페이스 엔드포인트
대상 서비스	S3, DynamoDB	대부분의 AWS 서비스, 다른 회사 서비스
동작 방식	라우팅 테이블에 경로 추가	서브넷에 ENI 생성 + DNS
접근 제어	엔드포인트 정책	엔드포인트 정책 + 보안 그룹
회사 내부망에서 접근	안 됨	됨
요금	없음	AZ마다 시간당 + GB당

S3는 두 방식을 모두 지원합니다. VPC 안에서만 쓴다면 무료인 게이트웨이를, 회사 내부망에서도 사설 경로로 S3에 가야 한다면 인터페이스를 고릅니다.

엔드포인트로 접근 범위를 좁히기

엔드포인트는 길일 뿐 아니라 검문소도 됩니다. 양쪽에서 조일 수 있습니다.

엔드포인트 정책: 엔드포인트에 붙이는 IAM 형식의 정책입니다. "이 엔드포인트로는 우리 회사 버킷만 접근 가능"처럼 쓰면, 서버가 탈취되더라도 다른 계정의 버킷으로 데이터를 빼내기 어렵습니다.
버킷 정책의 조건: S3 버킷 정책에 aws:SourceVpce 조건을 걸면 "이 엔드포인트를 거쳐 온 요청만 허용"이 됩니다. 접근 키가 유출되더라도 VPC 밖에서는 버킷을 열 수 없습니다.

내 서비스를 남에게 사설로 공개하기

PrivateLink는 AWS 서비스 전용이 아닙니다. 내 서비스를 NLB 뒤에 두고 엔드포인트 서비스로 등록하면, 다른 계정이나 고객사 VPC가 인터페이스 엔드포인트를 만들어 접속할 수 있습니다. 피어링과 달리 두 VPC의 네트워크를 통째로 잇지 않고 그 서비스 하나만 노출하므로, CIDR이 겹쳐도 문제없고 상대가 내 VPC의 다른 자원을 볼 수도 없습니다. SaaS 회사들이 고객에게 사설 연결을 제공할 때 쓰는 방식입니다.

다른 VPC, 회사 내부망과 잇기

VPC 두 개를 잇는 가장 단순한 방법은 VPC 피어링입니다. 단, 피어링은 전이되지 않습니다. A–B, B–C가 연결돼 있어도 A는 B를 거쳐 C로 갈 수 없습니다. VPC가 10개라면 모두 서로 잇기 위해 45개의 피어링이 필요합니다. 이때는 중앙 허브인 Transit Gateway에 각 VPC를 한 번씩 붙이는 편이 낫습니다.

방식	잇는 대상	어떻게 흐르나	언제 고르나
VPC 피어링	VPC ↔ VPC	1:1 직접 연결, 전이 안 됨	연결할 VPC가 몇 개뿐일 때
Transit Gateway	여러 VPC + 온프레미스	허브에 모여 라우팅	VPC가 많거나 계속 늘 때
Site-to-Site VPN	회사 내부망 ↔ VPC	인터넷 위 암호화 터널	빠르고 저렴하게 시작할 때
Direct Connect	회사 내부망 ↔ AWS	전용 물리 회선	대역폭과 일정한 지연이 중요할 때

Direct Connect는 회선을 설치하는 데 주 단위 시간이 걸리므로, VPN으로 먼저 연결하고 나중에 예비 경로로 남겨 두는 조합이 흔합니다. 어느 방식이든 앞서 말한 CIDR이 겹치지 않아야 합니다.

요청 하나의 여정

사용자가 https://shop.example.com/orders를 열었을 때, 앞의 요소들이 어떤 순서로 일하는지 따라가 봅니다.

요청이 인터넷 게이트웨이를 지나 퍼블릭 서브넷의 ALB에 도착합니다. 퍼블릭 서브넷의 NACL과 ALB 보안 그룹(443 허용)을 차례로 통과합니다.
ALB가 두 AZ 중 건강한 앱 서버를 골라 local 경로로 넘깁니다. 앱 보안 그룹은 "ALB 보안 그룹에서 온 8080"만 허용합니다.
앱 서버가 주문 내역을 DB에 묻습니다. DB 보안 그룹은 앱 보안 그룹에서 온 3306만 받습니다.
영수증 PDF는 S3에서 가져옵니다. 게이트웨이 엔드포인트 덕분에 NAT를 거치지 않습니다.
결제사 API는 외부에 있으니 같은 AZ의 NAT 게이트웨이를 통해 나갑니다.
응답은 왜던 길로 돌아갑니다. 보안 그룹은 상태를 기억하므로 따로 열어 둔 규칙 없이도 통과합니다.

이 흐름 어디에서도 앱과 DB는 퍼블릭 IP를 갖지 않습니다. 밖에서 보이는 것은 ALB 하나뿐입니다.

설계할 때 떠올릴 다섯 가지

넓게, 겹치지 않게: CIDR은 나중에 연결할 네트워크까지 생각해 잡습니다.
기본은 프라이빗: 인터넷에서 직접 받아야 하는 것만 퍼블릭 서브넷에 둡니다.
AZ마다 똑같이: 서브넷, NAT, 서버를 두 개 이상의 AZ에 대칭으로 배치합니다.
IP가 아니라 역할로 허용: 보안 그룹끼리 참조해 계층 간 통로를 엽니다.
AWS 서비스는 엔드포인트로: 내부망으로 갈 수 있는 트래픽은 인터넷을 타지 않게 합니다.

이 다섯 가지만 지켜도, 서비스가 커져서 VPC가 여러 개로 늘어날 때 크게 고칠 일이 드물어집니다.