[network] VPC 피어링

One-Line Summary

VPC Peering은 두 VPC를 사설 IP로 직접 연결해, 마치 같은 네트워크에 있는 것처럼 통신하게 해주는 1:1 프라이빗 연결이다. AWS 백본을 사용하므로 인터넷·게이트웨이·어플라이언스를 거치지 않고, 계정이 달라도(cross-account) 리전이 달라도(inter-region) 연결할 수 있다. 단, 두 VPC의 CIDR이 겹치면 안 되고, 전이(transitive)되지 않으며, 연결 후 양쪽 라우트 테이블에 상대 CIDR 경로를 직접 추가해야 통신이 성립한다.

Why It Exists

서로 다른 VPC(예: 서비스팀 VPC와 공용팀 VPC, 혹은 계정이 분리된 두 조직)의 리소스가 통신해야 하는데, 인터넷을 거치면 보안·지연·비용 문제가 생긴다. 그렇다고 하나의 거대한 VPC로 합치면 격리와 계정 분리의 이점을 잃는다. "VPC는 따로 두되, 사설 IP로 안전하게 이어달라"는 요구가 필요하다.

VPC Peering이 이 역할을 한다.

두 VPC를 인터넷으로 연결하면
  -> 공인 IP 노출, 인터넷 구간 지연·비용, 보안 위험

VPC Peering 경유
  -> 두 VPC를 AWS 백본으로 직접 연결(1:1)
  -> 서로의 리소스를 사설 IP로 접근(같은 네트워크처럼)
  -> 인터넷·게이트웨이·NAT·어플라이언스 없이 통신
  -> 단일 장애점 없음, 대역폭 병목 없음

시험 감각:

"두 VPC를 사설 IP로, 소수(1:1)로, 인터넷 없이 연결" = VPC Peering. "여러 VPC/온프렘을 허브로 대규모 연결" 이면 Transit Gateway 쪽으로 방향을 튼다.

Abbreviations

동작 원리 — 사설 IP로 같은 네트워크처럼

┌─ VPC-A 10.0.0.0/16 ──┐      ┌─ VPC-B 172.16.0.0/16 ──┐
│ EC2-A 10.0.1.10      │      │ EC2-B 172.16.1.20      │
└──────────┬───────────┘      └───────────┬────────────┘
           │      ◄──── pcx (peering) ────►            │
           └───────────────┬───────────────────────────┘
                    RT-A: 172.16.0.0/16 ─► pcx
                    RT-B: 10.0.0.0/16    ─► pcx
              (AWS 백본 · 1:1 · non-transitive · 게이트웨이 아님)

시험 감각: VPC Peering은 "장비(appliance)"나 "게이트웨이"가 아니라 논리적 연결이다. "대역폭이 얼마냐, 이중화는 어떻게 하냐" 같은 함정 보기는 대부분 오답 — 관리형이라 신경 쓸 필요가 없다.

CIDR은 절대 겹치면 안 된다 (빈출·핵심)

피어링하려는 두 VPC(및 통신 대상 서브넷)의 CIDR 대역이 겹치면 피어링 자체가 되지 않거나 라우팅이 성립하지 않는다.

[불가] VPC A 10.0.0.0/16  ↔  VPC B 10.0.0.0/16   (동일 대역, 겹침)
[불가] VPC A 10.0.0.0/16  ↔  VPC B 10.0.1.0/24   (B가 A에 포함됨)
[가능] VPC A 10.0.0.0/16  ↔  VPC B 172.16.0.0/16 (겹치지 않음)

이유는 라우트 테이블 동작에 있다. VPC 내부 대역은 local 경로가 항상 최우선이므로, 상대 VPC의 CIDR이 내 VPC CIDR과 겹치면 그 트래픽은 언제나 내부(local)로 빠지고 pcx로 나가지 못한다. 또한 라우팅은 longest prefix match로 결정되므로 겹친 대역은 목적지를 명확히 구분할 수 없다.

시험 감각: "두 VPC를 연결하려는데 CIDR이 겹친다" = 피어링 불가. 애초에 VPC를 설계할 때 대역을 겹치지 않게 나눠야 한다. 자세한 배경은 Route Table의 longest prefix match / local 최우선, VPC & Subnets의 CIDR 설계 참고.

전이되지 않는다 (Not Transitive) (매우 빈출)

VPC Peering은 연결한 두 VPC 사이에서만 통신한다. 전이(transitive) 라우팅이 안 된다.

A ── peering ── B ── peering ── C

A → B : OK (직접 피어링)
B → C : OK (직접 피어링)
A → C : ❌ (B를 경유해서 못 감! A-C 직접 피어링이 없음)

즉 A–B, B–C가 있어도 A는 B를 거쳐 C에 도달할 수 없다. A가 C와 통신하려면 A–C 직접 피어링을 별도로 맺어야 한다.

이렇게 mesh가 급증하는 관리 부담이 바로 Transit Gateway가 존재하는 이유다. TGW는 허브-스포크로 각 VPC를 한 번씩만 붙이고 전이 라우팅을 지원한다.

시험 감각: "여러 VPC를 서로 다 통신시켜야 한다 / peering이 너무 많아 관리가 어렵다 / 전이(transitive) 통신이 필요하다" = Transit Gateway. "딱 두 개(또는 소수) VPC만 사설 연결" = VPC Peering.

구성 순서 — 라우트와 보안 그룹까지 해야 완성 (빈출)

피어링 연결을 맺는 것만으로는 통신이 안 된다. 라우트 + 보안 그룹까지 양쪽을 맞춰야 한다.

[VPC A RT]  Destination 172.16.0.0/16  ->  Target pcx-xxxx
[VPC B RT]  Destination 10.0.0.0/16    ->  Target pcx-xxxx
   (둘 중 하나만 있으면 편도라 통신 안 됨 → 반드시 양쪽 다)

시험 감각: "피어링을 맺었는데 통신이 안 된다" = 십중팔구 한쪽(또는 양쪽) 라우트 테이블에 pcx 경로가 없거나 SG가 막고 있음. 라우트는 반드시 양방향(양쪽 RT) 이어야 한다. 라우트 대상으로서의 pcx는 Route Table 참고.

피어 보안 그룹 참조 (동일 리전 한정)

같은 리전의 피어링에서는 상대 VPC의 보안 그룹 ID를 SG 규칙의 소스로 직접 참조할 수 있다. IP 대역 대신 SG를 참조하므로 규칙 관리가 편하다.

시험 감각: "cross-region peering인데 상대 SG를 소스로 참조하려 한다" = 안 됨. inter-region은 CIDR 기반 규칙만.

엣지 케이스 — Edge-to-Edge 라우팅 불가 (빈출)

피어링 상대의 게이트웨이·엔드포인트를 빌려 쓸 수 없다. 이를 edge-to-edge routing이라 하며 지원되지 않는다.

[VPC A] ── peering ── [VPC B] ── IGW/NAT/VPN/Gateway Endpoint ── 외부

A가 B의 IGW로 인터넷?          ❌
A가 B의 NAT로 아웃바운드?       ❌
A가 B의 VPN/DX로 온프레미스?    ❌
A가 B의 Gateway Endpoint로 S3? ❌

시험 감각: "peering으로 상대 VPC의 NAT/IGW/VPN을 공유해서 나가겠다" = 불가. 그런 중앙 집중형 아웃바운드/공유가 필요하면 Transit Gateway(중앙 egress VPC 패턴)를 쓴다.

VPC Peering vs Transit Gateway (핵심 비교·빈출)

시험 감각: "VPC 두세 개, 저비용, 단순 사설 연결" → VPC Peering. "다수 VPC + 온프레미스를 한 곳에서, 전이 통신, 관리 단순화" → Transit Gateway.

VPC Peering vs PrivateLink (짧게)

시험 감각: "VPC 전체를 서로 통신" = Peering. "특정 서비스 하나만 노출하고 나머지는 격리 / CIDR이 겹쳐도 연결" = VPC Endpoint & PrivateLink.

비용 감각 (빈출)

시험 감각: "peering 연결 비용을 줄여라"는 함정 — 연결 자체는 공짜다. 실제 비용은 데이터 전송(특히 cross-AZ / cross-region)에서 나온다. TGW와 달리 시간당 부착 요금이 없다는 점이 소규모에서 유리.

Common Wrong Directions

Exam Triggers

Memory Sentence

VPC Peering = 두 VPC를 사설 IP로 잇는 1:1 프라이빗 연결(계정·리전 넘어 가능, AWS 백본, 단일 장애점·대역폭 병목 없음). CIDR 겹치면 불가, 전이 안 됨(A-B-C면 A→C 불가 → 직접 피어링), 연결 후 양쪽 라우트 테이블에 상대 CIDR→pcx + SG 허용까지 해야 통신. 상대의 IGW/NAT/VPN은 못 빌려 씀(edge-to-edge 불가). 다수 VPC·전이·온프렘 통합은 Transit Gateway, 서비스 하나만 노출은 PrivateLink. 연결 자체는 공짜, 돈은 데이터 전송(cross-AZ/region)에서.

References

• VPC peering basics
• VPC peering limitations (transitive, edge-to-edge, overlapping CIDR)
• Update route tables for a VPC peering connection
• Update security groups to reference peer security groups
• Unsupported VPC peering configurations
• VPC peering vs Transit Gateway