VPC Peering vs Transit Gateway: 언제 어떤 것을 선택해야 할까?
소규모 VPC 연결은 Peering, 대규모 허브-스포크 아키텍처는 Transit Gateway를 선택하세요. SAA-C03 시험 필수 토픽인 VPC 연결 옵션을 비교합니다.
관련 시험 도메인
- Domain 1: Design Secure Architectures
- Domain 2: Design Resilient Architectures
핵심 요약 (BLUF)
소규모 VPC 연결(2-3개)은 VPC Peering이 간단하고 저렴하며, 대규모 네트워크(10개 이상)나 온프레미스 연결이 필요하면 Transit Gateway가 적합합니다. VPC Peering은 1:1 연결로 전이적 라우팅이 불가하고, Transit Gateway는 허브-스포크 구조로 모든 VPC를 중앙에서 연결합니다.
시험 팁
시험 핵심: VPC Peering = 1:1 비전이적 + 저지연 + 저비용, Transit Gateway = 허브-스포크 + 전이적 라우팅 + 확장성
VPC 연결 옵션 한눈에 비교
| 비교 항목 | VPC Peering | Transit Gateway |
|---|---|---|
| 연결 방식 | 1:1 Point-to-Point | 허브-스포크 (Hub-Spoke) |
| 전이적 라우팅 | ❌ 불가 | ✅ 지원 |
| 최대 연결 수 | VPC당 125개 | 5,000개 VPC |
| 지연시간 | 최저 (직접 연결) | 약간 높음 (홉 추가) |
| 관리 복잡도 | VPC 증가 시 높음 | 중앙 집중 관리 |
| 온프레미스 연결 | ❌ 직접 불가 | ✅ VPN/Direct Connect |
| 비용 | 데이터 전송만 | 연결 비용 + 데이터 |
| 리전 간 연결 | ✅ 지원 | ✅ 지원 |
VPC Peering
VPC Peering이란?
VPC Peering은 두 VPC 간 프라이빗 네트워크 연결을 설정하는 기능입니다. 동일 네트워크에 있는 것처럼 프라이빗 IP로 통신합니다.
VPC Peering 구조:
VPC A VPC B
┌─────────────┐ Peering ┌─────────────┐
│ 10.0.0.0/16 │ ←───────────→ │ 10.1.0.0/16 │
│ │ Connection │ │
│ ┌─────────┐ │ │ ┌─────────┐ │
│ │ EC2 │ │ ←──────────→ │ │ RDS │ │
│ │10.0.1.5 │ │ Private IP │ │10.1.2.10│ │
│ └─────────┘ │ │ └─────────┘ │
└─────────────┘ └─────────────┘
VPC Peering 핵심 특징
1. 비전이적 (Non-Transitive)
VPC Peering은 직접 연결된 VPC끼리만 통신합니다. A-B, B-C가 피어링되어도 A-C는 통신 불가합니다.
비전이적 라우팅:
VPC A ←──→ VPC B ←──→ VPC C
A → B: ✅ 가능
B → C: ✅ 가능
A → C: ❌ 불가능 (직접 피어링 필요)
2. CIDR 중복 불가
피어링되는 VPC의 CIDR 블록이 겹치면 안 됩니다.
❌ 피어링 불가:
VPC A: 10.0.0.0/16
VPC B: 10.0.0.0/16 ← CIDR 동일
✅ 피어링 가능:
VPC A: 10.0.0.0/16
VPC B: 10.1.0.0/16 ← CIDR 다름
3. 라우팅 테이블 수동 구성
피어링 연결 후 각 VPC의 라우팅 테이블을 수동으로 업데이트해야 합니다.
VPC A 라우팅 테이블:
대상: 10.1.0.0/16 → 대상: pcx-xxxxxxxx (Peering Connection)
VPC B 라우팅 테이블:
대상: 10.0.0.0/16 → 대상: pcx-xxxxxxxx (Peering Connection)
VPC Peering 연결 수 계산
N개의 VPC를 모두 연결하려면 풀 메시(Full Mesh) 구성이 필요합니다:
필요한 피어링 연결 수 = N × (N-1) / 2
예시:
- 3개 VPC: 3 × 2 / 2 = 3개 피어링
- 5개 VPC: 5 × 4 / 2 = 10개 피어링
- 10개 VPC: 10 × 9 / 2 = 45개 피어링
- 20개 VPC: 20 × 19 / 2 = 190개 피어링
VPC Peering 적합한 경우
| 사용 사례 | 이유 |
|---|---|
| 2-3개 VPC 연결 | 관리 복잡도 낮음 |
| 최저 지연시간 필요 | 직접 연결, 홉 없음 |
| 비용 최소화 | 연결 비용 없음 |
| 단순 아키텍처 | 온프레미스 연결 불필요 |
시험 팁
시험 포인트: VPC Peering은 전이적 라우팅을 지원하지 않습니다. A-B-C 연결 시 A-C 통신 불가!
Transit Gateway
Transit Gateway란?
Transit Gateway는 중앙 허브로 여러 VPC와 온프레미스 네트워크를 연결하는 서비스입니다. 허브-스포크 아키텍처를 구현합니다.
Transit Gateway 구조 (허브-스포크):
┌─────────────────┐
│ Transit Gateway │
│ (허브) │
└────────┬────────┘
┌─────────────────┼─────────────────┐
│ │ │
↓ ↓ ↓
┌───────────┐ ┌───────────┐ ┌───────────┐
│ VPC A │ │ VPC B │ │ VPC C │
│(스포크) │ │(스포크) │ │(스포크) │
└───────────┘ └───────────┘ └───────────┘
│ │
└───── A ↔ B ↔ C 모두 통신 가능 ────┘
Transit Gateway 핵심 특징
1. 전이적 라우팅 (Transitive)
Transit Gateway에 연결된 모든 네트워크는 서로 통신 가능합니다.
전이적 라우팅:
VPC A ──┐
│
VPC B ──┼── Transit Gateway
│
VPC C ──┘
A → B: ✅ 가능
B → C: ✅ 가능
A → C: ✅ 가능 (TGW 경유)
2. 허브-스포크 아키텍처
중앙 집중식 관리로 연결 수가 줄어들고 관리가 단순해집니다.
연결 수 비교 (10개 VPC):
VPC Peering (풀 메시): 45개 연결
Transit Gateway: 10개 연결 (각 VPC → TGW)
3. 다양한 연결 지원
| 연결 유형 | 설명 |
|---|---|
| VPC 연결 | VPC 연결 (Attachment) |
| VPN 연결 | Site-to-Site VPN |
| Direct Connect | Direct Connect Gateway |
| 피어링 | 다른 Transit Gateway와 피어링 |
| Connect | SD-WAN 어플라이언스 연결 |
4. 라우팅 테이블
Transit Gateway 자체 라우팅 테이블로 트래픽 흐름을 세밀하게 제어합니다.
Transit Gateway 라우팅 테이블:
대상 → 대상
10.0.0.0/16 → VPC A Attachment
10.1.0.0/16 → VPC B Attachment
10.2.0.0/16 → VPC C Attachment
0.0.0.0/0 → VPN Attachment (온프레미스)
Transit Gateway 고급 기능
1. 라우팅 도메인 분리
여러 라우팅 테이블로 트래픽 분리:
라우팅 테이블 1 (프로덕션):
├── VPC Prod A
└── VPC Prod B
라우팅 테이블 2 (개발):
├── VPC Dev A
└── VPC Dev B
→ 프로덕션과 개발 환경 격리
2. 멀티캐스트
Transit Gateway는 멀티캐스트 트래픽을 지원합니다 (VPC Peering은 미지원).
3. 리전 간 피어링
리전 간 Transit Gateway 피어링:
서울 리전 TGW ←──────→ 버지니아 리전 TGW
│ │
↓ ↓
VPC A, B VPC C, D
→ 글로벌 네트워크 구축
Transit Gateway 적합한 경우
| 사용 사례 | 이유 |
|---|---|
| 10개 이상 VPC 연결 | 관리 복잡도 감소 |
| 온프레미스 연결 필요 | VPN/Direct Connect 통합 |
| 중앙 집중 관리 | 단일 제어 포인트 |
| 복잡한 라우팅 요구 | 다중 라우팅 테이블 |
| 확장 계획 | 향후 VPC 추가 용이 |
시험 팁
시험 포인트: Transit Gateway는 전이적 라우팅 지원 + 온프레미스(VPN/DX) 연결 가능
비용 비교
VPC Peering 비용
VPC Peering 비용 구성:
연결 비용: 무료
데이터 전송:
├── 동일 AZ: $0.01/GB (쌍방)
├── 다른 AZ: $0.01/GB (쌍방)
└── 다른 리전: $0.02/GB (발신측)
Transit Gateway 비용 (서울 리전)
Transit Gateway 비용 구성:
연결 비용: $0.07/시간/연결
├── VPC 1개 연결: $0.07 × 730시간 = $51.1/월
├── VPC 5개 연결: $51.1 × 5 = $255.5/월
└── VPC 10개 연결: $51.1 × 10 = $511/월
데이터 처리: $0.035/GB
비용 시나리오 비교
시나리오: 5개 VPC, 월 1TB 데이터 전송
VPC Peering (풀 메시, 10개 연결):
├── 연결 비용: $0
├── 데이터 전송: $0.01 × 1,024 = $10.24
└── 총계: ~$10/월
Transit Gateway:
├── 연결 비용: $0.07 × 730 × 5 = $255.5
├── 데이터 처리: $0.035 × 1,024 = $35.84
└── 총계: ~$291/월
→ 소규모에서는 VPC Peering이 저렴
시나리오: 20개 VPC, 월 10TB 데이터 전송
VPC Peering (풀 메시, 190개 연결):
├── 연결 비용: $0
├── 데이터 전송: $0.01 × 10,240 = $102.4
├── 관리 복잡도: 매우 높음 (190개 연결 관리)
└── 총계: ~$102/월 + 높은 운영 비용
Transit Gateway:
├── 연결 비용: $0.07 × 730 × 20 = $1,022
├── 데이터 처리: $0.035 × 10,240 = $358.4
├── 관리 복잡도: 낮음 (중앙 관리)
└── 총계: ~$1,380/월 + 낮은 운영 비용
→ 대규모에서는 Transit Gateway가 관리 효율적
선택 기준 가이드
결정 플로우차트
VPC 연결 옵션 선택:
온프레미스 연결이 필요한가?
│
├── YES → Transit Gateway
│
└── NO → VPC가 몇 개인가?
│
├── 2-3개 → VPC Peering
│
├── 4-10개 → 복잡도/비용 비교 후 결정
│
└── 10개 이상 → Transit Gateway
상세 선택 기준
| 요구사항 | VPC Peering | Transit Gateway |
|---|---|---|
| VPC 2-3개 연결 | ✅ 권장 | 가능 |
| VPC 10개 이상 | 복잡함 | ✅ 권장 |
| 최저 지연시간 | ✅ 최적 | 약간 높음 |
| 비용 최소화 (소규모) | ✅ 최적 | 높음 |
| 온프레미스 VPN/DX | ❌ | ✅ 필수 |
| 전이적 라우팅 | ❌ | ✅ 지원 |
| 중앙 집중 관리 | ❌ | ✅ 지원 |
| 향후 확장 계획 | 제한적 | ✅ 유연 |
시나리오별 솔루션
시나리오 1: 개발-프로덕션 VPC 연결
요구사항: 2개 VPC, 간단한 연결
선택: VPC Peering
이유: 비용 $0, 간단한 설정, 최저 지연시간
시나리오 2: 멀티 계정 환경 (10+ VPC)
요구사항: 10개 이상 VPC, 중앙 관리
선택: Transit Gateway
이유: 관리 단순화, 전이적 라우팅
시나리오 3: 하이브리드 클라우드
요구사항: VPC + 온프레미스 데이터센터 연결
선택: Transit Gateway + VPN 또는 Direct Connect
이유: VPC Peering은 온프레미스 연결 불가
시나리오 4: 글로벌 네트워크
요구사항: 서울, 버지니아, 프랑크푸르트 리전 연결
선택: Transit Gateway + 리전 간 피어링
이유: 글로벌 허브-스포크 아키텍처 구현
시나리오 5: 환경 분리 (개발/스테이징/프로덕션)
요구사항: 환경 간 격리, 공유 서비스 VPC 접근
선택: Transit Gateway + 다중 라우팅 테이블
이유: 라우팅 도메인으로 트래픽 분리
SAA-C03 시험 출제 포인트
- ✅ VPC Peering 비전이적: A-B-C 연결 시 A-C 통신 불가
- ✅ Transit Gateway 전이적: 모든 연결된 네트워크 간 통신 가능
- ✅ CIDR 중복 불가: 피어링/TGW 모두 CIDR 중복 시 연결 불가
- ✅ 온프레미스 연결: Transit Gateway만 VPN/Direct Connect 지원
- ✅ 비용: VPC Peering = 데이터만, TGW = 연결 + 데이터
- ✅ 라우팅: 피어링은 수동, TGW는 중앙 라우팅 테이블
시험 팁
시험 문제 예시: "회사는 3개의 VPC를 운영 중입니다. VPC A와 B, VPC B와 C가 피어링되어 있습니다. VPC A의 인스턴스가 VPC C의 데이터베이스에 접근하려면 어떻게 해야 할까요?" → 정답: VPC A와 C 사이에 직접 피어링 연결을 추가 (VPC Peering은 전이적 라우팅 미지원)
자주 묻는 질문 (FAQ)
Q: VPC Peering과 Transit Gateway를 함께 사용할 수 있나요?
네, 가능합니다. 특정 VPC 간 최저 지연시간이 필요하면 직접 피어링하고, 나머지는 Transit Gateway로 연결하는 하이브리드 구성이 가능합니다.
Q: Transit Gateway 지연시간은 얼마나 증가하나요?
일반적으로 수 밀리초 이내입니다. 대부분의 워크로드에서 무시할 수 있는 수준이지만, 초저지연이 필수인 경우(고빈도 트레이딩 등) VPC Peering이 더 적합할 수 있습니다.
Q: VPC Peering 연결이 실패하는 이유는?
가장 흔한 원인은 CIDR 중복입니다. 또한 라우팅 테이블 미설정, 보안 그룹/NACL 차단, DNS 해석 문제 등이 원인일 수 있습니다. 피어링 수락 여부도 확인하세요.
Q: Transit Gateway에서 특정 VPC 간 통신을 차단할 수 있나요?
네, 라우팅 테이블로 제어합니다. 별도의 라우팅 테이블을 만들어 특정 VPC만 연결하거나, 블랙홀 라우트를 추가하여 트래픽을 폐기할 수 있습니다.
Q: 다른 AWS 계정의 VPC와 연결할 수 있나요?
둘 다 가능합니다. VPC Peering은 피어링 요청을 보내고 상대방이 수락해야 합니다. Transit Gateway는 Resource Access Manager(RAM)로 다른 계정과 공유할 수 있습니다.
Q: 기존 VPC Peering에서 Transit Gateway로 마이그레이션하는 방법은?
점진적 마이그레이션을 권장합니다. Transit Gateway를 생성하고 VPC를 하나씩 연결한 후, 라우팅 테이블을 업데이트하고, 마지막으로 기존 피어링 연결을 삭제합니다.