Cloud/AWS

AWS Cloud WAN - Part 1

지기(ZIGI) 2021. 12. 9. 02:36
Today Keys :   cloud wan, wan, global network, network, manager, core, policy, cne, edge, segment

 

 

이번 포스팅에서는 AWS Re:Invent 2021에서 소개된 AWS Cloud WAN에 대한 첫 번째 포스팅입니다. Cloud WAN으로 다뤄야 할 내용이 많을 듯 하여, 몇 번에 나눠서 포스팅을 하게 될 것 같습니다. 이번 포스팅에서는 Cloud WAN에서 Global Network과 Core Network를 만든 후애, Core Network Policy를 수정해보는 예제입니다.
Cloud WAN에 대한 개론에 대해서는 별도 포스팅에서 다룰 예정입니다.

 


 
AWS Cloud WAN은  몇 번의 클릭만으로 지사, 데이터 센터 및 Amazon Virtual Private Cloud(VPC)를 연결할 수 있는 중앙 대시보드를 제공합니다. Cloud WAN에서는 네트워크 정책을 사용하여 한 위치에서 네트워크 관리 및 보안 작업을 자동화합니다. Cloud WAN은 온프레미스 및 AWS 네트워크에 대한 전체 보기를 생성하여 네트워크 상태, 보안 및 성능을 모니터링하는 데 도움이 됩니다.
    - AWS Cloud WAN 소개 페이지

 

Cloud WAN은 현재 일부 리전*에서 미리보기로 지원되고 있기 때문에 지원되는 리전의 VPC 메뉴에서 확인할 수 있습니다.

Cloud WAN은 현재 일부 리전*에서 미리보기로 지원되고 있기 때문에 지원되는 리전의 VPC 메뉴에서 확인할 수 있습니다.

  - 지원 리전(21년 12월 9일 기준) : US East (N. Virginia), US West (N. California), Africa (Cape Town), Asia Pacific (Mumbai), Asia Pacific (Singapore), Asia Pacific (Sydney), Asia Pacific (Tokyo), Europe (Ireland), Europe (Frankfurt), and South America (São Paulo).
 
 
Cloud WAN을 만들기 위해서 가장 먼저 글로벌 네트워크(Global Network)를 생성합니다.
 
 
 
글로벌 네트워크 생성 시, 글로벌 네트워크에 속하게 될  코어 네트워크(Core Network)로 함께 생성이 가능합니다.
물론 옵션이기 때문에 글로벌 네트워크를 생성한 이후에 생성해도 무방합니다.
코어 네트워크 생성을 위해서 코어 네트워크 이름을 입력합니다.            
 
 
 
추가로 코어 네트워크에서 사용할 ASN 범위와 엣지 로케이션, 세그먼트를 입력합니다.
ASN 범위에 대한 내용은 Cloud WAN의 이후 포스팅에서 다룰 예정입니다.
 
엣지 로케이션(Edge location)은 코어 영역에 속한 리전으로 코어 네트워크에서 관리하게 될 리전을 선택합니다.
여기에서는 us-east-1(버지니아) 1개를 선택했습니다.
코어 네트워크에서 리전을 선택하고 나면, 해당 리전에 코어 네트워크 엣지(Core Network Edge:CNE)가 생성됩니다.
코어 네트워크 엣지는 기존의 Transit Gateway의 역할과 유사하다고 생각하면 됩니다.
그리고 모든 엣지 로케이션에서 기본으로 활성화 될 기본 세그먼트(Segment) 이름을 설정합니다.
세그먼트는 글로벌 네트워크 내에서 허용되는 라우팅 도메인으로, 동일 세그먼트에 속한 경우에 상호 간의 라우팅이 가능한 구조라고 보면 됩니다.
물론 세그먼트가 다르더라도 연결은 가능하며, 이 부분은 Cloud WAN의 이후 포스팅에서 다룰 예정입니다.
 
 
 
코어 네트워크 설정 후에  글로벌 네트워크를 만들기 위해서 설정한 값을 확인하고 글로벌 네트워크를 생성합니다.            
 
 
 
잠시 후, 아래와 같이 글로벌 네트워크가 생성된 것을 확인 할 수 있습니다.
 
 
 
이제 코어 네트워크를 확인해 보면, 상태가 pending 인 것을 볼 수 있습니다.
이는 아직 코어 네트워크가 정상적으로 구성이 완료되지 않았기 때문입니다.
코어 네트워크에는 코어 네트워크에 대한 정책 정의를 위해서 코어 네트워크 정책 문서를 사용합니다.
해당 문서에 선언된 내용을 기반(관리자가 의도한[intend])으로 코어 네트워크의 설정이 이뤄집니다.
앞서 코어 네트워크 생성 시에 입력한 항목이 코어 네트워크 정책 문서를 만들기 위한 값이었습니다.
 
 
 
코어 네트워크의 정책 버전 항목에 들어가보면, 다음과 같이현재 정책이 Executing 상태인 것을 볼 수 있습니다.
 
 
 
시간이 좀 더 지나고 나면, 정책이 정상적으로 모두 적용이 되고 상태 값이
Executing에서 Execution succeeded로 변경된 것을 확인 할 수 있습니다.
 
 
 
정책이 모두 적용된 이후에는 코어 네트워크 개요에서 아래와 같이 확인이 가능합니다.
현재 코어 네트워크에서는 엣지 로케이션(초기 설정한 버지니아 리전)과 기본 세그먼트가 1개씩 있는 것을 볼 수 있습니다.
 
 
 
정책 문서를 클릭해서 어떤 항목들이 있는지 확인해 봅니다.
오늘 포스팅에서 각 항목을 모두 설명하지는 않으며, 추후 포스팅에서 하나씩 다뤄보려고 합니다.
현재 설정된 정책 값에는 엣지로케이션 값에 버지니아 리전이 있는 것을 볼 수 있습니다.
 
 
 
세그먼트는 'zigiseg1' 이라는 이름의 기본 세그먼트가 있습니다.
세그먼트 자체에도 몇 가지 속성 값이 있는 것을 볼 수 있습니다.
 
 
 
정책을 시각적 편집기(Visual editor)에서 설정이 가능하지만, 아래와 같이 JSON 형태로 설정도 가능합니다.
 
 

 

 
그럼 정책을 '편집'해서 코어 네트워크 설정을 변경해 보겠습니다.
정책에서 편집 버튼을 누르면 아래와 같이 코어 네트워크 정책(Core Network Policy)의 항목을 편집할 수 있습니다.
여기에서는 엣지 로케이션(Edge Location)에 싱가포트를 추가로 설정하려고 합니다. 
 
 
 
생성 버튼을 눌러서, 엣지 로케이션을 추가합니다.
여기에서는 앞서 얘기한 것처럼 싱가포르를 추가합니다.
위치(Location)을 제외하고는 다른 값은 우선 설정하지 않습니다.
엣지 로케이션 생성 버튼을 눌러서 엣지 로케이션을 추가합니다.
 
 
 
아래와 같이 엣지 로케이션이 추가된 것을 볼 수 있습니다.
 
 
 
편집기에서 수정한 값이 JSON에서도 반영되어서, 싱가포르 리전인 'ap-southeast-1'이 엣지로케이션에 포함된 것을 볼 수 있습니다. JSON에서도 속성 값 하나를 변경합니다. 4번째 줄에 위치한 vpn-ecmp-support 속성 값을 false에서 true로 변경합니다.  모든 값을 수정하고 나면, 하단의 정책 생성(create policy)를 클릭합니다.
 
 
 
새로운 정책 버전 ID 2가 생성된 것을 볼 수 있습니다.
초기 생성된 정책 버전 ID가 LIVE 상태인 것을 볼 수 있고 방금 수정한 정책 버전 ID 2는 LATEST로 최근에 업데이트 한 값임을 확인 할 수 있습니다. 그리고, ID2의 상태는 Pending generation 상태임을 볼 수 있습니다.
 
 
 
시간이 조금 지나고 나면, ID 2 정책의 상태가, Ready to execute로 변경된 것을 볼 수 있습니다.
이처럼 수정한 정책은 바로 적용되는 것이 추가로 적용을 해야 반영이 됩니다.
ID 2 정책을 선택하여, '변경 세트 보기 또는 적용'을 선택합니다.  
 
 
 
변경 세트를 보면, 방금 전에 수정한 항목이 표기가 된 것을 볼 수 있습니다.
에지 로케이션에 싱가포르 리전을 추가하였기 때문에 Core Network edge가 Add되는 것을 볼 수 있습니다.
또한 새로운 CNE는 기본 세그먼트의 라우팅 도메인에 속하기 때문에 Core Network segment도 변경되는 것을 볼 수 있습니다.
여기서 새 값과 이전 값을 클릭하면 JSON 형태로 현재 값(이전 값)과 변경하려는 ID의 새로운 값(새 값)을 확인할 수 있습니다.
변경 세트 적용을 선택하여, 방금 수정한 ID 2 Policy를 적용합니다.
 
 
 
새로운 버전의 정책의 실행이 이뤄집니다. 현재 상태가 Ready to execute에서 Executing로 변경된 것을 볼 수 있습니다.
 
 
 
시간이 지나고 나면 정책 적용이 끝나고 나면
ID 2 정책의 상태가 Execution succeeded로 바뀐 것을 볼 수 있습니다.
그리고 현재 해당 정책이 적용 중임을 볼 수 있는 LIVE가 ID 1에서 ID 2에 있는 것을 볼 수 있습니다. 
여기서 보면, 기존 ID 1의 값도 기존대로 남아 있는 것을 볼 수 있습니다. 추가로 새로운 버전의 정책이 만들어지면
버전 ID가 계속 늘어날텐데, 결국 저 정책 문서의 ID가 그대로 남아있기 때문에
기존 버전의 코어 네트워크 구조로 언제든지 원복 할 수 있게 됩니다.
필요에 따라서 적용해야 하는 코어 네트워크 구조를 정책 문서로 정의해서 필요한 상황에 맞춰서 각 정책 문서로 적용할 수 있는 것입니다.
 
 
 
마지막으로, 코어 네트워크 개요에서 엣지 로케이션이 정상적으로 추가로 만들어졌는지 확인을 해보면,
us-east-1(버지니아 리전)과 ap-southeast-1(싱가포르 리전) 2개의 엣지 로케이션이 있는 것을 볼 수 있습니다.
 
 
 
추가로 JSON에서 변경한 속성 값인 vpn-ecmp-support 속성도 '예'로 잘 변경된 것을 확인할 수 잇습니다.