アプリを Azure 仮想ネットワークと統合する

  • [アーティクル]

この記事では、Azure App Service の仮想ネットワーク統合機能と、それを App Service のアプリで設定する方法について説明します。 Azure Virtual Network を使用すると、インターネットにルーティングできないネットワークに多くの Azure リソースを配置できます。 App Service の仮想ネットワーク統合機能を使用すると、アプリは仮想ネットワーク内のリソースにアクセスしたり、仮想ネットワークを通じてリソースにアクセスしたりできます。

Note

ゲートウェイに必要な仮想ネットワークの統合に関する情報は、新しい場所に移動しました。

App Service には、次の 2 つのバリエーションがあります。

  • 専用コンピューティング価格レベル。Basic、Standard、Premium、PremiumV2、PremiumV3 が含まれます。
  • 専用のサポート インフラストラクチャを使用して仮想ネットワークに直接デプロイされ、Isolated と IsolatedV2 の価格レベルを使用している App Service Environment。

仮想ネットワーク統合機能は、Azure App Service 専用のコンピューティング価格レベルで使用されます。 アプリが App Service Environment にある場合、アプリは既に仮想ネットワークと統合されており、同じ仮想ネットワーク内のリソースに到達するために仮想ネットワーク統合機能を構成する必要はありません。 すべてのネットワーク機能の詳細については、「App Service のネットワーク機能」を参照してください。

仮想ネットワーク統合により、アプリから仮想ネットワーク内のリソースにアクセスできるようになりますが、仮想ネットワークからそのアプリへの受信プライベート アクセスが許可されるわけではありません。 プライベート サイト アクセスとは、Azure 仮想ネットワーク内など、プライベート ネットワークのみからアプリにアクセスできるようにすることです。 仮想ネットワーク統合は、アプリから仮想ネットワークへの送信呼び出しを行うためだけに使用されます。 受信プライベート アクセスについては、プライベート エンドポイントに関する記事を参照してください。

仮想ネットワーク統合の機能:

  • サポートされている Basic または Standard、Premium、Premium v2、Premium v3、または Elastic Premium の App Service 価格レベルが必要です。
  • TCP と UDP をサポートします。
  • App Service アプリ、関数アプリ、ロジック アプリで機能します。

仮想ネットワーク統合でサポートされない機能の例を次に示します。

  • ドライブのマウント。
  • Windows Server Active Directory ドメイン参加。
  • NetBIOS。

仮想ネットワーク統合は、同じリージョン内の仮想ネットワークへの接続をサポートします。 仮想ネットワーク統合を使用すると、アプリは次のものにアクセスできるようになります。

  • 統合した仮想ネットワーク内のリソース
  • アプリが統合されている仮想ネットワークとピアリングされた仮想ネットワーク内のリソース (グローバル ピアリング接続を含む)
  • Azure ExpressRoute 接続にまたがるリソース。
  • サービス エンドポイントでセキュリティ保護されたサービス
  • プライベート エンドポイントが有効なサービス

仮想ネットワーク統合を使っている場合は、次の Azure ネットワーク機能を使用できます。

  • ネットワーク セキュリティ グループ (NSG) :統合サブネットに配置された NSG を使って送信トラフィックをブロックできます。 仮想ネットワーク統合を使ってアプリへの受信アクセスを提供することはできないため、受信規則は適用されません。
  • ルート テーブル (UDR) :統合サブネット上にルート テーブルを配置して、必要な場所に送信トラフィックを送信できます。
  • NAT ゲートウェイ: NAT ゲートウェイを使うと、専用の送信 IP を取得し、SNAT ポートの枯渇を軽減できます。

仮想ネットワーク統合を有効にする方法を確認してください。

仮想ネットワーク統合のしくみ

App Service 内のアプリは、worker ロールでホストされます。 仮想ネットワーク統合は、委任されたサブネット内のアドレスで仮想インターフェイスを worker ロールにマウントすることによって機能します。 統合元のアドレスはお使いの仮想ネットワーク内にあるため、仮想ネットワーク内の VM と同じように、仮想ネットワーク内に存在するか、仮想ネットワークを経由してアクセスできるほとんどのものに、アクセスできます。

仮想ネットワーク統合のしくみを示す図。

仮想ネットワーク統合が有効になっている場合、アプリは仮想ネットワークを介して送信呼び出しを行います。 アプリのプロパティ ポータルに一覧表示される送信アドレスは、引き続きそのアプリによって使用されるアドレスです。 ただし、送信呼び出しが、統合仮想ネットワークまたはピアリングされた仮想ネットワーク内の仮想マシンまたはプライベート エンドポイントに対して行われる場合、送信アドレスは統合サブネットのアドレスになります。 インスタンスに割り当てられたプライベート IP は、環境変数 WEBSITE_PRIVATE_IP によって公開されます。

すべてのトラフィックのルーティングを有効にすると、すべての送信トラフィックが仮想ネットワークに送られます。 すべてのトラフィック ルーティングが有効でない場合、プライベート トラフィック (RFC1918) と統合サブネットに構成されたサービス エンドポイントのみが仮想ネットワークに送信されます。 インターネットへの送信トラフィックはアプリから直接ルーティングされます。

この機能では、worker ごとに 2 つの仮想インターフェイスがサポートされます。 worker あたり 2 つの仮想インターフェイスは、App Service プランごとに 2 つの仮想ネットワーク統合を意味します。 同じ App Service プラン内のアプリは、特定のサブネットへの仮想ネットワーク統合のうち 1 つだけを使用できます。 アプリで追加の仮想ネットワークまたは同じ仮想ネットワーク内の追加のサブネットに接続する必要がある場合、別の App Service プランを作成する必要があります。 使われる仮想インターフェイスは、顧客が直接アクセスできるリソースではありません。

サブネットの要件

仮想ネットワーク統合は、専用サブネットに依存します。 サブネットを作成すると、Azure サブネットは先頭から 5 つの IP を使います。 プラン インスタンスごとに、統合サブネットから 1 つのアドレスが使用されます。 アプリを 4 つのインスタンスにスケールする場合は、4 つのアドレスが使用されます。

サイズをスケールアップまたはスケールダウンすると、必要なアドレス空間が短期間に 2 倍になります。 スケール操作は、特定のサブネット サイズでサポートされる実際の使用可能なインスタンスに影響します。 次の表は、CIDR ブロックごとの最大使用可能アドレスと、使用可能アドレスが水平スケールに与える影響の両方を示しています。

CIDR ブロック サイズ 使用可能なアドレスの最大数 水平スケールの最大値 (インスタンス)*
/28 11 5
/27 27 13
/26 59 29

*ある時点でサイズまたは SKU のいずれかでスケールアップまたはスケールダウンする必要があることを前提としています。

割り当てた後はサブネット サイズを変更できないため、アプリが到達する可能性のあるスケールに対応できるだけの十分な大きさを持つサブネットを使用してください。 サブネット容量に関する問題を回避するには、64 個のアドレスを持つ /26 を使用してください。 Azure portal で仮想ネットワークとの統合の一部としてサブネットを作成する場合、必要な最小サイズは /27 です。 ポータルを介して統合する前にサブネットが既に存在する場合は、/28 サブネットを使用できます。

Note

Windows Containerは、各 App Service プラン インスタンスについてアプリごとに追加の IP アドレスを使用するため、それに応じてサブネットのサイズを設定する必要があります。 たとえば、4 つのアプリが実行されている 10 個の Windows Container App Service プラン インスタンスがある場合は、水平スケール (アップまたはダウン) をサポートするために 50 個の IP アドレスと追加のアドレスが必要です。

お使いのプラン内のアプリが、別のプラン内のアプリから既に接続されている仮想ネットワークにアクセスできるようにする場合は、既存の仮想ネットワーク統合によって使用されているものとは異なるサブネットを選びます。

アクセス許可

Azure portal や CLI を介して、または virtualNetworkSubnetId サイト プロパティを直接設定するときに、仮想ネットワーク統合を構成するには、サブネットまたは上位レベルで少なくとも次のロールベースのアクセス制御のアクセス許可が必要です。

アクション 説明
Microsoft.Network/virtualNetworks/read 仮想ネットワークの定義を読み取ります
Microsoft.Network/virtualNetworks/subnets/read 仮想ネットワーク サブネットの定義を読み取ります
Microsoft.Network/virtualNetworks/subnets/join/action 仮想ネットワークに参加します。

仮想ネットワークがアプリとは異なるサブスクリプションにある場合、仮想ネットワークがあるサブスクリプションが Microsoft.Web リソース プロバイダーに登録されていることを確認する必要があります。 プロバイダーはこのドキュメントに従って明示的に登録できますが、サブスクリプションで最初の アプリを作成するときに自動的に登録されます。

ルート

仮想ネットワーク統合を通過するトラフィックを制御できます。 仮想ネットワーク統合を構成する場合は、3 種類のルーティングを考慮する必要があります。 アプリケーション ルーティングでは、アプリから仮想ネットワークにルーティングされるトラフィックを定義します。 構成ルーティングは、アプリの起動の前またはその最中に行われる操作に影響を与えます。 例として、コンテナー イメージのプルと、Key Vault の参照を使ったアプリの設定があります。 ネットワーク ルーティングは、アプリと構成の両方のトラフィックが仮想ネットワークから送信される方法を処理する機能です。

アプリケーション ルーティングまたは構成ルーティングのオプションで、仮想ネットワーク統合を通じて送信されるトラフィックを構成できます。 トラフィックは、仮想ネットワーク統合を通じて送信される場合にのみ、ネットワーク ルーティングの対象になります。

アプリケーション ルーティング

アプリケーション ルーティングは、アプリから、その起動後に送信されるトラフィックに適用されます。 起動中のトラフィックについては、「構成ルーティング」を参照してください。 アプリケーション ルーティングを構成するときは、仮想ネットワークにすべてのトラフィックまたはプライベート トラフィック (RFC1918 トラフィックとも呼ばれます) のみをルーティングできます。 この動作を構成するには、 [すべてをルーティング] 設定を使用します。 [すべてをルーティング] が無効になっている場合、アプリはプライベート トラフィックのみを仮想ネットワークにルーティングします。 すべての送信アプリ トラフィックを仮想ネットワークにルーティングする場合は、[すべてをルーティング] が有効になっていることを確認してください。

  • アプリケーションまたは構成のルーティングで構成されたトラフィックのみが、統合サブネットに適用される NSG と UDR の対象になります。
  • [すべてをルーティング] が有効になっている場合、アプリからの送信パブリック トラフィックの送信元アドレスは、まだアプリのプロパティに一覧表示されている IP アドレスの 1 つです。 トラフィックをファイアウォールまたは NAT ゲートウェイ経由でルーティングする場合、送信元 IP アドレスはこのサービスから送信されます。

アプリケーションのルーティング設定方法を確認してください。

Note

SMTP トラフィックが仮想ネットワーク統合を経由してルーティングされる場合、App Service で送信 SMTP 接続 (ポート 25) がサポートされます。 ただし、サポートが可能かどうかは、仮想ネットワークがデプロイされているサブスクリプションの設定によって決まります。 2022 年 8 月 1 日より前に作成された仮想ネットワークまたはサブネットでは、 サブスクリプションから設定を同期するために、仮想ネットワークまたはサブネットへの一時的な構成変更を開始する必要があります。 たとえば、一時的なサブネットの追加、NSG の一時的な関連付けと関連付け解除、サービス エンドポイントの一時的な構成などを行います。 詳細については、Azure でのアウトバウンド SMTP 接続問題のトラブルシューティングに関するページを参照してください。

構成ルーティング

仮想ネットワーク統合を使用している場合は、構成トラフィックの一部を管理する方法を構成できます。 既定では、構成トラフィックはパブリック ルート経由で直接送信されますが、示された個々のコンポーネントについては、仮想ネットワーク統合を通じてルーティングするように明示的に構成できます。

コンテンツ共有

独自のコンテンツ用のストレージの使用は Functions でよく使用され、その場合 Functions アプリの一部としてコンテンツ共有が構成されます。

コンテンツ共有のトラフィックを仮想ネットワーク統合でルーティングするには、ルーティング設定が構成されていることを確認する必要があります。 コンテンツ共有ルーティングを構成する方法に関する記事を参照してください。

ルーティングの構成以外に、サブネットからのトラフィックが構成されているファイアウォールまたはネットワーク セキュリティ グループで、ポート 443 と 445 へのトラフィックが許可されていることを確認する必要があります。

コンテナー イメージのプル

カスタム コンテナーを使う場合は、仮想ネットワーク統合を使用してコンテナーをプルできます。 コンテナー プルのトラフィックを仮想ネットワーク統合でルーティングするには、ルーティング設定が構成されていることを確認する必要があります。 イメージ プルのルーティングを構成する方法に関する記事を参照してください。

Key Vault の参照を使用したアプリの設定

Key Vault の参照を使用したアプリの設定では、パブリック ルート経由でシークレットの取得が試みられます。 パブリック トラフィックが Key Vault でブロックされていて、アプリで仮想ネットワーク統合が使用されている場合、仮想ネットワーク統合を通じてシークレットの取得が試みられます。

注意

  • プライベート ストレージ アカウントへのバックアップ/復元は、現在サポートされていません。
  • プライベート Key Vault からの SSL/TLS 証明書の構成は、現在サポートされていません。
  • プライベート ストレージ アカウントへの App Service ログは、現在サポートされていません。 診断ログを使用し、ストレージ アカウントに対して信頼できるサービスを許可することをお勧めします。

ネットワーク ルーティング

ルート テーブルを使用して、アプリからの送信トラフィックを制限なくルーティングすることができます。 一般的な宛先には、ファイアウォール デバイスまたはゲートウェイを含めることができます。 また、ネットワーク セキュリティ グループ (NSG) を使用して、仮想ネットワークまたはインターネット内のリソースへの送信トラフィックをブロックできます。 統合サブネットに適用された NSG は、統合サブネットに適用されているルート テーブルに関係なく有効になります。

ルート テーブルとネットワーク セキュリティ グループは、仮想ネットワーク統合を通じてルーティングされるトラフィックにのみ適用されます。 詳細については、「アプリケーション ルーティング」と「構成ルーティング」を参照してください。 ルートは、受信アプリ要求からの返信には適用されず、NSG の受信規則は、アプリには適用されません。 仮想ネットワーク統合は、アプリからの送信トラフィックにのみ影響します。 アプリへの受信トラフィックを制御するには、アクセス制限機能またはプライベート エンドポイントを使います。

送信トラフィックに適用するネットワーク セキュリティ グループまたはルート テーブルを構成する場合は、アプリケーションの依存関係を考慮する必要があります。 アプリケーションの依存関係には、実行時にアプリに必要なエンドポイントが含まれます。 これらのエンドポイントは、アプリが呼び出している API とサービスの他に、証明書失効リスト (CRL) チェック エンドポイントや ID/認証エンドポイント (Azure Active Directory など) のような派生エンドポイントである可能性があります。 App Service で継続的デプロイを使用している場合は、型と言語に応じてエンドポイントを許可する必要がある場合もあります。 特に Linux の継続的デプロイの場合は、oryx-cdn.microsoft.io:443 を許可する必要があります。

オンプレミスの送信トラフィックをルーティングする場合は、ルート テーブルを使用して、送信トラフィックを Azure ExpressRoute ゲートウェイに送信できます。 ゲートウェイにトラフィックをルーティングする場合は、外部ネットワークのルートを設定して、応答を返信するようにします。 また、Border Gateway Protocol (BGP) ルートも、アプリのトラフィックに影響を与えます。 ExpressRoute ゲートウェイのようなものから BGP ルートを使用している場合は、アプリの送信トラフィックが影響を受けます。 BGP ルートもユーザー定義のルートと同様に、ルーティング スコープの設定に従ってトラフィックに影響を与えます。

サービス エンドポイント

仮想ネットワーク統合を使用すると、サービス エンドポイントで保護されている Azure サービスに接続できます。 サービス エンドポイントで保護されたサービスにアクセスするには、次の手順に従います。

  1. 統合のための特定のサブネットに接続するために、アプリとの仮想ネットワーク統合を構成します。
  2. 対象のサービスに移動し、統合サブネットに対してサービス エンドポイントを構成します。

プライベート エンドポイント

プライベート エンドポイントを呼び出す場合は、DNS 参照がプライベート エンドポイントに解決されることを確認します。 この動作は、次のいずれかの方法で実現できます。

  • Azure DNS プライベート ゾーンと統合する。 仮想ネットワークにカスタム DNS サーバーがない場合は、ゾーンが仮想ネットワークにリンクされたときに自動で統合が実行されます。
  • アプリで使用される DNS サーバーでプライベート エンドポイントを管理する。 構成を管理するには、プライベート エンドポイントの IP アドレスを把握している必要があります。 次に、A レコードを使用して、アクセスしようとしているエンドポイントがそのアドレスを指すようにします。
  • Azure DNS プライベート ゾーンに転送する独自の DNS サーバーを構成します。

Azure DNS プライベート ゾーン

仮想ネットワークに統合されたアプリでは、仮想ネットワークが構成されているのと同じ DNS サーバーが使用されます。 カスタム DNS が指定されていない場合は、Azure の既定の DNS と、仮想ネットワークにリンクされているすべてのプライベート ゾーンが使用されます。

制限事項

仮想ネットワーク統合を使う場合、いくつかの制限があります。

  • この機能は、Premium v2 と Premium v3 のすべての App Service デプロイから使用できます。 また、Basic および Standard レベルでも使用できますが、新しい App Service のデプロイからのみ利用できます。 以前のデプロイを使用している場合は、Premium v2 App Service プランからのみ、この機能を使用できます。 Basic または Standard App Service プランでこの機能を使用できるようにするには、Premium v3 App Service プランでアプリを作成します。 それらのプランは、最新のデプロイでのみサポートされます。 プランを作成した後に、必要に応じてスケールダウンできます。
  • この機能は、App Service Environment にある Isolated プランのアプリでは使用できません。
  • 従来の仮想ネットワークでは、ピアリング接続でリソースにアクセスすることはできません。
  • この機能を使用するには、Azure Resource Manager 仮想ネットワークで、/28 より大きい IPv4 のブロックからなる未使用のサブネットが必要です。
  • アプリと仮想ネットワークが同じリージョンに存在する必要があります。
  • 統合仮想ネットワークで IPv6 アドレス空間を定義することはできません。
  • 統合サブネットでは、サービス エンドポイント ポリシーを有効にすることはできません。
  • 統合サブネットは、1 つの App Service プランでしか使用できません。
  • 統合アプリがある仮想ネットワークを削除することはできません。 仮想ネットワークを削除する前に、統合を削除してください。
  • 1 つの App Service プランにつき、2 つ以上の仮想ネットワーク統合を持つことはできません。 同じ App Service プラン内の複数のアプリで、同じ仮想ネットワーク統合を使用できます。
  • 仮想ネットワーク統合を使っているアプリがあるときに、アプリまたはプランのサブスクリプションを変更することはできません。

オンプレミスのリソースにアクセスする

仮想ネットワーク経由でオンプレミスのリソースにアクセスするために、仮想ネットワーク統合機能に対する追加の構成は必要ありません。 必要なのは、単に ExpressRoute またはサイト間 VPN を使用して仮想ネットワークをオンプレミスのリソースに接続することだけです。

ピアリング

仮想ネットワーク統合でピアリングを使う場合、それ以上の構成を行う必要はありません。

仮想ネットワーク統合の管理

仮想ネットワークとの接続および切断は、アプリ レベルで行われます。 複数のアプリで仮想ネットワーク統合に影響する可能性がある操作は、App Service プラン レベルで行われます。 アプリの >[ネットワーク]>[仮想ネットワーク統合] ポータルから、仮想ネットワークに関する詳細を取得できます。 [App Service プラン]>[ネットワーク]>[仮想ネットワーク統合] ポータルの App Service プラン レベルでも、同様の情報が表示されます。

仮想ネットワーク統合インスタンスのアプリケーション ビューで、アプリケーションを仮想ネットワークから切り離し、アプリケーションのルーティングを構成できます。 仮想ネットワークからアプリを切断するには、 [切断] を選択します。 仮想ネットワークから切断すると、アプリが再起動されます。 切断によって仮想ネットワークが変更されることはありません。 サブネットは削除されません。 その後で仮想ネットワークを削除する必要がある場合は、まず仮想ネットワークからアプリを切断します。

インスタンスに割り当てられたプライベート IP は、環境変数 WEBSITE_PRIVATE_IP によって公開されます。 Kudu コンソールの UI にも、アプリで使用できる環境変数の一覧が表示されます。 この IP は、統合されたサブネットのアドレス範囲から割り当てられます。 この IP は、Azure 仮想ネットワークを通じてリソースに接続するために アプリで使用されます。

Note

WEBSITE_PRIVATE_IP の値は、必ず変更されます。 ただし、これは統合サブネットのアドレス範囲内の IP であるため、アドレス範囲全体からのアクセスを許可する必要があります。

価格の詳細

仮想ネットワーク統合機能には、App Service プランの価格レベルの料金を超える追加の使用料金はありません。

トラブルシューティング

機能は簡単にセットアップできますが、問題が発生しないという意味ではありません。 目的のエンドポイントへのアクセスに問題が発生した場合、監視している内容に応じてさまざまな実行可能な手順があります。 詳細については、仮想ネットワーク統合トラブルのシューティング ガイドを参照してください。

Note

  • 仮想ネットワーク統合は、App Service の Docker Compose シナリオではサポートされていません。
  • アクセス制限は、プライベート エンドポイント経由で受信するトラフィックには適用されません。

ネットワーク統合を切断する前に App Service プランまたは アプリを削除する

最初に 仮想ネットワーク統合を切断せずにアプリまたは App Service プランを削除した場合、削除したリソースとの統合に使われた仮想ネットワークまたはサブネットに対して、更新または削除操作を実行することはできません。 サブネット委任 'Microsoft. Web/serverFarms' はサブネットに割り当てられたままになり、更新または削除操作を実行できません。

サブネットまたは仮想ネットワークをもう一度更新または削除するには、仮想ネットワーク統合を再作成してから切断する必要があります。

  1. App Service プランとアプリを再作成します (以前とまったく同じ アプリ名を使う必要があります)。
  2. Azure portal のアプリの [ネットワーク] に移動し、仮想ネットワーク統合を設定します。
  3. 仮想ネットワーク統合を構成したら、[切断] ボタンを選びます。
  4. App Service プランまたはアプリを削除します。
  5. サブネットまたは仮想ネットワークを更新または削除します。

これらの手順に従っても仮想ネットワーク統合に関する問題が引き続き発生する場合は、Microsoft サポートにお問い合わせください。