azure 에서 망분리가 먼저 선행되어야 할 과제이다.
aws 에서의 망분리는 계층적 망분리로 서브넷과 라우팅 테이블을 이용하여 망분리를 구현한다. 하지만 gcp / azure는 망분리의 개념이 좀 다르다.
서브넷을 통한 망분리가 아닌 공인IP의 유무로 망분리를 구현한다.
근래에 구성도를 작성하면서 한편으로 계층적 망구성이 구성도 그리긴 불편한 생각이 들긴한데 그래도 익숙하고 편한데 azure 와 gcp 를 보니까 aws 의 망구성이 관리의 편의성이 떨어지는 느낌이기도 하고..조금 애매한 느낌이 든다.
azure 에서는 어떤 인프라도 리소스그룹안에서 만들어진다. gcp의 프로젝트 개념과도 같다. 그렇지만 좀 다른게 리전에 종속된다.
한국리전은 중부와 남부로 나뉘는데 중부를 azure 에선 중부를 주로 추천하는데 나는 중부말고 남부를 선택했다.
요구하는 바는 구독 그룹네임 리전 리소스 그룹다음에는 virtual network 를 생성하는데 VN은 서브넷을 생성하게 된다.
가상네트웤의 최대 크기는 10.0.0.0/8 까지로 16777216개 주소 를 사용할수 있다.
서브넷을 3개로 나누었고 서브넷은
보안그룹을 서브넷에 설정하여 접근제어가 가능하다.
aws 의 구성의 경우엔 az 별 서비스별 서브넷을 설정했지만 azure 는 az가 명시적으로 지정되지 않아 서비스별 서브넷을 생성해서 사용하는것이 최선으로보인다.
서브넷의 보안그룹으로 막으려면 tag ip id 로 명시적으로 막자.
서브넷별 nsg 가 구성되는게 좋을것 같다.
가상머신은 공용아이피를 없앤 채로 생성한후 나중에 공용IP를 부여할수있었다.
직렬연결은 가상화 머신의 화면을 그대로 포워딩해주는 방식으로 보이며 공용IP가 없는 상태에서도 연결할수 있었다.
굉장히 불편한 부분은 이다음에 발생했는데 lb 는 sku 개념덕분에 혼파망이 되었다.
sku는 basic / standard 두가지로 나누어져있는데
인터넷 통신
기본적으로 VNet의 모든 리소스는 인터넷으로 아웃바운드 통신을 할 수 있습니다. 공용 IP 주소 또는 공용 Load Balancer를 할당하여 리소스에 대해 인바운드로 통신할 수 있습니다. 공용 IP 또는 공용 Load Balancer를 사용하여 아웃바운드 연결을 관리할 수도 있습니다. Azure의 아웃바운드 연결에 대한 자세한 내용은 아웃바운드 연결, 공용 IP 주소 및 Load Balancer를 참조하세요.
하...모든인스턴스는 인터넷과 통신이 가능하다. 이거때문에 한참을 헤멧다.
nat gw가 필요가 없다..............................충격 막으려면 NSG로 막아라.
그래서 일단 정리하자면 azure 의 모든 네트워크 접근제어는 네트워크 단위가 아니라 NSG에서 모두 컨트롤한다.
azure LB사용할땐 가용성 집합을 이용해서 VM을 만든다.
리소스그룹-vpc-subnet-가용성집합-vm-lb 순으로 생성하게 된다.
LB는 베이직과 스텐다드..하 sku 개념이 제일짜증난다.
LB를 베이직으로 생성시에
???같은 가용성 집합인데????
음...이유는 다음에 찾아보기로 하고..
sku 가 스텐다드인경우엔 잘 된다..음 베이직이라 제한이 있는것으로 이해하고 지나가기로 한다.
상태 체크는 로드벨런스 안에서..아니면 zure monitor 을 이용하자.
근데 LB에서 페이지가 뜨는건 잘안됬다 왜지?
그리고 스터디를 마치고 집에와서 백엔드 규칙만 재생성하니 정상적으로 잘됨..뭐야이거..빡치네..
