🔥 VPC Peering과 Transit Gateway: VPC를 잇는 두 방법

콘솔에서 VPC 메뉴를 열면 사이드바 아래쪽에 Peering Connections와 Transit Gateway Attachments가 나란히 들어 있다. 같은 곳에 도구 두 개가 들어 있는 건 보통 그 자체로 신호다. 한쪽이 다른 한쪽을 완전히 대체하지 않는다는 의미다.

VPC를 잇는 일은 처음에는 한 줄짜리다. 양쪽 라우팅 테이블: 패킷이 어디로 가는지에 peer prefix 한 줄을 적어 넣고, Security Group: 인스턴스 레벨 방화벽에 sg-xxxx 참조 한 줄을 더하면 두 VPC 사이에 사설 IP 트래픽이 통한다. 그게 VPC Peering이다. 그런데 다섯 번째 VPC가 들어오는 순간, 한 줄짜리가 아니다.

대체재가 아니라 임계점이 다른 두 도구다. 메쉬가 무거워지는 시점에서 허브가 들어선다. 그 임계점이 어디서 만들어지는지를 따라가면 두 도구가 어디서 갈리는지 확인할 수 있다.

VPC Peering: 양쪽 route table에 한 줄씩

VPC Peering은 두 VPC 사이에 매달리는 1:1 사설 연결이다. 게이트웨이 박스도 없고, VPN 터널도 없고, 따로 부착되는 가상 어플라이언스도 없다. 두 VPC의 라우팅 테이블에 상대 VPC의 CIDR을 destination으로 하는 한 줄씩을 양쪽에 적어 넣으면 그 순간부터 두 VPC가 같은 사설 망인 것처럼 동작한다.

라우팅이 양방향으로 대칭하게 자동 채워지지는 않는다. AWS는 VPC A와 B 사이의 peering connection을 인식하지만, A의 라우팅 테이블에 B의 prefix를 적는 것도, B의 라우팅 테이블에 A의 prefix를 적는 것도 각각 사람이 한 번씩 해야 한다. 양쪽 VPC가 다른 계정에 있으면 한쪽이 connection을 요청하고 다른 쪽이 수락하는 두 단계 핸드셰이크가 추가로 들어가지만, 라우팅 한 줄씩 적는 일은 똑같다.

그리고 한 가지 cold rule이 있다. 두 VPC의 CIDR이 겹치면 AWS는 connection 자체를 즉시 .failed. 상태로 표시한다. 인바운드/아웃바운드 룰의 문제가 아니라 정의의 문제다. 같은 IP 주소가 양쪽에 있으면 라우팅 테이블이 어디로 보내야 할지 결정할 수 없다. 그래서 VPC를 만들 때부터 CIDR을 다르게 잡는다는 게 사실상 강제 사항이 된다. IPv6 CIDR이 따로 있어도 IPv4가 겹치면 그냥 fail이다 (verified 2026-04-26).

VPC Peering은 inter-region도 가능하다. 2017년 11월 29일 re:Invent에서 출시된 inter-region VPC peering이 그 사례다 (verified 2026-04-26). 같은 계정 안의 두 리전이든, 다른 계정의 두 리전이든 동일한 모델로 잇는다. CIDR 겹침 거부, 라우팅 한 줄씩, transitive routing 불가까지 똑같이 들고 온다.

가격도 가볍다. 연결 자체에는 시간당 요금이 없고, 같은 AZ 안에서 오가는 트래픽은 무료, AZ를 넘나드는 트래픽만 양방향 각각 GB당 0.01달러가 붙는다 (verified 2026-04-26 against Demystifying Amazon VPC peering charges). 두 VPC를 잇는 일에 고정 비용이 붙지 않는다는 점이 Peering의 첫 번째 매력이다.

transitive routing이 거부되는 규칙

여기까지가 Peering의 좋은 면. 그런데 한 가지 단단한 한도가 있다.

VPC Peering은 transitive routing을 지원하지 않는다 (AWS 공식 표현 그대로 "VPC peering does not support transitive peering relationships"). 이게 무슨 뜻이냐면, A↔B와 A↔C라는 두 peering이 있을 때 B의 패킷이 A를 거쳐서 C로 가는 길은 자동으로 열리지 않는다는 의미다. B에서 C로 가려면 B↔C라는 세 번째 peering connection을 따로 만들어야 한다.

이게 곱셈 문제로 변하는 이유다. VPC가 N개일 때 모두 사이를 잇는 풀 메쉬는 N(N-1)/2개의 peering connection이 필요하다. 4개면 6개, 6개면 15개, 10개면 45개, 50개면 1,225개. AWS 공식 문서가 직접 거는 예시는 VPC 100개를 풀 메쉬로 잇는 데 4,950개의 peering connection이 필요하다는 숫자다 (verified 2026-04-26).

연결 자체에 요금이 안 붙어도, 4,950줄의 라우팅 테이블 항목과 4,950개의 peering connection을 사람이 관리하는 일에는 운영 비용이 붙는다. 한 VPC가 추가될 때마다 기존 N개의 모든 VPC와 connection을 새로 만들고 라우팅을 양쪽에 적어 넣어야 한다. 한 줄짜리가 N줄짜리로 부풀고, 다음에는 NM줄짜리가 된다.

여기가 Peering이 무거워지는 지점이다. 다섯 번째 VPC가 들어올 때부터는 라우팅 테이블이 매번 한 줄씩 늘어나고, 한 VPC를 빼는 일도 N개의 라우팅 테이블에서 한 줄씩 지워야 한다. 그게 메쉬 토폴로지의 본질적 비용이다.

Transit Gateway: 허브 한 개와 attachment 다발

AWS Transit Gateway는 정확히 이 임계점에서 등장한다. 2018년 11월 26일 re:Invent에서 발표된 TGW는 VPC들 사이에 있는 허브 한 개다 (verified 2026-04-26 against Introducing AWS Transit Gateway 발표 노트).

구조는 간단하다. 리전 안에 Transit Gateway 한 개를 만든다. 그 다음 각 VPC에서 TGW로 attachment를 만들어 매단다. attachment는 VPC 안의 한 Subnet 한 장을 골라 그 Subnet에 ENI를 두는 형태다 (AZ당 하나씩). VPC들 사이의 통신은 서로를 직접 보지 않고 자기 attachment를 통해 TGW로 보낸다. TGW가 라우팅 테이블을 보고 다음 attachment로 패킷을 흘려준다.

여기서 양쪽 라우팅이 한 번씩 갈리는 구조다. VPC 안의 라우팅 테이블에는 "이 prefix들은 TGW로 보내라"는 한 줄을 적어 넣는다. TGW 안에는 별도의 TGW route table이 따로 있고, 거기에 attachment별로 propagation이나 static route가 들어간다. 라우팅 테이블: 패킷이 어디로 가는지에서 짚었듯 TGW는 VPC subnet RT에 propagate하지 않는다는 한 줄이 그래서 중요한 대목이었다. VPC 쪽 RT는 사람이 적고, TGW 쪽 RT는 attachment에서 자동 propagation으로 채울 수 있다. 두 카드는 서로 분리되어 있다.

그래서 N개의 VPC를 모두 잇는 일이 N(N-1)/2개의 connection이 아니라 N개의 attachment로 줄어든다. 4 VPC = 4 attachment. 10 VPC = 10 attachment. 100 VPC = 100 attachment. 한 VPC가 추가될 때 다른 VPC들의 라우팅을 건드리지 않고 새 attachment 하나만 만들면 되는 구조다. 그게 허브-스포크의 본질이고, 메쉬가 무거워지는 임계점에서 TGW가 들어서는 이유다.

자동 transitive routing도 따라온다. VPC A가 TGW에 매달리고 VPC B도 TGW에 매달려 있으면, 양쪽 VPC 라우팅 테이블에 TGW 대상 한 줄씩 박고 TGW route table에 두 attachment의 prefix가 propagate되는 순간 A↔B가 한 번에 통한다. Peering처럼 별도 connection을 만들 필요가 없다. 그게 hub의 정의 자체이기도 하다.

TGW에 따라오는 짐: 시간당, GB당, 그리고 100 Gbps

여기까지는 TGW가 N제곱 문제를 N으로 풀어주는 깔끔한 그림. 그런데 TGW에는 NAT Gateway: Private Subnet의 외부 연결에서 본 것과 정확히 같은 구조의 짐이 따라온다. 시간당 + GB당 이중 비용 구조.

AWS Transit Gateway의 가격은 두 항목에서 발생한다 (verified 2026-04-26 against AWS Transit Gateway pricing).

• VPC attachment 시간당 요금: AWS 공식 페이지의 예시 리전(US East/Ohio) 기준 0.05달러/h. 한 달 약 36달러. attachment 1개당.
• 데이터 처리 GB당 요금: 같은 예시 리전 기준 0.02달러/GB. TGW로 보내는 쪽 VPC owner에게 청구.

리전이 바뀌면 숫자도 다르다. 서울 리전(ap-northeast-2)도 attachment 시간당 + 데이터 처리 GB당 두 항목이 동시에 붙어 있는 구조는 동일하지만, 정확한 숫자는 AWS 공식 pricing 페이지에서 ap-northeast-2 탭으로 직접 확인하는 게 안전하다.

10개의 VPC를 TGW로 묶으면 AWS는 attachment 비용으로 월 약 360달러를 고정 청구한다. 데이터 처리 비용은 별도. 4,950개의 peering connection을 사람이 관리하는 일이 정말 무거워지는 어떤 임계점 이후에는 이 비용이 그래도 싸게 다가오지만, VPC가 두세 개일 때는 같은 비용이 과한 도구가 된다. NAT Gateway와 똑같은 패턴이다. 관리형이 감추는 비용은 작은 환경에서 비례적으로 더 무겁게 다가온다.

한도도 알고 있어야 한다 (verified 2026-04-26 against AWS Transit Gateway Quotas).

• TGW 한 개당 attachment 5,000개 (조정 가능). 사실상 한 리전 안에서 100~1,000 VPC 환경까지 한 TGW로 묶을 수 있다는 신호.
• VPC 한 개당 묶일 수 있는 TGW가 5개 (조정 불가, 공식 명칭은 Transit gateways per VPC). 한 VPC가 동시에 5개 이상의 TGW에 매달릴 수 없다.
• VPC attachment 한 개당 AZ당 최대 100 Gbps each direction burst (조정은 SA/TAM 경유 별도 협의). 예전 50 Gbps 한도가 100 Gbps로 올라간 상태가 현재.

100 Gbps라는 숫자가 일반 운영에서는 거의 닿지 않지만, 한 VPC 안에 초고성능 ML 학습이나 대용량 영상 transcoding처럼 100 Gbps급으로 몰리는 워크로드가 있다면 TGW 자체가 병목이 될 수 있다는 뜻이다. 알고 시작하는 것과 모르고 부딪히는 건 다른 문제다.

Security Group: 인스턴스 레벨 방화벽의 cross-VPC 참조 규칙에도 비대칭이 있다. VPC Peering으로 묶인 VPC 사이에는 SG ID로 양방향 참조가 가능하지만, TGW로 묶인 VPC 사이에는 인바운드 룰에서만 SG ID 참조가 허용한다 (verified 2026-04-26 against TGW VPC Attachments).

임계점: 그래서 언제 어느 쪽인가

이 두 도구가 같은 메뉴에 함께 들어 있는 이유로 돌아오자. 대체재가 아니다. 임계점이 다른 도구다.

VPC가 2~5개 수준이면 TGW는 보통 과한 도구다. Peering 한두 줄로 충분하다. 매월 36달러씩 하나당 붙어 있는 attachment 비용이, 손으로 관리하는 라우팅 테이블 한두 줄의 운영 부담보다 비례적으로 무거워지는 시점이다. 실제로 startup이나 한 팀이 운영하는 환경의 거의 전부가 여기 들어간다.

VPC가 6~20개 사이는 회색 지대. 풀 메쉬가 정말 필요한지(많은 환경이 그렇지 않다. 두세 hub VPC만 다른 모든 VPC와 통신하는 패턴이 흔하다), CIDR 설계가 안정적인지, on-prem과 묶일 일이 곧 들어올지 같은 주변 조건들이 결정을 좌우한다. 풀 메쉬가 정말 필요한 환경에서는 15개 이상부터는 보통 TGW가 더 가볍다.

VPC가 20개 이상인 환경에서는 TGW가 거의 기본값. 4,950개의 peering connection을 사람이 관리하는 일은 에러 가능성이 운영 비용을 뛰어넘는다. on-prem과 VPN/Direct Connect로 묶이는 환경, 다중 계정 환경에서 AWS Organizations로 공유되는 환경도 TGW의 주특기가 된다.

이건 마법의 숫자 하나가 정답이 아니라 운영 부담의 곡선이 교차하는 지점이다. attachment의 고정 시간당 비용과 사람이 관리하는 수동 라우팅의 운영 비용이 교차하는 지점에서 결정이 나고, 환경마다 그 지점이 다르다. 작은 환경에서 "다음에 커질 거니까 미리 TGW를 박자"는 흔한 함정인데, 실제로 커지지 않으면 AWS는 그 비용을 매월 그대로 청구한다.

CIDR이 처음부터 충돌하는 환경은 또 다른 이야기다. Peering은 두 VPC의 CIDR이 겹치는 순간 connection 자체를 AWS가 즉시 .failed. 상태로 표시한다. TGW는 조금 다르게, attachment 자체는 받아들이는데 겹치는 쪽 prefix가 TGW route table에 propagate되지 않는다 (verified 2026-04-26 against Amazon VPC attachments in AWS Transit Gateway). 결과적으로 트래픽이 흐르지 않는 건 같지만, 에러가 안 떠서 조용히 안 통하는 형태로 나타난다. 두 도구 모두 CIDR 재설계가 먼저고, 그게 정말 어려운 환경에서는 Private NAT Gateway + ALB 조합이나 PrivateLink로 겹침 자체를 우회하는 다른 패턴으로 옮겨 간다. 그건 이 글의 범위 밖이다.

결정은 VPC 개수가 아니라 곡선의 교차점에서

VPC를 잇는 결정은 VPC 개수 하나로 갈리지 않는다. 풀 메쉬가 정말 필요한지, on-prem이 곧 묶일지, 비용 곡선의 교차점이 어디인지가 같이 짠다. Peering의 한 줄짜리 가벼움이 어느 시점에서 무거워지고, TGW의 매월 고정 비용이 어느 시점에서 가벼워지는지, 그 교차점을 알고 있는 환경이 보통 운영 비용을 가장 적게 쓴다.

참고 자료

• How VPC peering connections work: Amazon VPC 공식 문서: Peering 동작 모델, transitive routing 거부, CIDR overlap 거부 규칙
• Amazon VPC attachments in AWS Transit Gateway: TGW VPC attachment의 라우팅 모델과 CIDR overlap 시 propagate 차단 동작
• AWS Transit Gateway Quotas: TGW당 attachment 5,000개·VPC당 TGW 5개·AZ당 100 Gbps 한도
• AWS Transit Gateway pricing: 시간당 attachment + GB당 데이터 처리의 이중 비용 구조와 리전별 표기
• Demystifying Amazon VPC peering charges (AWS 네트워킹 블로그): Peering의 same-AZ 무료·cross-AZ $0.01/GB 데이터 전송 가격 모델
• Introducing AWS Transit Gateway: re:Invent 2018 발표: 2018-11-26 출시 시점, 초기 지원 리전 목록
• Announcing Support for Inter-Region VPC Peering: re:Invent 2017 발표: 2017-11-29 inter-region VPC peering 출시