다음을 통해 공유

일반적인 구독 자동 판매 제품 라인 설정

  • 아티클

구독 자동 판매기는 조직이 Azure 환경의 일관된 크기 조정, 보안 및 거버넌스에 중요한 Azure 랜딩 존의 구독 민주화 디자인 원칙을 달성하는 데 도움이 됩니다. 또한 구독 자동 판매는 조직이 플랫폼 엔지니어링 원칙에 부합하는 데 도움이 됩니다. 자세한 내용은 가드레일을 사용한 셀프 서비스를 통해 제품 사고방식 채택 및 개발자 역량 강화를 참조하세요.

많은 조직에서는 애플리케이션 팀이 워크로드 및 서비스를 효과적으로 제공하는 데 필요한 유연성을 제공하기 위해 애쓰고 있습니다. 한 가지 주요 장애물은 구독 자동 판매 대한 표준화된 접근 방식이 부족하여 혼란, 지연 및 비효율성을 초래할 수 있다는 것입니다.

이 문서에서는 플랫폼 팀이 다양한 애플리케이션 팀의 다양한 요구를 충족하는 공통 구독 자동 판매 제품 라인을 설정하는 방법을 살펴봅니다. 이 문서에서는 다양한 제품 라인을 제공하는 이점에 대해 설명하고 실제 고객 배포를 기반으로 하는 일반적인 시나리오의 예를 제공합니다. 또한 구독 자동 판매 "모든 크기에 맞는" 디자인이 없는 이유와 애플리케이션 팀에 다양한 제품 라인을 제공해야 하는 이유에 대해서도 알아봅니다.

다음 다이어그램은 Azure 환경 내에서 관리 그룹 및 구독의 조직을 보여 줍니다.

Azure 환경 내에서 관리 그룹 및 구독의 조직을 보여 주는 다이어그램입니다.

다음 지침에서는 다양한 제품 라인이 필요한 이유를 설명하고 Azure 랜딩 존 및 구독 자동 판매 사용하는 고객을 위한 제품 라인 예제를 설명합니다.

다양한 제품 라인 활용

애플리케이션 팀에서 워크로드 및 서비스를 제공하는 데 필요한 구독은 다양한 유형과 스타일로 제공됩니다. 애플리케이션 팀 외부에서 조직에는 다양한 규정 준수 및 데이터 처리 규칙 또는 아키텍처 패턴과 같은 Azure 구독을 사용해야 하는 다른 요구 사항이 있을 수 있습니다.

구독 자동 판매 디자인 및 구현하는 조직의 접근 방식을 결정할 때 다음 질문을 하는 것이 좋습니다.

  • 플랫폼 팀이 구독 자동 판매 프로세스의 일부로 추가해야 하는 다른 리소스는 무엇인가요?

  • 각 애플리케이션 팀에 대해 기본적으로 환경당 하나와 같은 여러 구독을 배포하나요?

  • 모든 애플리케이션에 대해 기본적으로 스포크 가상 네트워크를 연결 허브에 피어하거나 다시 연결합니까?

  • 각 구독 내에서 RBAC(역할 기반 액세스 제어)를 어떻게 구성해야 하나요?

  • 구독 내에서 사용하는 아키텍처 또는 아키타입의 리소스와 스타일을 어떻게 제어하고 제어해야 하나요?

단일 구독 유형 또는 구독 스타일을 사용하여 모든 애플리케이션 및 플랫폼 팀의 고유한 요구 사항을 해결할 수는 없습니다. 플랫폼 팀은 애플리케이션 팀이 셀프 서비스 시스템을 통해 여러 유형의 구독 스타일 중에서 선택할 수 있는 유연성을 제공해야 합니다. 이러한 유형의 구독을 제품 라인이라고 합니다.

구독 자동 판매 "모든 크기에 맞는" 접근 방식만 제공하는 조직은 종종 내부 고객의 유연성을 제한합니다. 예를 들어 유연성이 부족하면 애플리케이션 팀의 아키텍처 디자인 선택이 제한되고 자판기 때문에 손상될 수 있습니다.

따라서 플랫폼 팀은 조직의 요구에 맞게 다양한 제품 라인을 제공해야 합니다. 이러한 유연성을 통해 소비자는 요구 사항에 가장 적합한 제품 라인을 선택할 수 있습니다.

애플리케이션 환경 관리

조직은 구독 자동 판매 프로세스 및 구현의 일부로 애플리케이션 팀의 애플리케이션 환경을 관리해야 합니다. 그러나 애플리케이션 팀이 애플리케이션을 제공할 때 원하는 방식(예: 개발/테스트/prod)을 관리할 수 있도록 유연성을 제공해야 합니다. 자세한 내용은 환경, 구독 및 관리 그룹을 참조 하세요.

일부 Azure 서비스는 배포 슬롯 기능을 사용하여 Azure 앱 Service와 같이 단일 Azure 구독의 단일 리소스 인스턴스 내에서 환경을 격리하는 데 도움이 되는 네이티브 기능을 제공합니다. 이 예제에서는 애플리케이션 팀이 별도의 구독을 사용하도록 강제하므로 팀은 Azure에서 제공하는 서비스의 전체 기능 집합을 활용할 수 없습니다. 별도의 구독은 운영 및 유지 관리 오버헤드를 포함하여 애플리케이션 배달 비용을 증가시킬 수도 있습니다.

구독 자동 판매 위한 일반 제품 라인 디자인

이제 플랫폼 팀이 Azure 플랫폼의 소비자에게 여러 Azure 구독 유형 및 스타일 또는 제품 라인을 제공해야 한다는 것을 이해했으므로 이 섹션에서는 산업 및 국가 또는 지역에서 사용할 수 있는 몇 가지 일반적인 제품 라인에 대해 설명합니다.

플랫폼 팀은 이러한 일반적인 구독 자동 판매 제품 라인을 기준선으로 사용해야 합니다. 팀은 고객의 플랫폼 엔지니어링 원칙에 부합하는 여러 옵션을 소비자에게 제공할 수 있습니다. 이 접근 방식은 내부 고객에게 Azure 랜딩 존 디자인 원칙 및 디자인 영역 권장 사항을 자유롭게 사용하여 워크로드 및 서비스를 제공하고 Azure 플랫폼 거버넌스를 제공합니다.

참고 항목

이러한 예제를 시작점으로 사용합니다. 조직의 요구에 맞게 이러한 제품 라인을 사용자 지정하고 확장할 수 있습니다.

구독 자동 판매 일반적인 제품 라인은 다음과 같습니다.

  • Corp connected: 연결 구독을 통해 다른 애플리케이션 및 온-프레미스 환경에 대한 기존 계층 3 IP 라우팅 연결이 필요한 워크로드.

  • 온라인: Azure Private Link 또는 노출된 API 또는 각 애플리케이션의 엔드포인트를 통한 상호 작용과 같은 최신 연결 서비스 및 아키텍처를 통해 다른 애플리케이션과 연결하는 워크로드입니다.

  • 기술 플랫폼: 다른 애플리케이션을 빌드할 수 있는 플랫폼을 빌드하는 워크로드입니다. 예를 들어 AKS 플랫폼 팀이 관리하는 AKS(Azure Kubernetes Service) 클러스터는 다른 애플리케이션 팀을 대신하여 AKS 클러스터 내에서 다른 애플리케이션을 호스트할 수 있습니다.

  • 공유 애플리케이션 포트폴리오: 긴밀하게 결합된 공통 애플리케이션 집합에 대해 동일한 애플리케이션 팀 간에 워크로드를 공유합니다. 자체 또는 특정 워크로드를 사용하여 애플리케이션을 호스트하지 않으려는 경우

  • 샌드박스: 애플리케이션 팀이 PoC(개념 증명) 또는 MVP(최소 실행 가능한 제품)를 빌드하고 더 적은 컨트롤을 적용할 수 있는 영역이므로 팀은 개발, 발명 및 자유를 촉진하여 사용 가능한 Azure 서비스 카탈로그에서 최상의 애플리케이션을 빌드할 수 있습니다.

회사 연결 제품 라인

애플리케이션 랜딩 존 구독 자동 판매 대한 내부 또는 개인 제품 라인이라고도 하는 corp 연결 제품 라인은 기존의 Layer-3 IP 메서드를 통해 연결을 제공합니다. 이 제품 라인을 사용하여 다음과 같은 리소스 간에 연결을 제공할 수 있습니다.

  • 동일한 애플리케이션 랜딩 존에 있습니다.

  • Azure 방화벽 또는 NVA(네트워크 가상 어플라이언스)를 통해 다른 회사 연결 애플리케이션 랜딩 존에서.

  • Azure ExpressRoute 또는 VPN 연결을 통해 온-프레미스 또는 다른 클라우드에 있습니다.

구독 자동 판매 사용하는 조직은 대부분의 온-프레미스 환경이 현재 작동하는 방식과 밀접하게 일치하기 때문에 이 제품 라인을 통합하는 경우가 많습니다. 그러나 필요한 경우에만 corp 연결된 제품 라인을 사용해야 합니다. 가능한 경우 온라인 제품 라인과 같은 최신 클라우드 네이티브 접근 방식을 선호하는 것이 좋습니다.

팁

회사 워크로드와 온라인 워크로드 간의 차이점에 대한 자세한 내용은 연결, 회사 및 온라인 관리 그룹의 용도는 무엇인가요?를 참조하세요.

다음 다이어그램은 회사 연결 구독 자동 판매 제품 라인의 예를 보여줍니다. 허브 및 스포크 네트워크 모델에 대해 이 설정을 사용하여 네트워크 트래픽 및 정책을 효과적으로 관리할 수 있습니다.

회사 연결 구독 자동 판매 제품 라인의 예를 보여 주는 다이어그램

Corp 연결된 제품 라인을 사용하는 경우

다음과 같은 경우 Corp 연결된 제품 라인을 사용합니다.

  • 합리화의 5가지 R을 기반으로 다시 호스팅 및 리팩터링 마이그레이션 및 애플리케이션 빌드를 수행하려고 합니다.

  • Azure에서 여정을 시작하고 비슷한 온-프레미스 아키텍처에 익숙합니다.

  • 애플리케이션을 Azure로 "리프트 앤 시프트"하려고 합니다.

  • 애플리케이션을 자체 랜딩 존 구독으로 격리하고 애플리케이션을 완전히 클라우드 네이티브로 다시 설계하지 않고 제로 트러스트에서 마이크로 분할 원칙으로 전환하여 워크로드 간의 보안을 강화하려고 합니다.

Corp 연결된 제품 라인에 대한 다음과 같은 다른 고려 사항을 기록해 둡니다.

  • 플랫폼 팀은 가상 네트워크를 애플리케이션 랜딩 존 구독에 자동 저장하고 가상 네트워크를 지역 허브 가상 네트워크 또는 Azure Virtual WAN 허브에 피어링할 수 있습니다. 그러면 팀에서 IPAM(IP 주소 관리) 도구를 사용하여 IP 주소 할당을 제어할 수 있습니다.

  • 플랫폼 팀은 일반적으로 서브넷 또는 다른 리소스를 가상 네트워크에 두지 않습니다. 대신 플랫폼 팀은 애플리케이션 팀에 이러한 활동을 할당하여 애플리케이션 네트워킹을 원하는 방식으로 디자인할 수 있습니다.

  • 플랫폼 팀은 구독 위의 관리 그룹에 할당된 Azure 정책을 사용하여 모든 서브넷에 연결된 NSG(표준화된 네트워크 보안 그룹)와 같은 원하는 동작을 적용합니다. 애플리케이션 팀은 이 Azure 정책을 상속하며 편집할 수 없습니다. 이 방법은 구독 민주화의 Azure 랜딩 존 디자인 원칙을 따릅니다.

온라인 제품 라인

애플리케이션 랜딩 존 구독 자동 판매 대한 온라인 제품 라인(외부 또는 공용 제품 라인이라고도 함)은 다른 애플리케이션 랜딩 존의 리소스 간 또는 ExpressRoute 또는 VPN 연결을 통해 온-프레미스 간에 기존 Layer-3 IP 메서드를 통해 연결을 제공하지 않습니다. 동일한 온라인 애플리케이션 랜딩 존 구독의 리소스는 가상 네트워크를 사용하여 Layer-3 IP 메서드를 통해 서로 통신할 수 있습니다. 그러나 가상 네트워크는 일반적으로 지역 연결 허브 또는 다른 애플리케이션 랜딩 존으로 피어백되지 않습니다.

대신 다음과 같은 리소스 간의 공용 인터페이스를 통해 연결을 제공할 수 있습니다.

  • 다른 애플리케이션 랜딩 존에서.

  • 온-프레미스.

  • 다른 클라우드에 있는 워크로드에서.

애플리케이션을 생성하는 데 사용하는 다양한 PaaS(Platform as a Service) 솔루션에 의해 노출되는 네트워크 제어, 인증 기능 및 권한 부여 기능을 사용하여 연결을 보호할 수 있습니다.

온라인 애플리케이션 랜딩 존 구독 내부 및 간 Private Link 서비스와 Azure 프라이빗 엔드포인트를 사용하여 애플리케이션 간의 프라이빗 계층 3 기반 연결을 활성화하고 노출할 수 있습니다. 애플리케이션 랜딩 존 내에서 사용하는 PaaS 서비스 간에 이 방법을 사용하여 보안 또는 규제 제어를 위해 이러한 PaaS 서비스의 공용 인터페이스를 사용하지 않도록 할 수도 있습니다.

프라이빗 엔드포인트와 함께 Private Link 서비스를 사용하여 온라인 애플리케이션 랜딩 존 내에서 호스트하는 애플리케이션을 Corp 연결된 애플리케이션 랜딩 존, 온-프레미스 위치 또는 기타 클라우드에 노출하고 게시할 수도 있습니다. 프라이빗 엔드포인트를 회사 연결 애플리케이션 랜딩 존 또는 연결 허브에 직접 배치한 다음 가상 네트워크 피어링, ExpressRoute 연결 또는 VPN 연결과 같은 기존 Layer-3 연결 방법을 통해 이러한 프라이빗 엔드포인트에 대한 액세스 권한을 부여할 수 있습니다.

온라인 응용 프로그램 랜딩 존 제품 라인을 고립 된 섬으로 생각하십시오. 기본적으로 구독 내의 리소스에 액세스할 수 있는 유일한 리소스는 동일한 온라인 애플리케이션 랜딩 존 구독 내에서 배포하는 리소스입니다. 앞에서 설명한 대로 이 문서의 기술을 사용하여 다른 애플리케이션 랜딩 존, 온-프레미스 위치 또는 기타 클라우드에 대한 연결을 확장할 수 있습니다.

팁

회사 워크로드와 온라인 워크로드 간의 차이점에 대한 자세한 내용은 연결, 회사 및 온라인 관리 그룹의 목적은 무엇인가요?를 참조하세요.

다음 다이어그램은 온라인 구독 자동 판매 제품 라인의 예를 보여줍니다.

온라인 구독 자동 판매 제품 라인의 예를 보여 주는 다이어그램

온라인 제품 라인을 사용하는 경우

다음을 수행하려는 경우 온라인 제품 라인을 사용합니다.

  • 합리화의 5가지 R을 기반으로 마이그레이션 및 애플리케이션 빌드를 리팩터링, 다시 아키텍처 지정, 다시 빌드 및 수행합니다.

  • 네트워킹 구성과 관련하여 애플리케이션 팀에 사용할 완전히 민주화된 애플리케이션 랜딩 존을 제공합니다.

  • 클라우드 네이티브 서비스 및 아키텍처를 활용합니다.

  • 제로 트러스트 원칙과의 맞춤을 상당히 향상시킵니다.

  • Corp 연결된 제품 라인을 사용하지만 개인 IP 주소 공간을 사용할 수 없거나 제한됩니다.

    • 이 시나리오에서는 Azure에서 IPv4 고갈 방지의 지침을 검토해야 합니다.

기술 플랫폼 제품 라인

Azure VMware Solution 또는 Azure Virtual Desktop과 같은 기술 플랫폼을 사용하는 팀은 기술 플랫폼 제품 라인을 구현해야 합니다. 기술 플랫폼 제품 라인은 기본적으로 고도의 기술 요구 사항에 더 적합한 구독 자동 판매 제품 라인입니다. 기술 플랫폼 제품 라인을 사용하여 일반적으로 조직 전체의 여러 다른 애플리케이션 팀에 대해 여러 애플리케이션을 호스트하는 크고 복잡한 워크로드를 호스트하고 관리할 수 있습니다. 애플리케이션 팀이 기본 기술 플랫폼 조각이 아닌 애플리케이션 파트만 관리하는 경우 이 제품 라인을 사용합니다.

팁

이 제품 라인을 더 잘 이해하려면 다음 예제를 고려하세요. AKS 팀과 같은 기술 플랫폼 팀은 AKS 플랫폼에서 애플리케이션을 실행해야 하는 다른 애플리케이션 팀에 AKS를 관리형 서비스로 제공하는 것을 목표로 합니다. AKS 기술 플랫폼 팀은 AKS의 관리, 유지 관리, 보안 및 구성을 제공합니다. 따라서 애플리케이션 팀은 애플리케이션만 유지 관리하고 플랫폼에 배포합니다.

기술 플랫폼 제품 라인에 다음 제품을 포함할 수 있습니다.

  • App Service 환경(일반적으로 별도의 App Service 계획을 통해).

  • AKS는 일반적으로 하나 이상의 클러스터 내의 네임스페이스를 통해 사용됩니다.

  • Azure VMware Solution 클러스터 또는 호스트의 Azure Virtual Machines .

  • Azure Virtual Desktop 은 전체 조직에 가상 데스크톱 또는 애플리케이션을 제공합니다.

팀이 조직의 다른 애플리케이션 팀에 서비스로 제공하려는 기술 플랫폼의 요구 사항에 따라 이러한 제품을 회사 연결 또는 온라인 제품 라인에 포함할 수 있습니다.

공유 애플리케이션 포트폴리오

애플리케이션 랜딩 존 구독 자동 판매 대한 공유 애플리케이션 포트폴리오 제품 라인은 소수의 Azure 리소스에서만 생성될 수 있는 간단한 애플리케이션에 대한 별도의 애플리케이션 방문 영역 구독이 필요하지 않은 워크로드용입니다.

애플리케이션 팀과 부서는 이 제품 라인을 사용하여 스토리지 계정 또는 SQL 서버와 같은 몇 가지 작은 애플리케이션 또는 공유 구성 요소를 호스트할 수 있습니다. 팀은 단일 구독 또는 소수의 구독에서 여러 애플리케이션 간에 이러한 구성 요소를 공유합니다.

Important

공통 팀은 이 제품 라인 아래에 추가한 구독을 소유합니다. 이 팀은 이 제품 라인에 대해 이 구독에 배포하는 애플리케이션의 관련 포트폴리오를 관리합니다. 고유한 애플리케이션 포트폴리오 소유자가 있는 관련 없는 애플리케이션 워크로드의 일반 배포에는 이 제품 라인을 사용하지 마세요.

조직에서 단일 구독으로 변경하고 리소스 그룹을 사용하여 액세스를 위임하는 경우 지속적인 유연성, 액세스 제어, 거버넌스 및 유지 관리 가능성을 보장하기 위해 신중하게 계획합니다.

여러 팀 간의 단일 구독에서 리소스 그룹 위임을 고려하는 경우 최종 결정을 내리기 전에 다음 고려 사항을 고려합니다.

지역 고려 사항
관련 애플리케이션 포트폴리오의 공통 소유권 - 부서의 사업부와 같은 공통 소유자가 동일한 엔터티의 승인 범위 내에 유지되도록 변경 관리를 간소화하기 위해 애플리케이션을 관리합니다.

- 워크로드가 로깅, 모니터링 및 보안을 포함하여 구독 전체에서 일관된 정책 할당을 따르는지 확인합니다.
규정 준수 - IAM 및 Azure 정책을 사용하여 NIST(National Institute of Standards and Technology), CIS(인터넷 보안 센터), PCI SSC(결제 카드 산업 보안 표준 위원회), 산업 요구 사항 및 지역 요구 사항을 포함하여 규정 준수 요구 사항이 있는 워크로드에 대한 구독을 만듭니다. 자세한 내용은 Azure 랜딩 존 조정을 참조 하세요.

- 거버넌스에 대한 개인 정보 및 데이터 처리 요구 사항을 사용하는 워크로드에 대한 구독을 만듭니다. 개별 구독은 액세스를 줄입니다.
Azure Policy Azure 정책을 관리 그룹, 구독, 리소스 그룹 및 리소스로 범위 지정합니다. 리소스 그룹에 리소스를 배포할 때 효율적인 거버넌스를 위해 높은 범위 수준에서 Azure 정책을 할당합니다.

리소스 그룹 범위 수준에서 Azure Policy를 관리할 때 다음 제약 조건을 고려합니다.
- 구독에 새 리소스 그룹을 추가할 때 Azure Policy 할당을 만들기 위한 관리 오버헤드 증가

- 정책 할당에 대한 변경 내용을 관리할 때 워크로드 증가

- 리소스 그룹에 정책을 즉시 할당하지 않으면 보안 및 거버넌스 격차가 증가합니다.

- 관리 그룹 및 구독과 같은 높은 범위에서 준수 상태를 롤업하는 기능을 줄입니다.
구독 제한 - 제한을 확인하여 애플리케이션이 성장을 방지하는 하드 한도에 도달하지 않도록 합니다. 각 구독에는 Azure 서비스에 대한 소프트 및 하드 제한이 있습니다.

- 구독 한도를 충족하는 대규모 성장 패턴을 예상하는 애플리케이션에 대해 별도의 구독을 만듭니다.

- 시끄러운 이웃 문제를 방지하기 위해 다른 사업부 또는 부서의 애플리케이션 팀과 구독을 공유하지 마세요.
Azure 서비스 및 기능 맞춤 단일 리소스 그룹 내에서 Virtual Machines, 가상 네트워크 및 간단한 PaaS 서비스와 같은 기본 Azure 서비스 기본 형식을 제공하는 서비스를 배포할 수 있습니다. 그러나 최신 복합 제품의 복잡성으로 단일 리소스 그룹의 경계를 벗어나 이러한 더 복잡한 서비스를 배포해야 할 수 있습니다. 이 배포 시나리오에 대해 이 문서의 앞부분에서 설명한 다른 민주화된 구독 방법을 사용합니다.
플랫폼 팀만 리소스 그룹을 만들 수 있습니다. 사업부 또는 부서의 다양한 애플리케이션 팀 간에 구독을 공유하는 경우 공유 구독에서 새 리소스 그룹을 만드는 팀의 기능을 제한할 수 있습니다.

이 제한은 리소스 그룹 스프롤을 제한합니다. 플랫폼 팀만 새 리소스 그룹을 만들고 제어할 수 있습니다.

이 방법은 RBAC 할당의 복잡성을 증가시키고 플랫폼 팀에 대한 종속성을 높여 애플리케이션 배포를 관리하므로 애플리케이션 팀의 민첩성과 권한 부여를 방해할 수 있습니다.

공유 애플리케이션 포트폴리오 제품 줄에서 자동 판매한 구독을 Corp 또는 Online 관리 그룹 아래에 배치할 수 있습니다. 이 메서드는 Azure 랜딩 존 기본 권장 계층 구조에 맞춥니다. 또는 조직의 관리 그룹 계층 구조가 요구 사항을 충족하도록 Azure 랜딩 존 아키텍처 맞춤의 지침을 따르는 경우 새 관리 그룹 아래에 구독을 배치할 수 있습니다.

다음 다이어그램에서는 제품 라인과 구독 자동 판매 공유 애플리케이션 포트폴리오의 예를 보여 있습니다.

제품 라인에 구독 자동 판매 공유 애플리케이션 포트폴리오의 예를 보여 주는 다이어그램

다음과 같은 경우 공유 애플리케이션 포트폴리오 제품 라인을 사용합니다.

  • 애플리케이션 팀은 애플리케이션이 공유하는 몇 가지 작은 리소스 또는 구성 요소를 제공해야 하지만 구성 요소는 전용 애플리케이션 랜딩 존에 직접 맞지 않습니다.

  • 동일한 부서의 애플리케이션 간에 공유해야 하는 리소스 또는 구성 요소가 있지만 구성 요소는 전용 애플리케이션 랜딩 존에 직접 맞지 않습니다.

  • 기술 플랫폼 팀은 다른 애플리케이션 팀이 서비스에서 애플리케이션을 사용하거나 호스트할 수 있도록 AKS, Azure Virtual Desktop 및 Azure VMware Solution과 같이 관리되는 대규모 공유 서비스를 호스트하려고 합니다.

샌드박스

애플리케이션 랜딩 존 구독 자동 판매 샌드박스 제품 라인을 사용하여 Azure에서 POC 또는 MVP를 빌드하는 안전하고, 가볍게 제어되고, 눈에 보이는 테스트 영역을 제공할 수 있습니다.

자세한 내용은 랜딩 존 샌드박스 환경 및 Azure 랜딩 존의 애플리케이션 개발 환경 관리를 참조하세요.

샌드박스는 시간이 제한되거나 예산이 제한되는 경우가 많으며, 이는 시간 제한 또는 예산 제한이 있음을 의미합니다. 이러한 경우 샌드박스를 확장 또는 제거 및 서비스 해제해야 합니다.

조직에서 애플리케이션 팀 또는 다른 사용자가 Azure에서 서비스를 테스트하고 실험할 샌드박스 제품 라인을 제공하지 않는 경우 팀은 IT 설정을 숨깁니다. 이 경우 조직은 보고 및 가시성을 제공하고 비즈니스 사용자가 플랫폼 팀의 제어 및 감독 외부에서 만드는 구독에 거버넌스를 적용하는 데 어려움을 겪을 수 있습니다.

플랫폼 팀은 쉽게 액세스할 수 있고, 바람직하게는 셀프 서비스를 제공하고, 조직의 사용자 및 팀을 위한 샌드박스 구독에 자동으로 승인된 액세스를 제공해야 합니다. 플랫폼 팀이 보고 제어할 수 있는 환경에 대한 사용자 및 팀 액세스를 제공하여 플랫폼 팀이 액세스하거나 제어할 수 없는 섀도 IT 환경을 방지하여 위험을 초래합니다.

샌드박스는 샌드박스의 구독 경계 외부에 있는 다른 가상 네트워크에 피어링하지 않기 때문에 온라인 제품 라인 구독의 네트워킹 구성 방식을 따르는 경우가 많습니다. 샌드박스에는 온-프레미스 위치 또는 다른 위치에 대한 하이브리드 연결을 방지하기 위한 추가 컨트롤이 있는 경우가 많습니다. 알 수 없는 원본이 샌드박스에서 승인되지 않은 위치로 데이터를 내보낼 수 없도록 이러한 컨트롤을 사용합니다. Azure 정책을 사용하여 이러한 컨트롤을 적용할 수 있습니다.

공유 애플리케이션 포트폴리오 및 기술 플랫폼 제품 라인과 마찬가지로 동일한 고려 사항으로 동일한 부서의 팀 간에 샌드박스 제품 라인을 공유할 수도 있습니다. 단일 샌드박스 구독을 만들고 리소스 그룹을 통해 팀 간에 공유하지 마세요. 대신 추가 샌드박스 구독을 만듭니다.

Azure에서 실험, PoC 만들기 또는 MVP를 만들려는 조직 전체의 모든 사용자에게 안전하고 안전한 관리형 Azure 구독을 제공해야 하는 경우 샌드박스 제품 라인을 사용합니다. 이러한 사용자를 가볍게 제어하고 모든 서비스에 대한 액세스 권한을 부여하여 섀도 IT 관행을 방지해야 합니다.

요약 및 요약

이 문서에서는 복잡한 구독 자동 판매 프로세스를 탐색하고 구현으로 이동하는 데 도움이 되는 규범적 지침을 간략하게 설명합니다.

가장 적합한 구독 자동 판매 제품 라인을 선택하기 위한 향후 애플리케이션 팀의 요구 사항을 결정합니다. 셀프 서비스 인터페이스를 통해 사용하도록 설정하고 노출하려는 구독 자동 판매 제품 라인의 우선 순위를 지정하기 위해 빌드하거나 마이그레이션하는 초기 워크로드 집합에 대한 요구 사항을 식별합니다.

각 제품 라인에는 구현 비용과 유지 관리 비용이 있습니다. 장기 비용 및 장기 혜택 및 사용량을 평가합니다.

고객은 일반적으로 처음에 다음 구독 자동 판매 제품 라인을 사용하도록 설정합니다.

추가 리소스

플랫폼 엔지니어링 접근 방식을 추가로 지원하려면 조직의 구독 자동 판매 제품 라인 및 제품을 디자인하고 구현할 때 다음 리소스를 검토합니다.

다음 단계

최상의 결과를 위해 최대한 많은 구독 자동 판매 프로세스를 자동화해야 합니다. 구독 자동 판매 자동화 구현에 대한 도우미 지침을 사용합니다.

구독 자동 판매 구현 지침