Azure Resource Manager 및 클래식 배포: 배포 모델 및 리소스 상태 이해Azure Resource Manager vs. classic deployment: Understand deployment models and the state of your resources

참고

이 문서에서 제공된 정보는 클래식 배포에서 Azure Resource Manager 배포로 마이그레이션하는 경우에만 사용됩니다.The information provided in this article is only used when you migrate from the classic deployment to the Azure Resource Manager deployment.

이 문서에서는 Azure Resource Manager 및 클래식 배포 모델에 대해 알아봅니다.In this article, you learn about Azure Resource Manager and classic deployment models. Resource Manager와 클래식 배포 모델은 Azure 솔루션을 배포하고 관리하는 별개의 두 가지 방식을 나타냅니다.The Resource Manager and classic deployment models represent two different ways of deploying and managing your Azure solutions. 서로 다른 두 가지 API 집합을 통해 작업하며, 배포된 리소스에는 중요한 차이점이 있습니다.You work with them through two different API sets, and the deployed resources can contain important differences. 두 가지 모델은 서로 호환되지 않습니다.The two models are not compatible with each other. 이 문서에서는 이러한 차이점을 설명합니다.This article describes those differences.

리소스의 배포와 관리를 단순화하기 위해 새 리소스 모두에 대해 Resource Manager를 사용하는 것이 좋습니다.To simplify the deployment and management of resources, Microsoft recommends that you use Resource Manager for all new resources. 가능하면 기존 리소스도 Resource Manager를 통해 다시 배포하는 것이 좋습니다.If possible, Microsoft recommends that you redeploy existing resources through Resource Manager.

Resource Manager를 새로이 경험하는 경우 먼저 Azure Resource Manager 개요에 정의된 용어를 검토할 수도 있습니다.If you are new to Resource Manager, you may want to first review the terminology defined in the Azure Resource Manager overview.

참고

이 문서는 새 Azure PowerShell Az 모듈을 사용하도록 업데이트되었습니다.This article has been updated to use the new Azure PowerShell Az module. AzureRM 모듈은 적어도 2020년 12월까지 버그 수정을 수신할 예정이므로 계속 사용하셔도 됩니다.You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. 새 Az 모듈 및 AzureRM 호환성에 대한 자세한 내용은 새 Azure PowerShell Az 모듈 소개를 참조하세요.To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Az 모듈 설치 지침은 Azure PowerShell 설치를 참조하세요.For Az module installation instructions, see Install Azure PowerShell.

배포 모델 내역History of the deployment models

Azure에서는 원래 클래식 배포 모델만 제공했습니다.Azure originally provided only the classic deployment model. 이 모델에서는 각 리소스가 독립적으로 존재하며 관련 리소스를 함께 그룹화할 방법이 없습니다.In this model, each resource existed independently; there was no way to group related resources together. 대신, 어떤 리소스로 솔루션 또는 애플리케이션이 구성되었는지를 수동으로 추적하고 통합된 방식으로 이를 관리해야 했습니다.Instead, you had to manually track which resources made up your solution or application, and remember to manage them in a coordinated approach. 솔루션을 배포하기 위해 포털을 통해 각 리소스를 개별적으로 만들거나 모든 리소스를 정확한 순서로 배포하는 스크립트를 만들어야 했습니다.To deploy a solution, you had to either create each resource individually through the portal or create a script that deployed all the resources in the correct order. 솔루션을 삭제하려면 각 리소스를 개별적으로 삭제해야 했습니다.To delete a solution, you had to delete each resource individually. 관련 리소스에 대한 액세스 제어 정책을 쉽게 적용 및 업데이트할 수 없었습니다.You could not easily apply and update access control policies for related resources. 마지막으로 리소스를 모니터링하고 청구를 관리하는 데 도움이 되는 조건으로 레이블을 지정하기 위한 태그를 리소스에 적용할 수 없었습니다.Finally, you could not apply tags to resources to label them with terms that help you monitor your resources and manage billing.

2014년에 Azure에서 리소스 그룹의 개념을 추가한 Resource Manager를 소개했습니다.In 2014, Azure introduced Resource Manager, which added the concept of a resource group. 리소스 그룹은 공통 수명 주기를 공유하는 리소스의 컨테이너입니다.A resource group is a container for resources that share a common lifecycle. 리소스 관리자 배포 모델에는 여러 이점을 제공합니다.The Resource Manager deployment model provides several benefits:

  • 솔루션에 대한 모든 서비스를 개별적으로 처리하는 것이 아니라 이러한 서비스를 그룹으로 배포, 관리 및 모니터링할 수 있습니다.You can deploy, manage, and monitor all the services for your solution as a group, rather than handling these services individually.
  • 수명 주기 내내 솔루션을 반복적으로 배포하며 안심하고 일관된 상태로 리소스를 배포할 수 있습니다.You can repeatedly deploy your solution throughout its lifecycle and have confidence your resources are deployed in a consistent state.
  • 리소스 그룹의 모든 리소스에 액세스 제어를 적용할 수 있으며 새 리소스를 리소스 그룹에 추가할 때 해당 정책이 자동으로 적용됩니다.You can apply access control to all resources in your resource group, and those policies are automatically applied when new resources are added to the resource group.
  • 리소스에 태그를 적용하여 구독에서 모든 리소스를 논리적으로 구성할 수 있습니다.You can apply tags to resources to logically organize all the resources in your subscription.
  • JSON(JavaScript Object Notation)을 사용하여 솔루션에 대한 인프라를 정의할 수 있습니다.You can use JavaScript Object Notation (JSON) to define the infrastructure for your solution. JSON 파일을 Resource Manager 템플릿이라고 합니다.The JSON file is known as a Resource Manager template.
  • 올바른 순서로 배포되므로 리소스 간의 종속성을 정의할 수 있습니다.You can define the dependencies between resources so they are deployed in the correct order.

리소스 관리자를 추가할 때 모든 리소스는 기본 리소스 그룹에 소급 추가되었습니다.When Resource Manager was added, all resources were retroactively added to default resource groups. 이제 클래식 배포를 통해 리소스를 만들 경우, 배포 시 해당 리소스 그룹을 지정하지 않은 경우에도 리소스가 해당 서비스에 대한 기본 리소스 그룹 내에서 자동으로 생성됩니다.If you create a resource through classic deployment now, the resource is automatically created within a default resource group for that service, even though you did not specify that resource group at deployment. 그러나 리소스 그룹 내에 존재한다 해도도 리소스 관리자 모델로 변환되었음을 의미하지는 않습니다.However, just existing within a resource group does not mean that the resource has been converted to the Resource Manager model.

모델에 대한 지원 이해Understand support for the models

다음의 세 가지 시나리오를 알고 있어야 합니다.There are three scenarios to be aware of:

  1. Cloud Services는 Resource Manager 배포 모델을 지원하지 않습니다.Cloud Services does not support Resource Manager deployment model.
  2. 가상 머신, 저장소 계정 및 가상 네트워크는 Resource Manager 및 클래식 배포 모델을 모두 지원합니다.Virtual machines, storage accounts, and virtual networks support both Resource Manager and classic deployment models.
  3. 다른 모든 Azure 서비스는 Resource Manager를 지원합니다.All other Azure services support Resource Manager.

가상 머신, 저장소 계정 및 가상 네트워크의 경우 클래식 배포를 통해 리소스를 만든 경우 기존 작업을 통해 계속 작업해야 합니다.For virtual machines, storage accounts, and virtual networks, if the resource was created through classic deployment, you must continue to operate on it through classic operations. Resource Manager 배포를 통해 가상 컴퓨터, 저장소 계정 또는 가상 네트워크를 만든 경우 Resource Manager 작업을 계속 사용해야 합니다.If the virtual machine, storage account, or virtual network was created through Resource Manager deployment, you must continue using Resource Manager operations. 이러한 차이는 구독에서 Resource Manager 및 클래식 배포를 통해 만든 리소스가 혼합되는 경우에는 혼동을 줄 수 있습니다.This distinction can get confusing when your subscription contains a mix of resources created through Resource Manager and classic deployment. 리소스가 동일한 작업을 지원하지 않기 때문에 이러한 리소스 조합은 예기치 않은 결과를 만들 수 있습니다.This combination of resources can create unexpected results because the resources do not support the same operations.

어떤 경우에는 Resource Manager 명령으로 클래식 배포를 통해 만들어지는 리소스에 대한 정보를 검색하거나, 클래식 리소스를 다른 리소스 그룹으로 이동하는 것과 같은 관리 작업을 수행할 수 있습니다.In some cases, a Resource Manager command can retrieve information about a resource created through classic deployment, or can perform an administrative task such as moving a classic resource to another resource group. 하지만 이 경우 해당 형식이 Resource Manager 작업을 지원한다는 느낌을 주어서는 안됩니다.But, these cases should not give the impression that the type supports Resource Manager operations. 예를 들어 클래식 배포로 만든 가상 컴퓨터가 포함된 리소스 그룹이 있다고 가정합니다.For example, suppose you have a resource group that contains a virtual machine that was created with classic deployment. 다음 Resource Manager PowerShell 명령을 실행하는 경우If you run the following Resource Manager PowerShell command:

Get-AzResource -ResourceGroupName ExampleGroup -ResourceType Microsoft.ClassicCompute/virtualMachines

다음 예제에서는 가상 컴퓨터를 반환합니다.It returns the virtual machine:

Name              : ExampleClassicVM
ResourceId        : /subscriptions/{guid}/resourceGroups/ExampleGroup/providers/Microsoft.ClassicCompute/virtualMachines/ExampleClassicVM
ResourceName      : ExampleClassicVM
ResourceType      : Microsoft.ClassicCompute/virtualMachines
ResourceGroupName : ExampleGroup
Location          : westus
SubscriptionId    : {guid}

그러나 Resource Manager cmdlet Get-AzVM만 Resource Manager를 통해 배포된 가상 머신을 반환합니다.However, the Resource Manager cmdlet Get-AzVM only returns virtual machines deployed through Resource Manager. 다음 명령은 클래식 배포를 통해 만든 가상 컴퓨터를 반환하지 않습니다.The following command does not return the virtual machine created through classic deployment.

Get-AzVM -ResourceGroupName ExampleGroup

리소스 관리자를 통해 만든 리소스만이 태그를 지원합니다.Only resources created through Resource Manager support tags. 클래식 리소스에 태그를 적용할 수 없습니다.You cannot apply tags to classic resources.

계산, 네트워크 및 스토리지에 대한 변경 내용Changes for compute, network, and storage

다음 그림에서는 Resource Manager를 통해 배포되는 계산, 네트워크 및 스토리지 리소스를 보여 줍니다.The following diagram displays compute, network, and storage resources deployed through Resource Manager.

Resource Manager 아키텍처

리소스 간의 관계는 다음과 같습니다.Note the following relationships between the resources:

  • 모든 리소스는 리소스 그룹 내에 존재합니다.All the resources exist within a resource group.
  • 가상 컴퓨터는 SRP(스토리지 리소스 공급자)에서 Blob 스토리지(필수)에 디스크를 저장하도록 정의된 특정 Storage 계정에 따라 달라집니다.The virtual machine depends on a specific storage account defined in the Storage resource provider to store its disks in blob storage (required).
  • 가상 머신은 네트워크 리소스 공급자(필수)에서 정의된 특정 NIC 및 Compute 리소스 공급자(선택 사항)에서 정의된 가용성 집합을 참조합니다.The virtual machine references a specific NIC defined in the Network resource provider (required) and an availability set defined in the Compute resource provider (optional).
  • NIC는 가상 머신의 할당된 IP 주소(필수), 가상 머신에 대한 가상 네트워크의 서브넷(필수) 및 NSG(네트워크 보안 그룹)(선택)를 참조합니다.The NIC references the virtual machine's assigned IP address (required), the subnet of the virtual network for the virtual machine (required), and to a Network Security Group (optional).
  • 가상 네트워크의 서브넷은 NSG(선택)를 참조합니다.The subnet within a virtual network references a Network Security Group (optional).
  • 부하 분산 장치 인스턴스는 가상 머신의 NIC(선택)를 포함하는 IP 주소의 백 엔드 풀을 참조하며, 로드 분산 장치 공용 또는 개인 IP 주소(선택)를 참조합니다.The load balancer instance references the backend pool of IP addresses that include the NIC of a virtual machine (optional) and references a load balancer public or private IP address (optional).

클래식 배포를 위한 구성 요소 및 해당 관계는 다음과 같습니다.Here are the components and their relationships for classic deployment:

클래식 아키텍처

가상 머신을 호스트팅하는 기존 솔루션에 포함되는 구성 요소는 다음과 같습니다.The classic solution for hosting a virtual machine includes:

  • 가상 머신 호스팅(계산)을 위한 컨테이너 역할을 하는 데 필요한 클라우드 서비스.A required cloud service that acts as a container for hosting virtual machines (compute). 가상 머신은 NIC(네트워크 인터페이스 카드) 및 Azure에서 할당된 IP 주소와 함께 자동으로 제공됩니다.Virtual machines are automatically provided with a network interface card (NIC) and an IP address assigned by Azure. 또한 클라우드 서비스는 외부 부하 분산 장치 인스턴스, 공용 IP 주소, 기본 엔드포인트를 포함하여 Windows 기반의 가상 머신을 위한 원격 데스크톱 및 원격 PowerShell 트래픽 및 Linux 기반의 가상 머신을 위한 SSH(Secure Shell) 트래픽을 허용합니다.Additionally, the cloud service contains an external load balancer instance, a public IP address, and default endpoints to allow remote desktop and remote PowerShell traffic for Windows-based virtual machines and Secure Shell (SSH) traffic for Linux-based virtual machines.
  • 운영 체제, 임시 및 추가 데이터 디스크(저장소)를 비롯하여 가상 머신을 위한 VHD를 저장하는 데 필요한 저장소 계정.A required storage account that stores the VHDs for a virtual machine, including the operating system, temporary, and additional data disks (storage).
  • 서브넷된 구조를 만들고 가상 머신이 위치한(네트워크) 서브넷을 지정할 수 있는 추가 컨테이너 역할을 하는 옵션 가상 네트워크입니다.An optional virtual network that acts as an additional container, in which you can create a subnetted structure and designate the subnet on which the virtual machine is located (network).

다음 표에서 Compute, Network 및 Storage 리소스 공급자의 상호 작동 방식에 대한 변경 내용을 설명합니다.The following table describes changes in how Compute, Network, and Storage resource providers interact:

항목Item 클래식Classic 리소스 관리자Resource Manager
Virtual Machines용 클라우드 서비스Cloud Service for Virtual Machines 클라우드 서비스는 플랫폼 가용성 및 부하 분산이 필요한 가상 머신을 유지하는 컨테이너였습니다.Cloud Service was a container for holding the virtual machines that required Availability from the platform and Load Balancing. 클라우드 서비스는 더 이상 새 모델을 사용하여 Virtual Machine을 만드는 데 필요한 개체가 아닙니다.Cloud Service is no longer an object required for creating a Virtual Machine using the new model.
Virtual NetworkVirtual Networks 가상 머신의 가상 네트워크는 선택 사항입니다.A virtual network is optional for the virtual machine. 포함되는 경우 Resource Manager에서 가상 네트워크를 배포할 수 없습니다.If included, the virtual network cannot be deployed with Resource Manager. 가상 머신에 Resource Manager에서 배포한 가상 네트워크가 필요합니다.Virtual machine requires a virtual network that has been deployed with Resource Manager.
Storage 계정Storage Accounts 가상 머신에 운영 체제, 임시 및 추가 데이터 디스크용 VHD를 저장하는 데 필요한 저장소 계정이 필요합니다.The virtual machine requires a storage account that stores the VHDs for the operating system, temporary, and additional data disks. 가상 머신에 Blob Storage에서 해당 디스크를 저장하는 스토리지 계정이 필요합니다.The virtual machine requires a storage account to store its disks in blob storage.
가용성 집합Availability Sets Virtual Machines에서 동일한 “AvailabilitySetName”을 구성하여 플랫폼 가용성을 표시했습니다.Availability to the platform was indicated by configuring the same “AvailabilitySetName” on the Virtual Machines. 최대 장애 도메인 수는 2개였습니다.The maximum count of fault domains was 2. 가용성 집합은 Microsoft.Compute 공급자가 표시하는 리소스입니다.Availability Set is a resource exposed by Microsoft.Compute Provider. 고가용성이 필요한 Virtual Machines는 가용성 집합에 포함되어야 합니다.Virtual Machines that require high availability must be included in the Availability Set. 최대 장애 도메인 수는 이제 3개입니다.The maximum count of fault domains is now 3.
선호도 그룹Affinity Groups 선호도 그룹은 Virtual Network를 만드는 데 필요했습니다.Affinity Groups were required for creating Virtual Networks. 그러나 지역 Virtual Network의 도입으로 더 이상 필요하지 않게 되었습니다.However, with the introduction of Regional Virtual Networks, that was not required anymore. 간단히 말해, Azure 리소스 관리자를 통해 표시되는 API에는 선호도 그룹 개념이 존재하지 않습니다.To simplify, the Affinity Groups concept doesn’t exist in the APIs exposed through Azure Resource Manager.
부하 분산Load Balancing 클라우드 서비스를 만들면 배포된 Virtual Machines에 대한 암시적 부하 분산 장치가 제공됩니다.Creation of a Cloud Service provides an implicit load balancer for the Virtual Machines deployed. 부하 분산 장치는 Microsoft.Network 공급자가 표시하는 리소스입니다.The Load Balancer is a resource exposed by the Microsoft.Network provider. 부하 분산이 필요한 Virtual Machines의 기본 네트워크 인터페이스는 부하 분산 장치를 참조해야 합니다.The primary network interface of the Virtual Machines that needs to be load balanced should be referencing the load balancer. 부하 분산 장치는 내부 또는 외부에 있을 수 있습니다.Load Balancers can be internal or external. 부하 분산 장치 인스턴스는 가상 머신의 NIC(옵션)를 포함하는 IP 주소의 백 엔드 풀을 참조하며 로드 분산 장치 공용 또는 개인 IP 주소(옵션)를 참조합니다.A load balancer instance references the backend pool of IP addresses that include the NIC of a virtual machine (optional) and references a load balancer public or private IP address (optional).
가상 IP 주소Virtual IP Address Cloud Services는 VM이 클라우드 서비스에 추가될 때 기본 VIP(가상 IP 주소)를 가져옵니다.Cloud Services gets a default VIP (Virtual IP Address) when a VM is added to a cloud service. 가상 IP 주소는 암시적 부하 분산 장치와 연결된 주소입니다.The Virtual IP Address is the address associated with the implicit load balancer. 공용 IP 주소는 Microsoft.Network 공급자가 표시하는 리소스입니다.Public IP address is a resource exposed by the Microsoft.Network provider. 공용 IP 주소는 고정(예약된) 또는 동적일 수 있습니다.Public IP address can be static (reserved) or dynamic. 동적 공용 IP는 부하 분산 장치에 할당될 수 있습니다.Dynamic public IPs can be assigned to a Load Balancer. 보안 그룹을 사용하여 공용 IP의 보안을 유지할 수 있습니다.Public IPs can be secured using Security Groups.
예약된 IP 주소Reserved IP Address Azure에서 IP 주소를 예약하고 클라우드 서비스와 연결하여 IP 주소를 고정할 수 있습니다.You can reserve an IP Address in Azure and associate it with a Cloud Service to ensure that the IP Address is sticky. 공용 IP 주소는 고정 모드에서 만들 수 있으며 예약된 IP 주소와 동일한 기능을 제공합니다.Public IP Address can be created in static mode and it offers the same capability as a reserved IP address.
VM당 PIP(공용 IP 주소)Public IP Address (PIP) per VM 공용 IP 주소를 VM에 직접 연결할 수도 있습니다.Public IP Addresses can also be associated to a VM directly. 공용 IP 주소는 Microsoft.Network 공급자가 표시하는 리소스입니다.Public IP address is a resource exposed by the Microsoft.Network provider. 공용 IP 주소는 고정(예약된) 또는 동적일 수 있습니다.Public IP Address can be static (reserved) or dynamic.
엔드포인트Endpoints 특정 포트에 대한 연결을 설정하려면 Virtual Machine에서 입력 엔드포인트를 구성해야 했습니다.Input Endpoints needed to be configured on a Virtual Machine to be open up connectivity for certain ports. 가상 머신에 연결하는 일반적인 모드 중 하나는 입력 엔드포인트를 설정하는 방식으로 수행되었습니다.One of the common modes of connecting to virtual machines done by setting up input endpoints. 부하 분산 장치에서 인바운드 NAT 규칙을 구성하여 특정 포트의 엔드포인트에서 VM에 연결하도록 지원하는 동일한 기능을 실현할 수 있습니다.Inbound NAT Rules can be configured on Load Balancers to achieve the same capability of enabling endpoints on specific ports for connecting to the VMs.
DNS 이름DNS Name 클라우드 서비스는 전역적으로 고유한 암시적 DNS 이름을 가져옵니다.A cloud service would get an implicit globally unique DNS Name. 예: mycoffeeshop.cloudapp.netFor example: mycoffeeshop.cloudapp.net. DNS 이름은 공용 IP 주소 리소스에 지정할 수 있는 선택적 매개 변수입니다.DNS Names are optional parameters that can be specified on a Public IP Address resource. FQDN 형식 예: <domainlabel>.<region>.cloudapp.azure.comThe FQDN is in the following format - <domainlabel>.<region>.cloudapp.azure.com.
네트워크 인터페이스Network Interfaces 기본 및 보조 네트워크 인터페이스와 해당 속성이 가상 머신의 네트워크 구성으로 정의되었습니다.Primary and Secondary Network Interface and its properties were defined as network configuration of a Virtual machine. 네트워크 인터페이스는 Microsoft.Network 공급자가 표시하는 리소스입니다.Network Interface is a resource exposed by Microsoft.Network Provider. 네트워크 인터페이스의 수명 주기는 Virtual Machine과 관련이 없습니다.The lifecycle of the Network Interface is not tied to a Virtual Machine. 네트워크 인터페이스는 가상 머신의 할당된 IP 주소(필수), 가상 머신에 대한 가상 네트워크의 서브넷(필수) 및 네트워크 보안 그룹(선택)을 참조합니다.It references the virtual machine's assigned IP address (required), the subnet of the virtual network for the virtual machine (required), and to a Network Security Group (optional).

다양한 배포 모델의 가상 네트워크를 연결하는 것에 대한 자세한 내용은 포털에서 다양한 배포 모델의 가상 네트워크 연결을 참조하세요.To learn about connecting virtual networks from different deployment models, see Connect virtual networks from different deployment models in the portal.

클래식에서 Resource Manager로 마이그레이션Migrate from classic to Resource Manager

클래식 배포에서 Resource Manager 배포로 마이그레이션할 준비가 되었다면 다음을 참조하세요.If you are ready to migrate your resources from classic deployment to Resource Manager deployment, see:

  1. 클래식에서 Azure Resource Manager로의 플랫폼 지원 마이그레이션에 대한 기술 정보Technical deep dive on platform-supported migration from classic to Azure Resource Manager
  2. 클래식에서 Azure Resource Manager로 IaaS 리소스의 플랫폼 지원 마이그레이션Platform supported migration of IaaS resources from Classic to Azure Resource Manager
  3. Azure PowerShell을 사용하여 클래식에서 Azure Resource Manager로 IaaS 리소스 마이그레이션Migrate IaaS resources from classic to Azure Resource Manager by using Azure PowerShell
  4. Azure CLI를 사용하여 클래식에서 Azure Resource Manager로 IaaS 리소스 마이그레이션Migrate IaaS resources from classic to Azure Resource Manager by using Azure CLI

질문과 대답Frequently asked questions

클래식 배포를 사용하여 만든 가상 네트워크에 Resource Manager를 사용하여 만든 가상 머신을 배포할 수 있나요?Can I create a virtual machine using Resource Manager to deploy in a virtual network created using classic deployment?

이 구성은 지원되지 않습니다.This configuration is not supported. Resource Manager를 사용하면 클래식 배포를 통해 만든 가상 네트워크에 가상 머신을 배포할 수 없습니다.You cannot use Resource Manager to deploy a virtual machine into a virtual network that was created using classic deployment.

Resource Manager를 사용하면 클래식 배포 모델을 통해 만든 사용자 이미지에서 가상 머신을 만들 수 있나요?Can I create a virtual machine using Resource Manager from a user image that was created using the classic deployment model?

이 구성은 지원되지 않습니다.This configuration is not supported. 하지만 클래식 배포 모델을 통해 만든 저장소 계정에서 VHD 파일을 복사하고 Resource Manager를 통해 만든 새 계정에 이 파일을 추가할 수는 있습니다.However, you can copy the VHD files from a storage account that was created using the classic deployment model, and add them to a new account created through Resource Manager.

내 구독의 할당량에 미치는 영향은 무엇입니까?What is the impact on the quota for my subscription?

Azure Resource Manager를 사용하여 만든 가상 머신, 가상 네트워크 및 저장소 계정에 대한 할당량은 다른 할당량과 별개입니다.The quotas for the virtual machines, virtual networks, and storage accounts created through the Azure Resource Manager are separate from other quotas. 각 구독에는 새 API를 사용하여 리소스를 만들 수 있는 할당량이 부여됩니다.Each subscription gets quotas to create the resources using the new APIs. 추가 할당량에 대한 자세한 내용은 여기에서 확인할 수 있습니다.You can read more about the additional quotas here.

Resource Manager API를 통해 가상 머신, 가상 네트워크 및 저장소 계정을 프로비전하는 데 자동화된 스크립트를 계속 사용할 수 있습니까?Can I continue to use my automated scripts for provisioning virtual machines, virtual networks, and storage accounts through the Resource Manager APIs?

사용자가 작성한 모든 자동화와 스크립트는 Azure Service Management 모드에서 만든 기존 가상 머신 및 가상 네트워크에서 계속 작동합니다.All the automation and scripts that you've built continue to work for the existing virtual machines, virtual networks created under the Azure Service Management mode. 하지만 Resource Manager 모드를 통해 동일한 리소스를 만드는 새 스키마를 사용하도록 스크립트를 업데이트해야 합니다.However, the scripts have to be updated to use the new schema for creating the same resources through the Resource Manager mode.

Azure 리소스 관리자 템플릿 예제는 어디서 찾을 수 있습니까?Where can I find examples of Azure Resource Manager templates?

Azure Resource Manager 빠른 시작 템플릿에서 포괄적인 시작 템플릿 집합을 찾을 수 있습니다.A comprehensive set of starter templates can be found on Azure Resource Manager Quickstart Templates.

다음 단계Next steps