Azure 랜딩 존에 대한 ISV(Independent Software Vendor) 고려 사항을 검토합니다.

  • 아티클

많은 조직에서 Azure 랜딩 존 개념 아키텍처는 클라우드 채택 과정의 대상을 나타냅니다. 랜딩 존은 여러 구독을 사용하여 Azure 환경을 빌드하는 방법을 설명합니다. 각 랜딩 존은 규모, 보안, 거버넌스, 네트워킹, ID를 고려하며 많은 고객으로부터 얻은 피드백과 교훈을 기반으로 합니다.

팁

Azure 랜딩 존을 도시 계획과 같다고 생각하는 것이 도움이 될 수 있습니다. 랜딩 존에 배포된 워크로드의 아키텍처는 도시 내 건물 계획과 같습니다.

건물을 건설하기 전에 도시의 물, 가스, 전기, 운송 시스템이 모두 마련되어 있어야 합니다. 마찬가지로 관리 그룹, 정책, 구독, RBAC(역할 기반 액세스 제어)를 비롯한 Azure 랜딩 존의 구성 요소는 프로덕션 워크로드를 배포하기 전에 모두 준비되어야 합니다.

Azure에서 솔루션을 빌드하고 운영하는 ISV(독립 소프트웨어 공급업체)는 Azure 환경을 빌드할 때 다음 리소스를 참조해야 합니다.

Azure 랜딩 존은 전체 Azure 환경의 방향을 선택하는 데 도움이 됩니다. 그러나 ISV, SaaS 공급자 또는 스타트업에서는 특정 구현 요구 사항이 더 많은 표준 고객 시나리오와 다를 수 있습니다. 다음은 몇 가지 구현 시나리오 예제입니다.

  • 고객이 자신의 구독에 배포하는 소프트웨어를 빌드합니다.
  • 사용자 고유 의 컨트롤 플레인 을 사용하고 자동화 스크립트 또는 소프트웨어를 사용하여 SaaS 솔루션에 대한 Azure 리소스를 배포하고 구성합니다.
  • 소규모 ISV 또는 스타트업이고 가능한 가장 낮은 비용으로 시작하려고 하며, 처음에는 Azure Firewall 및 Azure DDoS Protection과 같은 서비스를 사용하지 않을 수 있습니다.
  • 대규모 SaaS ISV이며 규모에 맞게 여러 구독에 SaaS 애플리케이션을 분할할 계획입니다. 또한 개발, 테스트, 스테이징, 프로덕션 환경에 해당하도록 구독을 그룹화하려고 합니다.
  • 조직의 운영 모델은 회사 IT 팀과 SaaS 제품 팀의 역할을 구분합니다. 조직의 회사 IT 팀은 Microsoft Office 365 및 Microsoft Teams와 같은 리소스를 관리할 수 있으며, SaaS 제품 팀은 SaaS 제품(중앙 플랫폼 및 ID 구성 요소 포함)을 빌드하고 운영하는 역할을 담당할 수 있습니다.

참고 항목

경우에 따라 ISV는 플랫폼 “공유 서비스” 측면과 실제 워크로드 리소스를 모두 포함하는 단일 Azure 구독으로 시작하려고 합니다. 기술적으로 가능하지만 나중에 구독 간에 리소스를 이동하고 일부 리소스 유형을 이동할 수 없는 경우 문제가 발생합니다. 디자인 편차의 영향을 검토하여 가능한 편차와 다양한 위험 수준을 이해합니다.

ISV 배포 모델

ISV 솔루션은 순수 SaaS, 고객 배포 또는 이중 배포 SaaS의 세 가지 배포 모델 중 하나에 적합한 경우가 많습니다. 이 섹션에서는 Azure 랜딩 존에 대한 각 모델의 다양한 고려 사항에 대해 설명합니다.

순수 SaaS

순수 SaaS 모델에서 소프트웨어는 Azure 구독에만 완전히 배포됩니다. 최종 고객은 자신의 Azure 구독에 배포하지 않고 소프트웨어를 사용합니다. 다음 다이어그램에서 사용자는 ISV에서 제공하는 순수 SaaS 애플리케이션을 사용합니다.

Diagram that shows a pure SaaS deployment model. A user directly uses the application deployed into the I S V's Azure subscription.

순수 SaaS 소프트웨어의 예로는 EAAS(Email as a Service), Kafka-as-a-service, cloud-data-warehouse-as-a-service 및 Azure Marketplace의 많은 SaaS 목록이 있습니다.

소규모 SaaS ISV인 경우 리소스를 즉시 배포하기 위해 여러 Azure 구독을 사용하지 않아도 될 수 있습니다. 그러나 크기를 조정하면 Azure의 구독 제한은 단일 구독 내에서 크기를 조정하는 기능에 영향을 줄 수 있습니다. 엔터프라이즈급 랜딩 존 디자인 원칙, 특히 구독 민주화를 검토하고 향후 성장을 계획할 수 있도록 다중 테넌트 아키텍처 접근 방식을 숙지합니다.

순수 SaaS 솔루션을 빌드하는 ISV는 다음 질문을 고려해야 합니다.

  • SaaS 솔루션을 구성하는 모든 Azure 리소스가 하나의 Azure 구독에 있어야 하나요, 아니면 여러 Azure 구독에 분할되어 있어야 하나요?
  • 각 고객을 고유한 전용 Azure 구독에 호스트해야 하나요, 아니면 하나 또는 몇 개의 공유 구독 내에서 리소스를 만들 수 있나요?
  • 배포 스탬프(배율 단위) 패턴을 솔루션의 모든 계층에 적용하려면 어떻게 해야 하나요?
  • 다중 테넌트 솔루션에서 Azure 리소스 조직을 사용하여 규모 문제 및 Azure 구독 제한 문제에 직면하지 않도록 하려면 어떻게 해야 하나요?

고객 배포

고객이 배포한 모델에서 최종 고객은 사용자로부터 소프트웨어를 구매한 다음, 자체 Azure 구독에 배포합니다. Azure Marketplace에서 배포를 시작하거나 지침에 따라 제공한 스크립트를 사용하여 수동으로 배포를 시작할 수 있습니다.

다음 다이어그램에서 ISV는 소프트웨어 패키지 또는 Azure Marketplace 카탈로그 제품을 제공하며, 사용자는 해당 리소스를 다른 워크로드와 함께 자체 Azure 구독에 배포합니다.

Diagram that shows a customer-deployed deployment model. A customer deploys resources provided by the ISV into their own Azure subscription, and users use those resources.

다이어그램에 있는 고객의 다른 워크로드 요소는 고객의 워크로드 또는 고객이 Azure 구독 내에서 배포한 다른 ISV 제품을 나타낼 수 있습니다. 고객은 다양한 ISV의 여러 제품을 Azure 구독에 배포하는 경우가 많습니다. 이러한 개별 제품을 결합하여 솔루션을 만듭니다. 예를 들어 고객은 한 ISV의 데이터베이스 제품, 다른 ISV의 네트워크 가상 어플라이언스, 세 번째 ISV의 웹 애플리케이션을 배포할 수 있습니다.

고객이 배포한 ISV 제품의 예로는 Azure Marketplace의 많은 가상 머신 이미지(예: 네트워크 및 스토리지 가상 어플라이언스)와 Azure 애플리케이션이 있습니다.

일부 고객 배포 솔루션의 경우 조직은 Azure Lighthouse 또는 Azure Managed Applications를 사용하여 최종 고객의 Azure 구독 내에 배포된 솔루션을 관리하고 업데이트를 제공할 수 있습니다. ISV, SIS(솔루션 통합자), MSP(관리 서비스 공급자)는 모두 특정 요구 사항을 충족할 때 이 전략을 사용할 수 있습니다.

고객이 배포한 ISV 솔루션은 Azure 랜딩 존의 관점에서 표준 애플리케이션 워크로드로 간주됩니다. Azure 고객이 채택하는 Azure 랜딩 존 디자인 원칙에 맞게 제품을 디자인할 때는 Azure 랜딩 존 지침을 고려합니다.

기존 고객의 워크로드를 Azure로 마이그레이션할 때 Azure 랜딩 존 개념을 잘 이해하는 것이 특히 중요합니다.

고객이 배포한 솔루션을 빌드하는 ISV는 다음 질문을 고려해야 합니다.

  • 고객은 자체 전용 구독에 솔루션을 배포해야 하나요, 아니면 관련 워크로드가 포함된 기존 구독에 솔루션을 배포해야 하나요?
  • 고객은 기존 워크로드(Azure 내부 및 외부)와 솔루션 간에 네트워크 연결을 설정해야 하나요?
  • 솔루션이 Microsoft Entra ID의 인증 메커니즘을 지원하나요 아니면 LDAP 또는 Kerberos와 같은 다른 프로토콜이 필요한가요?
  • 솔루션 템플릿과 고객의 Azure 정책 간의 충돌로 인한 위반과 같은 Azure Policy 위반을 줄이거나 제거하려면 어떻게 해야 하나요?

Azure Policy를 위반할 수 있는 고객 Azure 정책에는 “모든 서브넷에 네트워크 보안 그룹이 있어야 함” 및 “공용 IP 주소를 Corp 랜딩 존의 네트워크 인터페이스에 연결할 수 없음”과 같은 예제가 포함됩니다. 배포를 계획할 때 이러한 충돌을 일으키는 정책의 가능성을 염두에 두어야 합니다.

이중 배포 SaaS

일부 SaaS 솔루션은 고객의 Azure 구독에 배포된 리소스와 상호 작용하거나 이 리소스를 사용합니다. 이 배포 모델을 이중 배포 SaaS 또는 SaaS 하이브리드라고도 합니다. 다음 다이어그램에서 ISV는 최종 고객의 Azure 구독에 배포된 리소스와 상호 작용하는 호스트된 SaaS 솔루션을 제공합니다.

Diagram that shows a dual deployment SaaS deployment model.

이중 배포 SaaS의 실제 예는 고객의 Azure 구독에서 가상 머신에 배포된 Power BI 온-프레미스 데이터 게이트웨이를 선택적으로 사용할 수 있는 SaaS 서비스인 Microsoft Power BI입니다.

이중 배포 SaaS 시나리오의 다른 예는 다음과 같습니다.

  • 조직은 각 고객의 Azure 구독에서 Azure Virtual Desktop 리소스를 제어하는 SaaS 콘솔 인터페이스를 제공하는 제품인 Virtual Desktop Manager를 빌드합니다.
  • 조직은 데이터 분석을 위한 SaaS 콘솔을 제공하며, 각 고객의 Azure 구독에서 컴퓨팅 노드 가상 머신을 동적으로 만들고 삭제합니다.

이중 배포 ISV는 다음과 같은 두 가지 영역의 지침에 대해 Azure 랜딩 존을 참조해야 합니다. SaaS 서비스를 호스트하도록 고유한 Azure 환경을 구성하는 영역과 고객의 Azure 구독과 고객의 랜딩 존 배포 간에 적절한 상호 작용을 보장하는 영역입니다.

이중 배포 SaaS 솔루션을 빌드하는 ISV는 다음 질문을 고려해야 합니다.

  • 순수 SaaS 및 고객 배포 솔루션을 모두 빌드하기 위한 모든 고려 사항을 검토했나요?
  • Azure 구독에서 호스트해야 하는 솔루션의 구성 요소와 고객이 배포해야 하는 구성 요소는 무엇인가요?
  • 고객의 Azure 구독에 배포된 리소스와의 상호 작용 및 보안 프로비전을 어떻게 보장할 수 있나요?

Azure 랜딩 존 디자인 원칙 및 구현

Azure의 랜딩 존 디자인 원칙은 Log Analytics, Azure Monitor, Azure Firewall과 같은 Azure 네이티브 플랫폼 기능에 부합하는 것이 좋습니다. 랜딩 존 지침은 특정 Azure 랜딩 존 구현 옵션도 제공합니다.

ISV는 고유한 랜딩 존 환경을 구현하기로 결정할 수 있습니다. 구독 간에 Azure 리소스를 배포하려면 사용자 고유의 자동화를 사용해야 할 수 있습니다. 또는 로깅, 모니터링, 기타 플랫폼 계층 서비스에 이미 사용하는 도구를 계속 사용할 수 있습니다.

고유한 랜딩 존 환경을 구현하는 경우 참조를 위해 Azure 랜딩 존 지침 및 샘플 구현을 사용하고 검증된 Azure 랜딩 존 디자인에 맞게 접근 방식을 조정하는 것이 좋습니다.

Microsoft Entra 테넌트

각 Azure 랜딩 존 및 해당 관리 그룹 계층 구조는 단일 Microsoft Entra 테넌트에 뿌리를 두고 있습니다. 즉, Azure 리소스를 관리하기 위한 ID 원본으로 사용할 Microsoft Entra 테넌트가 먼저 결정해야 합니다. Microsoft Entra ID의 ID에는 사용자, 그룹 및 서비스 주체가 포함됩니다.

팁

랜딩 존에 대해 선택한 Microsoft Entra 테넌트는 애플리케이션 수준 인증에 영향을 주지 않습니다. 선택한 테넌트에 관계없이 Azure AD B2C와 같은 다른 ID 공급자는 계속 사용할 수 있습니다.

Azure 랜딩 존 및 Microsoft Entra 테넌트에 대한 지침은 단일 Microsoft Entra 테넌트를 사용하는 것이 강력히 권장되며 이는 대부분의 경우에 올바른 방법입니다. 그러나 SaaS ISV인 경우 두 개의 테넌트만 사용해야 할 수 있습니다.

일부 SaaS ISV의 경우 한 팀이 회사 리소스를 관리하고 별도의 팀이 SaaS 솔루션을 운영합니다. 이러한 분리는 운영상의 이유 또는 규정 요구 사항을 준수하기 위한 것일 수 있습니다. 회사 IT 팀은 SaaS 관련 구독 및 리소스를 관리할 수 없으므로 Microsoft Entra 테넌트의 관리자가 될 수 없습니다. 이 시나리오가 적용되는 경우 Office 365와 같은 회사 IT 리소스에 대한 테넌트 하나와 SaaS 솔루션을 구성하는 Azure 리소스에 대한 테넌트 1개 등 별도의 Microsoft Entra 테넌트 두 가지를 사용하는 것이 좋습니다.

각 Microsoft Entra 테넌트에는 고유한 do기본 이름이 있어야 합니다. 조직에서 두 개의 테넌트를 사용하는 경우 다음 다이어그램과 같이 contoso.com 회사 Microsoft Entra 테넌트 및 contoso-saas-ops.com SaaS Microsoft Entra 테넌트의 이름을 선택할 수 있습니다.

Diagram that shows Microsoft Entra tenant options for ISVs with a single corporate tenant or separation between corporate and SaaS Ops tenants.

Warning

여러 Microsoft Entra 테넌트 사용 시 관리 오버헤드가 증가합니다. Privileged Identity Management와 같은 Microsoft Entra ID P1 또는 P2 기능을 사용하는 경우 각 Microsoft Entra 테넌트에 대한 개별 라이선스를 구매해야 합니다. 상황에 따라 필요한 경우 여러 Microsoft Entra 테넌트만 사용하는 것이 가장 좋습니다.

사전 프로덕션 및 프로덕션 환경에 별도의 Microsoft Entra 테넌트는 사용하지 마세요. 각각에 별도의 Azure 구독과 contoso-saas-ops-prod.com 같은 contoso-saas-ops-preprod.com 두 개의 테넌트가 생성되는 대신 하나의 Microsoft Entra 테넌트만 만들어야 합니다. 관리 그룹 및 Azure RBAC를 사용하여 이 단일 테넌트에서 구독 및 리소스에 대한 액세스를 제어할 수 있습니다.

여러 Microsoft Entra 테넌트 사용에 대한 자세한 내용은 Azure 랜딩 존 및 여러 Microsoft Entra 테넌트 및 Microsoft Entra 백서로 Azure 환경 보안을 참조하세요.

관리 그룹

Azure 랜딩 존 개념 아키텍처는 특정 관리 그룹 계층 구조를 사용하는 것이 좋습니다. 그러나 ISV는 다른 조직과 다른 요구 사항을 가질 수 있습니다. 이 섹션에서는 ISV 조직이 랜딩 존 개념 아키텍처에서 권장하는 것과는 다른 방식을 채택하도록 선택할 수 있는 몇 가지 방법을 설명합니다.

최상위 관리 그룹

관리 그룹 계층 구조는 Azure에서 만든 테넌트 루트 그룹 관리 그룹 아래에 중첩됩니다. 테넌트 루트 그룹은 직접 사용하지 않습니다.

플랫폼 및 공유 서비스(예: 로깅, 네트워킹, ID, 보안)를 관리하는 중앙 집중식 회사 IT 팀이 있는 표준 조직은 일반적으로 Azure에서 만든 테넌트 루트 그룹 아래에 하나의 최상위 관리 그룹을 만들고 그 아래에 나머지 관리 그룹을 배포합니다. 이 최상위 관리 그룹은 일반적으로 조직 자체(예: Contoso)의 이름을 따서 명명됩니다.

SaaS ISV에는 하나의 SaaS 제품이 있거나 몇 가지 별도 SaaS 제품 또는 사업 부문이 있을 수 있습니다. 일반적으로 동일한 Microsoft Entra 테넌트에서 모든 제품(Microsoft Entra 테넌트 섹션에서 설명한 대로)에서 Azure 리소스를 관리해야 하지만, 일부 시나리오에서는 여러 관리 그룹 계층 구조를 배포하도록 선택할 수 있습니다.

제품이 서로 얼마나 독립적인지 생각해 보고, 다음을 확인해 보세요.

  • 제품이 모두 DevOps, ID, 보안, 연결, 로깅에 동일한 플랫폼을 사용하나요?
  • 이러한 공유 서비스는 단일 중앙 팀에서 운영하나요?

두 질문에 모두 '예'라고 대답한 경우 테넌트 루트 그룹 아래에 단일 최상위 SaaS 제품 관리 그룹을 만듭니다.

대신 아니요로 응답하고 각 SaaS 제품이 별도의 플랫폼 팀에서 관리 및 운영되는 경우 두 개의 최상위 관리 그룹인 SaaS Product-01 및 SaaS Product-02와 같이 각 제품에 대해 별도의 최상위 관리 그룹을 만드는 것이 좋습니다.

팁

한 ISV에 몇 개의 최상위 관리 그룹 이상이 있는 것은 드문 일입니다. 관리 및 운영 방식의 유사성으로 인해 여러 제품을 함께 결합하는 경우도 있을 수 있습니다.

이 관리 접근 방식은 엔터프라이즈급 랜딩 존에 대한 테스트 접근 방식과 유사합니다. 그러나 이 접근 방식에서는 테넌트 루트 그룹 아래에 Contoso 및 Contoso-Canary를 만드는 대신 예제 회사에서는 테넌트 루트 그룹 아래에 제품별 Contoso-SaaS-Product-01, Contoso-SaaS-Product-02, Contoso-SaaS-Product-03 최상위 관리 그룹을 만듭니다. 이 시나리오는 다음 다이어그램에서 설명합니다.

Diagram that shows top-level management group options with a single management group and separate management groups for each of the SaaS products

플랫폼 관리 그룹

Azure 랜딩 존 리소스 조직 계층 구조에서 플랫폼 관리 그룹에는 랜딩 존 구독의 워크로드에서 사용하는 구성 요소 및 공유 서비스를 호스트하는 모든 Azure 구독이 포함됩니다. 플랫폼 및 공유 서비스 구독에 배포된 구성 요소의 예로는 중앙 집중식 로깅 인프라(예: Log Analytics 작업 영역), DevOps, 보안, 자동화 도구, 중앙 네트워킹 리소스(예: 허브-VNet 및 DDos Protection 계획), ISV의 컨트롤 플레인 서비스가 있습니다.

플랫폼 관리 그룹은 기업 고객에게 역할과 정책을 편리하게 분리할 수 있도록 ID, 관리, 연결 자식 그룹으로 분할되는 경우가 많습니다.

조직에는 ID, 네트워킹, 관리와 같은 모든 공유 플랫폼 구성 요소를 관리하는 단일 팀이 있을 수 있습니다. 단일 팀이 있는 경우 여러 팀에서 해당 관리를 분리할 계획이 없는 경우 단일 플랫폼 관리 그룹을 사용하는 것이 좋습니다.

또는 중앙 집중식 플랫폼의 여러 부분을 관리하는 별도의 팀이 있는 경우 플랫폼 관리 그룹의 관리 그룹 계층 구조에 추가 수준을 배포해야 합니다. 이렇게 하면 중앙 집중식 플랫폼의 각 부분에 대해 별도의 정책을 할당할 수 있습니다.

다음 다이어그램에서는 플랫폼 관리 그룹의 두 가지 잠재적 구현을 보여 줍니다. 옵션 A는 플랫폼 관리 그룹에 관리 및 DevOps, ID 및 보안, 연결이라는 세 개의 자식 관리 그룹이 포함된 보다 포괄적인 시나리오를 보여 줍니다. 각 자식 관리 그룹에는 관련 리소스가 있는 구독이 포함됩니다. 옵션 B는 플랫폼 관리 그룹에 단일 플랫폼 구독이 포함된 보다 간단한 시나리오를 보여 줍니다.

Diagram that shows two management group hierarchies. Option A shows separate platform management groups for management, connectivity, and identity. Option B includes a platform management group option with a single management group.

랜딩 존 관리 그룹

랜딩 존 관리 그룹에는 SaaS 솔루션의 실제 하위 시스템 및 워크로드를 호스트하는 Azure 구독이 포함되어 있습니다.

이 관리 그룹에는 하나 이상의 자식 관리 그룹이 포함되어 있습니다. 랜딩 존 아래의 각 자식 관리 그룹은 모든 구독에 적용해야 하는 일관된 정책 및 액세스 요구 사항을 포함하는 워크로드 또는 하위 시스템 원형을 나타냅니다. 여러 원형을 사용하는 이유는 다음과 같습니다.

  • 규정 준수: SaaS 제품의 하위 시스템이 PCI-DSS 규격이어야 하는 경우 랜딩 존 아래에 PCI DSS 원형 자식 관리 그룹을 만드는 것이 좋습니다. PCI-DSS 규정 준수 범위 내에 있는 리소스를 포함하는 모든 Azure 구독은 해당 관리 그룹 내에 배치되어야 합니다.
  • 계층: SaaS 솔루션의 전용 계층 고객 및 무료 계층 고객을 위한 별도의 랜딩 존 아키타입을 만드는 것이 좋습니다. 각 자식 관리 그룹에는 서로 다른 Azure Policy 설정이 포함되어 있습니다. 예를 들어 무료 계층의 정책은 특정 가상 머신 SKU만 사용하도록 배포를 제한할 수 있으며 전용 계층의 정책에 따라 리소스를 특정 지역에 배포해야 할 수 있습니다.

환경별 관리 그룹

SaaS ISV는 소프트웨어 개발 수명 주기 환경을 순서대로 모델링하여 클라우드 환경을 구성하는 경우가 많습니다. 이를 위해서는 일반적으로 먼저 개발 환경, 테스트 환경, 스테이징 환경, 마지막으로 프로덕션 환경에 배포해야 합니다.

환경 간의 일반적인 차이점 중 하나는 각 구독 그룹에 액세스할 수 있는 사용자와 같은 Azure RBAC 규칙입니다. 예를 들어 DevOps, SaaSOps, 개발, 테스트 팀은 모두 서로 다른 환경에 대한 액세스 수준이 다를 수 있습니다.

Important

대부분의 Azure 고객은 수백 개의 애플리케이션을 가지고 있으며 각 애플리케이션 팀에 대해 별도의 Azure 구독을 사용합니다. 각 애플리케이션에 자체 개발, 테스트, 스테이징, 프로덕션 관리 그룹이 있는 경우 거의 동일한 정책을 가진 많은 관리 그룹이 있을 것입니다. 대부분의 고객의 경우 엔터프라이즈급 랜딩 존 FAQ에서는 각 환경에 대해 별도의 관리 그룹을 사용할 것을 권장합니다. 대신 단일 관리 그룹 내에서 별도의 구독을 사용하는 것이 좋습니다.

그러나 SaaS ISV는 대부분의 다른 Azure 고객과 다른 요구 사항을 가질 수 있으며, 경우에 따라 환경별 관리 그룹을 사용해야 할 충분한 이유가 있을 수 있습니다.

SaaS ISV는 동일한 하위 시스템, 애플리케이션 또는 워크로드의 분할된 데이터베이스 또는 파티션을 나타내는 여러 구독을 그룹화해야 하는 경우가 있습니다. 원형 관리 그룹과는 다른 방식으로 구독 그룹에 정책 또는 역할 할당을 적용해야 할 수 있습니다. 이 경우 원형 관리 그룹 아래에 각 환경에 해당하는 자식 관리 그룹을 만드는 것이 좋습니다.

다음 다이어그램에서는 두 가지 잠재적 옵션을 보여 줍니다. 옵션 A는 각 환경에 대해 별도의 구독이 있지만 환경별 관리 그룹이 없는 시나리오를 보여 줍니다. 옵션 B는 일반 스탬프 관리 그룹에서 환경별 관리 그룹이 있는 SaaS ISV 시나리오를 보여 줍니다. 각 환경별 관리 그룹에는 여러 구독이 포함됩니다. 시간이 지남에 따라 ISV는 정책 및 역할 할당의 공통 집합을 사용하여 점점 더 많은 구독에 걸쳐 각 환경에서 Azure 리소스의 크기를 조정합니다.

각 탭을 선택하여 두 다이어그램을 확인합니다.

서비스 해제된 관리 그룹과 샌드박스 관리 그룹

Azure 랜딩 존 리소스 조직 지침에서는 최상위 관리 그룹 바로 아래에 서비스 해제된 관리 그룹과 샌드박스 관리 그룹을 포함하도록 권장합니다.

서비스 해제된 관리 그룹은 사용하지 않도록 설정되고 결국 삭제되는 Azure 구독에 대한 보류 위치입니다. 더 이상 사용되지 않는 구독을 이 관리 그룹으로 이동하여 구독의 모든 리소스가 영구적으로 삭제될 때까지 추적할 수 있습니다.

샌드박스 관리 그룹에는 일반적으로 탐색 목적으로 사용되며 정책이 느슨하거나 적용되지 않은 Azure 구독이 포함됩니다. 예를 들어 개발 및 테스트를 위해 개별 개발자에게 자체 구독을 제공할 수 있습니다. 샌드박스 관리 그룹에 배치하여 이러한 구독에 일반 정책 및 거버넌스를 적용하지 않도록 할 수 있습니다. 이렇게 하면 개발자의 민첩성이 증가하고 Azure를 쉽게 실험할 수 있습니다.

Important

샌드박스 관리 그룹의 구독은 랜딩 존 구독에 직접 연결되지 않아야 합니다. 프로덕션 워크로드 또는 프로덕션 환경을 미러링하는 비 프로덕션 환경에 샌드박스 구독을 연결하지 마세요.

다음 다이어그램에서는 두 가지 잠재적 옵션을 보여 줍니다. 옵션 A에는 서비스 해제된 관리 그룹과 샌드박스 관리 그룹이 포함되지 않지만 옵션 B는 그렇지 않습니다.

Diagram that shows the Decommissioned and Sandboxes management groups on the same level as the Platform and Landing Zones management groups.

ISV 랜딩 존 예제

이 섹션에는 SaaS ISV에 대한 두 가지 예제 Azure 랜딩 존 구조가 포함되어 있습니다. 각 탭을 선택하여 두 개의 랜딩 존 예제를 비교합니다.

다음 다이어그램에서는 다음과 같은 특성을 가진 예제 SaaS ISV Azure 랜딩 존 계층 구조를 보여 줍니다.

Diagram that shows an example Azure landing zone hierarchy for an ISV. Most of the components from this article are omitted.

다음 단계