AWS Transit Gateway 중앙 허브가 전선으로 VPC들을 연결하는 평면 구성도
글 요약
AWS Transit Gateway 라우팅의 핵심인 Route Table, Association, Propagation의 관계를 실제 구성 예시와 함께 정리합니다. VPC 간 통신이 안 되는 이유, 라우팅 테이블 분리 전략, VPC 피어링·Direct Connect Gateway와의 차이점까지 한 번에 정리해 두면 현업에서 시간을 크게 아낄 수 있거든요.
“VPC 간 통신을 Transit Gateway로 묶었는데 왜 특정 VPC만 통신이 안 되지?”
Route Table과 Propagation 설정 하나가 빠지면 이런 문제가 발생합니다. 이 글에서는 Association과 Propagation의 차이부터, 실전에서 통하는 라우팅 분리 전략, 그리고 다른 연결 방식 대비 Transit Gateway만의 차별점까지 정리했어요.
Transit Gateway를 도입한 후 “설정은 다 했는데 VPC끼리 통신이 안 된다”는 문의가 정말 많이 들어오더라고요. 대부분이 Route Table은 만들었지만 Association 또는 Propagation이 빠진 경우였어요. Transit Gateway 라우팅은 VPC 라우팅 테이블과 완전히 다른 개념이라 처음 접하면 혼동하기 쉬운 부분이 많거든요. 오늘은 이 구조를 한 번에 정리해 보겠습니다.
Transit Gateway는 AWS 글로벌 인프라에서 리전 단위 허브 라우터 역할을 합니다. VPC 라우팅 테이블이 1:1 통신을 처리한다면 Transit Gateway는 다수의 VPC, VPN, Direct Connect를 하나의 라우팅 도메인으로 �어주는 거예요. 그래서 멀티 VPC, 멀티 계정 환경에서는 거의 필수로 사용되고 있거든요.
📌 이 글의 핵심 정리
- Transit Gateway 라우팅은 Default Route Table / Custom Route Table 두 종류로 나뉘며, 기본 동작이 다르다는 점을 먼저 이해하는 게 핵심이에요.
- Association은 어떤 Attachment가 이 Route Table을 “보는지”, Propagation은 어떤 Attachment 경로의 라우트가 자동으로 “들어오는지”를 결정합니다.
- VPC 간 통신이 안 되는 원인의 80%는 Propagation 미설정 또는 잘못된 Route Table Association이에요.
- 보안 경계가 다른 워크로드는 별도 Route Table로 분리해야 하며, Shared Services VPC 패턴이 자주 사용됩니다.
- VPC 피어링 대비 운영 복잡도는 낮고, Direct Connect Gateway 대비 멀티 리전 확장이 훨씬 자유로워요.
1. Transit Gateway 라우팅의 기본 개념
Transit Gateway가 등장한 배경
AWS 환경이 VPC 3~5개 수준이면 VPC 피어링으로도 충분히 커버가 됩니다. 하지만 VPC가 10개, 20개로 늘어나면 피어링 메시(완전 그래프) 구성의 한계가 �렷해지더라고요. 피어링 하나당 라우팅 테이블을 양쪽 모두 수정해야 하고, N개 VPC라면 N(N-1)/2개의 피어링이 필요합니다. Transit Gateway는 이 허브 역할을 단일 리소스로 흡수해 주는 개념이에요.
Attachment라는 용어부터 정리
Transit Gateway에서 Attachment는 TGW에 붙는 모든 연결 단위를 의미해요. VPC Attachment, VPN Attachment, Direct Connect Gateway Attachment, Peering Attachment(다른 리전의 TGW와 연결) 등이 여기에 해당합니다. 이후에 설명할 Association과 Propagation은 이 Attachment 단위로 동작하거든요.
⚠️ Transit Gateway 기본 개념 주의
- Transit Gateway는 리전 단위 리소스예요. 다른 리전 VPC와 통신하려면 별도의 Peering Attachment가 필요합니다.
- 기본값으로 생성되는 Default Route Table은 모든 Attachment가 자동으로 Association + Propagation 되는 특성이 있어, 운영 환경에서는 커스텀 라우트 테이블 사용을 강력히 권장합니다.
2. Route Table 구조와 설계 전략
빛나는 중앙 허브에서 주변 노드들로 연결선이 방사되는 허브 앤 스포크 네트워크 구조
Default Route Table vs Custom Route Table
Transit Gateway를 만들면 자동으로 Default Route Table 한 개가 생기고, 모든 Attachment가 여기에 자동 Association + Propagation 됩니다. 작은 테스트 환경에서는 편하지만, 운영 환경에서는 거의 항상 문제의 원인이 되더라고요. 이유는 간단합니다. 네트워크 분리 경계가 무너지거든요.
실전 권장 구성: Custom Route Table을 용도별로 분리
- Production-RT: 운영 VPC들만 Association, 모든 VPC 경로 Propagation
- Development-RT: 개발 VPC들만 Association, 사내 공유 VPC Propagation
- Shared-Services-RT: 공통 서비스 VPC만 Association, 다른 VPC들은 선택적 Propagation
- DMZ-RT: 인터넷 egress VPC 전용, 인터넷 경로 blackhole 처리
Static Route vs Propagated Route
Transit Gateway Route Table에는 두 가지 라우트 형태가 들어갑니다. Propagated Route는 Attachment가 자동으로 광고하는 CIDR이고, Static Route는 관리자가 직접 추가하는 라우트예요. 운영 중 VPC CIDR이 바뀌면 Propagated Route가 자동으로 따라가지만, 블랙홀(의도적으로 트래픽을 버리는 경로)은 Static으로 등록하는 패턴이 자주 사용됩니다.
💡 Route Table 설계 꿀팁
- Route Table 이름을 “용도-Association대상-Propagation대상” 컨벤션으로 통일하면, 팀이 바뀌어도 운영자가 즉시 구조를 파악할 수 있어요.
- CIDR 중첩은 Transit Gateway에서 라우팅 충돌을 일으킵니다. 신규 VPC는 CIDR 충돌 검사를 IaC 단계에서 반드시 수행하세요.
3. Association과 Propagation 실무 구성
Association이란?
Association은 “이 Attachment가 어느 Route Table을 보는가”를 결정합니다. Attachment 하나당 단 하나의 Route Table에만 Association할 수 있어요. 쉽게 말하면 “VPC-A는 Production Route Table을 본다”처럼 VPC별 라우팅 정책을 연결하는 거예요.
Propagation이란?
Propagation은 “다른 Attachment의 CIDR이 자동으로 들어오는 경로”를 의미합니다. Propagation으로 등록된 Attachment는 해당 Route Table에 자동으로 라우트가 추가돼요. Attachment 하나가 여러 Route Table에 동시에 Propagation될 수 있다는 점이 Association과의 큰 차이거든요.
구성 절차 (콘솔 기준)
Step 1 — Transit Gateway 생성 시 옵션 설정
TGW 생성 화면에서 Default route table association과 Default route table propagation을 모두 Disable로 설정합니다. 운영에서는 거의 항상 이 옵션을 꺼야 안전해요.
Step 2 — Custom Route Table 생성
VPC Peering 페이지의 Transit Gateway Route Tables 메뉴에서 신규 RT를 만들고, 위에서 설계한 Production-RT, Development-RT를 각각 생성합니다.
Step 3 — Attachment 별 Association / Propagation 지정
기존 VPC Attachment를 선택 → Associations 탭에서 Route Table 지정 → Propagations 탭에서 광고할 CIDR이 있는 Attachment를 체크합니다.
4. VPC 간 통신 시나리오별 구성
시나리오 A — 단순 허브-스포크 (모든 VPC 통신)
단일 Shared-RT에 모든 VPC Attachment를 Association + Propagation 하면 모든 VPC가 서로 통신할 수 있어요. 다만 운영에서는 보안상 권장되지 않습니다.
운영 VPC들은 Production-RT만 보고, 중앙 AD/DNS/관제 VPC는 모든 Production VPC의 CIDR을 Propagation 받습니다. 반대로 운영 VPC는 중앙 서비스 VPC만 Propagation 하면 중앙 서비스로의 단방향 통신이 만들어져요. 이 패턴이 가장 안정적이라고 경험상 느꼈습니다.
시나리오 C — 멀티 계정 / 멀티 VPC
각 계정의 VPC Attachment를 RAM(Resource Access Manager)으로 공유된 TGW에 연결하고, Route Table은 Network 계정에서 중앙 관리합니다. 이 구조가 가장 많이 쓰이는 엔터프라이즈 패턴이에요.
5. 다른 연결 방식과의 구체적 비교
Transit Gateway vs VPC Peering vs Direct Connect Gateway
VPC 연결을 고민할 때 Transit Gateway만 보지 말고, 다른 옵션과 비교해서 선택하는 게 현명해요. 아래는 실제 엔터프라이즈 프로젝트에서 자주 비교되는 세 가지 방식의 특징을 정리한 표입니다.
| 항목 | Transit Gateway | VPC Peering | Direct Connect Gateway |
|---|---|---|---|
| 확장성 | 허브-스포크, 최대 5,000 Attachment | 완전그래프, N(N-1)/2 연결 필요 | DX 회선 + VGW 다중 연결 |
| 라우팅 제어 | 세분화된 RT, Association/Propagation | VPC RT 직접 수정, 단순 | BGP, on-prem 라우터 위주 |
| 멀티 리전 | Peering Attachment로 지원 | Cross-region Peering 지원 | Global DX Gateway로 지원 |
| 비용 | Attachment + 데이터 처리 과금 | 데이터 처리 과금만 | DX 회선 + 포트 비용 |
| 적합 환경 | 10+ VPC, 멀티 계정, 중앙 통제 | 소수 VPC, 단순 1:1 통신 | 온프레미스 연결이 1차 목적 |
표에서 보이듯 VPC Peering은 소규모에 단순하지만, VPC가 늘어나면 라우팅 테이블과 피어링 수가 폭발적으로 증가해요. 반면 Transit Gateway는 Attachment와 Route Table만 관리하면 되니 확장성 측면에서 압도적입니다. Direct Connect Gateway는 본사-온프레미스 연결이 절대적인 경우에 강점이 있고, Transit Gateway와 함께 쓰는 경우가 대부분이에요.
Transit Gateway만의 차별화된 통찰
단순 연결 수단으로 보면 “비싼 VPC 피어링”으로 보일 수 있지만, 실제로는 중앙 라우팅 정책 관리가 핵심 가치예요. Security Group Reference, Network Firewall 통합, IP Multicast 같은 부가 기능은 Transit Gateway에서만 지원됩니다. 대규모 멀티 계정 환경일수록 이 중앙 통제 기능의 가치가 비용을 정당화하더라고요.
6. 운영 중 흔한 실패 사례와 해결법
실패 사례 — “분리했는데 VPC끼리 통신이 됩니다”
한 프로젝트에서 Production과 Development VPC를 완전히 분리하려고 했는데, 분명 별도 Route Table을 만들었는데도 통신이 되더라고요. 원인은 의외로 단순했습니다. Default Route Table Association이 Enable 상태였던 거예요. TGW 생성 시 기본값으로 켜져 있던 옵션을 그대로 둔 결과, Production-RT를 새로 만들었지만 기존 Attachment가 여전히 Default RT와 묶여 있었던 것이죠.
전문가 해결 노하우
해결 절차는 다음 순서로 진행했어요.
- Transit Gateway 상세 → Modify transit gateway → Default route table association/propagation 모두 Disable
- 모든 Attachment를 순회하며 기존 Default RT Association 제거
- 각 Attachment를 용도에 맞는 Custom RT에 신규 Association
- Propagation 의도 재검증 후 Static Route는 그대로 두고 Propagation 항목만 정리
- Reachability Analyzer로 VPC 간 경로 재검증
핵심은 TGW 생성 시점에 Default RT 옵션을 미리 꺼두는 것이에요. 운영 중 변경하면 모든 Attachment를 다시 점검해야 하거든요. IaC(Terraform/CloudFormation)로 구성할 때는 tgw_options 항목에 default_route_table_association = “disable”, default_route_table_propagation = “disable”을 명시적으로 선언하는 게 베스트 프랙티스입니다.
⚠️ Transit Gateway 운영 주의
- Propagation 자동 반영은 몇 분 이상 걸릴 수 있어요. 변경 직후에는 Reachability Analyzer 결과가 일관되지 않을 수 있습니다.
- Route Table 변경 시 다른 Attachment의 라우팅 경로까지 영향을 미칠 수 있으니, 변경 전 영향받는 Attachment 목록을 먼저 정리하세요.
자주 묻는 질문
Q.Association과 Propagation을 동시에 설정해야 하나요?
A. Association은 필수, Propagation은 선택입니다. Association은 Attachment가 어느 RT를 “볼지” 결정하고, Propagation은 다른 Attachment의 CIDR이 자동으로 들어올지를 결정해요. 단, 다른 VPC와 통신하려면 Propagation이 결국 필요해요.
Q.VPC Peering을 Transit Gateway로 마이그레이션할 때 가장 많이 겪는 문제는?
A. CIDR 중첩이에요. 기존 피어링은 서로 다른 VPC CIDR만 허용했지만, Transit Gateway는 Attachment 단위로 라우트를 흡수하기 때문에 중첩 CIDR이 있으면 라우팅 충돌이 발생합니다. 마이그레이션 전에 VPC CIDR 인벤토리를 반드시 확보하세요.
Q.Default Route Table을 계속 써도 되나요?
A. 소규모 테스트나 학습 환경 외에는 권장하지 않아요. 모든 Attachment가 자동 Association + Propagation 되기 때문에 보안 경계가 사라집니다. 운영에서는 반드시 Custom Route Table로 분리하세요.
Q.멀티 리전 Transit Gateway 연결 시 비용은 어떻게 발생하나요?
A. 리전 간 Peering Attachment와 데이터 처리량에 따라 과금됩니다. 평소보다 약 1.5~2배 수준의 추가 비용이 발생할 수 있으니, 비용 영향 분석 후 설계하세요.
Q.VPC 내부의 라우팅 테이블도 수정해야 하나요?
A. 네, VPC Route Table에 Transit Gateway로 향하는 라우트를 추가해야 해요. 대상은 TGW Attachment ID이고, 목적지 CIDR은 다른 VPC의 CIDR입니다. 이것을 빠뜨려서 통신이 안 되는 경우가 의외로 많아요.
Transit Gateway 라우팅은 처음에 어렵게 느껴지지만, Association = 보는 라우트 테이블, Propagation = 받는 라우트라는 공식만 머릿속에 박아두면 절반은 해결됩니다. 나머지 절반은 위에서 정리한 운영 시 주의사항과 비교표를 곁에 두고, 실제 구성할 때 한 단계씩 점검하면서 진행해 보세요. VPC 피어링이 단순해 보여도 운영 환경에서는 Transit Gateway의 중앙 통제 기능이 시간을 아껴주는 경우가 더 많더라고요.
본 문서는 개인 학습 및 정보 공유를 목적으로 작성되었으며, AWS 공식 문서의 내용을 대체하지 않습니다. 서비스 요금, 기능, 제약 조건은 변경될 수 있으므로 실제 구성 시에는 AWS 공식 문서와 Well-Architected 가이드를 반드시 함께 확인하시기 바랍니다. 본 글의 내용을 참고하여 발생하셨던 구성 오류나 비용 영향에 대해 작성자는 책임을 지지 않습니다.
