안녕하세요!!
오늘은 AWS Transit Gateway라는 녀석에 대해서 좀 알아보려고 합니다.
많은 AWS 엔지니어분들께서 말씀 하시길 'AWS의 네트워크는 Transit Gateway가 있기 전과 후로 나뉜다' 라고들 하시는데요.
그만큼 기존 VPC Peering이나 VPN 연결의 제약사항을 개선한 혁신적인 기술이자 관리 편의성마저 가져다 준
효자 서비스라고 할 수 있겠죠!!
그럼 이 Transit Gateway가 뭔지, 기존의 단일 Peering or Site to Site VPN과 무엇이 다른지 천천히 알아보도록 하겠습니다.
Transit Gateway 라는 녀석을 한마디로 정의한다면 클라우드의 Router 입니다.
라우터다보니 패킷의 대상 IP 주소를 가지고 Next hop으로 전달 해줍니다.
대상 IP 주소를 기반으로 Next hop으로 전달을 해주는 라우터다 보니, 일반 Peering과 Site to Site VPN의 연결에서는
제한적인 전이적 피어링과 엣지간 라우팅을 가능하게 해줍니다.
위의 제한적인 상황을 간단하게 예시를 들어볼까요??
A, B, C 각각 3개의 AWS VPC가 존재하고, On-Premise가 존재한다고 가정하겠습니다.
그림으로 나타내면 아래와 같겠습니다.
여기서, A VPC와 B VPC간의 통신요건이 발생했고, B VPC와 On-Premise간의 통신 요건이 발생했다고 가정하겠습니다.
지금은 리소스가 총 4개밖에 안되기에 굉장히 간단하지요.
A VPC - B VPC Peering // B VPC - On_Premise Site to Site VPN 으로 해결이 됩니다.
위와 같은 그림에서, On-Premise와 A VPC는 통신하지 못합니다.
이를 엣지간 라우팅 제한이라고 AWS Docs는 안내하며, 이를 해결하기 위해서는 TGW를 사용하라고 제안합니다.
On-Premise든 A VPC든 패킷을 B VPC로 던질 뿐, 이 패킷을 받고 IP 헤더를 열어서 대상 IP를 보고 전달 해줄 수 있는 라우터가 없는거지요.
이 라우터의 역할을 해주는 것이 TGW 라는 녀석입니다.
TGW를 써야하는 이유를 한가지 더 알아볼까요?
클라우드의 특성과 장점을 살려서 고객 리소스가 확장되고, 이에 따라 A VPC와 On-Premise와의 통신 요건이 또 발생 했다고 가정하겠습니다. 그러면, A VPC와 On-Premise간의 신규 Site-to-Site VPN을 구축해야만 합니다.
또, A VPC와 C VPC의 통신 요건이 추가되었다면 어떨까요..? 위에서는 꼴랑 4개의 격리된 네트워크지만, 이게 수백개의 네트워크로 확장된다면요..?
그리고, Peering이든 VPN이든 구축만 한다면 끝일까요?? 아닙니다. VPC내의 리소스(Ex. EC2, RDS)와 통신을 해야하는 On-Premise의 IP 대역을 대상으로 Local route table을 수정을 해줘야겠지요.
또, 대부분의 네트워크 장애는 Point-to-Point를 잡아가며 트러블슈팅을 해야기에 위와 같은 복잡한 구성을 주고
관리자에게 '장애났어!! 해결해줘!! 통신 안돼!!!' 라고 하면... 가슴속의 사표를 뙇!!!!..
자 그럼, 위와 같은 복잡한 구성을 TGW로 구성했을 때, 어떤 모양이 나오는지 보실까요?
* 개인적인 견해입니다.
TGW와 연결을 맺을 때 Attachment라는 녀석을 생성하게 되는데, VPC ENI와 TGW의 연결이라고 생각하시면 편할 것 같습니다.
즉, 'TGW라는 라우터의 특정 인터페이스(Ex. eth 0/0, eth 0/1)와 대상 VPC ENI의 연결이 Transit Gatewat Attachment라는 리소스로 표현된다'
라고 생각하시면 편할 것 같습니다.
위 구성처럼 TGW라는 녀석을 사용한다면, Local route table에서는 그냥 내 대역이 아닌 녀석(내 가족, 친구, 사돈의 팔촌이 아닌) 들을 다 TGW로 던져버리면 됩니다.
그럼 TGW에서 그 패킷의 대상을 보고 Routing rule에 의해 패킷이 전달되는 형태입니다.
다음 포스팅에서 다루겠지만 미리 살짝 언급을 드리면, TGW의 Route table을 만들 때, Association을 지정하게 되는데요. 이는 TGW Route table에서 하나의 소스 IP가 되고, 연결된 Route table에 정의된 대상의 IP 주소를 따라 Next hop으로 이동하게 됩니다.
이를 활용하면 위의 그림에서 각각의 Association을 갖는 Route table을 3개를 생성하여,
1) A VPC는 C VPC와 On-Premise만 통신되고
2) B VPC는 C VPC와 통신되고,
3) C VPC는 A VPC, B VPC, On-Premise와 통신되도록
구성하여 리소스를 분리하고 불필요한 통신요건을 차단할 수 있습니다.
위 내용들은 추후에 좀 더 자세하게 다루겠습니다.
위에서 간단하게 TGW의 장점들을 좀 살펴봤는데요.
장점만 있느냐? 아닙니다. 가장 큰 단점이 존재합니다..!! 비쌉니다.
그렇다고 무조건적으로 비싼것은 아닙니다. 관리적인 측면 또한 고려를 했을 때 싸다고 표현할 수도 있을 것 같습니다.
단순 Peering & VPN과 Transit Gateway의 비용은 Transit Gateway가 더 비쌉니다.
아래의 기준을 갖고 간단하게 비용 계산을 해볼까요..?
* Transit Gateway의 VPC 연결비용은 연결된 VPC의 소유자에게 청구됩니다.
* Transit Gateway의 VPN 연결비용은 Transit Gateway 소유자에게 청구됩니다.
* Transit Gateway의 Direct Connect 연결은 Direct Connect 게이트웨이 소유자에게 청구됩니다.
1) 서울 리전
2) 한달(730 시간)을 기준으로 5개의 VPC가 모두 Peering을 맺는다.
3) 데이터 전송량 500GB
| VPC Peering | Transit Gateway | |
| VPC 연결 비용 | 없음 | 시간당 0.07$ |
| VPC 데이터 전송 비용 | GB 당 0.02$ | GB 0.02 |
| 예상 총 금액 | VPC 연결비용 0$ VPC 데이터 전송 비용 10$ Total 10$ |
VPC 연결 비용 51.10 x 5 = 255.5$ VPC 데이터 전송 비용 10$ Total 265.5$ |
단순 Peering과 Transit Gateway의 계산은 Transit Gateway가 압도적으로 비싸네요.
다음은 아래 조건으로 VPN & Peering과 Transit Gateway를 비교해보겠습니다.
* AWS Transit Gateway VPN 연결 요금에 추가로 Site-to-Site VPN 연결 요금이 적용됩니다.
1) 서울 리전
2) 한달(730시간)을 기준으로 5개의 VPC가 모두 Peering을 맺는다.
3) 한달(730시간)을 기준으로 5개의 VPC가 모두 On-Premise와 VPN을 맺는다.
4) VPC간 데이터 전송량 500GB5) VPN간 데이터 전송량 500GB
| VPC Peering & Site-to-Site VPN | Transit Gateway | |
| VPC 연결 비용 | 없음 | 시간당 0.07$ |
| VPC 데이터 전송 비용 | GB 당 0.02$ | GB 0.02$ |
| VPN 연결 비용 | 시간당 0.05$ | 시간당 0.05$ |
| VPN 데이터 전송 비용 | GB 당 0.126$ | GB 당 0.126$ |
| Transit Gateway VPN 비용 | None | 시간당 0.07$ |
| 예상 총 금액 | VPC 연결비용 0$ VPC 데이터 전송 비용 10$ VPN 연결 비용 182.5$ VPN 데이터 전송 비용 63$ Total 255.5$ |
VPC 연결 비용 51.10 x 5 = 255.5$ VPC 데이터 전송 비용 10$ VPN 연결 비용 35.5$ TGW VPN 연결 비용 51.1$ VPN 데이터 전송 비용 63$ Total 415.1$ |
VPC Peering과 VPN의 조합으로 모든 VPC가 On-Premise와 통신을 하기위해서는 각각의 VPC마다 VPN을 맺어줘야해서, 비용이 꽤나 나오긴 하는데요. 이 마저도 Transit Gateway와 비교했을 때 싼 가격이긴 합니다.
그렇지만, 위에서 말씀드린 것처럼, 관리요소 또한 무시할 수 없는 비용(인건비)지요.
이런 것들을 고려하셨을 때, 상황에 맞는 서비스를 선택하셔야 한다고 생각합니다. 혹은, 적절히 섞을 필요도 있겠네요.
간단하게 Transit Gateway에 대해서 알아보고, 장점과 단점들에 대해서 써봤는데요.
이 후, 포스팅을 업로드 할 때에는 실제 Transit Gateway를 구성하는 방법을 알아보도록 하겠습니다.
'AWS > VPC' 카테고리의 다른 글
| Transit Gateway? (2) - 생성 (0) | 2021.05.09 |
|---|
