Transit Gateway로 여러 개의 VPC를 연결하기

여러 VPC를 운영하다 보면 서비스별, 환경별, 계정별로 네트워크가 자연스럽게 분리됩니다. 처음에는 VPC Peering만으로도 충분해 보이지만, 연결해야 할 VPC 수가 늘어날수록 구성은 빠르게 복잡해집니다. Peering 관계를 일일이 관리해야 하고, 라우팅까지 함께 늘어나면서 운영 부담도 커집니다. 이 시점에서 고려하게 되는 대표적인 Hub-and-Spoke 방식의 네트워크 서비스가 바로 AWS Transit Gateway 입니다.

 

Transit Gateway는 여러 VPC와 온프레미스 네트워크를 중앙에서 연결하기 위한 AWS의 네트워크 트랜짓 허브입니다. VPC 간 연결을 개별적으로 구성하는 대신 Transit Gateway를 중심으로 네트워크를 구축함으로써 연결 구조와 라우팅 관리를 단순화할 수 있습니다. 특히 VPC 수가 증가하는 환경에서는 pcx 기반 구성보다 확장성과 운영 효율적인 측면에서 유리합니다. 자세한 내용은 AWS Transit Gateway 공식 문서에서 확인할 수 있습니다. 이번 글에서는 Transit Gateway의 역할을 간단히 정리한 뒤, 여러 개의 VPC를 하나의 Transit Gateway에 연결하는 데모를 통해 Attachment 구성, 라우팅 설정, 그리고 Connection 확인 과정까지 순차적으로 알아보도록 하겠습니다.

 

먼저, 2개의 VPC를 생성해줍니다. 모든 VPC는 CIDR 중복이 발생해서는 안됩니다. 

필자는 아래와 같이 Workload VPC와 DB VPC를 생성하였습니다.

 

이후, Transit Gateway 탭으로 들어가 TGW를 새로 생성합니다.

 

저는 이름 태그를 my-precious-tgw로 지정하고, 설명을 작성했습니다.

이후, TGW를 위한 다양한 옵션 값을 지정해줘야 합니다. 각 옵션들에 대한 상세한 설명은 아래 남겨두었습니다.

- Amazon 측 ASN

tgw의 bgp 세션에서 AWS 측이 사용할 사설 ASN입니다. 주로 Site-to-Site VPN이나 Direct Connect 연동처럼 BGP를 쓰는 환경에서 의미가 있습니다. AWS 문서 기준으로 16bit 사설 ASN은 64512–65534, 32bit 사설 ASN은 4200000000–4294967294 범위를 사용합니다. On-Prem router와 ASN 충돌이 나지 않도록 주의해야 합니다.

필자는 편하게 65001로 지정하였습니다.

 

- DNS 지원

쉽게 설명하면 Cross-VPC 통신에서 DNS 질의가 정상적으로 진행되도록 하기 위한 설정입니다. 다만 중요한 점은, TGW가 붙어 있다고 해서 Route 53 Private Hosted Zone의 커스텀 DNS 이름 해석이 자동으로 모든 VPC에서 되는 것은 아닙니다. 

 

- 보안 그룹 참조 지원

tgw에 연결된 서로 다른 VPC 간에도 Security Group을 참조할 수 있게 하는 옵션입니다. 예를 들어 A VPC의 EC2 보안 그룹 규칙에서 B VPC의 보안 그룹을 source로 참조하는 식의 운영이 가능해져서, ip cidr 대신 sg chaining 기반으로 더 깔끔하게 정책을 관리할 수 있습니다. 이 옵션은 기본적으로 비활성화되어 있으나, Cross VPC sg referencing이 필요하다면 활성화하는 것을 권장합니다. 필자의 경우 DB VPC의 RDS Cluster가 Workload VPC의 ec2를 sg source로 사용하기 위해 활성화하였습니다.

 

- VPN ECMP 지원

tgw에 연결된 VPN에서 동일 비용 경로를 여러 개 사용해 트래픽을 분산할 수 있게 해줍니다. 주로 VPN 대역폭 활용이나 다중 터널 경로 사용 측면에서 중요합니다. 온프레미스 장비 쪽도 ECMP/BGP 정책이 맞아야 효과가 있습니다.

필자의 경우 VPN을 사용하지 않기에 비활성화 하였습니다.

 

- 기본 라우팅 테이블 연결

새로 생성되는 attachment(vpc attachment, vpn attachment 등)를 기본 tgw 라우팅 테이블에 자동으로 association할지 정하는 옵션입니다. 켜두면 새 attachment가 default rtb에 자동 연결됩니다. 끄면 attachment마다 수동으로 어떤 tgw rtb에 연결할지 정해야 합니다.

필자의 경우 서브넷이 각각의 rtb를 사용하고 있으므로 비활성화 하였습니다.

 

- 기본 라우팅 테이블 전파

새 attachment의 라우트가 기본 tgw 라우팅 테이블로 자동 propagate 할지 정하는 옵션입니다. 예를 들어 어떤 vpc를 tgw에 붙였을 때 그 vpc cidr이 자동으로 tgw route table에 전파되도록 할 수 있습니다. 끄면 필요한 route propagation을 수동으로 활성화해야 합니다.

필자의 경우 서브넷이 각각의 rtb를 사용하고 있으므로 비활성화 하였습니다.

 

- 멀티캐스트 지원

TGW를 멀티캐스트 트래픽 라우터처럼 사용할 수 있게 하는 옵션입니다. 이걸 켜면 이후 Transit Gateway multicast domain을 만들어 멀티캐스트 송신자와 수신자 그룹을 연결할 수 있습니다. 일반적인 웹 서비스 VPC 연결에서는 거의 안 쓰고, 특정 미디어/시장데이터/실시간 분산 시스템 같은 특수 워크로드에서 주로 사용합니다.

 

- 공유 첨부 파일 자동 수락

AWS RAM 등으로 다른 계정과 공유된 TGW에 대해, 다른 계정이 attachment 요청을 보냈을 때 자동으로 수락할지 정하는 옵션입니다. 멀티계정 환경에서 운영을 단순화할 수 있지만, 통제 관점에서는 수동 승인으로 두는 편이 더 안전할 수 있습니다.

필자의 경우 단일 계정 환경의 데모이므로 비활성화 하였습니다.

 

마지막으로, TGW의 CIDR을 지정할 수 있습니다.

이 옵션은 VPC처럼 리소스를 배치하는 네트워크 대역이 아니라, TGW가 Connect(GRE)나 Private IP VPN 같은 기능에서 자기 쪽 터널 주소로 사용할 전용 주소 풀입니다. 그래서 일반적인 VPC 간 연결만 구성할 때는 대부분 필요하지 않고, 이 값을 넣는다고 라우팅이 자동으로 열리거나 통신이 바로 되는 것도 아닙니다. 즉, "TGW의 고급 연결 기능용 주소 대역" 정도로 이해하면 됩니다.

 

TGW 생성이 완료되었습니다.

 

이제, TGW Attach를 진행하겠습니다.

Cross-VPC 연결이므로 연결 유형을 VPC로 설정하고, 아래와 같이 연결할 Subnet을 설정합니다.

 

DB VPC의 Association도 똑같이 설정해줍니다.

 

이제, Routing Table을 설정하겠습니다. Transit Gateway 라우팅 테이블로 들어가 생성을 누릅니다.

 

이후, 아래와 같이 TGW 연결이 필요한 Subnet의 RTB에 tgw 연결을 맺어줍니다.

 

그리고 DB VPC에 EC2를 파고, Workload VPC에 VPC Associated Cloudshell을 파준 후 핑을 쳐보면.

 

TGW 연결 성공!