[5] TGW와 Direct Connect는 언제 쓰나요?

안녕하세요!

TGW와 DX는 인프라를 AWS로 구축한 기업에서는 안쓰는 경우를 거의 본 적이 없습니다.
그 정도로 표준화되어 있는데요 왜 다들 사용하는 것일까요? 

앞서 VPC Peering에 대해 조금 알아봤습니다. 피어링은 VPC간 1:1 연결입니다. 다중 구성을 할 경우 매번 연결을 맺어줘야하는 불편함이 큽니다.

TGW는 뭔가요? 풀네임은 Transit Gateway입니다. Transit은 수송 Gateway는 입구 또는 관문으로 해석합니다. 무언가를 전달하는 관문이라는 의미가 되는데요, 정말로 TGW는 서로 격리된 VPC를 연결해주는 관문 역할을 합니다. 여러 VPC의 트래픽이 전달되는 허브와 같은 것이죠. 국제공항이나 터미널을 생각하시면 이해가 되시리라 생각됩니다.

Direct Conncect를 줄여서 DX라고 합니다. 왜 DX로 줄여졌는지는 명확히 확인하기 어려웠습니다만 DX로 편하게 부릅니다. DX는 aws리소스(VPC를 포함하는)와 온프레미스를 연결하는 전용선 서비스입니다. 실제로 전용선처럼 동작하기 위해 DX location을 관리하는 인터넷 서비스 프로바이더를 지정하여 DX 연결을 맺어달라고 요청하는 과정을 거쳐야합니다. TGW는 콘솔에서 활성화하고 연결을 맺어주는 것만으로 쉽게 끝나는 것과 조금 다르죠.

TGW를 사용하면 게이트웨이에 조인하는 방식으로 쉽게 여러 VPC간의 연결을 설정할 수 있습니다. 굉장히 심플하면서도 강력합니다. 특별한 요구사항 없이 하나 또는 여러 계정에서 VPC로 리소스를 어느정도 격리하면서 필요한 트래픽만 전달해줄 환경에 매우 적합합니다. 온프래미스와 aws의 VPC와 연결을 할 때에서 TGW만 있어도 가능합니다. 

여기서 끝난다면 행복하겠지만, 아마 여러분의 환경은 이것보다 조금 더 복잡할 것이라 생각됩니다. 대역폭과 응답속도가 중요할 수도 있고 private한 연결이나 secure한 연결이 필요할 수도 있습니다. 여기서 대역폭과 응답속도가 중요하다면 Direct Connect를 고려하게 됩니다. Direct Connect를 사용하면 private한 연결이 될 수 있습니다.

주의해야할 것이, private하다고해서 반드시 secure한 것은 아닙니다!

 

예전에 시험 공부할 때 이 부분을 틀린적이 있어 아직도 기억에 남습니다. 여기계신 많은 훌륭한 선배님들께서는 이미 다들 잘 아시겠지만, private하다고해서 반드시 secure하지는 않습니다. 
그렇다면 secure한 연결을 하기 위해서는 무엇을 해줘야 할까요? 아시는 것처럼 VPN입니다. 그래서 회사에서는 인터넷을 경유하는 패킷의 경우 즉, Direct Connect 혹은 TGW를 사용할 때 기본적으로 VPN도 같이 설정을 합니다. 

흥미로운 것은 DX는 site to site VPN을 지원하지 않습니다. 그러면 DX를 사용할 때 터널링은 어떻게? 보안은 어떻게 하나 라는 생각을 하실 수도 있는데요, site to site VPN은 아니지만 Private IP VPN은 지원합니다. Site to site VPN과 Private VPN은 서로 다른 서비스인가요? 심지어 콘솔에서 설정할 때에도 같은 탭(site to site VPN)에서 생성합니다.

그렇다면 둘은 뭐가 다를까요?

간단합니다. TGW는 인터넷 망을 이용합니다. 하지만 DX의 경우 인터넷을 이용하는 것이 아니죠. 전용선에서 VPN을 구성하는 것입니다. 네트워크를 처음 배울 때, 굳이? 라고 생각했던 적이 있는데 실제로 독립된 회선을 연결하는 것이 아니라 논리적으로 격리하는 것이기 때문에 환경에 따라 필요할 수도 있겠다 싶었습니다.  

다시 돌아가서, 대역폭과 응답속도가 중요하면 DX(Direct Connect)를 사용합니다. DX는 Q in Q 터널링을 통해 온프레미스에서 ISP의 연결망을 통해 aws의 데이터센터로 연결에 VLAN을 생성해 가상의 전용선을 사용하게 하는 것입니다. DX는 VPC와 온프레미스의 1:1 연결만 지원하는 것은 아닙니다. DX gw를 통해 여러 VPC와 온프레미스 사이의 연결을 생성할 수도 있습니다.

그렇다면 대역폭도 크고 응답속도도 빠른 DX를 쓰면되지 TGW는 왜 사용하지? 라는 의문을 가지실 수 있을 것 같습니다. 아님 말구요.. 저는 그랬습니다😆

그 이유는 당연히 비용입니다! 그리고 사용 목적이죠 ㅎㅎ

TGW는 DX에 비해 저렴합니다! tgw에 연결된 VPC(interface)마다 비용을 부과하지만 대역폭에 따른 비용을 추가로 부담하지 않습니다(물론 데이터 전송 비용은 부과합니다). 반면 DX는 대역폭에 따른 시간당 비용이 있으며 데이터 비용도 있습니다. DX가 훠얼씬 비쌉니다. 

또한 TGW는 전체적인 라우팅을 aws 중심으로 관리한다는 목적 의식이 강합니다. TGW는 라우팅을 관리하겠다는 목적으로 사용되며 DX는 더 빠르고 프라이빗한 연결이 필요한 경우에 사용됩니다. 따라서 이 둘은 상호 보완적이며 대체적인 관계라고 보기는 어렵습니다.
따라서 DX나 TGW의 docs를 보면 둘을 같이 사용하는 best practice가 많이 있습니다. 아래 사진처럼요.

https://docs.aws.amazon.com/ko_kr/vpc/latest/tgw/tgw-dcg-attachments.html

이 아키텍쳐는 하나의 DX 연결을 통해 여러 VPC에 접근하게하는 구성입니다. 만약 VPC들이 하나의 리전에 속할 경우 유용한 아키텍쳐입니다. 만약 여러 리전에 이러한 구성이 필요하다면 DX gw를 같이 사용하는 것이 고려될 것입니다. 빠른 통신을 위해서요. 아래 그림을 봅시다.

하나의 리전에서는 통신 속도가 매우 빠릅니다. 물론 같은 데이터 센터안에 있고 동일 렉으로 dedicated된 것보단 덜 하겠지만요. 다른 리전에 있는 리소스에도 신속한 트래픽의 흐름이 필요하다면 이 그림처럼 DX gw를 통해 여러 연결을 하나의 gw에서 관리하도록 설계할 수 있습니다.

그리고 production 환경에서 가장 중요한 것이 있죠. 가용성입니다. DX도 하나의 회선만 사용하기엔 부족하다고 느껴질 수도 있고 불측의 장애에 대비되지 못한다는 생각이 들 수 있습니다. 그러한 경우에 대비해 DX도 이중화를 하곤 합니다.

그림이 점점 복잡해져가는 것 같습니다. 하지만 차근차근보면 별거 없습니다. DX 로케이션을 두 개로 잡고 연결을 이중화했습니다. DX gw별로 연결하는 VPC를 구분해두었습니다. 그리고 VPC간의 통신은 TGW를 이용하게 했습니다. 추가로 DX로케이션에서 gw endpoint를 통해 S3나 DynamoDB에도 빠르게 접근할 수 있게 설정되어 있습니다.
DX gw는 최대 10개의 VPC만 연결시킬 수 있습니다. 따라서 직접 VPC가 많아지면 DX gw도 늘어나야합니다. 위에서 본 것처럼 TGW를 VPC 앞에 두는 것도 좋은 방법이 되겠죠. 

이중화는 정말 중요합니다. aws에서도 정말 많이 강조합니다. 심지어 Service Level Agreement에서도 이중화를 안할 경우 낮은 서비스 수준만을 보장합니다. DX의 SLA를 보시면 이중화를 할 경우 99.99%를 보장하고 이 수준을 달성하지 못하면 크래딧을 환급하지만 이중화를 하지 않을 경우에는 95.0%를 보장합니다. 

쓰다보니 내용이 또 길어졌습니다.. TGW와 DX에 대해 대충 감이 오실지 모르겠습니다 ㅎㅎ
이렇게 가다가 언제 k8s로 들어가게 될지 모르겠습니다🥲 한 두번 정도 더 aws 서비스에 대한 이야기를 하고 언능 쿠버네티스로 넘어가보도록 하겠습니다 ㅎㅎ

항상 읽어주셔서 감사드리며 오늘도 행복한 하루 되시기 바랍니다!!!