Azure 仮想ネットワーク内のリソースの名前解決
注意
この記事では、間もなくサポート終了 (EOL) 状態になる Linux ディストリビューションである CentOS について説明します。 適宜、使用と計画を検討してください。 詳細については、「CentOS のサポート終了に関するガイダンス」を参照してください。
Azure を使用して、IaaS、PaaS、ハイブリッド ソリューションをホストできます。 仮想マシン (VM) と仮想ネットワークにデプロイされている他のリソースとの通信を容易にするために、これらが相互に通信できるようにする必要がある場合があります。 IP アドレスに依存するのではなく、覚えやすく変化のない名前を使用することで、通信プロセスを簡素化することができます。
仮想ネットワーク内に配置されたリソースがドメイン名を内部 IP アドレスに解決する必要がある場合、次の 4 つの方法のいずれかを使用できます。
独自の DNS サーバーを使用する名前解決 (Azure で提供される DNS サーバーにクエリを転送する可能性がある)
どちらの名前解決方法を使用するかは、リソースが互いに通信するために必要な方法によって決まります。 次の表では、シナリオと対応する名前解決の方法を示します。
Note
Azure DNS プライベート ゾーンは推奨のソリューションです。これにより、DNS ゾーンとレコードを柔軟に管理できるようになります。 詳しくは、「プライベート ドメインに Azure DNS を使用する」をご覧ください。
Note
Azure 提供の DNS を使用する場合は、適切な DNS サフィックスが仮想マシンに自動的に適用されます。 それ以外のオプションを選択する場合は、完全修飾ドメイン名 (FQDN) を使用するか、適切な DNS サフィックスを仮想マシンに手動で適用する必要があります。
| シナリオ | ソリューション | DNS サフィックス |
|---|---|---|
| 同じ仮想ネットワーク内に配置された VM 間、または同じクラウド サービス内の Azure クラウド サービスのロール インスタンス間での名前解決。 | Azure DNS プライベート ゾーンまたは Azure で提供される名前解決 | ホスト名または FQDN |
| 異なる仮想ネットワーク内の VM 間または異なるクラウドサービスのロール インスタンス間での名前解決。 | Azure DNS プライベート ゾーン、Azure DNS Private Resolver、または Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。 「独自の DNS サーバーを使用する名前解決」を参照してください。 | FQDN のみ |
| 仮想ネットワーク統合を使用した Azure App Service (Web App、Function、Bot など) から同じ仮想ネットワーク上のロール インスタンスまたは VM への名前解決。 | Azure DNS Private Resolver、または Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。 「独自の DNS サーバーを使用する名前解決」を参照してください。 | FQDN のみ |
| App Service Web Apps から同じ仮想ネットワーク内の VM への名前解決。 | Azure DNS Private Resolver、または Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。 「独自の DNS サーバーを使用する名前解決」を参照してください。 | FQDN のみ |
| ある仮想ネットワーク内の App Service Web Apps から異なる仮想ネットワーク内の VM への名前解決。 | Azure DNS Private Resolver、または Azure で解決するために仮想ネットワーク間でクエリを転送する、ユーザーが管理する DNS サーバー (DNS プロキシ)。 「独自の DNS サーバーを使用する名前解決」を参照してください。 | FQDN のみ |
| Azure 内の VM またはロール インスタンスからのオンプレミスのコンピューターとサービスの名前解決。 | Azure DNS Private Resolver、またはユーザーが管理する DNS サーバー (オンプレミスのドメイン コントローラー、ローカルの読み取り専用ドメイン コントローラー、ゾーン転送を使用して同期する DNS セカンダリなど)。 「独自の DNS サーバーを使用する名前解決」を参照してください。 | FQDN のみ |
| オンプレミスのコンピューターからの Azure のホスト名の解決。 | 対応する仮想ネットワーク内のユーザーが管理する DNS プロキシ サーバーにクエリを転送し、プロキシ サーバーが解決するために Azure にクエリを転送します。 「独自の DNS サーバーを使用する名前解決」を参照してください。 | FQDN のみ |
| 内部 IP 用の逆引き DNS。 | Azure DNS プライベート ゾーン、Azure によって提供される名前解決、Azure DNS Private Resolver、またはお客様所有の DNS サーバーを使用した名前解決。 | 適用なし |
| 仮想ネットワークではなく、異なるクラウド サービスに配置された VM またはロール インスタンス間での名前解決。 | 適用不可。 異なるクラウド サービス内にある VM とロール インスタンス間の接続は、仮想ネットワークの外側ではサポートされません。 | 適用なし |
Azure で提供される名前解決
Azure によって提供される名前解決では、基本的な権限を持つ DNS 機能のみが提供されます。 Azure 提供の DNS を使用する場合は、Azure によって DNS ゾーン名とレコードが管理されます。 ユーザーが DNS ゾーン名や DNS レコードのライフ サイクルを制御することはできません。 仮想ネットワークに対応したフル機能の DNS ソリューションが必要な場合は、Azure DNS プライベート ゾーンとお客様が管理する DNS サーバー、または Azure DNS Private Resolver を使用できます。
Azure では、パブリック DNS 名の解決と共に、同じ仮想ネットワークまたはクラウド サービス内に存在する VM とロール インスタンス用に内部の名前解決が提供されます。 クラウド サービス内の VM とインスタンスは、同じ DNS サフィックスを共有するため、ホスト名のみで十分です。 ただし、クラシック デプロイ モデルを使用して展開された仮想ネットワークでは、クラウド サービスが異なると DNS サフィックスも異なります。 このような状況では、異なるクラウド サービス間で名前を解決するために FQDN が必要になります。 Azure Resource Manager デプロイ モデルを使用して展開された仮想ネットワークでは、DNS サフィックスは仮想ネットワーク内のすべての仮想マシン間で一貫性があるため、FQDN は必要ありません。 DNS 名は、VM とネットワーク インターフェイスの両方に割り当てることができます。 Azure 提供の名前解決ではどのような構成も必要ありませんが、前の表で詳しく説明したように、すべてのデプロイ シナリオに適しているわけではありません。
Note
クラウド サービスの Web と Worker ロールを使用した場合、Azure Service Management REST API を使用して、ロール インスタンスの内部 IP アドレスにアクセスすることもできます。 詳細については、「サービス管理 REST API リファレンス」を参照してください。 アドレスは、ロール名とインスタンス数に基づきます。
特徴
Azure で提供される名前解決の機能を次に示します。
使いやすさ。 構成は必要ありません。
高可用性: 独自の DNS サーバーのクラスターを作成および管理する必要はありません。
このサービスは、オンプレミスと Azure の両方のホスト名を解決するために、独自の DNS サーバーで使用できます。
同じクラウド サービス内の VM とロール インスタンスの間で、FQDN を必要とすることなく名前解決を使用できます。
Azure Resource Manager デプロイ モデルを使用する仮想ネットワーク内の VM 間では、FQDN を必要とすることなく名前解決を使用できます。 クラシック デプロイ モデルの仮想ネットワークの場合は、異なるクラウド サービスの名前を解決するときに FQDN が必要になります。
自動生成される名前を使用するのではなく、デプロイの内容がよくわかるホスト名を使用できます。
考慮事項
Azure で提供される名前解決を使用する場合の考慮事項を次に示します。
Azure によって作成される DNS サフィックスは変更できません。
DNS 参照のスコープは仮想ネットワークです。 ある仮想ネットワークに対して作成された DNS 名を、他の仮想ネットワークから解決することはできません。
独自のレコードを手動で登録することはできません。
WINS と NetBIOS はサポートされません。 Windows エクスプローラーに VM を表示することはできません。
ホスト名は DNS 互換である必要があります。 名前に使用できる文字は 0-9、a-z、および "-" のみであり、最初または最後の文字として "-" は使用できません。
DNS クエリ トラフィックは VM ごとに調整されます。 調整は、ほとんどのアプリケーションに影響しません。 要求の調整が発生した場合は、クライアント側のキャッシュが有効になっていることを確認します。 詳細については、「DNS クライアントの構成」を参照してください。
DNS 解決の問題を回避するには、仮想ネットワーク内の仮想マシンごとに異なる名前を使用します。
最初の 180 のクラウド サービス内の VM だけが、クラシック デプロイ モデルの各仮想ネットワークに対して登録されます。 この制限は、Azure Resource Manager の仮想ネットワークには適用されません。
Azure DNS IP アドレスは 168.63.129.16 です。 このアドレスは静的な IP アドレスであり、変更されません。
逆引き DNS の考慮事項
VM の逆引き DNS は、Azure Resource Manager ベースのすべての仮想ネットワークでサポートされています。 [vmname].internal.cloudapp.net という形式の Azure が管理する逆引き DNS (PTR) レコードは、VM を起動すると自動的に追加され、VM を停止 (割り当て解除) すると削除されます。 次の例を参照してください。
C:\>nslookup -type=ptr 10.11.0.4
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
4.0.11.10.in-addr.arpa name = myeastspokevm1.internal.cloudapp.net
逆引き DNS ゾーン internal.cloudapp.net は Azure によって管理され、直接は表示も編集もできません。 [vmname].internal.cloudapp.net 形式の FQDN に対する前方参照も、仮想マシンに割り当てられた IP アドレスへと解決されます。
Azure DNS プライベート ゾーンが仮想ネットワーク リンクを使用して仮想ネットワークにリンクされ、そのリンクで自動登録が有効になっている場合、逆引き DNS クエリは 2 つのレコードを返します。 片方のレコードは [vmname].[privatednszonename] という形式で、他方は [vmname].internal.cloudapp.net という形式です。 次の例を参照してください。
C:\>nslookup -type=ptr 10.20.2.4
Server: UnKnown
Address: 168.63.129.16
Non-authoritative answer:
4.2.20.10.in-addr.arpa name = mywestvm1.internal.cloudapp.net
4.2.20.10.in-addr.arpa name = mywestvm1.azure.contoso.com
上記のように 2 つの PTR レコードが返されると、いずれかの FQDN の前方参照によって VM の IP アドレスが返されます。
逆引き DNS 参照は、他の仮想ネットワークとピアリングされている場合でも、特定の仮想ネットワークにスコープ設定されます。 ピアリングされた仮想ネットワークにある仮想マシンの IP アドレスに対する逆引き DNS クエリは、NXDOMAIN を返します。
Note
逆引き DNS (PTR) レコードは、フォワード プライベート DNS ゾーンに格納されません。 逆引き DNS レコードは、逆引き DNS (in-addr.arpa) ゾーンに格納されます。 vnet に関連付けられている既定の逆引き DNS ゾーンは、表示または編集できません。
Azure DNS プライベート ゾーンを使用して独自の逆引き参照ゾーンを作成し、このゾーンを仮想ネットワークにリンクすることにより、仮想ネットワークで逆引き DNS 機能を無効にできます。 たとえば、仮想ネットワークの IP アドレス空間が 10.20.0.0/16 の場合、空のプライベート DNS ゾーン 20.10.in-addr.arpa を作成し、これを仮想ネットワークにリンクすることができます。 このゾーンは、仮想ネットワークの既定の逆引き参照ゾーンをオーバーライドします。 このゾーンは空です。 これらのエントリを手動で作成しない限り、逆引き DNS は NXDOMAIN を返します。
PTR レコードの自動登録はサポートされていません。 エントリを作成する場合は、手動で入力します。 他のゾーンで有効になっている場合は、仮想ネットワークの自動登録を無効にする必要があります。 この制限は、自動登録が有効になっている場合に 1 つのプライベート ゾーンのみをリンクできるようにするという制限に起因します。 プライベート DNS ゾーンを作成して仮想ネットワークにリンクする方法の詳細については、プライベート DNS のクイックスタート ガイドを参照してください。
Note
Azure DNS プライベート ゾーンはグローバルであるため、逆引き DNS ルックアップを作成して複数の仮想ネットワークをまたにかけることができます。 これを行うには、逆引き参照用の Azure DNS プライベート ゾーン (in-addr.arpa ゾーン) を作成して仮想ネットワークにリンクします。 VM の逆引き DNS レコードは手動で管理する必要があります。
DNS クライアントの構成
このセクションでは、クライアント側のキャッシュとクライアント側の再試行について説明します。
クライアント側のキャッシュ
DNS クエリには、ネットワーク経由で送信する必要がないものもあります。 クライアント側のキャッシュは、ローカル キャッシュから繰り返される DNS クエリを解決することで、待ち時間を短縮し、ネットワークの停止に対する復元性を高めるのに役立ちます。 DNS レコードには、有効期限 (TTL) メカニズムが含まれています。有効期限により、キャッシュは、レコードの鮮度に影響を与えずに、可能な限り長い時間レコードを格納できます。 このため、クライアント側のキャッシュはほとんどの状況に適しています。
既定の Windows DNS クライアントには、組み込みの DNS キャッシュがあります。 Linux ディストリビューションの一部では、既定でキャッシュは含まれていません。 ローカル キャッシュがまだ存在していない場合は、各 Linux VM に DNS キャッシュを追加します。
多数のさまざまな DNS キャッシュ パッケージ (dnsmasq など) を使用できます。 最も一般的なディストリビューションに dnsmasq をインストールする方法を次に示します。
RHEL/CentOS (NetworkManager を使用):
次のコマンドを使用して dnsmasq パッケージをインストールします。
sudo yum install dnsmasq次のコマンドを使用して dnsmasq サービスを有効にします。
systemctl enable dnsmasq.service次のコマンドを使用して dnsmasq サービスを起動します。
systemctl start dnsmasq.serviceテキスト エディターを使用して
prepend domain-name-servers 127.0.0.1;を /etc/dhclient-eth0.conf に追加します。次のコマンドを使用して、ネットワーク サービスを再起動します。
service network restart
Note
dnsmasq パッケージは、Linux で使用可能な多くの DNS キャッシュの 1 つにすぎません。 使用する前に、目的とするニーズに適合するかどうかと、その他のキャッシュがインストールされていないことを確認してください。
クライアント側の再試行
DNS では、主に UDP プロトコルが使用されます。 UDP プロトコルでは、メッセージの配信が保証されないため、再試行ロジックは、DNS プロトコル自体で処理されます。 各 DNS クライアント (オペレーティング システム) では、作成者の選択に応じて、再試行ロジックが異なる場合があります。
- Windows オペレーティング システムでは、1 秒後に再試行されます。その後、2 秒後、4 秒後に再試行され、さらにもう一度その 4 秒後に再試行されます。
- 既定の Linux の設定では、5 秒後に再試行されます。 再試行の仕様を 1 秒間隔の 5 回に変更することをお勧めします。
cat /etc/resolv.conf を使用して、Linux VM の現在の設定を確認します。 options 行を調べます。以下に例を示します。
options timeout:1 attempts:5
resolv.conf ファイルは自動生成され、編集すべきではありません。 options 行を追加する具体的な手順は、ディストリビューションによって異なります。
RHEL/CentOS (NetworkManager を使用):
テキスト エディターを使用して、ファイル /etc/sysconfig/network-scripts/ifcfg-eth0 に行
RES_OPTIONS="options timeout:1 attempts:5"を追加します。次のコマンドを使用して、NetworkManager サービスを再起動します。
systemctl restart NetworkManager.service
独自の DNS サーバーを使用する名前解決
このセクションでは、VM、ロール インスタンス、および Web アプリについて説明します。
注意
Azure DNS Private Resolver を使用すると、仮想ネットワークで VM ベースの DNS サーバーを使用する必要がなくなります。 VM ベースの DNS ソリューションを使用する場合は、次のセクションを参照してください。ただし、コスト削減、組み込みの高可用性、スケーラビリティ、柔軟性など、Azure DNS Private Resolver を使用する利点は多数あります。
VM とロール インスタンス
名前解決のニーズが、Azure で提供される機能の範囲を超えている場合があります。 たとえば、Microsoft Windows Server Active Directory ドメインを使用して、仮想ネットワーク間で DNS 名を解決することが必要である場合があります。 これらのシナリオを可能にするために、Azure では独自の DNS サーバーを使用できます。
仮想ネットワーク内の DNS サーバーは、Azure の再帰的リゾルバーに DNS クエリを転送できます。 この手順により、その仮想ネットワーク内のホスト名を解決することができます。 たとえば、Azure で実行しているドメイン コントローラー (DC) は、そのドメインに対する DNS クエリに応答し、他のすべてのクエリを Azure に転送できます。 クエリを転送することで、VM はオンプレミスのリソース (DC 経由) と Azure で提供されるホスト名 (フォワーダー経由) の両方を参照できます。 Azure の再帰的リゾルバーへのアクセスは、仮想 IP 168.63.129.16 を通じて提供されます。
重要
この設定で VNet 上のカスタム DNS サーバー IP とともに VPN Gateway を使用している場合は、中断されていないサービスを維持するために、Azure DNS IP (168.63.129.16) を一覧に追加する必要があります。
また、DNS の転送により、仮想ネットワーク間の DNS 解決も可能になり、オンプレミスのマシンが Azure で提供されるホスト名を解決できるようになります。 VM のホスト名を解決するために、DNS サーバー VM は、同じ仮想ネットワークに存在し、Azure にホスト名のクエリを転送するように構成されている必要があります。 DNS サフィックスは仮想ネットワークごとに異なるため、条件付きの転送ルールを使用し、解決のために正しい仮想ネットワークに DNS クエリを送信します。 次の図は、2 つの仮想ネットワークと、この方法を使用して仮想ネットワーク間の DNS 解決を行うオンプレミスのネットワークを示しています。 DNS フォワーダーの例は、Azure クイック スタート テンプレートのギャラリーと GitHub で確認できます。
Note
ロール インスタンスは、同じ仮想ネットワーク内の VM の名前解決を実行できます。 これは、VM のホスト名と internal.cloudapp.net DNS サフィックスで構成される FQDN を使用することで可能になります。 ただし、この場合、名前解決は、ロール インスタンスがロール スキーマ (.cscfg ファイル) に定義されている VM 名を持っている場合にのみ成功します。
<Role name="<role-name>" vmName="<vm-name>">
別の仮想ネットワーク内の VM の名前解決 (internal.cloudapp.net サフィックスを使用する FQDN) を実行する必要があるロール インスタンスは、このセクションで説明する方法 (2 つの仮想ネットワーク間で転送を行うカスタム DNS サーバー) を使用してこの操作を行う必要があります。
Azure で提供される名前解決を使用している場合、Azure の動的ホスト構成プロトコル (DHCP) によって内部 DNS サフィックス (.internal.cloudapp.net) が各 VM に提供されます。 ホスト名のレコードは internal.cloudapp.net ゾーン内に存在するため、このサフィックスによってホスト名を解決できます。 独自の名前解決ソリューションを使用している場合、このサフィックスは他の DNS アーキテクチャ (ドメイン参加シナリオなど) に干渉するため、VM には提供されません。 代わりに、Azure によって、機能を持たないプレース ホルダー (reddog.microsoft.com) が提供されます。
必要に応じて、PowerShell または API を使用して、内部 DNS サフィックスを調べることができます。
- Azure Resource Manager デプロイ モデルの仮想ネットワークの場合、ネットワーク インターフェイス REST API、Get-AzNetworkInterface PowerShell コマンドレット、および az network nic show Azure CLI コマンドを通じてサフィックスを取得することができます。
Azure へのクエリの転送がニーズに合わない場合は、独自の DNS ソリューションを提供するか、Azure DNS Private Resolver をデプロイします。
独自の DNS ソリューションを提供する場合は、次のようなソリューションにする必要があります。
たとえば、DDNS 経由で、適切なホスト名解決を提供する。 DDNS を使用するときは DNS レコードの清掃を無効にすることが必要になる場合があります。 Azure の DHCP リースが長く、清掃によって、完了前に DNS レコードが削除されることがあります。
適切な再帰的解決を提供し、外部ドメイン名の解決を可能にする。
対象のクライアントからのアクセスを可能にし (ポート 53 の TCP および UDP)、インターネットへのアクセスを可能にする。
外部エージェントによる脅威を軽減するために、インターネットからのアクセスをセキュリティ保護する。
Note
- 最高のパフォーマンスを得るには、Azure VM を DNS サーバーとして使用するときに IPv6 を無効にする必要があります。
- NSG は、DNS リゾルバー エンドポイントのファイアウォールとして機能します。 NSG セキュリティ規則を変更またはオーバーライドして、DNS リスナー エンドポイントへの UDP ポート 53 (および必要に応じて TCP ポート 53) へのアクセスを許可する必要があります。 ネットワーク上にカスタム DNS サーバーが設定された後、ポート 53 を経由するトラフィックはサブネットの NSG をバイパスします。
重要
Azure DNS サーバーに DNS 要求を転送するカスタム DNS サーバーとして Windows DNS サーバーを使用している場合は、Azure 再帰 DNS サーバーが適切な再帰操作を実行できるように、転送タイムアウト値を 4 秒以上増やしてください。
この問題の詳細については、「フォワーダーと条件付きフォワーダーの解決タイムアウト」 を参照してください。
この推奨事項は、転送タイムアウト値が 3 秒以下の他の DNS サーバー プラットフォームにも適用される場合があります。
これを行わないと、プライベート DNS ゾーンのレコードがパブリック IP アドレスで解決される可能性があります。
Web Apps
仮想ネットワークにリンクされた App Service を使用して構築された Web アプリから同じ仮想ネットワーク内の VM への名前解決を実行する必要があるとします。 Azure (仮想 IP 168.63.129.16) にクエリを転送する DNS フォワーダーがあるカスタム DNS サーバーを設定することに加え、次の手順を実行します。
既に実行していなければ、仮想ネットワークへのアプリの統合に関するページの説明に従って、Web アプリに対する仮想ネットワークの統合を有効にします。
vnet にリンクされた Web アプリ (App Service を使用して構築) から、同じプライベート ゾーンにリンクされていない別の vnet 内の VM への名前解決を実行する必要がある場合は、両方の vnet でカスタム DNS サーバーまたは Azure DNS Private Resolver を使用します。
カスタム DNS サーバーを使用するには、次の手順に従います。
クエリを Azure の再帰的リゾルバー (仮想 IP 168.63.129.16) に転送することもできる VM 上のターゲット仮想ネットワーク内に DNS サーバーを設定します。 DNS フォワーダーの例は、Azure クイック スタート テンプレートのギャラリーと GitHub で確認できます。
VM 上のソース仮想ネットワーク内に DNS フォワーダーを設定します。 この DNS フォワーダーを、ターゲット仮想ネットワーク内の DNS サーバーにクエリを転送するように構成します。
ソース仮想ネットワークの設定内にソース DNS サーバーを構成します。
仮想ネットワークへのアプリの統合に関するページの指示に従って、ソース仮想ネットワークにリンクする App Service Web App に対する仮想ネットワークの統合を有効にします。
Azure DNS Private Resolver を使用するには、「ルールセット リンク」を参照してください。
DNS サーバーの指定
独自の DNS サーバーを使用する場合、Azure では、仮想ネットワークごとに複数の DNS サーバーを指定できます。 また、ネットワーク インターフェイス (Azure Resource Manager の場合) またはクラウド サービス (クラシック デプロイ モデルの場合) ごとに複数の DNS サーバーを指定することもできます。 ネットワーク インターフェイスまたはクラウド サービスに対して指定された DNS サーバーは、仮想ネットワークに対して指定された DNS サーバーよりも優先されます。
Note
DNS サーバーの IP などのネットワーク接続プロパティは、VM 内で直接編集しないでください。 これは、仮想ネットワーク アダプターを交換したときのサービス回復時にネットワーク接続プロパティが消去される可能性があるためです。 これは、Windows VM と Linux VM の両方に適用されます。
Azure Resource Manager デプロイ モデルを使用している場合は、仮想ネットワークとネットワーク インターフェイス用の DNS サーバーを指定できます。 詳細については、仮想ネットワークの管理に関するページとネットワーク インターフェイスの管理に関するページを参照してください。
Note
仮想ネットワークのカスタムの DNS サーバーを選択する場合は、DNS サーバーの少なくとも 1 つの IP アドレスを指定する必要があります。そうしないと、仮想ネットワークは構成を無視し、代わりに Azure で提供される DNS を使用します。
Note
既にデプロイされている仮想ネットワークまたは仮想マシンの DNS 設定を変更した場合、新しい DNS 設定を有効にするには、仮想ネットワーク内の影響を受けるすべての VM で DHCP リースの更新を実行する必要があります。 Windows OS を実行している VM の場合は、その VM で直接 ipconfig /renew を入力することによってこれを行うことができます。 この手順は OS によって異なります。 ご使用の種類の OS の関連ドキュメントを参照してください。
次のステップ
Azure Resource Manager デプロイ モデル: