서로 다른 VPC에 있는 서버끼리 통신해야 할 때, 인터넷을 거치지 않고 사설 IP로 직접 연결하는 방법이 VPC 피어링입니다. 마이크로서비스를 VPC별로 분리했거나, 다른 계정·리전의 자원에 붙어야 할 때 자주 씁니다. 개념은 단순하지만 CIDR 설계와 라우팅을 빠뜨리면 "피어링은 됐는데 통신이 안 되는" 상황에 자주 빠집니다.
피어링이 되는 것과 안 되는 것
| 항목 | 동작 |
|---|---|
| 사설 IP 통신 | 두 VPC가 인터넷 없이 직접 통신 |
| 리전·계정 간 | 다른 리전·다른 계정의 VPC와도 가능 |
| CIDR 중복 | 대역이 겹치면 연결 불가 |
| 전이 라우팅 | A-B, B-C가 있어도 A는 C와 통신 불가 |
| 게이트웨이 공유 | 상대 VPC의 IGW·NAT는 쓸 수 없음 |
가장 자주 발목 잡는 두 가지는 CIDR 중복과 전이 불가입니다. 피어링은 1:1 직접 연결만 의미하므로, 여러 VPC를 허브처럼 묶으려면 Transit Gateway가 필요합니다.
구성 순서
-
CIDR이 겹치지 않는지 먼저 확인합니다. 둘 다
10.0.0.0/16이면 피어링 자체가 막힙니다. VPC를 만들 때부터 대역을 분리해 두는 게 정석입니다. -
피어링 연결을 요청하고 수락합니다. 다른 계정이면 상대가 수락해야 활성화됩니다.
로컬 터미널
aws ec2 create-vpc-peering-connection \
--vpc-id vpc-aaaa \
--peer-vpc-id vpc-bbbb
aws ec2 accept-vpc-peering-connection \
--vpc-peering-connection-id pcx-xxxx
- 양쪽 라우팅 테이블에 상대 대역 경로를 추가합니다. 이 단계를 한쪽만 하면 패킷이 가도 응답이 못 돌아옵니다.
로컬 터미널
# VPC A 라우팅 테이블: B 대역을 피어링으로
aws ec2 create-route --route-table-id rtb-a \
--destination-cidr-block 10.1.0.0/16 \
--vpc-peering-connection-id pcx-xxxx
# VPC B 쪽에도 A 대역(10.0.0.0/16)을 동일하게 추가
- 보안 그룹을 상대 대역으로 허용합니다. 라우팅이 맞아도 보안 그룹이 막으면 통신이 안 됩니다. 인바운드 규칙에 상대 VPC의 CIDR(또는 보안 그룹 ID)을 추가합니다.
안 될 때 점검 순서
연결이 안 되면 이 순서로 봅니다.
- 피어링 상태가
active인가 (수락 누락?) - 양쪽 라우팅 테이블에 상대 대역 경로가 다 있는가
- 보안 그룹·NACL이 상대 대역을 허용하는가
- A를 거쳐 C로 가려는 전이 통신은 아닌가
요점 정리
- VPC 피어링은 두 VPC를 사설 IP로 직접 잇는 1:1 연결입니다.
- CIDR이 겹치면 연결할 수 없으므로 대역 설계가 먼저입니다.
- 라우팅은 반드시 양쪽 모두, 보안 그룹도 상대 대역을 열어야 합니다.
- 전이 라우팅은 안 되므로, 다수 VPC 연결은 Transit Gateway를 씁니다.
VPC 피어링과 라우팅·보안 그룹을 직접 구성해 통신을 확인하는 실습은 클라우드 트랙에서 회원가입 없이 무료로 할 수 있습니다.