Transit Gateway
Transit Gateway는 VPC Peering과 마찬가지로 서로 다른 VPC간에 통신이 가능하게 하는 서비스입니다.
VPC Peering은 1 대 1 VPC 연결만 지원하여 직접적으로 연결되어있지 않은 VPC에 바로 접근할 수 없었다면 Transit Gateway는 중앙 허브를 통해 여러 VPC간 연결 정책을 중앙에서 관리할 수 있고, VPN을 통해 VPC와 온프레미스 네트워크를 연결할 수 있습니다.
Transit Gateway 특징
- 중앙 허브와 VPN을 통해 VPC와 온프레미스 네트워크를 연결할 수 있습니다.
- 복잡한 피어링 관계를 제거하여 네트워크를 간소화 시킬 수 있습니다.
- 클라우드 라우터 역할을 하므로 새로운 연결을 한 번만 추가하면 됩니다.
- 다른 리전간의 Transit Gateway와 피어링 연결이 가능합니다.
Transit Gateway 사용 이유
VPC Peering을 사용해 같은 리전에 있는 VPC와 다른 리전에 있는 VPC를 연결하고 VPN을 통해 온프레미스 네트워크와 연결하기위해서는 다음과 같은 구조로 인프라를 구성해야 됩니다.
VPC Peering을 사용하는 경우에 더욱 더 큰 규모의 서비스일수록 인프라를 관리하기가 매우 까다로워 집니다. 온프레미스 네트워크와 연결하기 위해 VGW(Virtual Private Gateway)를 구성해야 하며 VPC를 한개만 추가하는 것만으로도 수많은 Peering Connection이 추가될 수도 있습니다.
Transit Gateway를 사용하면 중앙허브를 통해 위 인프라를 더욱더 관리하기 쉽고 확장성있는 구조로 변경할 수 있습니다.
VPC를 Transit Gateway에 연결해주기만하면 Transit Gateway에 연결된 모든 다른 VPC와 통신이 가능하게 됩니다.
또한 CGW(Customer Gateway)와 Transit Gateway를 연결하게 되면 Transit Gateway에 연결된 VPC는 VPN을 통해 온프레미스 네트워크와도 통신이 가능합니다.
따라서 연결해야하는 VPC 개수가 많으며, 온프레미스와의 VPN연결 까지 관리해야한다면 Transit Gateway를 사용하는 것이 관리적인 측면에서 훨씬 유리 합니다.
VPC Peering과의 차이점
비용
같은 조건을 기준으로 Transit Gateway를 사용하는 것이 VPC Peering을 사용하는 것보다 약 1.5배 정도 비쌉니다.
Transit Gateway 요금과 관련된 정보는 아래 사이트를 통해 확인하실 수 있습니다.
https://aws.amazon.com/ko/transit-gateway/pricing/
VPC 개수 제한
VPC Peering의 경우 VPC당 125개까지 연결이 가능하고, Transit Gateway는 Transit Gateway당 5000개의 VPC를 연결할 수 있습니다.
대역폭
VPC Peering의 경우 대역폭에 제한이 없지만 Transit Gateway는 최대 대역폭이 50Gbps로 제한이 있습니다.
그렇기 때문에 Transit Gateway를 사용하여 서비스를 구축할 때 서비스에 대한 대역폭 제한을 고려해야합니다.
대역폭은 초당 처리할 수 있는 데이터의 양을 의미합니다.
Transit Gateway 사용법
구현해야할 아키텍처는 다음과 같습니다. 같은 리전에 있는 3개의 VPC를 Transit Gateway를 통해 통신이 가능하도록 구현해야합니다.
우선 AWS 콘솔에 접속한 후 같은 리전에 3개의 VPC를 만들어줍니다. (VPC 생성 과정은 생략하도록 하겠습니다.)
그 다음 VPC 콘솔화면에서 왼쪽에 있는 메뉴중 Transit Gateways를 선택한 후 Create transit gateway 버튼을 눌러 Transit Gateway를 생성해 주도록 합니다.
그 다음 이름을 지정해주고 다음과 같이 옵션을 선택해줍니다.
여기서 잠깐 몇 가지 중요한 옵션들에 대해 간략히 설명하고 넘어가도록 하겠습니다.
- ASN(Autonomous System Number, 자율 시스템 번호)
- AS(Autonomous System)는 일관된 라우팅 정책을 가지고 있는 라우터의 집단입니다.
- AS간에 연결하는데 있어서 유일한 통신규약이 BGP(Border Gateway Protocol, TCP 179)인데 이 BGP를 사용하기 위해서는 ASN을 지정해줘야 합니다. 쉽게 말해 각각의 시스템을 식별하기 위한 식별 번호라고 생각하시면 됩니다.
- 지정 가능한 ASN의 범위는 64512~65534 혹은 4200000000~4294967294 입니다.
- 지정하지 않을 경우 default ASN(64512)이 부여됩니다.
- DNS support(DNS 지원)
- 해당 옵션을 활성화하면 인스턴스의 Public IPv4 DNS가 가르키는 IP를 Public IP에서 Private IP로 전환합니다.
- 인터넷을 통해 외부로 통신하는 것이 아닌 내부로 통신하기 때문에 보안성을 향상시킬 수 있습니다.
- 해당 옵션을 사용하기 위해서는 VPC 옵션에서 DNS hostnames 옵션을 활성화 해야합니다.
- VPN ECMP support(VPN ECMP 지원)
- 해당 옵션을 활성화하면 VPN 터널 간에 ECMP(Equal Cost Multipath, 동일 비용 다중 경로) 라우팅을 지원합니다.
- 예를 들어 동일한 CIDR를 가진 2개의 VPN 터널을 통해 트래픽을 전송하려 하는 경우 트래픽을 1:1로 균등하게 분산하여 전송합니다.
- Default route table association(기본 라우팅 테이블 연결)
- 해당 옵션을 활성화하면 Transit Gateway 라우팅을 위한 기본 라우팅 테이블이 생성됩니다.
- VPC를 Transit Gateway와 연결하면 VPC의 라우팅 테이블이 자동으로 Transit Gateway의 기본 라우팅 테이블에 연결됩니다.
- Default route table propagation(기본 라우팅 테이블 전파)
- 해당 옵션을 활성화하면 VPN 연결과 함께 동적 라우팅을 사용하는 경우 VPN 연결과 연결된 라우팅 테이블의 경로가 BGP를 통해 CGW(Customer Gateway)에 전달됩니다.
- Auto accept shared attachments(공유 첨부 파일 자동 수락)
- AWS Resource Access Manager를 사용해 Transit Gateway를 다른 계정과 공유할 수 있습니다.
- 다른 계정과 Transit Gateway를 공유하기 위해 공유를 요청한 경우 해당 옵션을 활성화하면 별도의 수락을 하지 않아도 자동으로 수락됩니다.
- Transit Gateway CIDR Block(선택 사항)
- 지정한 CIDR의 범위에 해당되는 VPC만 Transit Gateway와 연결할 수 있습니다.
- 169.254.0.0/16 과 온프레미스 네트워크와 겹치는 CIDR는 지정할 수 없습니다.
모든 설정을 마쳤다면 하단에 Create transit gateway 버튼을 눌러 Transit Gateway를 생성해 줍니다.
잘 생성된 것을 보실 수 있습니다.
그 다음 왼쪽 메뉴에 Transit Gateway Attachments를 선택한 후 Create transit gateway attachment 버튼을 눌러 VPC를 Transit Gateway에 추가해줍니다.
그 다음 이름과 Transit Gateway, 연결 타입을 지정해 줍니다. 그리고 DNS support 옵션을 활성화 해주신후 추가할 VPC를 지정해 줍니다.
모든 설정을 마쳤다면 하단에 Create transit gateway attachment 버튼을 눌러 VPC를 추가해 줍니다.
위와 똑같은 과정으로 나머지 두 개의 VPC 모두 추가해 줍니다.
그 다음 VPC의 라우팅 테이블로 가서 Transit Gateway를 추가해 줘야 합니다.
왼쪽에서 Route Tables 메뉴를 선택한 후 편집할 라우팅 테이블을 선택해줍니다.
Routes 메뉴를 선택한 후 Edit routes 버튼을 눌러 라우팅 테이블을 편집합니다.
필자의 경우 3개의 VPC 모두 CIDR가 10.x.0.0/16 으로 시작하기 때문에 Destination을 10.0.0.0/8 로 지정해 주었습니다.
Destination과 Target 모두 지정해주었다면 아래에 Save changes 버튼을 눌러 변경 사항을 저장해줍니다.
나머지 두 개의 라우팅 테이블도 위와 같은 과정으로 편집해줍니다.
모든 라우팅 테이블 편집을 마쳤다면 이제 서로 다른 VPC가 Transit Gateway를 사용해 통하여 통신할 준비가 완료된 것입니다.
이제 간단하게 테스트를 해보도록 합시다.
필자는 테스트를 위해 각 VPC 별로 인스턴스를 하나씩 생성해 주었습니다. (인스턴스 생성 과정은 생략하도록 하겠습니다.)
VPC A 에서 VPC B로, VPC C에서 VPC A로 ssh 접속을 시도해본 결과, 성공적으로 접속이 되는 것을 보실 수 있습니다.
또한 위에서 Transit Gateway를 생성할 때 DNS suppport 옵션을 활성화 해주었기에 인스턴스의 DNS가 Private IP를 가르키는 것을 보실 수 있습니다.
이말은 즉슨 인터넷을 통해 외부로 통신하는 것이 아닌 Private IP를 통해 내부적으로 통신하는 것을 의미합니다.
참고 : https://yoo11052.tistory.com/170
- https://docs.aws.amazon.com/ko_kr/vpc/latest/tgw/what-is-transit-gateway.html
- https://kim-dragon.tistory.com/178
- https://docs.aws.amazon.com/ko_kr/vpc/latest/tgw/how-transit-gateways-work.html
- https://2infinity-and-beyond.tistory.com/7
- https://aws.amazon.com/ko/premiumsupport/knowledge-center/transit-gateway-ecmp-multiple-tunnels/
'[AWS-RDP] > TransitGateway' 카테고리의 다른 글
[중요4][AWS] Transit Gateway에 대해 알아보자!! (23) | 2024.05.30 |
---|---|
[중요4][AWS] Transit Gateway를 다른 AWS계정과 공유하여 사용 해보자! (40) | 2024.05.30 |
[중요3][AWS] Transit Gateway 통한 계정간 VPC 연결 (36) | 2024.05.30 |
[참고][AWS] Transit Gateway? (1) - 개념 및 비용비교 (1) | 2023.05.01 |
[중요][AWS] Transit Gateway? (2) - 생성 (0) | 2023.05.01 |
댓글