Azure DevTest Labs 인프라 거버넌스

이 문서에서는 조직 내 DevTest Labs에 대한 리소스의 정렬 및 관리에 대해 설명합니다.

리소스

Azure 구독 내에서 DevTest Labs 리소스 정렬

조직에서 일반 애플리케이션 개발에 Azure를 사용하기 시작하기 전에 IT 플래너는 먼저 전체 서비스 포트폴리오의 일부로 기능을 도입하는 방법을 검토해야 합니다. 검토 영역에는 다음과 같은 문제가 포함되어야 합니다.

• 애플리케이션 개발 수명 주기와 관련된 비용을 측정하는 방법
• 조직은 제안된 서비스 제품을 회사 보안 정책과 어떻게 일치합니까?
• 개발 및 프로덕션 환경을 분리하는 데 세분화가 필요한가요?
• 관리, 안정성 및 성장의 장기적인 용이성을 위해 도입되는 컨트롤은 무엇인가요?

첫 번째 권장 사례는 프로덕션 및 개발 구독 간의 부서가 설명된 조직의 Azure 분류를 검토하는 것입니다. 다음 다이어그램에서 제안된 분류를 통해 개발/테스트 및 프로덕션 환경을 논리적으로 분리할 수 있습니다. 이 방법을 사용하면 조직은 각 환경과 연결된 비용을 개별적으로 추적하는 청구 코드를 도입할 수 있습니다. 자세한 내용은 규범적 구독 거버넌스를 참조 하세요. 또한 Azure 태그를 사용하여 추적 및 청구를 위해 리소스를 구성할 수 있습니다.

두 번째 권장 방법은 Azure Enterprise Portal 내에서 DevTest 구독을 사용하도록 설정하는 것입니다. 이 경우 조직은 Azure Enterprise 구독에서 일반적으로 제공되지 않는 클라이언트 운영 체제를 실행할 수 있습니다. 그런 다음 컴퓨팅에 대해서만 지불하고 라이선스에 대해 걱정하지 않는 엔터프라이즈 소프트웨어를 사용합니다. Microsoft SQL Server와 같은 IaaS의 갤러리 이미지를 포함하여 지정된 서비스에 대한 청구는 사용량에만 기반합니다. EA(기업계약) 고객의 경우 여기에서, 그리고 종량제 고객의 경우 여기에서 Azure DevTest 구독에 대한 세부 정보를 확인할 수 있습니다.

이 모델은 조직에 대규모로 Azure DevTest Labs를 배포할 수 있는 유연성을 제공합니다. 조직은 100~1,000대의 가상 머신이 병렬로 실행되는 다양한 사업부에 수백 개의 랩을 지원할 수 있습니다. 따라서 동일한 구성 관리 및 보안 제어 원칙을 공유할 수 있는 중앙 집중식 엔터프라이즈 랩 솔루션의 개념을 더욱 확실하게 구축할 수 있습니다.

또한 이 모델을 사용하는 조직에서는 Azure 구독과 연결된 리소스 한도가 소진되는 상황이 발생하지 않습니다. 구독 및 서비스 제한에 대한 자세한 내용은 Azure 구독 및 서비스 제한, 할당량 및 제약 조건을 참조 하세요. DevTest Labs 프로비전 프로세스는 많은 수의 리소스 그룹을 사용할 수 있습니다. Azure DevTest 구독의 지원 요청을 통해 제한을 늘리도록 요청할 수 있습니다. 개발 구독 사용량이 늘어도 프로덕션 구독 내의 리소스에는 영향이 없습니다. DevTest Labs 크기 조정에 대한 자세한 내용은 DevTest Labs의 크기 조정 할당량 및 제한을 참조 하세요.

고려해야 하는 일반적인 구독 수준 제한은 프로덕션 및 개발 구독을 모두 지원하기 위해 네트워크 IP 범위 할당을 할당하는 방법입니다. 이러한 할당은 시간이 지남에 따라 증가를 고려해야 합니다(온-프레미스 연결 또는 엔터프라이즈가 Azure 구현을 기본값으로 설정하지 않고 네트워킹 스택을 관리해야 하는 다른 네트워킹 토폴로지 가정). 권장되는 방법은 작은 서브넷이 있는 여러 가상 네트워크를 사용하는 것이 아니라 큰 IP 주소 접두사를 할당하고 많은 큰 서브넷으로 나눈 몇 개의 가상 네트워크를 사용하는 것입니다. 예를 들어 10개의 구독을 사용하여 10개의 가상 네트워크(각 구독에 대해 하나씩)를 정의할 수 있습니다. 격리가 필요하지 않은 모든 랩은 구독의 가상 네트워크에서 동일한 서브넷을 공유할 수 있습니다.

랩당 사용자 수 및 조직당 랩 수

동일한 개발 프로젝트에 연결된 사업부 및 개발 그룹은 동일한 랩에 연결되어야 합니다. 두 그룹에 동일한 유형의 정책, 이미지 및 종료 정책을 적용할 수 있습니다.

지리적 경계를 고려해야 할 수도 있습니다. 예를 들어 미국 북동부 미국 개발자는 미국 동부 2에 프로비전된 랩을 사용할 수 있습니다. 또한 콜로라도 주 댈러스, 텍사스 및 덴버의 개발자는 미국 중남부에서 리소스를 사용하도록 지시받을 수 있습니다. 외부 제3자와 공동 작업이 있는 경우 내부 개발자가 사용하지 않는 랩에 할당될 수 있습니다.

Azure DevOps Projects 내의 특정 프로젝트에 랩을 사용할 수도 있습니다. 그런 다음 지정된 Microsoft Entra 그룹을 통해 보안을 적용하여 두 리소스 집합에 모두 액세스할 수 있습니다. 랩에 할당된 가상 네트워크는 사용자를 통합하는 또 다른 경계일 수 있습니다.

리소스 삭제 방지

권한 있는 사용자만 리소스를 삭제하거나 랩 정책을 변경할 수 있도록 랩 수준에서 권한을 설정합니다. 개발자는 DevTest Labs 사용자 그룹 내에 포함되어야 합니다. 수석 개발자 또는 인프라 책임자는 DevTest Labs 소유자여야 합니다. 랩 소유자는 두 명뿐인 것이 좋습니다. 손상 방지를 위해 이 정책은 코드 리포지토리로 확대 적용됩니다. 랩 사용자는 리소스를 사용할 수는 있지만 랩 정책을 업데이트할 수는 없습니다. 각 기본 제공 그룹이 랩 내에서 갖는 역할 및 권한을 나열하는 다음 문서를 참조하세요. Azure DevTest Labs에서 소유자 및 사용자 추가

비용 및 소유권 관리

비용 및 소유권은 개발 및 테스트 환경의 구축을 고려할 때 주요 관심사입니다. 이 섹션에서는 비용을 최적화하고 환경 전체에서 소유권을 조정하는 데 도움이 되는 정보를 찾습니다.

비용 최적화

DevTest Labs의 몇 가지 기본 제공 기능은 비용을 최적화하는 데 도움이 됩니다. 사용자 작업을 제한하려면 비용 관리, 임계값 및 정책 문서를 참조하세요.

개발 및 테스트 워크로드에 DevTest Labs를 사용하는 경우 기업계약의 일부인 Enterprise 개발/테스트 구독 혜택을 사용하는 것이 좋습니다. 또는 종량제 고객인 경우 종량제 DevTest 제안을 고려할 수 있습니다.

이 접근 방법에는 여러 가지 이점이 있습니다.

• Windows 가상 머신, 클라우드 서비스, HDInsight, App Service 및 Logic Apps에서 특별히 낮은 개발/테스트 속도
• 다른 Azure 서비스의 EA(훌륭한 기업계약) 요금
• Windows 8.1 및 Windows 10 등 갤러리의 전용 개발/테스트 이미지에 액세스

현재 Visual Studio를 구독(표준 구독, 연간 클라우드 구독 및 월간 클라우드 구독) 중인 경우에만 Enterprise 개발/테스트 구독 내에서 실행되는 Azure 리소스를 사용할 수 있습니다. 그러나 최종 사용자는 애플리케이션에 액세스하여 피드백을 제공하거나 승인 테스트를 수행할 수도 있습니다. 애플리케이션 개발 및 테스트에만 이 구독 내의 리소스를 사용할 수 있습니다. 작동 시간 보장은 없습니다.

DevTest 제품을 사용하기로 결정한 경우 애플리케이션 개발 및 테스트에만 이 혜택을 사용합니다. Azure DevOps 및 HockeyApp을 사용하는 경우를 제외하고 구독 내에서의 사용에는 재정적으로 지원되는 SLA가 적용되지 않습니다.

조직 전체에서 역할 기반 액세스 정의

중앙 IT 부서는 필요한 사항만 소유하고 프로젝트 및 애플리케이션 팀이 필요한 수준의 제어 권한을 갖도록 하는 것이 좋습니다. 일반적으로 중앙 IT는 구독을 소유하고 네트워킹 구성과 같은 핵심 IT 기능을 처리합니다. 구독에 대한 소유자 집합은 작아야 합니다. 이러한 소유자는 필요할 때 다른 소유자를 지정하거나, 구독자 수준 정책(예: “공용 IP 없음”)을 적용할 수 있습니다.

계층 1 또는 계층 2 지원과 같이 구독 전반에서 액세스 권한이 필요한 사용자 하위 집합도 있을 수 있습니다. 이 경우 이러한 사용자에게 리소스를 관리할 수 있도록 참가자 액세스 권한을 부여하되, 사용자 액세스 또는 정책 조정 권한은 부여하지 않는 것이 좋습니다.

DevTest Labs 리소스 소유자는 프로젝트 또는 애플리케이션 팀과 가깝습니다. 이러한 소유자는 컴퓨터 및 소프트웨어 요구 사항을 이해합니다. 대부분의 조직에서 DevTest Labs 리소스의 소유자는 프로젝트 또는 개발 책임자입니다. 이 소유자는 랩 환경 내에서 사용자 및 정책을 관리하고 DevTest Labs 환경에서 모든 가상 머신을 관리할 수 있습니다.

DevTest Labs 사용자 역할에 프로젝트 및 애플리케이션 팀 구성원을 추가합니다. 이러한 사용자는 가상 머신을 만들 수 있습니다(랩 및 구독 수준 정책에 따라). 사용자는 자체 가상 머신을 관리할 수도 있지만 다른 사용자에게 속한 가상 머신을 관리할 수는 없습니다.

자세한 내용은 Azure 엔터프라이즈 스캐폴드 - 규범적 구독 거버넌스를 참조하세요.

회사 정책 및 규정 준수

이 섹션에서는 Azure DevTest Labs 인프라에 대한 회사 정책 및 규정 준수 관리에 대한 지침을 제공합니다.

공용 및 프라이빗 아티팩트 리포지토리

공용 아티팩트 리포지토리는 가장 일반적으로 사용되는 소프트웨어 패키지의 초기 집합을 제공합니다. 일반적인 개발자 도구 및 추가 기능을 재현하는 데 시간을 투자하지 않고도 신속한 배포에 도움이 됩니다. 자체 프라이빗 리포지토리를 배포하도록 선택할 수 있습니다. 공용 및 프라이빗 리포지토리를 병렬로 사용할 수 있습니다. 공용 리포지토리를 사용하지 않도록 설정할 수도 있습니다. 프라이빗 리포지토리를 배포하는 기준은 다음과 같은 질문과 고려 사항에 의해 구동되어야 합니다.

• 조직에 DevTest Labs 제품의 일부로 회사 라이선스 소프트웨어를 포함해야 하는 요구 사항이 있나요? 대답이 '예'이면 프라이빗 리포지토리를 만들어야 합니다.
• 조직은 전체 프로비전 프로세스의 일부로 필요한 특정 작업을 제공하는 사용자 지정 소프트웨어를 개발하나요? 대답이 '예'이면 프라이빗 리포지토리를 배포해야 합니다.
• 조직의 거버넌스 정책이 격리를 요구하며 외부 리포지토리 구성을 조직이 직접 관리하지 않는 경우 프라이빗 아티팩트 리포지토리를 배포해야 합니다. 이 프로세스의 일부로, 공용 리포지토리의 초기 복사본을 복사하고 프라이빗 리포지토리에 통합할 수 있습니다. 그런 다음 조직 내의 아무도 더 이상 액세스할 수 없도록 퍼블릭 리포지토리 사용하지 않도록 설정할 수 있습니다. 이 방법은 조직 내의 모든 사용자에게 조직에서 승인한 단일 리포지토리만 갖도록 하고 구성 드리프트를 최소화하도록 합니다.

단일 리포지토리 또는 여러 리포지토리

조직의 전반적인 거버넌스 및 구성 관리 전략의 일부로 중앙 집중식 리포지토리를 사용하는 것이 좋습니다. 여러 리포지토리를 사용하는 경우 시간이 지남에 따라 관리되지 않는 소프트웨어의 사일로가 될 수 있습니다. 중앙 저장소를 사용하면 여러 팀이 프로젝트에서 이 리포지토리의 아티팩트를 사용할 수 있습니다. 표준화, 보안, 관리 용이성을 적용하고 노력의 중복을 제거합니다. 중앙 집중화의 일환으로 장기 관리 및 지속 가능성을 위한 권장 사례는 다음과 같습니다.

• Azure 구독이 인증 및 권한 부여에 사용하는 것과 동일한 Microsoft Entra 테넌트와 Azure Repos를 연결합니다.
• 중앙에서 관리되는 Microsoft Entra ID에 모든 DevTest Labs Developers라는 그룹을 만듭니다. 아티팩트 개발에 기여하는 모든 개발자는 이 그룹에 배치되어야 합니다.
• 동일한 Microsoft Entra 그룹을 사용하여 Azure Repos 리포지토리 및 랩에 대한 액세스를 제공할 수 있습니다.
• Azure 리포지토리에서 분기 또는 분기를 사용하여 주 프로덕션 리포지토리와 개발 중인 리포지토리를 분리해야 합니다. 콘텐츠는 적절한 코드 검토 후에 끌어오기 요청을 사용하여 기본 분기에만 추가됩니다. 코드 검토자가 변경을 승인하면 기본 분기의 유지 관리를 담당하는 수석 개발자가 업데이트된 코드를 병합합니다.

회사 보안 정책

조직은 다음을 통해 기업 보안 정책을 적용할 수 있습니다.

• 포괄적인 보안 정책 개발 및 게시 이 정책은 소프트웨어, 클라우드 자산 사용과 관련된 허용 가능한 사용 규칙을 명시합니다. 또한 정책을 명확하게 위반하는 항목도 정의합니다.
• 사용자 지정 이미지, 사용자 지정 아티팩트를 개발하고, Active Directory를 사용하여 정의한 보안 영역 내의 오케스트레이션을 허용하는 배포 프로세스를 개발합니다. 이 방법은 회사 경계를 적용하고 일반적인 환경 제어 집합을 설정합니다. 개발자가 전체 프로세스의 일부로 안전한 개발 수명 주기를 개발하고 따를 때 개발자가 고려할 수 있는 환경에 대한 이러한 제어입니다. 또한 개발을 방해할 수 있는 지나치게 제한적이지는 않지만 합리적인 컨트롤 집합을 제공하는 것이 목표입니다. 랩 가상 머신을 포함하는 OU(조직 구성 단위)의 그룹 정책은 프로덕션에서 발견되는 총 그룹 정책의 하위 집합일 수 있습니다. 또는 식별된 위험을 적절하게 완화하기 위한 또 다른 집합이 될 수도 있습니다.

데이터 무결성

조직은 원격 개발자가 코드를 제거하거나 맬웨어 또는 승인되지 않은 소프트웨어를 도입할 수 없도록 하기 위해 어떤 방식으로 데이터 무결성을 보장할 수 있습니다. 외부 컨설턴트, 계약자 또는 DevTest Labs에서 공동으로 작업하는 원격지 직원으로 인한 위협을 완화하기 위해 여러 계층의 컨트롤이 사용됩니다.

앞에서 설명한 것처럼 첫 번째 단계에는 누군가가 정책을 위반할 때의 결과를 명확하게 설명하는 허용 가능한 사용 정책이 초안으로 작성되고 정의되어 있어야 합니다.

원격 액세스를 위한 컨트롤의 첫 번째 계층은 랩에 직접 연결되지 않은 VPN 연결을 통해 원격 액세스 정책을 적용하는 것입니다.

두 번째 컨트롤 계층은 원격 데스크톱을 통한 복사 및 붙여넣기를 금지하는 그룹 정책 개체 집합을 적용하는 것입니다. FTP 및 RDP 서비스와 같은 환경에서 아웃바운드 서비스를 허용하지 않도록 네트워크 정책을 구현할 수 있습니다. 사용자 정의 라우팅은 모든 Azure 네트워크 트래픽을 온-프레미스로 강제로 되돌릴 수 있지만, 프록시를 통해 제어하여 콘텐츠 및 세션을 검사하지 않는 한 데이터 업로드를 허용할 수 있는 모든 URL을 라우팅에서 처리할 수 없습니다. 외부 네트워크 리소스의 브리징을 허용하지 않도록 DevTest Labs를 지원하는 가상 네트워크 내에서 공용 IP를 제한할 수 있습니다.

궁극적으로 조직 전체에 동일한 유형의 제한을 적용해야 하며, 이는 콘텐츠 게시물을 수락할 수 있는 이동식 미디어 또는 외부 URL의 가능한 모든 방법도 고려해야 합니다. 보안 정책을 검토하고 구현하려면 보안 전문가와 상의하세요. 자세한 권장 사항은 Microsoft Cyber Security를 참조하세요.

애플리케이션 마이그레이션 및 통합

개발/테스트 랩 환경이 설정되면 다음 질문에 대해 생각해야 합니다.

• 프로젝트 팀 내에서 환경을 사용하는 방법
• 필요한 조직 정책을 따르고 민첩성을 기본 애플리케이션에 가치를 추가하려면 어떻게 해야 할까요?

Azure Marketplace 이미지와 사용자 지정 이미지 비교

특정 관심사 또는 조직의 요구 사항이 없는 한 Azure Marketplace는 기본적으로 사용해야 합니다. 사용자 지정 조직 이미지를 사용해야 하는 몇 가지 일반적인 예는 다음과 같습니다.

• 애플리케이션을 기본 이미지의 일부로 포함해야 하는 복잡한 소프트웨어 설정입니다.
• 애플리케이션을 설치하고 설치하는 데 몇 시간이 걸릴 수 있으며, 이는 Azure Marketplace 이미지에 추가되는 컴퓨팅 시간을 효율적으로 사용하는 것이 아닙니다.
• 개발자와 테스터는 가상 머신에 빠르게 액세스해야 하며 새 가상 머신의 설치 시간을 최소화하려고 합니다.
• 모든 시스템에 대해 규정 준수 또는 규제 조건(예: 보안 정책)을 적용해야 하는 경우

사용자 지정 이미지는 신중하게 사용하는 것이 좋습니다. 기본 이미지의 VHD 파일을 관리해야 하므로 사용자 지정 이미지가 더 복잡해지기 때문입니다. 그리고 소프트웨어 업데이트를 사용하여 해당 기본 이미지를 정기적으로 패치해야 합니다. 이러한 업데이트에는 새 OS(운영 체제) 업데이트 및 소프트웨어 패키지 자체에 필요한 업데이트 또는 구성 변경 내용이 포함됩니다.

수식 및 사용자 지정 이미지

일반적으로는 비용과 재사용 여부에 따라 사용할 항목을 결정합니다.

다음과 같은 경우 사용자 지정 이미지를 만들어서 비용을 줄일 수 있습니다.

• 많은 사용자 또는 랩에 이미지가 필요한 경우.
• 필요한 이미지에서 기본 이미지 위에 많은 소프트웨어가 있는 경우.

이 솔루션은 이미지를 한 번 만드는 것을 의미합니다. 사용자 지정 이미지는 가상 머신의 설정 시간을 줄입니다. 설정하는 동안 가상 머신 실행에서 비용이 발생하지 않습니다.

또 다른 요소는 소프트웨어 패키지 변경 빈도입니다. 일별 빌드를 실행하며 소프트웨어가 사용자 가상 머신에 이/있어야 하는 경우에는 사용자 지정 이미지 대신 수식을 사용하는 것이 좋습니다.

네트워크 구성을 설정하는 패턴

개발 및 테스트 가상 머신이 공용 인터넷에 연결할 수 없는지 확인하는 경우 인바운드 및 아웃바운드 트래픽이라는 두 가지 측면을 고려해야 합니다.

인바운드 트래픽 - 가상 머신에 공용 IP 주소가 없는 인터넷에서 가상 머신에 연결할 수 없습니다. 일반적인 접근 방식은 사용자가 공용 IP 주소를 만들지 못하도록 구독 수준 정책을 설정하는 것입니다.

아웃바운드 트래픽 - 가상 머신이 퍼블릭 인터넷으로 직접 이동하지 못하도록 차단하고 트래픽이 회사 방화벽을 통과하도록 강제 지정하려는 경우 강제 라우팅을 사용하여 Azure ExpressRoute 또는 VPN을 통해 온-프레미스에서 트래픽을 라우팅할 수 있습니다.

참고 항목

프록시 설정 없이 트래픽을 차단하는 프록시 서버가 있는 경우 랩의 아티팩트 스토리지 계정에 예외를 추가하는 것을 잊지 마세요.

가상 머신 또는 서브넷에 대한 네트워크 보안 그룹을 사용할 수도 있습니다. 이 단계에서는 트래픽 허용 또는 차단을 위한 또 다른 보호 계층을 추가합니다.

새 가상 네트워크와 기존 가상 네트워크 비교

VM이 기존 인프라와 상호 작용해야 하는 경우에는 DevTest Labs 환경 내에서 기존 가상 네트워크를 사용하는 방식을 고려해야 합니다. ExpressRoute를 사용하는 경우 구독에 할당된 IP 주소 공간을 조각화하지 않도록 가상 네트워크 및 서브넷 수를 최소화합니다. 여기서는 가상 네트워크 피어링 패턴(허브-스포크 모델)을 사용하는 것도 좋습니다. 이 접근 방식을 사용하면 지정된 지역 내에서 구독 간에 가상 네트워크 및 서브넷 통신이 가능합니다.

각 DevTest Labs 환경에는 자체 가상 네트워크가 있을 수 있지만 구독당 가상 네트워크 수에는 제한이 있습니다. 기본 수는 50이지만 100까지 높일 수 있습니다.

공유, 공용 또는 개인 IP

사이트 간 VPN 또는 Express 경로를 사용하는 경우에는 내부 네트워크에서만 머신에 액세스할 수 있고 공용 인터넷을 통해서는 액세스할 수 없도록 프라이빗 IP 사용을 고려합니다.

참고 항목

랩 소유자는 이 서브넷 정책을 변경하여 VM에 대한 공용 IP 주소를 실수로 만드는 사람이 없도록 할 수 있습니다. 구독 소유자는 공용 IP 만들기를 금지하는 구독 정책을 만들어야 합니다.

공유 공용 IP를 사용하는 경우 랩의 가상 머신은 공용 IP 주소를 공유합니다. 이 방법은 지정된 구독에 대한 공용 IP 주소에 대한 제한을 위반하지 않아야 하는 경우에 유용할 수 있습니다.

랩 한도

알아야 할 몇 가지 랩 제한 사항이 있습니다. 이러한 제한은 다음 섹션에 설명되어 있습니다.

구독당 랩 제한

구독당 만들 수 있는 랩 수에 대한 특정 제한은 없습니다. 그러나 구독당 사용되는 리소스의 양은 제한됩니다. Azure 구독에 대한 제한 및 할당량 및 이러한 제한을 늘리는 방법에 대해 읽을 수 있습니다.

랩당 VM 제한

랩당 만들 수 있는 VM의 수에는 특정 제한이 없지만 그러나 사용되는 리소스(VM 코어, 공용 IP 주소 등)는 구독별로 제한됩니다. Azure 구독에 대한 제한 및 할당량 및 이러한 제한을 늘리는 방법에 대해 읽을 수 있습니다.

사용자 또는 랩당 가상 머신 수 제한

사용자당 또는 랩당 가상 머신 수를 고려할 때 세 가지 주요 관심사가 있습니다.

• 팀이 랩의 리소스에 재출할 수 있는 전체 비용. 여러 컴퓨터를 스핀업하는 것 자체는 간단합니다. 비용을 제어하는 메커니즘 중 하나는 사용자당 또는 랩당 VM 수를 제한하는 것입니다.
• 랩의 총 가상 머신 수는 사용 가능한 구독 수준 할당량의 영향을 받습니다 . 상한 중 하나는 구독당 800개의 리소스 그룹입니다. DevTest Labs는 현재 각 VM에 대한 새 리소스 그룹을 만듭니다(공유 공용 IP를 사용하지 않는 한). 구독에 랩이 10개 있는 경우 랩은 각 랩에 약 79개의 가상 머신(800개의 상한 - 10개의 랩 자체에 대한 10개의 리소스 그룹) = 랩당 79개의 가상 머신에 적합할 수 있습니다.
• 랩이 Express Route를 통해 온-프레미스에 연결된 경우(예:) VNet/서브넷에 사용할 수 있는 정의된 IP 주소 공간이 있습니다. 랩의 VM이 생성되지 않도록 하려면(오류: IP 주소를 가져올 수 없음) 랩 소유자는 사용 가능한 IP 주소 공간에 맞춰 랩당 최대 VM을 지정할 수 있습니다.

Resource Manager 템플릿 사용

테스트 환경에 Azure DevTest Labs 사용의 단계를 사용하여 Resource Manager 템플릿을 배포합니다. 기본적으로는 Resource Manager 템플릿을 Azure Repos 또는 GitHub Git 리포지토리에 체크 인하고 템플릿용 프라이빗 리포지토리를 랩에 추가합니다.

개발 머신을 호스트하는 데 DevTest Labs를 사용하는 경우에는 이 시나리오가 유용하지 않을 수 있습니다. 이 시나리오를 사용하여 프로덕션을 나타내는 스테이징 환경을 빌드합니다.

랩당 또는 사용자당 가상 머신 수 옵션은 랩 자체에서 기본적으로 생성되는 머신 수만 제한합니다. 이 옵션은 Resource Manager 템플릿을 통해 환경에서 생성되는 컴퓨터 수는 제한하지 않습니다.