1. 글 도입: 왜 TGW 라우팅 테이블을 알아야 하는가
- VPC 피어링의 한계: VPC 간 연결이 많아질수록 관리가 복잡해짐
- TGW 도입 이유: 중앙집중형 라우팅 및 연결 관리 간소화
- TGW에서 라우팅 테이블이 핵심 역할을 한다는 점 강조
2. VPC 라우팅 테이블 복습
- 각 서브넷 단위로 연결되는 라우팅 테이블
- 라우팅 대상:
local, IGW, NAT GW, VPC 피어링, VPN, Direct Connect 등 - 정적(Route Table)이고 명시적으로 선언해야 함
📌 예시
Destination | Target
------------------|----------------
10.0.0.0/16 | local
0.0.0.0/0 | igw-123456
192.168.0.0/16 | pcx-abcdef
3. TGW 라우팅 테이블이란 무엇인가?
- TGW는 여러 VPC 및 온프레미스를 연결하는 허브 역할
- 각 Attachment(VPC, VPN 등) 는 특정 라우팅 테이블에 연결됨
- TGW 라우팅 테이블은 TGW 내부에서 트래픽을 어디로 전달할지 결정
📌 예시
Destination | Attachment
------------------|------------------------
10.0.0.0/16 | VPC-A
192.168.0.0/16 | VPN-Attachment
172.16.0.0/12 | VPC-B
4. TGW vs VPC 라우팅 테이블: 차이점 비교
| 항목 | VPC 라우팅 테이블 | TGW 라우팅 테이블 |
|---|---|---|
| 적용 대상 | 서브넷 단위 | Attachment 단위 (VPC, VPN 등) |
| 경로 대상 | ENI, IGW, NAT, 피어링 등 | 다른 Attachment (VPC, VPN 등) |
| 라우팅 구성 위치 | 각 VPC 내부 | TGW 내부 |
| 구성 방식 | 각 서브넷에 명시적으로 연결 | 각 Attachment에 명시적으로 연결 |
| 주요 목적 | 인터넷/내부 통신 경로 지정 | TGW 내에서의 트래픽 흐름 제어 |
| 복잡한 네트워크 구성 시 | 스파게티처럼 얽힘 | 중앙집중형 구조로 깔끔하게 구성 가능 |
5. TGW 라우팅 테이블 구성 시 주의사항
- 한 TGW에 여러 개의 라우팅 테이블 생성 가능 (세분화된 제어)
- 전파(Route Propagation) 를 통해 자동 등록 가능 (예: VPN 연결 시)
- 명시적 라우팅 추가 필요: 전파가 되지 않는 경우 수동으로 route 등록
- 보안그룹과 별개: 라우팅이 된다고 해서 트래픽이 허용된 것은 아님
6. 예시 시나리오: 3개의 VPC와 VPN 연결
- VPC-A, VPC-B는 서로 통신
- VPC-C는 내부 백업용으로 VPC-A만 통신
- VPN은 모든 VPC와 통신해야 함
💡 이럴 경우:
- TGW 라우팅 테이블을 2개로 분리
- VPC-C는 제한된 테이블에 연결
- VPN은 두 테이블에 전파
7. 마무리 및 실무 팁
- TGW 라우팅 테이블을 활용하면 네트워크 정책을 논리적으로 분리 가능
- 초기 설계 시, Attachment의 목적별로 라우팅 테이블을 분리하는 게 유지보수에 유리
- CloudFormation이나 Terraform으로 구성 시에도 라우팅 테이블 분리는 좋은 패턴