次の方法で共有

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

  • [アーティクル]

Note

2024 年 6 月 1 日より、新しく作成されたすべての App Service アプリには、名前付け規則 <app-name>-<random-hash>.<region>.azurewebsites.net を使用して一意の既定のホスト名を生成するオプションが備わります。 既存のアプリ名は変更されません。

例: myapp-ds27dh7271aah175.westus-01.azurewebsites.net

詳細については、App Service リソースの一意の既定のホスト名に関するページを参照してください。

この記事では、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 つの仮想ネットワーク統合を意味します。 つまり、1 つの App Service プランでは、最大 2 つのサブネット/仮想ネットワークとの仮想ネットワーク統合を行うことができます。 同じ App Service プラン内のアプリは、特定のサブネットとの仮想ネットワーク統合の 1 つだけを使用できます。つまり、アプリは特定の時点で 1 つの仮想ネットワーク統合しか持つことができません。

サブネットの要件

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

インスタンス サイズをスケールアップ/ダウンすると、スケーリング操作の完了時に App Service プランで使用される IP アドレスの量が一時的に 2 倍になります。 既存のインスタンスのプロビジョニングを解除する前に、新しいインスタンスを完全に動作させる必要があります。 スケール操作は、特定のサブネット サイズでサポートされる実際の使用可能なインスタンスに影響します。 プラットフォームのアップグレードでは、送信トラフィックを中断せずにアップグレードできるようにするために、空き IP アドレスが必要です。 最後に、スケール アップ、スケール ダウン、または操作の完了後、IP アドレスが解放されるまでに少し時間がかかることがあります。 まれに、この操作は最大 12 時間になる可能性があり、急いでスケールイン/スケールアウト、またはスケールアップ/スケールダウンする場合は、最大スケールよりも多くの IP が必要です。

割り当てた後はサブネット サイズを変更できないため、アプリが到達する可能性のあるスケールに対応できるだけの十分な大きさを持つサブネットを使用してください。 プラットフォームのアップグレード用に IP アドレスも予約する必要があります。 サブネットの容量に関する問題を回避するには、計画された最大スケールの 2 倍の IP を割り当て直すことをお勧めします。 64 個のアドレスを持つ /26 は、1 つのマルチテナント App Service プランの最大スケールをカバーします。 Azure portal で仮想ネットワークとの統合の一部としてサブネットを作成する場合、必要な最小サイズは /27 です。 ポータルを介して統合する前にサブネットが既に存在する場合は、/28 サブネットを使用できます。

マルチプラン サブネット参加 (MPSJ) を使用すると、複数の App Service プランを同じサブネットに参加させることができます。 すべての App Service プランは同じサブスクリプション内にある必要がありますが、仮想ネットワークおよびサブネットは別のサブスクリプションに含めることができます。 各 App Service プランの各インスタンスにはサブネットからの IP アドレスが必要であり、MPSJ を使用するにはサブネットの最小サイズ /26 が必要です。 多数または大規模なプランに参加する場合は、より大きなサブネット範囲を計画する必要があります。

Windows Containers 固有の制限

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

計算の例:

App Service プラン インスタンスごとに必要な数: 4 つの Windows Container Apps = 4 つの IP アドレス App Service プラン インスタンスごとに 1 つの IP アドレス 4 + 1 = 5 つの IP アドレス

10 インスタンスの場合: 5 x 10 = App Service プランごとに 50 個の IP アドレス

1 つの App Service プランがあるため、1 x 50 = 50 個の IP アドレス。

さらに、使用される worker レベルで使用可能なコアの数によっても制限されます。 各コアで、3 つのネットワーク ユニットが追加されます。 worker 自体で 1 ユニットを使用し、各仮想ネットワーク接続で 1 ユニットを使用します。 残りのユニットはアプリに使用できます。

計算の例:

4 つのアプリが実行され、仮想ネットワーク統合を使用している App Service プラン インスタンス。 アプリは、2 つの異なるサブネットに接続されています (仮想ネットワーク接続)。 この構成には、7 つのネットワーク ユニット (worker に 1 つ + 接続に 2 つ + アプリに 4 つ) が必要です。 この構成を実行するための最小サイズは I2v2 (4 コア x 3 ユニット = 12 ユニット) です。

I1v2 では、同じ (1 つの) 接続を使用して最大 4 つのアプリを実行することも、2 つの接続を使用して 3 つのアプリを実行することもできます。

アクセス許可

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

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

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

Routes

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

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

申請ルート指定

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

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

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

Note

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

構成ルーティング

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

コンテンツ共有

Azure Functions の既定では、Premium プランで関数アプリをスケーリングするときに、デプロイ ソースとしてコンテンツ共有が使用されます。 仮想ネットワーク統合を介してトラフィックがこのコンテンツ共有にルーティングされるように、追加の設定を構成する必要があります。 詳細については、コンテンツ共有ルーティングを構成する方法に関する記事を参照してください。

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

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

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

バックアップ/復元

App Service にはバックアップと復元が組み込まれていますが、独自のストレージ アカウントにバックアップしたい場合は、カスタムのバックアップと復元機能を使用できます。 仮想ネットワーク統合を通してストレージ アカウントにトラフィックをルーティングする場合は、ルートの設定を構成する必要があります。 仮想ネットワーク統合経由ではデータベース バックアップはサポートされません。

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

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

Note

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

ルーティングのアプリ設定

App Service には、アプリケーションと構成のルーティングを構成するための既存のアプリ設定があります。 両方が存在する場合は、サイトのプロパティによってアプリの設定がオーバーライドされます。 サイトのプロパティには、Azure Policy で監査可能であり、構成時に検証されるという利点があります。 サイトのプロパティの使用をお勧めします。

その場合でも、既存の WEBSITE_VNET_ROUTE_ALL アプリ設定を使ってアプリケーションのルーティングを構成することはできます。

アプリの設定は、一部の構成ルーティング オプションにも存在します。 これらのアプリ設定は、WEBSITE_CONTENTOVERVNET および WEBSITE_PULL_IMAGE_OVER_VNET という名前です。

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

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

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

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

Azure では、UDP ポート 30,000 を使用してネットワーク正常性チェックを行います。 このトラフィックをブロックした場合、アプリに直接の影響はありませんが、Azure サポートがネットワーク関連の問題を検出してトラブルシューティングすることがより難しくなります。

オンプレミスの送信トラフィックをルーティングする場合は、ルート テーブルを使用して、送信トラフィックを 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 のブロックからなる未使用のサブネットが必要です。 MPSJ には、/26 ブロック以上が必要です。
  • アプリと仮想ネットワークが同じリージョンに存在する必要があります。
  • 統合仮想ネットワークで IPv6 アドレス空間を定義することはできません。
  • 統合サブネットでは、サービス エンドポイント ポリシーを有効にすることはできません。
  • 統合アプリがある仮想ネットワークを削除することはできません。 仮想ネットワークを削除する前に、統合を削除してください。
  • 1 つの App Service プランにつき、2 つ以上の仮想ネットワーク統合を持つことはできません。 同じ App Service プラン内の複数のアプリで、同じ仮想ネットワーク統合を使用できます。
  • 仮想ネットワーク統合を使っているアプリがあるときに、アプリまたはプランのサブスクリプションを変更することはできません。

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

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

ピアリング

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

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

仮想ネットワークとの接続および切断は、アプリ レベルで行われます。 複数のアプリで仮想ネットワーク統合に影響する可能性がある操作は、App Service プラン レベルで行われます。 アプリの >[ネットワーク]>[仮想ネットワーク統合] ポータルから、仮想ネットワークに関する詳細を取得できます。 [App Service プラン]>[ネットワーク]>[VNet 統合] ポータルの 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 サポートにお問い合わせください。