AWS Transit Gateway 심화 3강

TGW를 진짜로 이해했는지 가르는 지점이 딱 하나 있다. association과 propagation의 차이다. 여기서 헷갈리면 "붙였는데 통신이 안 된다"의 늪에 빠진다.

이 강은 그 두 개념과 정적 경로를 예제로 못 박는다.

이 강의 목표는 다음과 같다.

• TGW 라우팅 테이블이 무엇인지 안다.
• association(소속)과 propagation(전파)을 명확히 구분한다.
• VPC 경로를 왜 손으로 넣어야 하는지 이해한다.

1. TGW 라우팅 테이블

TGW는 자체 라우팅 테이블을 갖는다. 기본 테이블이 하나 있고, 필요하면 더 만든다. 각 행은 "목적지 CIDR → 어느 어태치먼트로" 형태다. 목적지를 보고 다음 홉(어태치먼트)을 고른다.

2. association — 어느 테이블을 볼 것인가

association은 "이 어태치먼트가 어떤 라우팅 테이블에 소속되는가"다.

• 어태치먼트 하나는 정확히 한 개의 라우팅 테이블에만 소속된다.
• 반대로 한 라우팅 테이블에는 여러 어태치먼트가 소속될 수 있다.
• 소속된 테이블이, 그 어태치먼트에서 나온 트래픽이 "참고하는" 테이블이다.

3. propagation — 경로를 누가 채우나

propagation은 "어태치먼트가 알고 있는 경로가 라우팅 테이블에 자동으로 올라오는 것"이다.

• VPN·Direct Connect Gateway·Connect는 BGP로 자기 경로를 알린다. 전파를 켜면 그 경로가 테이블에 자동 등록된다.
• VPC는 경로를 전파하지 않는다. VPC의 CIDR은 TGW가 자동으로 알지 못하므로, TGW 라우팅 테이블에 정적 경로로 직접 넣어야 한다.

한 문장 요약: association은 "어느 테이블을 보나", propagation은 "그 테이블이 어떻게 채워지나". 둘은 별개이고, 둘 다 맞아야 통신이 된다.

예제 1) VPC-A, VPC-B를 TGW에 붙이고 기본 테이블에 association했다. 그런데 A에서 B로 핑이 안 간다. 원인 후보는?

해설) 두 곳을 봐야 한다. ① TGW 라우팅 테이블에 B의 CIDR(예: 10.2.0.0/16 → VPC-B 어태치먼트) 정적 경로가 있는가(VPC는 전파 안 됨). ② VPC-A의 서브넷 라우팅 테이블에 "10.2.0.0/16 → tgw-xxxx" 경로가 있는가. 둘 중 하나만 빠져도 통신이 안 된다.

예제 2) 온프레미스(192.168.0.0/16)를 VPN으로 붙이고 전파를 켰다. TGW 테이블에는 이 경로가 보이는데, 정작 VPC 안 인스턴스는 온프레로 못 간다. 왜?

해설) TGW 테이블은 전파로 채워졌지만, VPC 서브넷 라우팅 테이블에는 아무도 경로를 안 넣어줬다. VPC 쪽에서 "192.168.0.0/16 → tgw-xxxx"를 추가해야 인스턴스의 패킷이 TGW로 향한다. TGW 안과 VPC 안, 두 층의 라우팅을 늘 함께 생각해야 한다.

예제 3) "전파를 켜면 VPC 경로도 자동으로 올라오겠지"라고 가정했다. 맞나?

해설) 아니다. 전파는 BGP를 쓰는 어태치먼트(VPN/DXGW/Connect)에만 해당한다. VPC 어태치먼트의 CIDR은 전파되지 않으니 항상 정적 경로로 넣는다. 이 오해가 초심자 장애의 절반이다.

정리

• TGW 라우팅 테이블 = "목적지 CIDR → 어태치먼트" 표.
• association: 어태치먼트는 테이블 하나에 소속(어느 표를 보나).
• propagation: VPN/DXGW/Connect 경로가 BGP로 자동 등록. VPC는 정적 경로로 직접.
• 통신은 항상 TGW 테이블 + VPC 서브넷 테이블 두 층이 맞아야 성립.

다음 강에서는 라우팅 테이블을 여러 개로 쪼개서 망을 격리·공유하는 설계 패턴을 본다.