[ AWS ] Core Network Policy(CNP) Segment Routing 수정하기

AWS는 내가 지금 다니고 있는 회사에서 사용하는 SAP와 유사하다고 한다. 다만 각각 다른 방식으로 서비스를 제공하고 있다는 점을 알게 되었다. AWS의 경우에는 User가 클라우드에 대한 자유도가 굉장히 방대하지만 클라우드에 대한 이해도가 없는 사람에게는 그만큼 접근성이 떨어지거나 활용도가 미흡할 것이다. 반면에 SAP는 완성된 UI를 User에게 제공하면서 손쉽게 클라우드 플랫폼을 사용할도록 해주지만, 그에 반해 커스터마이징이 어렵다는 문제도 있다.  

---

 

 

Policy version에서 전에 생성해 두었던 Policy version - 2를 클릭해 들어가보면
edge location에 지정된 region에 Core Network Edge가 생성되어 있다.

Core Network Edge는 Core Network와 Attachment를 통해 연결하는 region을 연결해주는 Resource이다.    

내부적으로는 Transit Gateway와 유사한 동작을 수행해 Transit Gateway와 유사한Resource를 edge location으로 지정한 region에 Core Network Edge로 배치하게 된다.

다만, Transit Gateway와 유사하긴 하지만, Managed 형태로 제공되고, 동적 Routing과 같이 차이점이 있긴 하다. 

---

 

 

여기서 한 번 확인해야할 것은 바로 Segement에서 prod에만
Isolated attachments(격리된 연결) 항목이 yes(예)로 되어 있다.

이는 Octank 네트워크의 요건 중에 Prod 환경은 높은 보안성을 위해
Oregon region의 Prod 환경과도 통신이 차단돼야하고,
Legacy 환경과만 통신이 가능해야한다는 것을 위한 설정이다.

기본적으로는 같은 Segment 내에서는 Attachment 간의 Routing이 활성화 된다.
따라서 region이 다르다고 하더라도 같은 Segment에 속한다면 Routing이 활성화 되는 것이다.

그러나 Octank는 prod 환경의 높은 보안성을 위해 prod 환경의 region 간의 통신을 차단하고자 하기 때문에
같은 Segment 내라도 다른 Attachment라면 통신을 단절시키기 위해 Isolated Attachments 설정을 적용한다.   

---

 

 

Policy version - 2 체크박스를 클릭한 뒤 편집 기능에 진입한다.

세그먼트작업 - 선택사항을 선택하고 생성을 클릭한다.  

---

 

 

모달창으로 나타나면 Segment는 prod로 선택해주고,
공유대상은 선택 항목 허용을 선택한 뒤
Segment 목록 허용을 legacy로 선택한다.

이는 prod와 legacy 간의 sharing(공유)을 생성하는 과정이다.

---

 

 

새롭게 생성된 정책이 Ready to execute로 상태가 바뀌게 되면,
View or apply change set(변경 세트 보기 또는 적용)을 클릭해 변경점을 적용한다. 

정책 반영이 완료되면, dev, prod legacy Segment 중 prod와 legacy Segment 간의 항소 Routing이 활성화 된다.

---

Next Stage : [ AWS ] VPC Routing Table 수 정하기

[ AWS ] VPC Routing Table 수 정하기

반응형