안녕하세요. 오늘은 지난번 포스팅 [AWS/VPC] - Transit Gateway? (1) - 개념 및 비용비교에 이어서,
실제 Transit Gateway를 생성해보는 포스팅을 작성해보고자 합니다.
Transit Gateway? (1)
안녕하세요!! 오늘은 AWS Transit Gateway라는 녀석에 대해서 좀 알아보려고 합니다. 많은 AWS 엔지니어분들께서 말씀 하시길 'AWS의 네트워크는 Transit Gateway가 있기 전과 후로 나뉜다' 라고들 하시는데
junhyeong-jang.tistory.com
바로 포스팅 시작하겠습니다.
AWS Web Console - VPC - Transit Gateway - Create Transit Gateway
다음으로 적절한 Name 태그와 설명 등 옵션들을 설정해주도록 되어있는데,
우선 ASN 번호는 CGW와 ASN 번호가 겹치면 오류가 발생합니다. AWS Default 값은 64512 입니다.
또한, DNS Support 기능을 켜서 DNS 호스트 이름을 프라이빗 IPv4 주소로 확인하기 위해서 해당 기능을 활성화했고,
Default route table이 아닌, 별도의 Route table을 생성할 것이기 때문에, Default route table association 및 Propagation 속성은 비활성화했습니다. (개인적인 생각이지만, 기본으로 생성되는 리소스들은 사용하지 않는 것이 휴먼에러나 보안사고를 예방할 수 있다고 생각합니다.)
그리고 TGW를 위한 CIDR을 따로 할당해 줄 수 있는데, 이는 Transit Gateway Connect 연결 및 피어에 필요합니다.
아래와 같은 옵션으로 TGW를 생성하겠습니다.
TGW를 만들었으면, 테스트를 위해서 TGW가 존재하는 리전에서 서로 다른 VPC A, B를 만들어서, 이 2개의 VPC를 통신시키도록 하겠습니다. 간단한 그림으로 표현하면 아래와 같겠네요.
VPC 생성과정은 패스하고, 바로 서로 다른 VPC에 TGW Attachment(이하 ATC)를 생성하도록 하겠습니다.
ATC는 지난번 포스팅에서도 말씀드렸지만, 쉽게 생각해서 TGW라는 Router의 특정 Interface(fa 0/0, fa0/1 ...)와 연결을 맺기 위해 생성하는 리소스(ENI)라고 생각하시면 됩니다.
(만약, VPC를 대상으로 ATC를 생성하게 되면, 대상 VPC에 TGW ATC용으로 ENI가 생성됩니다.)
VPC - Transit Gateway Attachments - Create Transit Gateway Attachment
- TGW를 선택하고 ATC Type을 정해줍니다.
- ATC의 Name 태그를 입력해줍니다.
- DNS Support 기능을 활성화합니다.
- 연결할 VPC를 선택합니다.
- ATC를 만들 서브넷을 지정합니다.
* 여기서 잠깐!!
AWS에서는 TGW를 위한 작은 CIDR 범위를 가진 별도의 서브넷을 사용하라고 권장합니다.
NACL을 적용하여 조직의 컴플라이언스 유지가 용이하기 때문입니다.
또한, 현재 TEST 환경에서는 TGW가 있는 Account에서 ATC를 생성하기 때문에 TGW를 바로 탐색할 수 있는데요.
만약, 다른 Account라면 어떨까요?? 내 Resource가 아닌 다른 계정의 TGW를 탐색할 수 있을까요?
불가능합니다.
그렇기에 Resource Access Manager(RAM) 라는 서비스를 통해서, TGW를 공유해주어야 합니다.
아래는 RAM 서비스의 사진입니다. 공유할 Resource를 선택하고, Account ID(12자리 계정번호)를 넣어주면 됩니다.
그리고, ATC 생성 또한 TGW를 공유받은 Account에서 생성해주어야 하겠지요.
TGW 공유에 대한 자세한 내용은 아래 링크 참조하시기 바랍니다.
docs.aws.amazon.com/ko_kr/vpc/latest/tgw/tgw-transit-gateways.html#tgw-sharing
전송 게이트웨이 - Amazon Virtual Private Cloud
전송 게이트웨이 전송 게이트웨이를 사용하면 VPC와 VPN 연결을 동일한 리전에 연결하고 두 리전 간의 트래픽을 라우팅할 수 있습니다. 전송 게이트웨이는 AWS 계정에서 작동하며, AWS Resource Access M
docs.aws.amazon.com
자.. 다시 돌아와서.. 위와 같은 옵션으로 TGW ATC를 생성하도록 하겠습니다.
생성하게 되면, 위에서 말씀드린 것처럼 ATC의 ENI가 대상 VPC의 각 서브넷에서 생성되는 것을 확인하실 수 있습니다.
위와 같은 방법으로 B VPC의 ATC를 만들어주도록 하겠습니다.
자, ATC를 생성했으니 이제 Route table을 생성해주겠습니다.
TGW를 생성하면서 자동으로 만들어진 Default route table이 있는데, 저는 위에서 TGW를 생성하면서 생성되는 ATC들을 Default Route table에 자동으로 연결(Association) 되지 않도록 설정하고, 전파(Propagation) 옵션도 비활성화했습니다.
즉, Default route table은 그냥 빈 깡통입니다.
A-VPC-ATC의 Route table 한 개, B-VPC-ATC의 Route table 한 개, 총 2개의 Route table을 생성하겠습니다.
VPC - Transit Gateway Route Tables - Create Transit Gateway Route Table
이렇게 두 개의 Route table을 만들어 주었다면,
A-VPC-ATC-RT에 Association을 A-VPC-ATC를 넣어주고, Route는 B-VPC CIDR > B-VPC-ATC 를 향하도록,
B-VPC-ATC-RT에 Assocation을 B-VPC-ATC를 넣어주고, Route는 A-VPC CIDR > A-VPC-ATC 를 향하도록
각각 설정해주도록 하겠습니다.
아래 순서에서는 A-VPC-ATC-RT 로만 예를 보여드리겠습니다.
Create association을 눌러주고,
A-VPC-ATC를 선택하여, 연결을 맺어주고,
Routes에서 Create static route를 누르고,
B VPC의 CIDR과 B-VPC-ATC를 선택하여 Route rule을 생성합니다.
마찬가지로 B-VPC-ATC-RT도 같은 방법으로 설정해주도록 합니다.
자 그럼, 이제 TGW의 RT는 설정이 끝났는데요.
Local route table을 수정하여서 A VPC에서 B VPC를 대상으로 패킷을 보내려면 TGW를 보내도록, 그 반대의 경우도 TGW로 보내도록 설정해줍시다.
자 여기까지 구성하고, Flow를 살짝 설명드리자면..
'V-VPC에서 B-VPC로 가려면 TGW로 보내라' 라는 규칙이 있습니다.(물론 그 반대의 경우도 있습니다.)
그러면, 해당 패킷은 생성된 ATC(ENI)를 통해서 TGW에 도달할 건데요.
TGW Route table을 생성하면서 Association에 어떤 녀석을 달아줬는지 기억하시나요??
바로 ATC를 달아주었습니다.
지난번 포스팅에서 Association이 하나의 Source가 되고, 연결된 TGW Route rule에 따라 패킷이 전달된다고 말씀드렸습니다.
그래서, Route table을 쪼개면, 리소스를 분리하고 불필요한 통신 요건을 차단할 수 있다고 말씀드린 것입니다.
예시로 A-VPC의 EC2가 B-VPC로 ICMP 메시지를 보내는 상황을 그림으로 정리하면 아래와 같습니다.
위와 같이 통신요건마다 각각 별도의 Route table을 만들어준다면, 예를 들어 아래와 같은 구성도 가능합니다.
A-VPC : B-VPC와 C-VPC와 IDC와 통신
B-VPC : A-VPC와 IDC와 통신
C-VPC : A-VPC와 통신
* 불필요한 통신 요건을 줄이는 것은 혹시 모를 보안사고 및 침해사고에 영향받는 리소스를 최소화할 수 있습니다!!
자 그럼, 마지막으로 통신이 되는지 확인하고, 확장한 TGW의 예시 아키텍처와 함께 포스팅 마치겠습니다.
(당연한 얘기지만, 통신하려는 각 EC2에서 SG를 열어주어야겠지요..? 저는 ping으로 테스트하기에 ICMP를 열겠습니다.)
이렇게 TGW를 사용하여 서로 다른 VPC 간의 통신을 시켜보았습니다.
테스트 환경에서는 2개의 VPC만 가지고 테스트를 해보았지만, 실제로 수십수백 개의 VPC 및 VPN을 연결한다면,
TGW의 관리 편의성을 실감하실 수 있을 겁니다!!
또한, VPN 테스트를 하시고 싶으시다면 Openswan을 활용하여 테스트해보시길 바랍니다 ^^
그럼 이만 포스팅 마치도록 하겠습니다.
감사합니다.
'AWS > VPC' 카테고리의 다른 글
| Transit Gateway? (1) - 개념 및 비용비교 (2) | 2021.05.03 |
|---|
