여러분은 AWS를 사용하면서 네트워크 구조를 어떠한 방식으로 만들고 계신가요?

AWS 인프라의 확장이나 보안을 위해 어떠한 방식으로 대처하고 계신가요?

오늘은 첫번째 시간으로 AWS 네트워크 서비스 연결의 핵심이라고 생각하는 Transit Gateway를 말씀드리고자 합니다.

Transit Gateway는 지난 2018년 12월 서울 리전에 런칭 하였습니다.

꽤 오래 전에 서비스가 생겼음에도 많은 분들이 아래와 같은 구조로 VPC Peering을 통한 FULL MESH 네트워크를 구성하십니다.

물론 이 구조가 장점이 없는 것은 아닙니다.

가장 큰 장점으로는 VPC 간의 트래픽 비용이 저렴합니다.

VPC Peering 서비스는 EC2의 트래픽 비용으로 계산되기 Cross AZ(Availability Zones)만 과금이 됩니다. 때문에 VPC간 통신 트래픽 비용이 상대적으로 저렴합니다.

하지만, 회사에 AWS 인프라를 관리할 수 있는 사람이 적거나 또는 DevOps 같이 여러 업무를 겸직을 하고 있는 경우에 인프라가 늘면 늘 수록 감당하기가 힘들어집니다. 그리고, 만약 라우팅을 확인하려고 한다면 여러 계정에 있는 여러 VPC의 라우팅 테이블을 각각 확인해주어야 합니다.

사실 MESH 형태의 인프라를 관리하는 건 굉장히 피곤한 일입니다

개인적으로 다음 Case에 해당된다면 Transit Gateway 사용을 권장 합니다.

• Application 서비스들이 매우 빠른 속도로 확장되고, 인프라의 확보가 빨라야 하는 경우

• 지사 혹은 공장 등으로 많은 인터페이스를 연결해야하는 경우

• BGP로 전파되는 라우팅의 경로가 100 line이 넘는 경우

• 운영, 품질, 개발 등의 환경을 VPC로 나누고 라우팅을 세세히 제어하려고 하는 경우

• 해외 지사와 안정적인 Private 네트워크를 구성하고 싶지만 MPLS, SD-WAN을 구성할 여력이 안되는 경우

• SAP on AWS를 도입/이전 하시려고 하는 경우

• In/Outbound 트래픽을 감사하려고 하시는 경우

• EC2 환경의 Application에서 Multicast를 이용하는 경우

예를 들어서 설명 드리면 이해가 더 쉬울 것 같습니다.

아래는 Transit Gateway를 이용하는 가상 회사의 아키텍처입니다.

각 VPC의 용도는 다음과 같습니다.

• Services VPC : 대외 서비스가 존재하는 VPC

• Shared VPC : 사내 그룹웨어, 보안 솔루션의 정책 서버, 소스 배포 서비스 등이 존재하는 VPC

• DEV VPC : 개발 환경의 VPC로 가상 회사의 개발 파트너 사에서 유일하게 접근할 수 있는 환경

• Playground : 내부 엔지니어와 개발자의 역량 강화를 위한 AWS 테스트 환경

여러분도 아시다시피 VPC는 Virtual Private Cloud의 약어로 독립된 네트워크 환경을 구성해 줍니다. 이러한 독립된 네트워크 환경에 Transit Gateway를 이용해 각 환경을 연결하거나, 연결하지 못하게 할 수 있습니다. 이러한 라우팅 설정을 쉽게 할 수 있게 도와줍니다.

Transit Gateway(이하 'TGW'로 병기) 서비스는 5가지 기능이 있는데, 각각의 역할은 다음과 같습니다.

• Transit Gateways : Transit Gateway를 생성할 수 있는 기능입니다.

• Transit Gateway Attachments : TGW에서 연결을 담당하는 기능입니다. 구성요소로 VPC, S2S VPN, Cross region Transit Gateway 연결을 위한 Peering Connection이 있습니다.

• Transit Gateway Route Tables : TGW의 라우팅을 담당하는 라우팅 테이블들이 모여 있는 곳 입니다. 모든 Attachment는 하나의 Route Table을 사용해야 통신이 가능합니다. 위의 아키텍처처럼 특정 Attachment를 기준으로 각각 라우팅 테이블을 나누어서 설정할 수도 있습니다.

• Transit Gateway Multicast : Multicast 설정을 위한 메뉴 입니다.

• Network Manager : 별도의 비용없이 TGW를 쉽게 모니터링하고, 라우팅을 검증할 수 있는 기능입니다.

기본적인 TGW의 기능을 알게되었다면, 샘플 아키텍처를 Console GUI환경으로 만들어보겠습니다.

저희가 이번에 테스트로 만들 환경은 아래 아키텍처와 같습니다.

먼저 TGW를 만들어 보겠습니다.

이때 다른 옵션은 생성 후 변경할 수 있지만, ASN은 변경하지 못합니다.

ASN은 이후 Attachment로 생성하는 구성 요소 중 BGP 프로토콜을 이용하는 장비들과 Overlap 될 수 없으니, BGP를 사용하시는 분들은 ASN을 다시 한번 확인해주시면 되겠습니다.

이후 각각의 VPC 별로 Attachment를 생성합니다.

아래의 스크린샷은 Red_VPC를 기준으로 합니다.

Attachment를 생성하게 되면, 선택된 Subnet에 TGW 용도의 Elastic Network Interface(ENI)가 자동으로 생성 됩니다.

이제 각각의 Trangit G/W의 Route Table을 생성하고, 각각 Associations 해줍니다.

아래는 Red RoutingTable에서 Red_VPC를 association 시켜준 화면입니다.

이제 Transit G/W에서 각각의 VPC에 할당된 Route Table이 생겼습니다.

라우팅 정책을 넣도록 합니다.

우리는 아래와 같은 도표 형태로 구성되게 할 것 입니다.

[Red 라우팅 테이블]

Route Type을 보시면, ‘Static’으로 명시되어 있습니다.

Route Type에는 2가지의 종류가 있습니다.

• Static : 관리자가 manually하게 입력한 경로

• Propagated : RouteTable의 propagations에 등록된 Attahcment가 자동으로 전파한 경로

아래의 Blue, Green 라우팅 테이블을 유심히 보시면 어떤 것은 Static으로 설정되어 있고, 어떤 것은 Propagated 상태입니다.

이것은 ‘이렇게도 할 수 있다’는 것을 보여드리기 위해 테스트 환경을 구성한 것이니, 가급적 VPC는 Propagations에 등록하여 관리하는 것을 권해 드립니다.

[Blue 라우팅 테이블]

[Green 라우팅 테이블]

설정이 완료 되었으면, TGW ‘Network Manager’를 통해 라우팅 정책이 정상적인지 확인해 봅니다.

[Red_VPC ↔ Blue_VPC]

[Blue_VPC ↔ Green_VPC]

위에서 말씀드린대로 의도적으로 통신이 안되게끔 하였기에 이러한 결과가 출력됩니다.

처음 서비스가 런칭되었을 때 개념을 이해하기 힘들었었는데, 다른 분은 삽질을 덜 하시게끔 문서를 만들어보았습니다.

도움이 되셨나요?

피드백을 남겨주시면 다음 문서에는 보완할 수 있도록 하겠습니다.

아래 링크들은 AWS의 공식 가이드 문서이니, 읽어보시면 도움되시리라 생각됩니다.

긴 글 읽어주셔서 감사합니다.

• Single Internet exit point from multiple VPCs

• Centralized Router

• Working with Route Tables in AWS Transit Gateway