Terraform으로 AWS Transit Gateway 구성하기 — VPC Peering 한계를 넘어 멀티 계정 네트워크 허브 만들기

중앙 허브가 여러 VPC와 글로브를 연결하는 평면적 네트워크 인프라 구성도

VPC 두세 개 정도면 VPC Peering으로도 충분합니다. 그런데 VPC가 다섯 개, 계정은 세 개, 그리고 Direct Connect까지 붙는 순간 이야기가 달라지거든요. 처음엔 “그냥 Peering 연결만 더하면 되지”라고 생각했는데, 실제로는 라우트 테이블이 폭발하고 전파 설정이 꼬여서 야간에 장애 대응을 한 적이 더러 있었습니다. Transit Gateway는 이런 N:N의 한계를 단일 허브로 우회하기 위해 등장했고, Terraform과 함께 쓰면 반복 작업을 코드로 자동화할 수 있어서 대규모 멀티 계정 환경에서 사실상 표준처럼 자리 잡았습니다.

이 글에서는 Transit Gateway의 구조를 짚고, Terraform으로 흔히 짜게 되는 실전 모듈, 그리고 다른 대안들과의 차이점을 표로 비교합니다. 마지막에는 제가 실제로 겪었던 실패 사례와 그 해결 노하우를 풀어놓았으니, 끝까지 읽으시면 설계 단계에서 시간을 한두 시간은 아끼실 수 있을 거예요.

Transit Gateway 핵심 개념과 작동 원리

Transit Gateway가 풀어내는 네트워크 병목

Transit Gateway는 리전 단위의 가상 라우터입니다. VPC Peering이 일대일로 연결되는 1:1 관계라면, Transit Gateway는 다수의 VPC, VPN, Direct Connect 게이트웨이를 하나의 허브에 꽂고 라우트 테이블로 흐름을 제어합니다. 별도의 관리형 장비 없이 AWS 백본에서 라우팅을 처리하기 때문에, 운영자가 CIDR 충돌과 라우트 비대화에 시달릴 일이 확 줄어요.

세 가지 핵심 객체

먼저 Transit Gateway 자체(TGW)는 리전 안의 허브 인스턴스입니다. 다음으로 Transit Gateway Attachment는 VPC·VPN·Peering 등을 TGW에 붙이는 연결 단위예요. 마지막으로 Transit Gateway Route Table이 트래픽 경로를 결정하는데, 여기서 “Association(연결)”과 “Propagation(전파)”이 무엇을 의미하는지 정확히 이해하는 게 전체 설계의 출발점이더라고요. Association은 어떤 attachment가 이 라우트 테이블을 참조할지 지정하는 것이고, Propagation은 특정 attachment의 CIDR을 라우트 테이블에 자동으로 학습시키는 기능입니다.

라우트 테이블 분리가 곧 운영 전략

초기 설계자 대부분은 기본 라우트 테이블 하나에 모든 attachment를 몰아넣습니다. VPC가 늘어날수록 이 라우트 테이블이 거대해지고, 나중에 “개발계 VPC가 운영계 DB에 접근 못하게 막고 싶다”는 요구가 들어오면 결국 처음부터 분리 작업을 해야 하거든요. 권장 패턴은 용도별/티어별 라우트 테이블을 분리하고, `blackhole` 라우트와 명시적 차단 규칙을 함께 두는 것입니다. 처음부터 분리해 두면, 나중에 보안 정책이 바뀌어도 attachment의 Association만 옮기면 끝납니다.

VPC Peering vs Transit Gateway vs Cloud WAN 비교

같은 문제를 푸는 방식이 여러 가지이니, 자기 환경에 맞는 선택지가 뭔지 표로 먼저 정리합니다. 그래야 나중에 “왜 TGW냐”는 질문에 흔들리지 않거든요.

네 가지 옵션의 차이 한눈에 보기

어떤 상황에서 Peering을 유지할까

VPC가 둘뿐이고, 데이터 전송 비용이 민감한 환경 — 예를 들어 같은 계정 안의 Frontend-Backend 조합 — 에서는 여전히 VPC Peering이 가장 가성비가 좋습니다. 데이터 처리 요금이 0원이라는 점이 TGW 대비 압도적으로 유리하거든요. 반면 VPC가 네 개 이상, 혹은 계정이 둘 이상, Direct Connect가 등장하는 순간 TGW로 가는 게 정신건강에 이롭습니다. Cloud WAN은 정책 기반 글로벌 망을 원할 때, 3rd Party SD-WAN은 트랜짓 암호화나 멀티클라우드 같은 특수 요구가 있을 때 선택지로 떠오릅니다.

Terraform으로 Transit Gateway 구성하는 실전 코드

네트워크 전용 계정에 TGW 모듈 만들기

대부분의 기업은 Network 계정을 따로 두고, 다른 워크로드 계정들이 RAM으로 TGW를 공유받는 구조를 채택합니다. Terraform으로 이 흐름을 짤 때, 가장 먼저 만들어야 할 자원은 `aws_ec2_transit_gateway` 자체예요. 다음 코드는 멀티 캐스트 지원, 기본 라우트 테이블 비활성화, DNS 지원 옵션을 함께 켜는 패턴입니다.

기본 라우트 테이블을 비활성화(`default_route_table_association = false`, `default_route_table_propagation = false`)하는 이유는, 모든 attachment가 자동으로 기본 테이블에 붙으면 의도치 않은 통신이 발생할 수 있기 때문입니다. 처음부터 분리된 라우트 테이블 정책을 강제하는 게 대규모 운영의 핵심이더라고요.

VPC Attachment와 라우트 테이블 연결

TGW가 만들어졌다면, 각 VPC마다 `aws_ec2_transit_gateway_vpc_attachment`를 생성합니다. 여기서 `transit_gateway_default_route_table_association = false`를 명시적으로 두고, 별도로 만든 `aws_ec2_transit_gateway_route_table`에 `transit_gateway_route_table_association` 자원으로 연결합니다. 전파(propagation)도 마찬가지로 `aws_ec2_transit_gateway_route_table_propagation` 자원을 통해 명시적으로 켜고 끄는 게 안전해요.

⚠️ 실무에서 자주 보는 실수: `vpc_attachment` 안에서 `route_table_id`를 지정하지 않고 별도 association 자원으로 빼는 패턴을 무시하면, 기본 라우트 테이블에 자동 연결되어 보안 정책이 무너지기 쉽습니다.

공유 라우트와 정적 라우트 추가

VPC 외부의 SaaS 구간이나 on-prem 대역을 TGW로 끌어와야 한다면, `aws_ec2_transit_gateway_route` 자원으로 정적 라우트(static route)를 추가합니다. 다음은 `10.50.0.0/16` 대역을 on-prem VPN attachment로 보내는 예시예요. propagation으로 자동 학습되지 않는 비-VPC 대역은 거의 모두 정적 라우트로 다뤄야 하거든요.

멀티 계정·멀티 리전 라우팅과 RAM 공유

RAM으로 TGW를 다른 계정에 공유하기

Network 계정의 TGW를 다른 워크로드 계정에서 사용하려면, `aws_ram_resource_share`와 `aws_ram_resource_share_association`을 통해 공유합니다. Terraform은 `data “aws_caller_identity”`와 `data “aws_organizations_organization”`을 함께 활용하면, Organizations 단위로 한 번에 권한을 부여할 수 있어요. 공유받은 계정 쪽에서는 `aws_ec2_transit_gateway_vpc_attachment`를 자기 VPC에 대해 생성하면 끝입니다. TGW 자체는 Network 계정에 있고, attachment만 로컬에서 만드는 구조라 권한 경계가 깔끔하게 분리됩니다.

리전 간 Transit Gateway Peering

글로벌 서비스라면 서울과 버지니아 TGW를 연결해야 합니다. 이때 쓰는 자원이 `aws_ec2_transit_gateway_peering_attachment`예요. 다만 리전 간 peering에는 데이터 전송 요금이 발생하므로, 가능하면 동일 리전 안에서 멀티 VPC로 흡수하는 게 비용상 유리합니다. 어쩔 수 없이 멀티 리전이어야 한다면, Cloud WAN을 검토해 보는 게 더 단순한 결과로 이어지는 경우가 많습니다.

흔한 실패 사례와 해결 노하우

실패 사례: 검은색홀 라우팅으로 야간 장애

제가 실제로 겪었던 사고입니다. 새로 합류한 동료가 prod-db VPC attachment를 일반 라우트 테이블에서는 떼어내고, 보안팀이 따로 만든 restricted-db-rt에만 association 했어요. 그런데 다른 워크로드 계정의 VPC attachment가 prod-db 라우트 테이블에 전파되어 있던 거죠. 새벽 한 시쯤, 결제 시스템이 갑자기 DB에 연결 못 한다는 알림이 울렸습니다. 원인은 명확했습니다. 라우트 테이블에 특정 CIDR이 blackhole으로 들어간 상태에서 attachment가 어떤 propagation 그룹에도 속하지 않게 되었고, 결국 패킷이 그대로 사라졌어요.

해결 노하우: 세 가지 안전장치

첫째, 태그 기반 모듈화로 attachment가 어떤 클래스(`prod`, `dev`, `shared`)에 속하는지 강제합니다. Terraform 변수에 허용된 클래스만 받도록 validation 규칙을 두면 오타로 새 클래스가 생기는 걸 막을 수 있어요. 둘째, association과 propagation을 명시적 리소스로 분리합니다. attachment 안에 숨기면 자동 전파가 켜져 있는 줄 모르고 두 정책을 동시에 만족시키는 경우가 생깁니다. 셋째, CI 단계에서 `terraform plan`을 자동 검토하도록 만듭니다. PR마다 영향받는 attachment 리스트를 댓글로 던져주면, 리뷰어가 빠르게 인지할 수 있습니다.

비용 최적화와 운영 시 체크리스트

시간당 고정 요금과 데이터 처리 요금의 분리

TGW 비용은 크게 두 축으로 나뉩니다. TGW 자체의 시간당 요금과 attachment가 처리한 GB당 데이터 요금입니다. 단순한 dev 환경이라면 TGW를 항상 켜둘 이유가 없기 때문에, 야간·주말에는 attachment를 분리해서 비용을 아끼는 운영 패턴을 쓰기도 합니다. 다만 안정성보다 비용이 우선인 환경에 한정해야 하고, 운영 단계에서는 단일 attachment로 통일하는 게 일반적이거든요.

운영 시 반드시 체크할 항목들

• 라우트 테이블별 association / propagation 매트릭스를 주기적으로 점검하는가
• CIDR 인벤토리를 계정·리전별로 중앙 관리하고 있는가
• Flow Logs를 TGW 레벨에서 켜고, 외부로 나가는 트래픽 패턴을 모니터링하는가
• RAM 공유 변경 시 Terraform으로 자동 반영되도록 CI/CD 파이프라인이 연결되어 있는가

자주 묻는 질문

Transit Gateway는 단순한 “VPC Peering 대체품”이 아닙니다. 멀티 계정·멀티 리전 확장을 전제로 한 네트워크 백본이고, Terraform으로 그 백본을 선언적으로 관리할 때 비로소 운영 부담이 크게 줄어듭니다. 처음부터 라우트 테이블을 분리하고, CIDR 인벤토리를 통제하고, 자동 검토 파이프라인을 두는 게 안정적인 멀티 계정 망의 출발점이거든요. 작은 VPC 두 개로 파일럿을 돌려본 뒤, 그 노하우를 팀 표준 모듈로 자리 잡히게 만들어 보세요. 한 번 패턴이 자리 잡히면, 새 계정과 새 VPC가 추가되어도 클릭 한두 번이 아니라 PR 하나로 끝나는 경험을 하실 수 있을 거예요.

면책조항

본 글은 개인 경험과 AWS 공식 문서를 바탕으로 작성된 참고용 콘텐츠입니다. 실제 환경에 적용하시기 전에 반드시 AWS 공식 문서 및 최신 요금 정책을 확인하시고, 조직의 보안·컴플라이언스 정책에 부합하는지 검토하신 후 적용하시기 바랍니다. 본 글의 내용을 따른 결과에 대해 작성자는 어떠한 책임도 지지 않습니다.