VPC 간/외부 연결 — Peering, VPN, Transit, PrivateLink

VPC 내부의 라우팅이 해결되면 다음 질문은 VPC 밖과의 연결이다. 다른 VPC, 온프레미스 데이터센터, 외부 SaaS 서비스와는 어떻게 연결되는가.

VPC Peering, Transit Gateway, Site-to-Site VPN, PrivateLink 네 메커니즘이 각각 다른 토폴로지·비용·운영 트레이드오프를 가지며, 어느 것을 선택하느냐가 시스템 전체의 구조를 결정한다.

VPC Peering

가장 단순한 옵션이 VPC Peering이다. 두 VPC를 직접 연결해 서로의 사설 IP 공간에 도달할 수 있게 한다.

같은 리전·같은 계정뿐 아니라 다른 리전, 다른 계정의 VPC도 연결 가능하다. Peering은 토폴로지가 mesh인 1:1 연결이라, 세 VPC를 모두 연결하려면 세 개의 Peering(A-B, B-C, A-C)이 필요하다.

한계는 transitive 라우팅이 지원되지 않는다는 점이다. A-B와 B-C를 Peering으로 연결해도 A에서 C로는 직접 갈 수 없다. 양쪽이 직접 Peering 관계여야 한다. VPC 수 N이 늘면 연결 수가 N(N-1)/2로 폭증하므로, 소수의 VPC를 묶을 때만 적합하다.

Transit Gateway

VPC 수가 늘어나면 Peering의 mesh 구조는 빠르게 부담이 된다. Transit Gateway가 이 한계를 해소한다.

flowchart LR
    subgraph Peering ["Peering: mesh"]
        VA["VPC A"] --- VB["VPC B"]
        VB --- VC["VPC C"]
        VA --- VC
        VC --- VD["VPC D"]
        VA --- VD
        VB --- VD
    end
    subgraph Transit ["Transit Gateway: hub-spoke"]
        TGW(("TGW"))
        TVA["VPC A"] --- TGW
        TVB["VPC B"] --- TGW
        TVC["VPC C"] --- TGW
        TVD["VPC D"] --- TGW
    end

Transit Gateway는 중앙 허브 역할을 한다. 다수의 VPC가 spoke로 연결되고, 허브를 통해 모든 spoke 간 통신이 transitive하게 이뤄진다. VPC 수가 늘어도 연결 수가 선형으로만 증가한다.

비용 모델은 Peering과 다르다. 시간당 부착 비용 + 트래픽당 처리 비용이 붙어, 작은 규모에서는 Peering보다 비싸지만 N이 커질수록 효율이 역전된다. 라우팅 도메인을 여러 개로 분리하는 옵션이 있어 멀티 테넌트 환경에서 격리를 유지하기도 좋다.

Site-to-Site VPN

VPC와 온프레미스 데이터센터를 묶어야 할 때 가장 먼저 떠오르는 옵션이다. 공용 인터넷 위에 IPSec 터널을 세워 두 네트워크를 논리적으로 연결한다.

정적 라우팅과 BGP 동적 라우팅 둘 다 옵션으로 제공된다. 다만 공용 인터넷이 매개라 대역폭과 지연이 변동성을 가지며, 미션 크리티컬 트래픽에는 부담이 될 수 있다. 안정적 연결이 필요하면 Direct Connect나 Cloud Interconnect 같은 전용선 옵션이 별도로 있다.

PrivateLink

지금까지 셋이 IP 라우팅 기반이었다면, PrivateLink는 결이 다르다. IP/CIDR 단위로 두 네트워크를 잇는 게 아니라 서비스 단위로 endpoint를 노출한다.

서비스 제공자 측 VPC에 endpoint를 만들면, 소비자 측 VPC는 그 endpoint를 ENI(Elastic Network Interface) 또는 동등 자원으로 자기 VPC 안에서 인식한다. 두 VPC의 IP 공간이 어떻게 분포해 있든 무관하다 — endpoint 단위 연결이라 CIDR 충돌이 문제가 되지 않는다.

방향성도 다르다. PrivateLink는 단방향이다. 제공자가 노출한 서비스를 소비자가 호출하는 형태고, 그 반대는 별도 endpoint를 만들어야 한다. SaaS 서비스나 자사 서비스의 사적 노출, 클라우드 매니지드 서비스의 VPC 진입점 등에 자주 쓰인다.

비교 표

네 메커니즘을 한 표에 놓으면 트레이드오프가 분명해진다.

메커니즘	토폴로지	Transitive	비용 모델	주 사용처
VPC Peering	1:1 mesh	❌	비교적 저렴 (트래픽당)	소수 VPC 직접 연결
Transit Gateway	hub-spoke	✅	시간당 + 트래픽당	다수 VPC, 라우팅 도메인 분리
Site-to-Site VPN	사이트 ↔ VPC 터널	(BGP 사용 시 ✅)	시간당 + 트래픽당	온프레미스 ↔ VPC
PrivateLink	서비스 endpoint	(해당 없음)	endpoint당 + 트래픽당	서비스 단위 노출, CIDR 무관

CIDR 충돌 함정

VPC Peering과 Transit Gateway 모두 IP 라우팅 기반이다. 두 VPC의 CIDR가 겹치면 패킷의 행선지가 모호해져 라우팅이 깨진다.

처음부터 겹치지 않게 CIDR 대역을 자르면 나중 연결 단계에서 돌아올 운영 비용을 피할 수 있다. 조직 단위로 IP 대역을 미리 분배해 두는 원칙이 특히 다수의 VPC 환경에서 강하게 작동한다.

이미 충돌이 발생한 환경이라면 PrivateLink가 우회로가 된다. PrivateLink는 IP 라우팅이 아닌 서비스 endpoint 노출이므로 양쪽 CIDR가 같아도 통신이 가능하다. 다만 IP 단위 광범위 통신이 아닌 “특정 서비스만 노출"이라는 좁은 사용 패턴에 한정된다.

벤더 명칭 매핑

네 메커니즘의 벤더별 명칭은 다음과 같다.

개념	AWS	GCP	Azure	Alibaba Cloud
1:1 직접 연결	VPC Peering	VPC Network Peering	VNet Peering	VPC Peering
Hub-Spoke 다수 연결	Transit Gateway	Network Connectivity Center	Virtual WAN	CEN (Cloud Enterprise Network)
온프레미스 IPSec 연결	Site-to-Site VPN	Cloud VPN	VPN Gateway	VPN Gateway
서비스 단위 노출	PrivateLink	Private Service Connect	Private Link	PrivateLink

이름이 살짝씩 다르지만 추상은 거의 같다. AWS의 PrivateLink와 GCP의 Private Service Connect, Azure의 Private Link가 같은 결의 서비스 endpoint 모델이다.

정리

VPC 밖과의 연결은 네 메커니즘 중 하나로 풀린다.

VPC Peering: 1:1 mesh, transitive 불가, 소수 VPC에 적합
Transit Gateway: hub-spoke, transitive 가능, 다수 VPC에서 비용 효율 역전
Site-to-Site VPN: 온프레미스 ↔ VPC IPSec 터널
PrivateLink: IP 라우팅 무관, 서비스 endpoint 단위 노출

어떤 메커니즘을 고르느냐가 VPC 밖과의 토폴로지·비용·격리 정책을 사실상 결정한다. 그리고 IP 라우팅 기반 메커니즘 세 개는 CIDR 충돌이 생기면 그 선택이 못쓰게 되므로, 조직 단위 IP 분배를 처음부터 잡아두는 일이 이 선택을 지탱한다.

다음 편은 보안 — Security Group과 NACL이 VPC 위에서 어떻게 다른 계층의 방어선을 만드는지 다룬다.

VPC Peering#

Transit Gateway#

Site-to-Site VPN#

PrivateLink#

비교 표#

CIDR 충돌 함정#

벤더 명칭 매핑#

정리#