Azure App Service と Azure Functions のネットワーク統合を計画して実装する

• 7 分

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

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

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

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

仮想ネットワーク統合により、アプリから仮想ネットワーク内のリソースにアクセスできるようになりますが、仮想ネットワークからそのアプリへの受信プライベート アクセスが許可されるわけではありません。 プライベート サイト アクセスとは、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) と統合サブネットに構成されたサービス エンドポイントのみが仮想ネットワークに送信されます。 インターネットへの送信トラフィックはアプリから直接ルーティングされます。

Windows App Service プランの場合、仮想ネットワーク統合機能では、worker ごとに 2 つの仮想インターフェイスがサポートされます。 worker あたり 2 つの仮想インターフェイスは、App Service プランごとに 2 つの仮想ネットワーク統合を意味します。 つまり、1 つの Windows App Service プランでは、最大 2 つのサブネット/仮想ネットワークとの仮想ネットワーク統合を行うことができます。 同じ App Service プラン内のアプリは、特定のサブネットとの仮想ネットワーク統合の 1 つだけを使用できます。つまり、アプリは特定の時点で 1 つの仮想ネットワーク統合しか持つことができません。 Linux App Service プランでは、プランごとに 1 つの仮想ネットワーク統合のみがサポートされます。

サブネットの要件

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

サイズのスケールアップ/スケールダウン、またはインスタンス数のイン/アウトを行うと、必要なアドレス空間が短時間で 2 倍になります。 スケーリング操作では、同じ数の新しいインスタンスが追加された後、既存のインスタンスが削除されます。 スケール操作は、特定のサブネット サイズでサポートされる実際の使用可能なインスタンスに影響します。 プラットフォームのアップグレードでは、送信トラフィックを中断せずにアップグレードできるようにするために、空き IP アドレスが必要です。 最後に、スケール アップ、スケール ダウン、または操作の完了後、IP アドレスが解放されるまでに少し時間がかかることがあります。

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

計算の例:

App Service プランのインスタンスごとに、次のものが必要です。

• 4 つの Windows コンテナー アプリ = 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 アドレス。

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

アクセス許可

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

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

Routes

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

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

申請ルート指定

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

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

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

構成ルーティング

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

コンテンツ共有

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

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

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

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

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

バックアップ/復元

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

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

Key Vault の参照を使用したアプリの設定では、パブリック ルート経由でシークレットの取得が試みられます。 パブリック トラフィックが 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 の場合は、さらに allow files.pythonhosted.org, pypi.org を行う必要があります。

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

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

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

ピアリング

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

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

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

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

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

価格の詳細

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

トラブルシューティング

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

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

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

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

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

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