VPC 완전 정복: 클라우드 안에 '나만의 네트워크'를 짓는 법

들어가며: 클라우드는 "공유 공간"이다

AWS의 데이터센터에는 수백만 명의 고객이 같은 물리적 서버, 네트워크, 스토리지를 공유하고 있다. 당신의 EC2 인스턴스 옆에 전혀 모르는 다른 회사의 인스턴스가 돌아가고 있을 수 있다.

이것은 아파트와 같다. 같은 건물에 수백 세대가 살지만, 각 세대는 독립된 공간이다. 옆집에 누가 사는지 몰라도 되고, 옆집에서 내 집에 들어올 수 없다.

하지만 만약 아파트에 문 잠금장치, 벽, 복도 구분이 없다면? 누구나 아무 집에나 들어갈 수 있을 것이다.

초기 AWS(2006~2009)가 바로 이랬다. EC2 인스턴스들이 하나의 공유 네트워크(EC2-Classic) 에서 돌아갔다. 모든 인스턴스가 같은 네트워크에 있으니 기본적으로 서로 통신이 가능했고, 보안 그룹이 유일한 방어선이었다.

이것은 보안에도, 네트워크 설계에도 부족했다. 기업들은 온프레미스에서 하던 것처럼 자신만의 격리된 네트워크를 원했다.

2009년, AWS는 이 요구에 VPC(Virtual Private Cloud)로 응답했다.

1. VPC란 무엇인가

정의

VPC는 AWS 클라우드 안에 만드는 논리적으로 격리된 가상 네트워크다. 회사 사무실의 사설 네트워크(LAN)를 클라우드에 그대로 옮겨놓은 것이라 생각하면 된다.

VPC 안에서는:

• IP 대역을 직접 정한다 (10.0.0.0/16 같은 CIDR 블록)
• 서브넷으로 영역을 나눈다 (부서별 네트워크처럼)
• 라우팅 규칙을 설정한다 (트래픽이 어디로 갈지)
• 방화벽을 설정한다 (누가 접근할 수 있는지)
• 다른 고객의 VPC와 완전히 격리된다

아파트 비유로 이해하기

VPC의 모든 개념을 아파트 건물에 비유하면 직관적으로 이해할 수 있다:

2. VPC의 구성 요소를 하나씩 뜯어보기

서브넷: 네트워크를 방(Room)으로 나누기

VPC를 만들면 큰 IP 주소 공간(예: 10.0.0.0/16 = 65,536개 IP)을 얻는다. 이 공간을 서브넷으로 나눈다.

퍼블릭 서브넷: 인터넷 게이트웨이(IGW)와 연결된 라우트 테이블을 가진 서브넷. 여기에 있는 리소스는 인터넷과 직접 통신 가능. ALB, NAT Gateway, Bastion Host를 여기에 둔다.

프라이빗 서브넷: IGW로의 라우트가 없는 서브넷. 외부에서 직접 접근 불가. 애플리케이션 서버, 데이터베이스를 여기에 둔다.

인터넷 게이트웨이(IGW)와 NAT 게이트웨이

인터넷 게이트웨이(IGW): VPC의 정문. VPC와 인터넷을 연결한다. 양방향 통신.

NAT 게이트웨이: 프라이빗 서브넷의 리소스가 인터넷에 나가기만 할 수 있게 해준다. 외부에서 들어오는 것은 차단.

프라이빗 서브넷의 EC2가 OS 패치를 다운받거나, 외부 API를 호출할 때 NAT 게이트웨이를 거친다. 하지만 외부에서 이 EC2에 직접 접근하는 것은 불가능하다.

보안 그룹 vs 네트워크 ACL

두 가지 방화벽이 있다. 역할이 다르다:

3. VPC 보안: Capital One 사고의 교훈

VPC 설정이 뚫리면 모든 것이 뚫린다

이 시리즈에서 반복 등장한 2019년 Capital One 사고를 VPC 관점에서 다시 보자.

공격 경로:

1. 공격자가 Capital One의 WAF(Web Application Firewall) 설정 오류를 발견
2. WAF가 설치된 EC2의 IAM 역할에 과도한 권한이 부여되어 있었음
3. SSRF(Server-Side Request Forgery) 공격으로 EC2 메타데이터 서비스에서 IAM 자격증명 탈취
4. 이 자격증명으로 S3 버킷과 RDS에 접근 → 1억 600만 명의 데이터 유출

VPC 관점에서의 문제:

• WAF/프록시 서버가 퍼블릭 서브넷에 있으면서 내부 리소스에 과도한 접근 권한을 가지고 있었음
• 프라이빗 서브넷에 있어야 할 리소스가 적절히 격리되지 않았음
• SSRF에 대한 방어가 없었음 (EC2 메타데이터 서비스 IMDSv2 미사용)

기타 VPC 관련 보안 사고

4. 실전 VPC 아키텍처

3티어 웹 서비스의 표준 VPC

이 시리즈에서 다룬 모든 서비스를 VPC 안에 배치하면:

보안 그룹 규칙:

핵심: 보안 그룹 간 참조. RDS의 인바운드에 "앱 서버 보안그룹"을 지정하면, 앱 서버 보안그룹에 속한 인스턴스만 RDS에 접근할 수 있다. IP를 하드코딩하지 않으므로, 앱 서버가 늘어나거나 IP가 바뀌어도 보안 규칙이 자동으로 적용된다.

VPC Endpoints: AWS 서비스에 인터넷 없이 접근

프라이빗 서브넷의 앱이 S3, DynamoDB, ECR에 접근해야 한다. NAT 게이트웨이를 거치면 데이터 전송비가 발생한다.

VPC Endpoint를 사용하면 AWS 서비스에 VPC 내부 네트워크를 통해 직접 접근한다. 인터넷을 거치지 않으므로:

• NAT 게이트웨이 비용 절감
• 네트워크 지연 감소
• 보안 강화 (트래픽이 AWS 네트워크를 벗어나지 않음)

5. VPC 비용: NAT 게이트웨이의 함정

NAT 게이트웨이는 비싸다

VPC 비용의 가장 큰 함정: NAT 게이트웨이.

고가용성을 위해 AZ 2개에 각각 NAT 게이트웨이를 배치하면 월 $65+ (데이터 전송비 별도).

프라이빗 서브넷의 EC2/ECS가 Docker 이미지를 ECR에서 Pull하거나, S3에서 데이터를 가져올 때, 모든 트래픽이 NAT를 거치면 비용이 급증한다.

NAT 비용 절감 전략

6. VPC 고급 기능

VPC 피어링: VPC 간 사설 통신

두 VPC를 프라이빗 네트워크로 직접 연결한다. 인터넷을 거치지 않으므로 빠르고 안전하다.

사용 사례:

• 프로덕션 VPC ↔ 관리 VPC 연결
• 여러 팀의 VPC 간 데이터 공유
• 다른 AWS 계정의 VPC와 연결

Transit Gateway: 허브 앤 스포크

VPC가 10개, 20개로 늘어나면 피어링으로는 관리가 어렵다 (N×N 연결). Transit Gateway는 중앙 허브에 모든 VPC를 연결하는 허브 앤 스포크 모델이다.

VPC Flow Logs: 네트워크의 CCTV

VPC를 오가는 모든 트래픽을 로깅한다. 보안 감사, 이상 트래픽 탐지, 네트워크 디버깅에 필수적이다.

# Flow Log 레코드 예시
2 123456789 eni-abc123 10.0.1.5 203.0.113.5 443 49152 6 25 5000 1616729292 ACCEPT

"10.0.1.5에서 203.0.113.5:443으로 TCP 연결, 25 패킷, 5000 바이트, 허용됨"

7. 실제 사례

Netflix: 수백 개의 VPC

Netflix는 수백 개의 마이크로서비스를 여러 VPC에 분산 운영한다. 서비스 간 통신은 VPC 피어링과 Transit Gateway로 연결하며, 보안 그룹으로 세밀한 접근 제어를 적용한다.

Coinbase: 암호화폐 거래소의 VPC 보안

암호화폐 거래소 Coinbase는 모든 리소스를 프라이빗 서브넷에 배치하고, 퍼블릭 접근은 CloudFront + WAF → ALB 경로만 허용한다. VPC Flow Logs를 실시간으로 분석하여 이상 트래픽을 즉시 차단한다.

한국 기업 사례

• 토스: 금융 데이터 보호를 위해 엄격한 VPC 격리. 프로덕션 VPC, 개발 VPC, 관리 VPC를 완전 분리
• 쿠팡: Transit Gateway로 수십 개의 VPC를 중앙 관리. 마이크로서비스별 VPC 격리
• 카카오뱅크: 금융 규제 준수를 위해 프라이빗 서브넷에서만 운영. 인터넷 접근 최소화

8. VPC 설계 모범 사례

반드시 지킬 것

1. DB는 반드시 프라이빗 서브넷에. RDS, ElastiCache, OpenSearch를 퍼블릭 서브넷에 두지 마라
2. 보안 그룹은 IP가 아닌 보안 그룹 참조. 앱 서버 SG → DB SG 참조로 유연한 접근 제어
3. S3/DynamoDB Gateway Endpoint 필수. 무료이면서 NAT 비용 절감
4. VPC Flow Logs 활성화. 보안 감사와 디버깅의 기초 데이터
5. IMDSv2 강제. SSRF 공격 방어의 핵심
6. 서브넷 IP 여유 확보. /24(256개)보다 /20(4,096개)으로 넉넉하게

기본 VPC를 쓰지 마라

AWS 계정을 만들면 기본 VPC(Default VPC) 가 자동 생성된다. 이 기본 VPC의 모든 서브넷은 퍼블릭이다. 빠른 시작에는 편리하지만, 프로덕션에는 절대 사용하지 마라. 반드시 커스텀 VPC를 설계하고 퍼블릭/프라이빗을 명시적으로 분리하라.

마치며: VPC는 클라우드 보안의 기초다

이 시리즈에서 다룬 모든 AWS 서비스 — EC2, ECS, RDS, Lambda, OpenSearch — 는 VPC 안에서 실행된다. VPC는 이 모든 서비스의 네트워크 기초다.

VPC를 제대로 설계하면:

• 외부 공격으로부터 내부 리소스를 보호
• 서비스 간 통신을 세밀하게 제어
• 비용을 최적화 (NAT, VPC Endpoint)
• 규제 준수 (네트워크 격리, 로깅)

VPC를 잘못 설계하면:

• DB가 인터넷에 노출되어 데이터 유출
• 불필요한 NAT 비용 수백 달러
• 서비스 간 통신 불가로 장애
• Capital One 같은 대규모 보안 사고

클라우드에서 "보안"이라고 하면 IAM, 암호화, WAF 같은 것을 먼저 떠올리지만, 가장 기초적이고 가장 중요한 보안은 네트워크 격리 — 즉, VPC 설계다. 벽이 제대로 세워져야 도어락(보안 그룹)도 의미가 있다.

코어닷투데이의 모든 AWS 인프라는 커스텀 VPC 위에 구축되어 있다. 퍼블릭 서브넷에는 ALB만, 프라이빗 서브넷에 앱 서버와 AI 추론 엔진, DB 서브넷에 Aurora — 이 원칙은 규모에 상관없이 동일하다.