[aws] Transit Gateway란?

안녕하세요 :)

A VPC - B VPC를 연결할 때 어떻게 하시나요?
VPC Peering 방법이 있지만, C VPC, D VPC, E VPC 등 더 많은 VPC를 상호 연결하려 할 때 과연 VPC Peering이 최선일까요?

오늘은 이에 대한 해답인, Transit Gateways에 대해 알아보고 2개의 VPC가 서로 통신할 수 있도록 구성해보겠습니다.

---

Transit Gateway

Transit Gateway는 가상 사설 클라우드(VPC)와 온프레미스 네트워크를 상호 연결하는 데 사용할 수 있는 네트워크 전송 허브

🔊 Transit Gateway의 구성 요소

• Attachment
  Amazon VPC, VPN 연결과 TGW간의 연결을 의미
  리전 내 모든 가용영역(서브넷)을 지정하여 가용성과 성능을 확보하는 것을 권장
• Association
  TGW는 별도의 라우트 테이블을 운영(VPC 라우트 테이블과 별개)
  각각의 Attachment는 반드시 하나의 TGW 라우트 테이블에 Association(연결)되어야 함
  하나의 TGW 라우트 테이블은 하나 또는 다수의 Attachment를 가질 수 있음
• Propagation
  Route Table을 전파 온프레미스는 BGP 및 Static Routing, VPC의 CIDR은 API를 통해 동적으로 전파함

---

VPC 생성

상호 연결할 VPC를 생성합니다. qa, prd는 2개의 CIDR을 갖습니다.
mgmt vpc와 qa vpc가 통신할 수 있도록 설정하겠습니다.

Transit gateways 생성

AWS Console > VPC > Transit Gateways로 들어갑니다.
Create transit gateway를 클릭해 transit gateway를 생성합니다.

transit gateway의 이름을 입력하고, 나머지 옵션은 default로 설정하여 생성 합니다.

# 옵션 설명
- Amazon side ASN : Direct Connect Gateway, VPN과 BGP 연동 시 필요한 Amazon Side의 ASN (Private ASN)
- DNS support : transit gateway의 DNS 호스트 이름을 프라이빗 ip주소로 확인할 것인지에 대한 선택
- VPN EMCP support : 단일 대상에 대한 다수의 VPN 연결이 있는 경우(터널이 여러개일 경우), ECMP를 사용할지에 대한 구성, 현재 1.25GB의 대역폭 Limit을 가지는데 이것을 ECMP로 묶어 더 높은 대역폭을 가지도록 할 수 있음
- Default route table association : TGW는 기본적으로 default route table을 가지는데, TGW에 Attach되는 VPC 또는 VPN을 Default Route Table에 포함 시킬 것인지에 대한 선택
- Default route table propagation : Association 된 대상(VPC, VPN, DX)를 자동으로 Default Route Table에 적용

+ Default route table association, propagation을 비활성화 하고 TGW를 생성할 경우, default route table은 생기지 않습니다.
+ 1개의 Attachment는 1개의 route table과 매핑됩니다. 1개의 Attachment는 여러개의 route table을 가질 수 없습니다.
+ 1개의 transit gateway는 여러 개의 route table을 가질 수 있습니다.
+ propagations를 활성화 하면 routes에 propagations에 지정한 VPC의 CIDR이 자동으로 등록됩니다.

생성한 transit gateway를 확인하고 State가 Available이 되는 것을 확인합니다.

 

transit gateway attachment 생성

• Attachment
  Amazon VPC, VPN 연결과 TGW간의 연결을 의미합니다.
  리전 내 모든 가용영역(서브넷)을 지정하여 가용성과 성능을 확보하는 것을 권장합니다.

attachment의 이름을 입력하고, 연결할 VPC를 선택합니다.
가용성을 위해 모든 가용영역을 체크하고 서브넷을 선택합니다.
해당 가용영역의 ENI로 transit gateway와 연결이 되는 구조이기 때문에, ENI가 생성될 서브넷을 선택해줍니다.

위의 과정을 반복하여, qa-vpc와 prd-vpc attachment도 생성해줍니다.
아래와 같이 연결할 vpc 3개의 목록이 생성된다면 완료된 것입니다.

추가로, transit gateway attachment를 생성할 때 선택한 서브넷에 transit gateway 연결을 위한 ENI가 생성된 것을 확인하실 수 있습니다.

transit gateway  route tables 설정

attachment를 생성하면 동시에 "default" transit gateway route table에 연결됩니다.
하나의 transit gateway는 하나의 route table을 꼭 가집니다.
또한 1개의 attachment는 1개의 transit gateway route table과 매핑 됩니다.

route tables > Associations에 보면 route table에 연결되어 있는 attachment 목록이 보입니다.

Routes에 VPC의 보조 CIDR을 포함한 모든 CIDR가 등록되어 있는 것을 확인할 수 있습니다.

 

VPC route tables 설정

TGW route table과 VPC route table은 다릅니다.
쉽게 말해 TGW는 VPC 간의 라우팅을 담당했다면, VPC route table은 VPC로 들어온 트래픽이 내부의 라우팅을 담당합니다.

qa VPC route table을 수정해서, mgmt VPC -> qa VPC로 요청이 왔을 때 TGW로 보내도록 설정합니다.

mgmt VPC route table도 수정해서, ping이 들어올 수 있도록 qa VPC CIDR 대역을 설정합니다.

mgmt VPC 내부 리소스가 qa VPC의 내부 리소스로 패킷을 전송한다면, qa VPC 라우팅 테이블 설정에 따라, trangit gateway로 전달합니다. 이렇게 trangit gateway에서 연결되어 있는 qa VPC Attachment를 확인하고 해당 ENI로 패킷을 전달합니다. 이렇게 되면, mgmt VPC -> qa VPC로 패킷을 전달할 수 있는 상태가 되는 것이죠!

마지막으로 qa EC2에서 mgmt EC2로 ping을 날려 서로 통신이 되는지 확인하겠습니다.

성공 ✨

2개의 VPC에 대한 통신 테스트만 하였지만, Multi-VPC 환경을 구축하기 위해서는 TGW가 필수라고 생각합니다:)

---

참고) https://www.youtube.com/watch?v=vEFh0BQ3iOk