VPC 피어링
더 많은 작업
- VPC Peering; VPC 피어링; AWS VPC 피어링
- 두 VPC를 1:1로 직접 연결해 사설 IPv4·IPv6 주소로 마치 같은 네트워크처럼 통신하게 하는 아마존 VPC 기능
VPC 피어링 연결은 두 VPC 사이에 트래픽을 사설 주소로 라우팅할 수 있게 해 준다. 같은 계정의 VPC끼리는 물론 다른 AWS 계정의 VPC와도, 다른 리전의 VPC와도(리전 간 VPC 피어링) 연결할 수 있다. 피어링은 VPC의 기존 인프라를 이용하므로 별도의 게이트웨이나 VPN 장비가 아니며, 단일 장애점이나 대역폭 병목이 없다.
리전 간 피어링 트래픽은 AWS 시설을 떠나기 전에 암호화되고 항상 AWS 글로벌 백본에 머물며 공용 인터넷을 지나지 않는다.
| 항목 | 설명 |
|---|---|
| 연결 형태 | 두 VPC 사이의 1:1 관계. VPC 하나가 여러 피어링 연결을 가질 수는 있다 |
| 전이적 라우팅 | 지원하지 않음. A–B, A–C가 연결돼 있어도 B와 C는 A를 거쳐 통신할 수 없다 |
| CIDR 중복 | 두 VPC의 IPv4 또는 IPv6 CIDR이 하나라도 겹치면 연결할 수 없다 |
| 범위 | 같은 리전·다른 리전, 같은 계정·다른 계정 모두 가능 |
| 중복 연결 | 같은 두 VPC 사이에 피어링 연결은 하나만 가능 |
| 라우팅 | 양쪽 VPC 소유자가 각자 라우팅 테이블에 상대 VPC CIDR → 피어링 연결 경로를 직접 추가해야 함 |
| 요금 | 연결 생성 요금 없음. 같은 가용 영역 안에서 오가는 데이터는 무료이고, 가용 영역 간·리전 간 전송에는 데이터 전송 요금 |
| 할당량 | VPC당 활성 피어링 연결 기본 50개, 요청하면 최대 125개 |
- 요청자 VPC 소유자가 수락자 VPC 소유자에게 피어링 연결을 요청한다. 수락자 VPC의 CIDR은 요청자와 겹치면 안 된다.
- 수락자가 요청을 수락하면 연결이 활성화된다. 수락하지 않은 요청은 7일 뒤 만료된다.
- 양쪽 소유자가 각자의 라우팅 테이블에 상대 VPC 주소 범위를 피어링 연결로 보내는 경로를 추가한다.
- 필요하면 보안 그룹 규칙을 고친다. 같은 리전의 피어링이라면 상대 VPC의 보안 그룹을 원천·대상으로 참조할 수 있다.
- 퍼블릭 DNS 호스트 이름이 사설 IP로 해석되게 하려면 피어링 연결의 DNS 확인 지원 옵션을 켠다.
라우팅 테이블 예시(VPC A 10.0.0.0/16, VPC B 10.1.0.0/16)는 다음과 같다.
| 위치 | 대상 주소 | 대상 |
|---|---|---|
| VPC A 라우팅 테이블 | 10.1.0.0/16 | pcx-11112222 |
| VPC B 라우팅 테이블 | 10.0.0.0/16 | pcx-11112222 |
피어링은 두 VPC 사이의 트래픽만 전달한다. 상대 VPC의 게이트웨이나 연결을 빌려 밖으로 나가는 엣지 간 라우팅(edge to edge routing)은 모두 안 된다.
| VPC A에 있는 것 | VPC B에서 쓸 수 있는가 |
|---|---|
| 인터넷 게이트웨이 | 불가. B는 A의 인터넷 게이트웨이로 인터넷에 나갈 수 없다 |
| NAT 장치(NAT 게이트웨이, NAT 인스턴스) | 불가 |
| 사내망과의 Site-to-Site VPN 연결 | 불가 |
| 사내망과의 Direct Connect 연결 | 불가 |
| S3 게이트웨이 엔드포인트 | 불가 |
| 다른 VPC C와의 피어링 | 불가(전이적 피어링 미지원). B–C를 직접 피어링해야 한다 |
이 밖에 피어링된 VPC의 아마존 DNS 서버에 직접 질의할 수 없고, 리전 간 피어링의 MTU는 8500바이트로 같은 리전 피어링(9001바이트)보다 작다.
VPC가 많아지면 피어링은 그물망(full mesh)이 된다. 모든 VPC를 서로 연결하려면 n(n-1)/2개의 연결이 필요하므로, AWS 백서의 예처럼 VPC 100개를 전부 잇는 데 4,950개의 피어링 연결이 필요하다. 연결마다 양쪽 라우팅 테이블을 관리해야 하고 VPC당 연결 수에도 한도가 있다. 또 온프레미스 연결(VPN, Direct Connect)도 VPC마다 따로 만들어야 한다. 그래서 AWS 백서는 연결할 VPC가 10개 미만이고 각 연결을 개별 관리할 수 있을 때 피어링을 권하고, 그 이상은 AWS Transit Gateway 같은 허브 방식을 쓰라고 안내한다.
| 항목 | VPC 피어링 | AWS Transit Gateway |
|---|---|---|
| 구조 | 점대점(1:1), 많아지면 그물망 | 허브 앤 스포크 |
| 전이적 라우팅 | 불가 | 가능(라우팅 테이블로 통제) |
| 규모 | 수 개~십여 개 VPC에 적합 | 수천 개 VPC까지 연결 |
| 온프레미스 연결 공유 | 불가. VPC마다 따로 연결 | VPN·Direct Connect를 한 번 붙여 모든 VPC가 공유 |
| 요금 | 시간당 요금 없음, 가용 영역 간·리전 간 데이터 전송 요금만 | 연결(attachment)당 시간 요금 + 처리 데이터 요금 |
| 성능 | 별도 장비가 없어 대역폭 병목 없음 | 연결별 대역폭 한도가 있음 |
| 보안 그룹 참조 | 같은 리전이면 상대 VPC 보안 그룹 참조 가능 | 인바운드 규칙에서 참조 가능 |
AWS 백서는 VPC 피어링이 VPC 간 연결 방식 가운데 총비용이 가장 낮고 전체 성능이 가장 높다고 설명한다. 그래서 VPC 몇 개만 서로 대량 통신하는 경우에는 Transit Gateway 환경에서도 그 구간만 피어링을 추가하는 혼합 구성이 쓰인다.
- 피어링은 전이적이지 않다. "A–B, B–C가 피어링되어 있는데 A와 C가 통신하지 못한다"는 문제는 A–C 피어링을 추가하거나 Transit Gateway로 바꾸는 것이 답이다.
- CIDR이 겹치는 VPC는 피어링할 수 없다. 이 경우 주소 재설계나 PrivateLink(특정 서비스만 노출) 같은 대안을 고른다.
- 피어링 연결을 만든 것만으로는 통신되지 않는다. 양쪽 라우팅 테이블 경로와 보안 그룹 규칙을 함께 확인한다.
- 다른 계정, 다른 리전 VPC와도 피어링할 수 있다.
- 다수 VPC와 온프레미스를 중앙에서 연결하고 관리 부담을 줄이라는 요구에는 피어링보다 Transit Gateway가 맞다. 소수 VPC 간 연결을 가장 저렴하게 하라면 피어링이 맞다.