VPC 피어링(VPC Peering)은 두 AWS VPC를 사설 네트워크를 통해 직접 연결하여 인스턴스 간에 트래픽을 라우팅할 수 있게 해주는 강력한 기능입니다. 연결 자체는 쉽게 설정되지만, 피어링 후에도 인스턴스 간 통신이 이루어지지 않는 가장 흔한 이유는 라우팅 테이블 설정의 누락 때문입니다. VPC 피어링은 연결 통로만 제공할 뿐, 이 통로를 통해 트래픽이 이동하도록 양쪽 VPC의 라우팅 경로를 명시적으로 설정해 주어야 합니다.
VPC 피어링이란? – “사설 터널”의 정확한 의미
| 항목 | 설명 |
|---|---|
| 연결 방식 | AWS 백본 네트워크를 통한 사설 연결 (퍼블릭 인터넷 경유 X) |
| 지원 범위 | 동일 리전, 동일 계정 / 다른 계정 / 다른 리전 (Inter-Region Peering) |
| 제한 사항 | CIDR 블록 중복 불가, 전이적 연결 불가 (A↔B, B↔C ≠ A↔C) |
| 비용 | 데이터 전송량 기반 과금 (리전 간은 더 비쌈) |
핵심: VPC 피어링은 “터널은 뚫어줬지만, 내비게이션은 안 줬다” 는 의미입니다. → 라우팅 테이블이 내비게이션 역할!
1. VPC 피어링 통신 실패의 3대 핵심 원인
VPC 피어링이 활성화된 후에도 통신이 안 되는 문제는 대부분 다음 세 가지 요소 중 하나 또는 그 이상에서 발생합니다.
| 핵심 원인 | 설명 | 진단 시 나타나는 일반적인 증상 |
| 라우팅 테이블 누락 | 양쪽 VPC의 서브넷 라우팅 테이블에 상대 VPC의 CIDR 대역을 피어링 연결(pcx-xxxxxx)로 향하도록 설정하지 않은 경우. 가장 흔한 원인입니다. | ping 시 Request Timeout 발생, telnet 연결 실패. |
| 보안 그룹(SG) 차단 | 통신을 시도하는 인스턴스 또는 수신하는 인스턴스의 보안 그룹 인바운드/아웃바운드 규칙이 상대 VPC의 트래픽을 명시적으로 허용하지 않은 경우. | 라우팅은 되지만 Connection Refused 또는 ping 시 응답 없음. |
| NACL 차단 | VPC 서브넷 레벨의 네트워크 ACL(NACL) 규칙이 통신에 필요한 포트(예: ICMP, TCP 22, 80)를 명시적으로 Deny하거나, 반환 트래픽을 차단한 경우. | 통신이 간헐적이거나 특정 포트만 차단됨. |
2. 실전 점검: 라우팅 테이블 설정 누락 사례와 복구
VPC 피어링 연결 후 통신이 안 될 때, 라우팅 테이블이 양방향으로 설정되었는지 확인하는 것이 최우선입니다.
VPC 피어링 라우팅 설정 원칙 (양방향 필수)
VPC 피어링은 대칭(Symmetric) 구조가 아닙니다. VPC A에서 VPC B로 가는 경로는 설정했더라도, VPC B에서 VPC A로 돌아오는 경로를 설정하지 않으면 통신이 실패합니다.
| 구분 | VPC A (10.10.0.0/16) | VPC B (10.20.0.0/16) |
| VPC A 라우팅 테이블 | 대상: 10.20.0.0/16 (VPC B의 CIDR) 타겟: pcx-xxxxxx (피어링 연결 ID) | – |
| VPC B 라우팅 테이블 | – | 대상: 10.10.0.0/16 (VPC A의 CIDR) 타겟: pcx-xxxxxx (피어링 연결 ID) |
통신 불가 사례 (라우팅 누락)
- 문제 상황: VPC A 인스턴스가 VPC B 인스턴스에
ping을 보냅니다. VPC A의 라우팅 테이블에는 VPC B로 가는 경로가 설정되어 있어 패킷이 피어링 연결을 통해 VPC B로 성공적으로 도달합니다. - 실패 원인: VPC B 인스턴스는
ping요청을 받았지만, 응답 패킷을 VPC A로 돌려보내기 위한 라우팅 경로가 VPC B의 라우팅 테이블에 설정되어 있지 않습니다. 따라서 응답 패킷은 VPC B의 Local 또는 Internet Gateway로 향하게 되어 패킷이 드롭됩니다. - 결과: VPC A 클라이언트는 응답을 받지 못하고 “Request Timeout” 오류를 발생시킵니다.
복구 조치: 양쪽 서브넷의 라우팅 테이블에 상대방 VPC의 CIDR과 피어링 연결 ID(pcx-xxxxxx)를 타겟으로 지정하는 경로를 즉시 추가해야 합니다.
3. 통신 활성화를 위한 종합 체크리스트
라우팅 테이블 설정을 완료한 후에도 통신이 안 된다면, 반드시 보안 그룹과 NACL 설정을 확인해야 합니다.
체크리스트 1: 라우팅 및 네트워크 연결 확인 (가장 중요)
| 항목 | 상태 확인 | 조치 사항 |
| 피어링 상태 | 피어링 연결 상태가 Active인지 확인합니다. | Pending Acceptance 상태라면 수락해야 합니다. |
| VPC A 라우팅 | VPC A 서브넷의 라우팅 테이블에 VPC B CIDR 경로가 pcx-xxxxxx를 타겟으로 하는지 확인합니다. | 경로를 추가합니다. |
| VPC B 라우팅 | VPC B 서브넷의 라우팅 테이블에 VPC A CIDR 경로가 pcx-xxxxxx를 타겟으로 하는지 확인합니다. | 경로를 추가합니다. |
| CIDR 중복 | 두 VPC의 CIDR 대역이 겹치는지(Overlapping) 확인합니다. | CIDR이 겹치면 피어링 자체가 불가능하며, VPC를 재생성해야 합니다. |
체크리스트 2: 보안 그룹(SG) 및 NACL 확인
SG와 NACL은 상태 기반이므로, 인바운드 규칙뿐만 아니라 아웃바운드 규칙도 확인해야 합니다.
| 항목 | VPC A 인스턴스 SG | VPC B 인스턴스 SG |
| 인바운드 규칙 | 대상 CIDR: VPC B CIDR(10.20.0.0/16) 허용 포트: 통신에 필요한 포트(예: 22, 80, 443) | 대상 CIDR: VPC A CIDR(10.10.0.0/16) 허용 포트: 통신에 필요한 포트 |
| 아웃바운드 규칙 | 대상 CIDR: VPC B CIDR에 대해 모든 포트 허용 (또는 특정 포트) | 대상 CIDR: VPC A CIDR에 대해 모든 포트 허용 (또는 특정 포트) |
SG 최적화 팁: 보안 그룹 규칙의 소스(Source) 또는 대상(Destination)에 IP CIDR 대신 상대방 인스턴스의 보안 그룹 ID를 직접 지정하는 것이 가장 안전하고 효율적인 방법입니다.
체크리스트 3: NACL 검토 (최후 점검)
- NACL 확인: NACL은 무상태(Stateless)이므로, 인바운드 및 아웃바운드 트래픽에 대해 모두 명시적으로 허용 규칙이 있어야 합니다.
- 규칙: 인바운드 및 아웃바운드 모두 상대 VPC CIDR과 통신 포트, 그리고 임시 포트(Ephemeral Ports, 1024-65535)에 대한
ALLOW규칙이 있어야 합니다.
결론: VPC 피어링 성공의 핵심 – “라우팅 + 보안” 이 전부다
VPC 피어링 연결 후 통신이 안 되는 문제는 대부분 라우팅 테이블 누락에서 시작됩니다. 피어링 요청을 수락하고 Active 상태가 되었다고 해서 통신이 자동으로 보장되는 것은 아닙니다. 연결을 수락한 후에는 반드시 양쪽 VPC의 서브넷 라우팅 테이블에 상대방의 CIDR 경로를 피어링 연결 타겟으로 명시해야 합니다. 이 기본 단계를 확인한 후, 보안 그룹(Security Group)과 NACL(Network ACL)이 트래픽을 차단하고 있지 않은지 양방향으로 점검하면, 90% 이상의 VPC 피어링 통신 문제를 해결할 수 있습니다.
1. 핵심 원칙: “라우팅은 방향성, 보안은 양방향”
| 요소 | 방향성 | 확인 포인트 |
|---|---|---|
| 라우팅 테이블 | 단방향 (A → B와 B → A 각각 설정 필요) | Destination CIDR → Target = pcx-xxxx |
| 보안 그룹 | 단방향 (인바운드/아웃바운드 별도) | SG가 자기 참조 허용 여부 |
| NACL | stateless → 양방향 규칙 모두 필요 | 인바운드 + 아웃바운드 동일 포트 허용 |
실전 팁:
- 라우팅은 “내가 상대를 어떻게 가는지” → 내 라우팅 테이블에 추가
- 보안은 “상대가 나에게 올 수 있는지” → 내 SG/NACL에 인바운드 허용
2. 실전 체크리스트 (5분 내 진단)
| 단계 | 명령어 / 콘솔 경로 | 확인 내용 |
|---|---|---|
| 1. 피어링 상태 | 콘솔 → VPC → Peering Connections | Status = Active |
| 2. 라우팅 테이블 (양쪽) | VPC → Route Tables | |
| → 10.1.0.0/16 → pcx-xxx (VPC A) | ||
| → 10.2.0.0/16 → pcx-xxx (VPC B) | ||
| 3. 서브넷 연관 | Route Table → Subnet Associations | 통신하려는 서브넷이 라우팅 테이블에 연결되었는지 |
| 4. 보안 그룹 | EC2 → Security Groups | |
| 인바운드: Source = 10.2.0.0/16 (VPC B → A) | ||
| 아웃바운드: Destination = 10.1.0.0/16 (기본 허용) | ||
| 5. NACL | VPC → Network ACLs | |
| 인바운드: 10.2.0.0/16, 포트 허용 | ||
| 아웃바운드: 10.1.0.0/16, 포트 허용 | ||
| 6. 테스트 | EC2 인스턴스 내 |
bash
# VPC A → VPC B
ping 10.2.1.10
telnet 10.2.1.10 33063. 흔한 실수 TOP 3 & 해결법
| 실수 | 증상 | 해결 |
|---|---|---|
| 라우팅 테이블에 서브넷 미연결 | 일부 인스턴스만 통신 | Route Table → Subnet Associations 추가 |
| NACL 아웃바운드 누락 | 요청은 가지만 응답이 안 옴 | NACL 아웃바운드에 동일 포트 허용 추가 |
| SG 자기 참조 누락 | 같은 VPC 내 인스턴스 간 통신 실패 | 인바운드에 sg-xxxx (self) 추가 |
4. 예방 조치 & 자동화 팁
- Terraform / CloudFormation으로 관리 hcl
resource "aws_route" "vpc_a_to_b" { route_table_id = aws_route_table.vpc_a.id destination_cidr_block = "10.2.0.0/16" vpc_peering_connection_id = aws_vpc_peering_connection.main.id } - CloudWatch + EventBridge 알람
- VPC Flow Logs → REJECT 발생 시 Slack 알림
- 문서화
- Confluence에 “VPC A ↔ B 피어링 설정 가이드” 작성
- 라우팅/CIDR/SG 테이블 포함
5. 한 줄 요약 (Runbook용)
“피어링 Active → 양쪽 라우팅 테이블에 CIDR 추가 → 서브넷 연결 → SG/NACL 양방향 허용 → ping 테스트” 이 5단계를 빠짐없이 수행하면 VPC 피어링은 100% 통신 성공합니다.
이 결론을 운영팀 교육 자료나 장애 대응 Runbook에 삽입하면, 신입 엔지니어도 10분 내에 VPC 피어링 통신 문제를 자가 진단할 수 있습니다.
Disclaimer: 본 블로그의 정보는 개인의 단순 참고 및 기록용으로 작성된 것이며, 개인적인 조사와 생각을 담은 내용이기에 오류가 있거나 편향된 내용이 있을 수 있습니다.