AWS Cloud WAN - Part 3

Today Keys :   cloud wan, wan, global network, network, manager, core,route, cne, edge, segment, attachment, isolated, acceptance

---

AWS Re:Invent 2021에서 소개된 AWS Cloud WAN에 대한 세 번째 포스팅입니다.  첫 번째와 두 번째 포스팅에서 Cloud WAN의 Global Network/Core Network/Segment/Attacment를  구성하여, 서로 다른 리전의 VPC를 통신해 보았습니다. 세 번째 포스팅에서는 Segment 구성 시에 설정 가능한 Require acceptance, Isolated Attachments 옵션과, Segments Actions의 Route를 설정해 보면서 Attachment의 연결 시의 승인 절차와 라우팅 제어에 대해서 알아봅니다.

처음 포스팅 시에도 남긴 얘기지만, Cloud WAN으로 다뤄야 할 내용이 많을 듯 하여 몇 번에 나눠서 포스팅을 할 예정이며, Cloud WAN에 대한 개론에 대해서도 별도 포스팅으로 다룰 예정입니다.

AWS Cloud WAN Part 1 : https://zigispace.net/1150

AWS Cloud WAN - Part 1

AWS Cloud WAN Part 2 : https://zigispace.net/1151 

AWS Cloud WAN - Part 2

---

오늘 포스팅에서 다뤄질 아키텍처는 아래와 같이 Cloud WAN의 2번째 포스팅의 아키텍처와 동일합니다.

 

 

 

Core Network의 Segment를 만들 때, Require acceptance를 체크하게 되면

지난 Cloud WAN 2번째 포스팅에서 본 것처럼, Attachment를 Segment에 연결 시에 바로 연결되지 않고

아래와 같이 Pedning 상태에서 승인을 대기합니다.

 

 

 

그럼 이번에는 Segment에 Require acceptance를 옵션을 해제하고, Attachment를 연결해 보겠습니다.

Core network의 현재 Policy version을 선택하고, edit를 눌러서 수정합니다.

Segment 탭에서 기존에 만들었던, zigiseg1 이라는 Segment을 선택해서 아래와 같이

'Require acceptance' 옵션의 체크를 해제합니다.

변경한 옵션이 적용되도록, 새로운 Policy version을 적용합니다.

 

 

 

새로운 Core Network의 Policy가 완전히 적용되고 나면, 이제 다시 Attachment를 만들어 봅니다.

Virginia 리전에 있는 VPC를 ZIGI-VIRG-VPC2-Attach 라는 이름으로 연결합니다.

 

 

 

Attachment를 추가하자마자, 별도의 허가 절차 없이 바로 Attachment가 생성되는 것을 확인 할 수 있습니다.

※ 저는 이후 테스트를 위해서 해당 Attachment를 생성이 완료된 이후에 바로 다시 삭제했습니다.

 

 

 

이번에는 Segment의 또 다른 옵션인 Isolated attachments 옵션을 테스트 해 보겠습니다.

기본적으로, Segment에 연결된 Attachment는 동일한 Segment 내에서

라우팅이 전파(Propagate)되기 때문에  통신이 가능합니다.

만약 동일한 Segment 내의 라우팅 전파를 차단해서,

Segment 내에 연결된 Attachment간의 통신을 막고 싶다면, 'Isolated attachments' 옵션을 사용합니다.

옵션명 그대로 attachments 간을 고립시킬 수 있습니다. 

테스트를 위해서 Core Network Policy의 Segment 설정에서 아래와 같이 'Isolated attachment' 옵션을 체크하고,

신규 Verison의 Core Network Policy를 적용합니다.

 

 

 

Isolated attachment설정 후,  Policy 적용 시에 Attachment route propagation(전파)가 삭제되는 것을 볼 수 있습니다.

 

 

Core Network에서 실제 라우팅 테이블을 확인해 보면,

Isolated attachment 옵션을 적용하기 전에는

아래와 같이 Virginia(10.1.0.0/22)와 Singapore(10.2.0.0/24) 대역에 대한 라우팅이 조회되는 것을 볼 수 있지만,

 

Isolated attachment 옵션을 적용한 이후에는

아래와 같이 아무런 라우팅 정보가 없는 것을 확인 할 수 있습니다.

 

 

Segment 단위로 Attachment에 대한 라우팅을 전체 전파하거나, 고립 시키는 것 이외에

개별 대역(CIDR)로 Static한 라우팅 설정도 가능합니다.

Core Network Policy의 Segment actions - optional 탭의 'Route' 에서 Static 라우팅을 설정합니다.

다음과 같이 어떤 Segment에 적용할 것인지와 목적지 네트워크 대역(CIDR)그리고,

Target(Next hop)으로 쓰일 Attachment를 입력합니다.

zigiseg1 Segment에서 목적지 대역을 10.1.0.0/22로 하고, 해당 대역이 연결된 Virginia쪽 Attachment를 설정합니다.  

 

 

 

추가로 Singapore 쪽 대역인 10.2.0.0/22에 대해서도 동일한 방식으로 라우팅 설정을 합니다.

Virginia(10.1.0.0/22)와 Singapore(10.2.0.0/22)에 대한 라우팅 설정을 다음과 같이 하고 나면,

새로운 Core Network Policy Version을 다시 적용합니다.

 

 

 

Core Network Policy가 모두 적용되고 나면, 다시 라우팅 테이블을 확인해봅니다.

 

먼저 zigiseg1 Segment의 Virginia(us-east-1)의 라우팅 테이블을 보면,

Virginia 대역인 10.1.0.0/22가 보이고, Route Type이 Static인 것을 볼 수 있습니다.

여기서 추가로 확인 할 것은, Singapore 대역인 10.2.0.0/22도 보이고, 이는 Route type이 Propagated 인 것을 볼 수 있습니다.

Singapore에 대한 대역도 Static하게 앞에서 라우팅 설정을 했었고,

이를 통해서 다시 Singapore에 대한 라우팅을 전파 받은 것을 알 수 있습니다.

 

 

 

이어서,zigiseg1 Segment의 Singapore(ap-southeast-1) 에 대한 라우팅 테이블을 확인하면 아래와 같으며,

앞서 살펴본 Virginia와 유사하게 동일 리전의 대역은 attachment를 목적지로 static 설정되어 있고,

다른 리전은 segment를 목적지로 전파 받은 것을 확인할 수 있습니다.