배포 범위 이해

완료됨

가상 머신, Azure SQL 논리 서버 및 데이터베이스, 스토리지 계정, 가상 네트워크 및 대부분의 다른 Azure 리소스를 리소스 그룹에 배치해야 합니다. 그러나 일부 리소스는 다른 방식으로 배포할 수 있습니다. 이러한 리소스는 일반적으로 Azure 환경의 동작을 제어하는 데 사용됩니다.

이 단원에서는 Azure 리소스 조직 계층 구조를 검토하고 다양한 범위에서 특정 리소스를 배포하는 방법을 살펴봅니다.

Azure 리소스 계층 구조

Azure에는 여러 수준의 관리가 있는 계층적 리소스 구조가 있습니다. 다음은 토이 회사가 Azure 환경을 구성하는 방법을 보여 주는 다이어그램입니다.

Azure 테넌트, 3개의 관리 그룹, 3개의 구독 및 4개의 리소스 그룹을 보여 주는 다이어그램.

귀하의 테넌트는 Microsoft Entra 인스턴스에 해당합니다. 일반적으로 조직에는 Microsoft Entra 인스턴스가 하나만 있습니다. 이 인스턴스는 리소스 계층의 루트 역할을 합니다.

관리 그룹은 Azure 구독을 구성하는 방법을 제공합니다. 각 테넌트에는 단일 루트 관리 그룹이 있으며, 그 아래에 관리 그룹의 고유한 계층 구조를 설정할 수 있습니다. 조직의 다양한 부분 또는 자체 보안 또는 거버넌스 요구 사항이 있는 구독에 대해 별도의 관리 그룹을 만들 수 있습니다. 관리 그룹에 정책 및 액세스 제어 제한을 적용할 수 있으며 계층 구조의 해당 관리 그룹 아래의 모든 구독은 이러한 제한을 상속합니다. 관리 그룹은 지역에 배포되지 않으며 리소스의 위치에 영향을 주지 않습니다.

구독은 청구 계정 역할을 하며 리소스 그룹 및 리소스를 포함합니다. 관리 그룹과 마찬가지로 구독에는 위치가 없으며 리소스가 배포되는 위치를 제한하지 않습니다.

리소스 그룹은 리소스 에 대한 논리적 컨테이너입니다. 리소스 그룹을 사용하면 관련 리소스를 단일 단위로 관리하고 제어할 수 있습니다. 가상 머신, Azure App Service 계획, 스토리지 계정 및 가상 네트워크와 같은 리소스를 리소스 그룹에 배치해야 합니다. 리소스 그룹은 Azure가 그룹의 리소스에 대한 메타데이터를 추적할 수 있도록 위치에 만들어지지만 그룹 내의 리소스는 다른 위치에 배포할 수 있습니다.

앞에서 설명한 예제는 관리 그룹을 사용하는 방법을 보여 주는 매우 기본적인 시나리오입니다. 조직에서는 프로덕션 Azure 환경을 시작하는 데 필요한 Azure 리소스 및 구성 집합인 랜딩 존 구현을 고려할 수도 있습니다. 엔터프라이즈 규모 랜딩 존은 관리 그룹 및 구독을 사용하여 Azure 리소스를 효과적으로 관리하는 검증된 접근 방식입니다.

4개의 관리 그룹과 4개의 구독이 있는 엔터프라이즈 규모의 랜딩 존 아키텍처 다이어그램.

계층 구조의 다양한 수준을 이해하여 따라가는 모델 중에서 Azure 환경을 사용하고 관리하는 방법에 대한 유연한 컨트롤을 적용할 수 있습니다. Bicep을 사용하면 인프라의 모든 이점을 코드로 사용하여 이러한 컨트롤을 관리할 수 있습니다.

비고

특정 범위에 배포되는 다른 리소스도 있습니다. 확장 리소스는 다른 Azure 리소스의 범위에서 배포됩니다. 예를 들어 리소스 잠금은 스토리지 계정과 같은 리소스에 배포되는 확장 리소스입니다.

리소스 그룹에 리소스를 배포하는 데 이미 익숙하므로 배포에 대한 다른 범위를 살펴보겠습니다.

구독 범위 리소스

다음과 같은 경우 구독에 리소스를 배포할 수 있습니다.

  • 새 리소스 그룹을 만들어야 합니다. 리소스 그룹은 실제로 구독 범위 리소스일 뿐입니다.
  • 구독 내의 모든 리소스에 대한 액세스 권한을 부여해야 합니다. 예를 들어 HR 부서에 부서의 모든 Azure 리소스가 포함된 Azure 구독이 있는 경우 HR 부서의 모든 사용자가 구독의 내용을 읽을 수 있도록 역할 할당을 만들 수 있습니다.
  • Azure Policy를 사용하고 있으며 구독 내의 모든 리소스에 정책을 정의하거나 적용하려고 합니다. 예를 들어, 토이 회사의 R&D 부서에서 팀의 구독 내에서 만들 수 있는 가상 머신 SKU 목록을 제한하는 정책을 배포하도록 요청했습니다.

관리 그룹 범위 리소스

다음과 같은 경우 관리 그룹에 리소스를 배포할 수 있습니다.

  • 관리 그룹 계층 구조에 속하는 모든 구독 내의 모든 리소스에 대한 액세스 권한을 부여해야 합니다. 예를 들어 클라우드 운영 팀은 조직의 모든 구독에 액세스해야 할 수 있습니다. 루트 관리 그룹에서 역할 할당을 만들 수 있습니다. 그러면 클라우드 운영 팀이 Azure의 모든 항목에 액세스할 수 있습니다.

    주의

    관리 그룹, 특히 루트 관리 그룹을 사용하여 리소스에 대한 액세스 권한을 부여할 때는 매우 주의해야 합니다. 계층 구조의 관리 그룹 아래에 있는 모든 리소스는 역할 할당을 상속합니다. 조직에서 ID 관리 및 인증에 대한 모범 사례를 따르고 최소 권한 원칙을 따르는지 확인합니다. 즉, 필요하지 않은 액세스 권한을 부여하지 않습니다.

  • 전체 조직에서 정책을 적용해야 합니다. 예를 들어 조직에는 어떤 상황에서도 특정 지역에서 리소스를 만들 수 없다는 정책이 있을 수 있습니다. 해당 지역의 리소스 생성을 차단하는 정책을 루트 관리 그룹에 적용할 수 있습니다.

비고

관리 그룹을 처음으로 사용하기 전에 Azure 환경에 맞게 설정합니다.

테넌트 범위 리소스

다음과 같은 경우 테넌트에 리소스를 배포할 수 있습니다.

  • Azure 구독을 만들어야 합니다. 관리 그룹을 사용하는 경우 구독은 리소스 계층 구조의 관리 그룹 아래에 있지만 구독은 테넌트 범위 리소스로 배포됩니다.

    비고

    모든 Azure 고객이 인프라를 코드로 사용하여 구독을 만들 수 있는 것은 아닙니다. Microsoft와의 청구 관계에 따라 불가능할 수 있습니다. 자세한 내용은 프로그래밍 방식으로 Azure 구독 만들기를 참조하세요.

  • 관리 그룹을 만들거나 구성하고 있습니다. Azure는 테넌트에 대해 관리 그룹을 사용하도록 설정할 때 단일 루트 관리 그룹을 만들고 그 아래에 여러 수준의 관리 그룹을 만들 수 있습니다. Bicep을 사용하여 전체 관리 그룹 계층 구조를 정의할 수 있습니다. 관리 그룹에 구독을 할당할 수도 있습니다.

    Bicep을 사용하면 테넌트 범위에 배포를 제출할 수 있습니다. 테넌트 범위 배포에는 특별한 권한이 필요합니다. 그러나 실제로는 테넌트 범위 배포를 제출할 필요가 없습니다. 다른 범위의 템플릿을 사용하여 테넌트 범위 리소스를 배포하는 것이 더 간단합니다. 이 모듈의 뒷부분에서 이 작업을 수행하는 방법을 확인할 수 있습니다.

    팁 (조언)

    테넌트 범위에서는 정책 또는 역할 할당을 만들 수 없습니다. 그러나 전체 조직에서 액세스 권한을 부여하거나 정책을 적용해야 하는 경우 이러한 리소스를 루트 관리 그룹에 배포할 수 있습니다.

리소스 ID

지금까지 구독 내에 있는 리소스의 리소스 ID에 대해 잘 알고 있습니다. 예를 들어 구독 범위 리소스인 리소스 그룹을 나타내는 리소스 ID는 다음과 같습니다.

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/ToyDevelopment

동일한 정보의 시각적 표현은 다음과 같습니다.

리소스 그룹에 대한 리소스 ID의 스크린샷

구독 자체에는 다음과 같은 ID가 있습니다.

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e

비고

구독은 관리 그룹의 자식으로 간주되지만 해당 리소스 ID에는 관리 그룹 ID가 포함되지 않습니다. Azure는 다른 리소스 관계와 다른 방식으로 구독과 관리 그룹 간의 관계를 추적합니다. 이렇게 하면 모든 리소스 ID를 변경하지 않고도 관리 그룹 간에 구독을 유연하게 이동할 수 있습니다.

관리 그룹 또는 테넌트 범위에서 리소스를 사용하는 경우 리소스 ID는 정상과 약간 다르게 보일 수 있습니다. 주로 특정 리소스에 대한 정보와 리소스 유형을 섞는 일반적인 패턴을 따릅니다. 그러나 특정 형식은 작업 중인 리소스에 따라 달라집니다.

관리 그룹에 대한 예제 리소스 ID는 다음과 같습니다.

/providers/Microsoft.Management/managementGroups/ProductionMG

다음과 같은 모양입니다.

관리 그룹의 리소스 ID 스크린샷

비고

관리 그룹에는 식별자와 표시 이름이 모두 있습니다. 표시 이름은 관리 그룹에 대한 사람이 읽을 수 있는 설명입니다. 관리 그룹의 ID에 영향을 주지 않고 표시 이름을 변경할 수 있습니다.

리소스가 관리 그룹 범위에 배포되면 해당 리소스 ID에는 관리 그룹 ID가 포함됩니다. 다음은 관리 그룹 범위에서 만든 역할 정의에 대한 예제 리소스 ID입니다.

/providers/Microsoft.Management/managementGroups/ProductionMG/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000

동일한 ID의 시각적 표현은 다음과 같습니다.

관리 그룹 범위에 배포된 역할 정의에 대한 리소스 ID의 스크린샷

다른 역할 정의는 구독 범위에서 정의될 수 있으므로 리소스 ID는 약간 다르게 보입니다.

/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/providers/Microsoft.Authorization/roleDefinitions/00000000-0000-0000-0000-000000000000

동일한 ID의 시각적 표현은 다음과 같습니다.

구독 범위에 배포된 역할 정의에 대한 리소스 ID의 스크린샷

이제 Azure 리소스 계층 구조와 각 범위에서 배포할 수 있는 리소스 유형을 이해했으므로 리소스를 배포할 범위에 대한 결정을 내릴 수 있습니다. 예를 들어 리소스 그룹, 구독 또는 관리 그룹의 범위에서 정책 정의를 만들어야 하는지 여부에 대해 정보에 입각한 선택을 할 수 있습니다. 다음 단원에서는 이러한 각 범위를 대상으로 하는 Bicep 파일을 만드는 방법을 알아봅니다.