AWS Transit Gateway 심화 5강

지금까지는 한 리전 안이었다. 실무의 TGW는 회사 데이터센터로, 그리고 다른 리전으로 뻗어 나간다.

이 강은 온프레미스 연결 세 방식과 리전 간 Peering, 그리고 멀티리전 DR 설계를 다룬다.

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

• 온프레미스 연결(VPN·Direct Connect)의 트레이드오프를 안다.
• 리전 간 TGW Peering의 성격을 이해한다.
• 멀티리전에서 ASN과 TGW 개수를 어떻게 잡는지 안다.

1. 온프레미스로 — VPN vs Direct Connect

방식	회선	특징
Site-to-Site VPN	인터넷 위 IPsec	빠른 구축·저렴, 대역·지연은 인터넷에 의존
Direct Connect (+DXGW)	통신사 전용 회선	안정적·저지연·고대역폭, 구축 오래·비쌈

실무 정석은 Direct Connect를 주 경로, VPN을 백업 경로로 함께 두는 것이다. BGP가 자동으로 우선순위를 정한다.

• VPN은 BGP 동적 라우팅을 권장한다. 여러 터널에 ECMP(multipath)를 켜면 대역을 합칠 수 있다.
• Direct Connect는 Direct Connect Gateway(DXGW)를 통해 TGW에 연결한다. DXGW는 여러 리전의 TGW를 묶는 관문 역할도 한다.

예제 1) Direct Connect 주 회선이 끊겼을 때 VPN으로 자동 전환되게 하려면?

해설) 두 경로를 BGP로 붙이고 온프레 라우터에서 DX 경로를 더 선호하도록 광고한다(예: AS-path 짧게/로컬 프리퍼런스 높게). DX가 죽으면 BGP가 경로를 거둬들이고 VPN 경로로 수렴한다. 정적 경로로는 이 자동 절체가 매끄럽지 않다.

2. 리전 간 — TGW Peering

다른 리전의 TGW와 Peering으로 붙으면, 리전을 넘어 통신할 수 있다.

• AWS 글로벌 백본을 타며 자동 암호화된다.
• Peering 경로는 전파되지 않으므로 정적 경로로 넣는다(2·3강의 원칙 그대로).
• 리전 간 트래픽은 8500 MTU를 지원한다.

예제 2) 서울 리전 VPC와 버지니아 리전 VPC가 통신해야 한다. 무엇을 만들고 어떤 경로를 넣나?

해설) ① 서울 TGW ↔ 버지니아 TGW Peering 어태치먼트 생성. ② 서울 TGW 테이블에 "버지니아 CIDR → peering 어태치먼트" 정적 경로, 버지니아 쪽엔 그 반대. ③ 각 VPC 서브넷 테이블에도 상대 리전 CIDR → 각자 TGW 경로. 역시 TGW 층 + VPC 층 둘 다.

3. 멀티리전 설계 원칙

• 리전당 TGW는 1개로 충분하다. TGW는 그 자체로 고가용성(다중 AZ)이라 HA용으로 더 만들 필요가 없다.
• 여러 TGW를 쓸 때는 ASN을 리전마다 다르게 준다. 같은 ASN이 마주 보면 BGP가 경로를 루프로 보고 버린다.
• CIDR을 리전·환경별로 겹치지 않게 설계한다. 겹치면 TGW가 어디로 보낼지 정할 수 없다.

예제 3) 서울·버지니아 두 TGW에 똑같이 ASN 64512를 줬더니 리전 간 경로가 학습되지 않는다. 왜?

해설) BGP는 자기 ASN이 경로의 AS-path에 다시 나타나면 루프로 판단해 그 경로를 버린다. 두 TGW의 ASN이 같으면 상대가 광고한 경로에 자기 ASN이 들어 있어 폐기된다. 서로 다른 ASN(예: 64512 / 64513)을 줘야 한다.

정리

• 온프레는 VPN(빠름·저렴) + Direct Connect(전용·안정)를 BGP로 조합, DX 주·VPN 백업.
• 리전 간은 TGW Peering(암호화·정적 경로), 리전당 TGW 1개면 충분.
• 멀티리전은 ASN을 다르게, CIDR은 겹치지 않게.

다음 강에서는 여러 계정이 TGW 하나를 공유하는 방법과 요금·모니터링·한도, 설계 베스트 프랙티스를 정리하며 시리즈를 마친다.