3. Azure 4가지 범위 (Resource 위주)

Azure Platform에서 Resource는 Azure를 통해서 관리가 가능한 Service 및 Application을 의미합니다.

Resource Group하는 Resource Group은 가장 기본이 되는 요소입니다..

오늘은 이 Resource와 Resource Group이 포함되어 있는 4가지 범위에 대해서 살펴보겠습니다.

 

1. Azure의 4가지 범위

Azure 범위

2. Resource 

 2.1. Azure 통해서 사용할 수 있으며 관리 가능한 항목을 의미합니다.

 2.3. VM(가상머신), Storage Account, Web App, Database, Vnet(가상네트워크 )등 입니다.

 

728x90

 

3. Resource Group

 3.1. 특징

  3.1.0. Azure Platform 기본 요소 입니다.

  3.1.1. Azure Solution과 관련된 Resource를 보관하는 논리적인 Container를 의미합니다.

  3.1.2. Group으로 관리하려는 Resource만 포함됩니다.

  3.1.3. 조직에 대한 적합성을 기반으로 Resource Group에 속할 Resource를 결정하게 됩니다.

  3.1.4. 모든 Resource는 Resource Group내에 존재, 하나의 Resource는 반드시 단일 Resource Group의 멤버입니다.

  3.1.5. Resource Group간 이동이 가능하나 하나 이상의 Resource그룹에 중첩해서 속할 수는 없습니다.

  3.1.6. Resocuce를 Provision하기 전에 반드시 Resource Group이 존재해야 합니다.

 3.2. Resource Group 유형

  3.2.1. 논리 그룹화

   3.2.1.1. 동일한 그룹에 리소스 배치 : 사용량, 형식, 위치가 비슷한 리소스

   3.2.1.2. 리소스에 질서를 부여하고 체계적으로 구성가능

논리 그룹

  3.2.2. 수명 주기

   3.2.2.1 리소스 그룹을 삭제하면 내부의 모든 리소스 삭제

   3.2.2.2 테스트 후 리소스를 폐기하는 개발 및 테스트 환경에 유요

   3.2.2.3. 리소스 세트를 한꺼번에 간편하게 제거 가능

수명 주기

  3.2.3. 권한 부여 

   3.2.3.1. RBAC(역할기반 액세스제어)권한 적용 범위

   3.2.3.2. 리소스 그룹에 RBAC권한 적용시 편리한 관리 가능

   3.2.3.3. 필요 리소스만 사용하도록 액세스 제한 가능

 3.3. Resource Manager

  3.3.1. Azure 배포 및 관리 서비스

  3.3.2. Azure 계정에서 Resource 생성, 업데이트, 삭제할 수 있는 관리계층 제공

  3.3.3. Resource 보호 및 구성 : Access Control, locked, Tag등의 관리 기능 제공

Resource Mananger

 3.4. Resource Manager 사용 이점

  3.4.1. 선언적 템플릿을 통한 인프라 관리

   3.4.1.1. json : 배포 및 정의

  3.4.2. 모든 리소스를 그룹으로 배포, 관리, 모니터링 가능

  3.4.3. Resource의 올바른 배포를 위한 Resource 간 종속성 정의

  3.4.4. 모든 서비스에 액세스 제어 적용

   3.4.4.1. RBAC가 기본적으로 관리 템플릿에 통합

  3.4.5. Resource Tag를 적용하여 모든 Resource를 논리적으로 구성 

  3.4.6. 동일 Tag -> Resource Group 비용확인 -> 조직의 청구를 명확하게 함.

 

4. Azure 구독

 4.1. 특징

  4.1.1. Azure 사용시 반드시 Azure 구독 필요 - 과금

  4.1.2. Azure 제품 및 서비스에 대한 인증과 권한이 부여된 액세스 기능 제공

  4.1.3. Azure Active Directory ( Azuer AD : AAD ) 또는 Azure AD Trust Directory에 있는 ID인 Azure 계정과 연결된 Azure Service의 논리적인 단위.

  4.1.4. Azure 계정에는 하난 또는 그 이상 구독 존재 : Resource 생성 시 선택

  4.1.5. 구독이 여러개인 경우 각기 다른 청구 모델이 존재

Azure 구독

 4.2. 구독 경계의 2가지 유형

  4.2.1. 청구경계

   4.2.1.1. Azure 사용에 따른 Azure 계정 청구 방식 결정

   4.2.1.2. 청구 요구 사항에 따른 여러개의 구독 생성 가능

   4.2.1.3. 각 구독에 별도의 청구서 및 송장 생성

  4.2.2. 액세스 제어 경계 

   4.2.2.1. 비즈니스 내에서 여러 부서에 대한 별도의 구독 정책 적용

   4.2.2.2. 특정 구독으로 사용자가 프로비전하는 Resource에 대한 Access Control

 

5. 관리그룹

 5.1. 특징

  5.1.1. 구독이 많은 경우 해당 구독에 대한 액세스, 정책 및 규정준수를 효율적으로 관리하는 방법 제공

  5.1.2. 구독 상위의 범위 수준에서 제공

  5.1.3. 관리그룹이라는 컨테이너에 구독을 구성하고, 거버너스 조건을 관리 그룹에 적용하여 구독에 자동으로 상속

  5.1.4. 단일 그룹내의 모든 구독은 동일한 Azure AD 테넌트를 신뢰

관리 그룹

 5.2. 관리 그룹 및 구독의 계증 구조

  5.2.1. 관리 그룹

   5.2.1.1. 단일 디렉토리에 10,000 관리 그룹 제공

   5.2.1.2. 관리 수준 트리는 6개 수준까지 지원, 단 Root 수준 및 구독 수준은 포함되지 않음 8개 수준

   5.2.1.3. 각 관리 그룹 및 구독은 하나의 부모만 존재

   5.2.1.4. 각 관리 그룹은 여러개의 자식 항목 포함

  5.2.2. 예시) 프로덕션 그룹에 VM의 위치를 한국 중부로 지정, 하위 EA 구독에 상속되고 해당 구독에 속한 모든 VM에 적용

 

조금은 낯설고 힘이 드는 개념 정리입니다.

하지만 지금 개념 정립을 하지 않으면 과금 및 상속에 대한 제어가 불가능하기에 꼭 익혀 두셔야 합니다.

하나하나 작업을 진행하다보면 고개가 절로 끄덕여 집니다.

MS가 이런 계증 및 과금에는 강합니다. 그게 Active Directory 자체 임으로.....

 

Have a nice day!