英語で読む

次の方法で共有

Azure Functions のネットワーク オプション

  • [アーティクル]

この記事では、Azure Functions のホスティング オプションで利用できるネットワーク機能について説明します。 以下に示すネットワーク オプションは、受信ネットワーク機能と送信ネットワーク機能として分類することができます。 受信機能を使用すると、アプリに対するアクセスを制限できます。一方、送信機能を使用すると、仮想ネットワークでセキュリティ保護されているリソースに接続でき、送信トラフィックのルーティング方法を制御することができます。

ホスティング モデルには、さまざまなレベルのネットワーク分離機能があります。 正しいものを選択することで、ネットワーク分離の要件を満たすことができます。

機能 Flex 従量課金プラン 従量課金プラン Premium プラン 専用プラン/ASE Container Apps1
受信 IP の制限 ✔ ✔ ✔ ✔ ✔
受信プライベート エンドポイント ✔ ✔ ✔
仮想ネットワークの統合 ✔ ✔2 ✔3 ✔
送信 IP の制限 ✔ ✔ ✔ ✔
  1. 詳細については、「Azure Container Apps 環境でのネットワーク」を参照してください。
  2. 仮想ネットワーク トリガーを使用する場合、特別な考慮事項があります。
  3. ゲートウェイが必要な仮想ネットワーク統合をサポートするのは、専用/ASE プランのみです。

クイックスタート リソース

次のリソースを使用して、Azure Functions のネットワーク シナリオをすぐに開始できます。 これらのリソースは、記事全体で参照されています。

受信ネットワークの機能

次の機能を使用すると、関数アプリへの受信要求をフィルター処理できます。

受信アクセス制限

アクセス制限を使用すると、アプリへのアクセスを許可または拒否される IP アドレスの優先順位付きリストを定義できます。 この一覧には、IPv4 と IPv6 のアドレス、またはサービス エンドポイントを使用する特定の仮想ネットワーク サブネットを含めることができます。 1 つ以上のエントリがある場合、リストの最後にあるものは暗黙的に "すべて拒否" になります。 IP 制限は、すべての関数ホスティング オプションで有効です。

アクセス制限は、Flex 従量課金プラン、エラスティック Premium、従量課金制、App Service で使用できます。

注意

ネットワーク制限が適用されると、仮想ネットワーク内からか、または Azure portal へのアクセスに使用しているコンピューターの IP アドレスを [信頼された宛先のリスト] に入れている場合にのみ、デプロイを行うことができます。 ただし、ポータルを使用して関数を管理することもできます。

詳細については、「Azure App Service の静的なアクセス制限」を参照してください。

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

Azure プライベート エンドポイントは、Azure Private Link を使用するサービスに、プライベートで安全に接続するためのネットワーク インターフェイスです。 プライベート エンドポイントでは、仮想ネットワークのプライベート IP アドレスを使用して、サービスが仮想ネットワークに実質的に組み込まれます。

Flex 従量課金、エラスティック Premium、専用 (App Service) の各プランでホストされている機能にプライベート エンドポイントを使用できます。

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

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

詳細については、Web Apps でのプライベート エンドポイントの使用に関する記事を参照してください。

ストレージやサービス バスなどのプライベート エンドポイント接続を持つその他のサービスを呼び出すには、必ずプライベート エンドポイントへの送信呼び出しを行うようにアプリを構成してください。 関数アプリのストレージ アカウントでプライベート エンドポイントを使用する方法の詳細については、「お使いのストレージ アカウントを仮想ネットワークに制限する」をご覧ください。

サービス エンドポイント

サービス エンドポイントを使用すると、選択した仮想ネットワーク サブネットに多数の Azure サービスを制限し、より高度なセキュリティを実現できます。 リージョン仮想ネットワーク統合を使用すると、関数アプリは、サービス エンドポイントで保護されている Azure サービスに接続できます。 この構成は、仮想ネットワークの統合をサポートするすべての計画でサポートされています。 セキュリティで保護されているサービス エンドポイントにアクセスするには、次の手順に従います。

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

詳細については、「仮想ネットワーク サービス エンドポイント」を参照してください。

サービス エンドポイントの使用

特定のサブネットへのアクセスを制限するには、種類が仮想ネットワークである制限規則を作成します。 その後、アクセスを許可または拒否するサブスクリプション、仮想ネットワーク、およびサブネットを選択できます。

選んだサブネットの Microsoft.Web でサービス エンドポイントがでまだ有効になっていない場合は、[見つからない Microsoft.Web サービス エンドポイントを無視する] チェック ボックスをオンにしていない限り、自動的に有効になります。 サービス エンドポイントをアプリで有効にしてサブネットでは有効にしないというシナリオは、主としてサブネット上でそれらを有効にするためのアクセス許可があるかどうかに依存します。

サブネット上でサービス エンドポイントを有効にするために他のユーザーが必要な場合は、 [見つからない Microsoft.Web サービス エンドポイントを無視する] チェック ボックスをオンにします。 アプリをサービス エンドポイント用に構成し、後でサブネットで有効にします。

種類として仮想ネットワークが選択された [IP 制限の追加] ウィンドウのスクリーンショット。

App Service Environment で実行されているアプリへのアクセスを制限するために、サービス エンドポイントを使うことはできません。 アプリが App Service Environment 内にあるときは、IP アクセス規則を適用することでアプリへのアクセスを制御できます。

サービス エンドポイントを設定する方法については、Azure Functions のプライベート サイト アクセスの設定に関するページ参照してください。

送信ネットワーク機能

このセクションの機能を使って、アプリで行われる送信接続を管理できます。

仮想ネットワークの統合

このセクションでは、アプリからのデータ送信を制御するために Azure Functions でサポートされる機能について詳しく説明します。

仮想ネットワーク統合により、関数アプリは仮想ネットワーク内のリソースにアクセスできます。 統合されると、アプリは、送信トラフィックを仮想ネットワーク経由でルーティングします。 これにより、アプリは、選択したサブネットからのトラフィックのみを許可するルールを使用して、プライベート エンドポイントまたはリソースにアクセスできます。 宛先が仮想ネットワーク外部の IP アドレスである場合でも、NAT Gateway を構成していない限り、ソース IP はアプリのプロパティにリストされているアドレスのいずれかから送信されます。

Azure Functions では、2 種類の仮想ネットワーク統合がサポートされています。

仮想ネットワーク統合を設定する方法については、仮想ネットワーク統合の有効化に関する記事を参照してください。

リージョンでの仮想ネットワーク統合

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

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

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

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

注意

すべての送信トラフィックを仮想ネットワークにルーティングする場合は、統合サブネットに適用される NSG と UDR に従います。 仮想ネットワークに統合されている場合、トラフィックを他の場所に送信するルートを指定しない限り、パブリック IP アドレスへの関数アプリの送信トラフィックは、引き続きアプリのプロパティにリストされているアドレスから送信されます。

リージョン仮想ネットワーク統合ではポート 25 を使用できません。

Flex 従量課金プランに関する考慮事項:

  • こちらの手順に従って、Microsoft.App Azure リソース プロバイダーがサブスクリプションで有効になっていることを確認します。 これは、サブネットの委任に必要です。
  • Flex 従量課金プランで実行する場合に必要なサブネットの委任は、Microsoft.App/environments です。 これは、委任要件が異なるエラスティック Premium および専用 (App Service) とは異なります。
  • アプリが 40 個を超えてスケーリングする場合でも、1 つの関数アプリに対して最大 40 個の IP アドレスを使用するように計画できます。 たとえば、同じサブネットに統合されている Flex 従量課金関数アプリが 15 個ある場合、最大で 15 x 40 = 600 個の IP アドレスの使用を計画する必要があります。 この制限は変更される可能性があり、実施されていません。
  • 他の目的 (プライベートまたはサービス エンドポイント、または他のホスティング プランやサービスへの委任など) に既に使用されているサブネットは使用できません。 同じサブネットを複数の Flex 従量課金アプリで共有できますが、ネットワーク リソースがこれらの関数アプリ間で共有されるため、1 つの関数アプリが同じサブネット上の他の関数アプリのパフォーマンスに影響する可能性があります。

エラスティック Premium、専用 (App Service)、Container Apps プランに関する考慮事項:

  • この機能は、エラスティック Premium と App Service Premium V2 および Premium V3 で使用できます。 また、Standard でも使用できますが、新しい App Service のデプロイからのみ利用できます。 以前のデプロイを使用している場合は、Premium v2 App Service プランからのみ、この機能を使用できます。 Standard App Service プランでこの機能を使用できるようにするには、Premium V3 App Service プランでアプリを作成します。 それらのプランは、最新のデプロイでのみサポートされます。 その後、必要に応じてスケールダウンできます。
  • この機能は、App Service Environment にある Isolated プランのアプリでは使用できません。
  • アプリと仮想ネットワークが同じリージョンに存在する必要があります。
  • この機能には、Azure Resource Manager 仮想ネットワーク内に /28 以上の未使用のサブネットが必要です。
  • 統合サブネットは、1 つの App Service プランでしか使用できません。
  • App Service プランごとに最大 2 つのリージョン仮想ネットワーク統合を使用できます。 同じ App Service プラン内の複数のアプリが、同じ統合サブネットを使用できます。
  • 統合アプリがある仮想ネットワークを削除することはできません。 仮想ネットワークを削除する前に、統合を削除してください。
  • リージョン仮想ネットワーク統合を使用しているアプリがあるときに、アプリまたはプランのサブスクリプションを変更することはできません。

仮想ネットワーク統合を有効にす

  1. Azure portal の関数アプリで、[ネットワーク] を選択し、[VNet 統合] で [構成するにはここをクリック] を選択します。

  2. [Add VNet]\(VNet の追加) を選択します。

    アプリの仮想ネットワーク統合を有効にすることができる [VNet 統合] ページのスクリーンショット。

  3. ドロップダウン リストには、お使いのサブスクリプションで同じリージョンに存在するすべての Azure Resource Manager 仮想ネットワークが含まれます。 統合する仮想ネットワークを選択します。

    VNet の選択

    • Flex 従量課金およびエラスティック Premium ホスティング プランは、リージョンの仮想ネットワーク統合のみをサポートします。 仮想ネットワークが同じリージョン内にある場合、新しいサブネットを作成するか、空の既存のサブネットを選択します。

    • 別のリージョンの仮想ネットワークを選択するには、ポイント対サイトが有効になっている仮想ネットワーク ゲートウェイがプロビジョニングされている必要があります。 リージョン間の仮想ネットワーク統合は Dedicated プランでのみサポートされますが、グローバル ピアリングはリージョン仮想ネットワーク統合と連携します。

統合中にアプリは再起動されます。 統合が完了すると、統合されている仮想ネットワークの詳細が表示されます。 既定では、[ルートすべて] が有効になり、すべてのトラフィックが仮想ネットワークにルーティングされます。

プライベート トラフィック (RFC1918 トラフィック) のみをルーティングする場合は、App Service に関するこちらの記事の手順に従ってください。

サブネット

仮想ネットワーク統合は、専用サブネットに依存します。 サブネットをプロビジョニングすると、Azure サブネットは先頭から 5 つの IP を失います。 エラスティック Premium と App Service の各プランの場合、プラン インスタンスごとに統合サブネットから 1 つのアドレスが使用されます。 アプリを 4 つのインスタンスにスケールする場合は、4 つのアドレスが使用されます。 Flex 従量課金の場合、これは適用されず、インスタンスは IP アドレスを共有します。

エラスティック Premium および専用 (App Service) プランでは、インスタンスのサイズをスケールアップまたはスケールダウンすると、必要なアドレス空間が短時間で 2 倍になります。 これは、特定のサブネット サイズでサポートされる実際の使用可能なインスタンスに影響します。 次のテーブルに、CIDR ブロック 1 つにつき利用可能なアドレスの最大数と、水平スケーリングに対する効果を記載します。

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

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

割り当てた後はサブネット サイズを変更できないため、アプリが到達する可能性のあるスケールに対応できるだけの十分な大きさを持つサブネットを使用してください。 Functions のエラスティック Premium プランのサブネット容量に関する問題を回避するには、Windows では /24 で 256 アドレス、Linux では /26 で 64 アドレスを使用する必要があります。 Azure portal で仮想ネットワークとの統合の一部としてサブネットを作成する場合、Windows と Linux でそれぞれ、/24 と /26 の最小サイズが必要です。

Flex 従量課金プランを使用すると、Flex 従量課金プランで実行されている複数のアプリを同じサブネットに統合できます。 これは、エラスティック Premium および専用 (App Service) ホスティング プランには当てはまりません。 これらのプランでは、各 App Service プランに接続できる仮想ネットワークは 2 つだけです。 単一の App Service プランの複数のアプリは同じサブネットに参加できますが、別のプランのアプリは、その同じサブネットを使用できません。

この機能は、カスタム コンテナーを含め、Windows と Linux の両方のアプリで完全にサポートされています。 すべての動作は、Windows アプリと Linux アプリ間で同じです。

ネットワーク セキュリティ グループ

仮想ネットワーク内のリソース間のトラフィックは、ネットワーク セキュリティ グループを使用して制御できます。 たとえば、アプリの送信トラフィックが仮想ネットワーク内のリソースに到達するか、またはネットワークから離れるのをブロックするセキュリティ規則を作成できます。 これらのセキュリティ規則は、仮想ネットワーク統合が構成されたアプリに適用されます。 パブリック アドレスへのトラフィックをブロックするには、仮想ネットワーク統合が必要であり、[すべてをルーティング] を有効にする必要があります。 仮想ネットワーク統合はアプリからの送信トラフィックのみに影響を与えるため、NSG での受信規則はアプリに適用されません。

アプリへの受信トラフィックを制御するには、アクセス制限機能を使用します。 統合サブネットに適用される NSG は、統合サブネットに適用されているルートに関係なく有効になります。 関数アプリが、[すべてをルーティング] が有効になっている仮想ネットワークに統合されており、統合サブネット上のパブリック アドレス トラフィックに影響するルートがない場合でも、すべての送信トラフィックは、統合サブネットに割り当てられた NSG の対象になります。 [すべてをルーティング] が有効になっていない場合、NSG は RFC1918 トラフィックにのみ適用されます。

ルート

ルート テーブルを使用して、アプリからの送信トラフィックを任意の場所にルーティングすることができます。 既定では、ルート テーブルは、RFC1918 の送信先トラフィックのみに影響を与えます。 [すべてをルーティング] が有効になっている場合、すべての送信呼び出しが影響を受けます。 [すべてをルーティング] が無効になっている場合、ルート テーブルの影響を受けるのはプライベート トラフィック (RFC1918) のみです。 統合サブネット上に設定されているルートは、受信アプリ要求への応答には影響を与えません。 一般的な宛先には、ファイアウォール デバイスまたはゲートウェイを含めることができます。

オンプレミスのすべての送信トラフィックをルーティングする場合は、ルート テーブルを使用して、すべての送信トラフィックを ExpressRoute ゲートウェイに送信できます。 ゲートウェイにトラフィックをルーティングする場合は、外部ネットワークのルートを設定して、応答を返信するようにしてください。

また、Border Gateway Protocol (BGP) ルートも、アプリのトラフィックに影響を与えます。 ExpressRoute ゲートウェイのようなものから BGP ルートを使用している場合は、アプリの送信トラフィックが影響を受けます。 既定では、BGP ルートは、RFC1918 の送信先トラフィックにのみ影響を与えます。 関数アプリが [すべてをルーティング] が有効になっている仮想ネットワーク 統合されている場合、すべての送信トラフィックは BGP ルートの影響を受ける可能性があります。

送信 IP の制限

送信 IP の制限は、Flex 従量課金プラン、エラスティック Premium プラン、App Service プラン、App Service Environment で利用できます。 App Service Environment が展開されている仮想ネットワークの送信制限を構成することができます。

エラスティック Premium プランまたは App Service プランの関数アプリを仮想ネットワークと統合した場合でも、アプリは既定でインターネットへの送信呼び出しを行うことができます。 [すべてをルーティング] が有効になっている VNet と関数アプリを統合することにより、すべての送信トラフィックが仮想ネットワークに強制的に送信されます。この場合は、ネットワーク セキュリティ グループのルールを使用してトラフィックを制限できます。 Flex 従量課金の場合、すべてのトラフィックは既に仮想ネットワーク経由でルーティングされているため、[すべてをルーティング] は必要ありません。

仮想ネットワークを使用して送信 IP を制御する方法については、Azure 仮想ネットワークの NAT ゲートウェイを使用した Azure Functions の送信 IP 制御に関するチュートリアルを参照してください。

Azure DNS プライベート ゾーン

アプリを仮想ネットワークと統合すると、仮想ネットワークが構成されているのと同じ DNS サーバーが使用され、仮想ネットワークにリンクされている Azure DNS プライベート ゾーンと連携します。

自動化

次の API では、リージョンでの仮想ネットワーク統合をプログラミングで管理できます。

  • Azure CLI: az functionapp vnet-integration コマンドを使用し、リージョンでの仮想ネットワーク統合を追加、一覧表示、または削除します。
  • ARM テンプレート:リージョンでの仮想ネットワーク統合は、Azure Resource Manager テンプレートを使用することで有効にできます。 完全な例については、こちらの関数クイックスタート テンプレート ページを参照してください。

ハイブリッド接続

ハイブリッド接続は、他のネットワークのアプリケーション リソースにアクセスするために使用できる Azure Relay の機能です。 アプリからアプリケーション エンドポイントにアクセスできます。 アプリケーションにアクセスするために使用することはできません。 ハイブリッド接続は、Windows で実行されている、従量課金プラン以外のすべての関数に使用できます。

Azure Functions で使用されるとき、各ハイブリッド接続は、単一の TCP ホストとポートの組み合わせに相互に関連付けられます。 つまり、TCP リッスン ポートにアクセスしている限り、任意のオペレーティング システムの任意のアプリケーションがハイブリッド接続のエンドポイントになることができます。 ハイブリッド接続機能では、アプリケーション プロトコルやアクセス先は認識されません。 ネットワーク アクセスを提供するだけです。

詳細については、ハイブリッド接続に関する App Service ドキュメントを参照してください。 これらの同じ構成手順を Azure Functions に使用できます。

重要

ハイブリッド接続は、関数アプリが Windows で実行されている場合にのみサポートされます。 Linux アプリはサポートされません。

仮想ネットワーク経由で Azure Services に接続する

仮想ネットワーク統合により、関数アプリは仮想ネットワーク内のリソースにアクセスできます。 このセクションでは、アプリを特定のサービスに接続する際に考慮すべき検討事項について概説します。

お使いのストレージ アカウントを仮想ネットワークに制限する

注意

ストレージ アカウントでプライベート エンドポイントが有効になっている関数アプリをすばやくデプロイするには、次のテンプレートをご覧ください: Azure Storage プライベート エンドポイントを使用する関数アプリ。

関数アプリを作成するときは、BLOB、Queue、および Table Storage をサポートする汎用の Azure Storage アカウントを作成またはリンクする必要があります。 このストレージ アカウントは、サービス エンドポイントまたはプライベート エンドポイントで保護されているものに置き換えることができます。

ネットワーク制限付きストレージ アカウントは、Flex 従量課金、エラスティック Premium、専用 (App Service) プランの関数アプリで使用できます。従量課金プランはサポートされていません。 エラスティック Premium および専用プランの場合、プライベート コンテンツ共有ルーティングが構成されていることを確認する必要があります。 仮想ネットワークでセキュリティ保護されたストレージ アカウントを使用して関数アプリを構成する方法については、「お使いのストレージ アカウントを仮想ネットワークに制限する」を参照してください。

Key Vault 参照を使用する

Azure Key Vault 参照を使用すると、コードの変更を必要とせずに、Azure Functions アプリケーションで Azure Key Vault のシークレットを使用することができます。 Azure Key Vault は、アクセス ポリシーと監査履歴を完全制御する、一元化されたシークレット管理を提供するサービスです。

アプリに対して仮想ネットワーク統合が構成されている場合、Key Vault 参照を使用して、ネットワークで制限されたコンテナーのシークレットを取得することができます。

仮想ネットワーク トリガー (非 HTTP)

ワークロードでは、仮想ネットワークによって保護されたイベント ソースからアプリをトリガーすることが必要な場合があります。 HTTP 以外のトリガー ソースから受信したイベントの数に基づいてアプリを動的にスケーリングする場合は、次の 2 つのオプションがあります。

専用 (App Service) プランで実行されている関数アプリは、イベントに基づいて動的にスケーリングされません。 代わりに、スケールアウトは、定義した自動スケーリング規則によって決まります。

仮想ネットワーク トリガーを使用するエラスティック Premium プラン

エラスティック Premium プランでは、仮想ネットワークでセキュリティ保護されたサービスによってトリガーされる関数を作成できます。 これらの非 HTTP トリガーは、"仮想ネットワーク トリガー" と呼ばれます。

既定では、仮想ネットワーク トリガーによって、関数アプリが、プレウォームされたインスタンス数を超えてスケーリングされることはありません。 ただし、特定の拡張機能では、関数アプリの動的なスケーリングが行われる仮想ネットワーク トリガーがサポートされています。 次のいずれかの方法を使うと、サポートされている拡張機能の関数アプリでこの "動的スケーリング監視" を有効にできます。

  1. Azure portal で関数アプリに移動します。

  2. [設定] で [構成] を選び、[関数のランタイム設定] タブで [Runtime Scale Monitoring] (ランタイム スケール監視) を [オン] に設定します。

  3. [保存] を選んで関数アプリの構成を更新し、アプリを再起動します。

VNETToggle

ヒント

仮想ネットワーク トリガーの監視を有効にすると、アプリケーションのパフォーマンスに影響する可能性がありますが、この影響は非常に小さいはずです。

仮想ネットワーク トリガーの動的スケーリング監視のサポートは、Functions ランタイムのバージョン 1.x では利用できません。

この表の拡張機能では、仮想ネットワーク トリガーの動的スケーリング監視がサポートされています。 最適なスケーリング パフォーマンスを得るには、ターゲット ベースのスケーリングもサポートするバージョンにアップグレードする必要があります。

拡張機能 (最小バージョン) 実行時スケーリング監視のみ ターゲット ベースのスケーリングあり
Microsoft.Azure.WebJobs.Extensions.CosmosDB > 3.0.5 > 4.1.0
Microsoft.Azure.WebJobs.Extensions.DurableTask > 2.0.0 該当なし
Microsoft.Azure.WebJobs.Extensions.EventHubs > 4.1.0 > 5.2.0
Microsoft.Azure.WebJobs.Extensions.ServiceBus > 3.2.0 > 5.9.0
Microsoft.Azure.WebJobs.Extensions.Storage > 3.0.10 > 5.1.0*

* Queue Storage のみ。

重要

仮想ネットワーク トリガーの監視を有効にすると、これらの拡張機能のトリガーだけが、アプリを動的にスケーリングできます。 表にない拡張機能のトリガーも使用できますが、事前にウォーミングされたインスタンス数を超えてスケーリングが行われることはありません。 すべてのトリガーとバインド拡張機能の完全な一覧については、トリガーとバインドに関する記事をご覧ください。

仮想ネットワーク トリガーを使用した App Service プランと App Service Environment

関数アプリが App Service プランまたは App Service Environment のいずれかで実行される場合、仮想ネットワークでセキュリティ保護されたリソースによってトリガーされる関数を記述できます。 関数が正しくトリガーされるようにするには、トリガー接続で定義されているリソースにアクセスできる仮想ネットワークに、アプリを接続する必要があります。

たとえば、仮想ネットワークからのみトラフィックを受け入れるように Azure Cosmos DB を構成するとします。 この場合、その仮想ネットワークとの仮想ネットワーク統合を提供する App Service プランで関数アプリをデプロイする必要があります。 統合により、該当の Azure Cosmos DB リソースによって関数がトリガーされるようになります。

テストに関する考慮事項

プライベート エンドポイントを使用して関数アプリで関数をテストする場合、そのネットワーク内の仮想マシン (VM) など、同じ仮想ネットワーク内からテストを行う必要があります。 その VM からポータルで [コードとテスト] オプションを使用するには、次の CORS オリジンを関数アプリに追加する必要があります。

  • https://functions-next.azure.com
  • https://functions-staging.azure.com
  • https://functions.azure.com
  • https://portal.azure.com

プライベート エンドポイントまたは他のアクセス制限を使って関数アプリへのアクセスを制限している場合は、サービス タグ AzureCloud を許可リストに追加する必要もあります。 許可リストを更新するには:

  1. 関数アプリに移動し、[設定]>[ネットワーク] を選んでから、[受信アクセスの構成]>[パブリック ネットワーク アクセス] を選びます。

  2. [パブリック ネットワーク アクセス] が [選択した仮想ネットワークと IP アドレスから有効] に設定されていることを確認します。

  3. [サイトのアクセスとルール] の [規則を追加する]:

    1. [ソース] 設定の [種類] として Service Tag、[サービス タグ] として AzureCloud を選びます。

    2. アクションが [許可] であることを確認し、目的の名前と優先度を設定します。

トラブルシューティング

機能は簡単にセットアップできますが、問題が発生しないという意味ではありません。 目的のエンドポイントへのアクセスに関して問題が発生した場合は、アプリのコンソールからの接続をテストするために、いくつかのユーティリティを利用できます。 利用できるコンソールが 2 つあります。 1 つは Kudu コンソールで、もう 1 つは Azure portal 内のコンソールです。 アプリから Kudu コンソールにアクセスするには、[ツール]>[Kudu] の順に移動します。 [サイト名].scm.azurewebsites.net で Kudo コンソールにアクセスすることもできます。 Web サイトが読み込まれたら、[デバッグ コンソール] タブに移動します。お使いのアプリから Azure portal にホストされたコンソールにアクセスするには、[ツール]>[コンソール] の順に移動します。

ツール

ネイティブ Windows アプリでは、ping、nslookup、tracert の各ツールは、セキュリティの制約により、コンソールから使用することはできません (カスタム Windows コンテナーで動作します)。 それを補うために、2 つの独立したツールが追加されています。 DNS 機能をテストするために、nameresolver.exe という名前のツールを追加しました。 の構文は次のとおりです。

nameresolver.exe hostname [optional: DNS Server]

nameresolver を使用すると、アプリが依存しているホスト名を確認できます。 この方法によって、DNS の構成に誤りがあるかどうかや、DNS サーバーへのアクセス権がないかどうかをテストできます。 環境変数 WEBSITE_DNS_SERVER と WEBSITE_DNS_ALT_SERVER を調べることによって、アプリによって使用される DNS サーバーをコンソール上で確認できます。

注意

nameresolver.exe ツールは現在の、カスタム Windows コンテナーでは動作しません。

次のツールを使用して、ホストとポートを組み合わせたものへの TCP 接続をテストすることができます。 このツールは tcpping という名前で、構文は次のとおりです。

tcpping.exe hostname [optional: port]

tcpping ユーティリティを使用すると、特定のホストとポートにアクセスできるかどうかがわかります。 成功として示されるのは、ホストとポートの組み合わせでリッスンしているアプリケーションがあり、アプリから指定のホストとポートへのネットワーク アクセスがある場合のみです。

仮想ネットワークによってホストされたリソースへのアクセスをデバッグする

さまざまな要因によって、アプリから特定のホストとポートへのアクセスが妨げられる場合があります。 ほとんどの場合は、次のいずれかに該当します。

  • ファイアウォールがルートを塞いでいる。 ルートを塞いでいるファイアウォールがあると、TCP タイムアウトに達します。 この場合の TCP タイムアウトは 21 秒です。 tcpping ツールを使用して接続をテストします。 TCP タイムアウトには、ファイアウォール以外にさまざまな要因が考えられますが、まずはここから開始します。
  • DNS にアクセスできない。 DNS タイムアウトは、DNS サーバーごとに 3 秒です。 2 つの DNS サーバーがある場合、タイムアウトは 6 秒です。 nameresolver を使用して、DNS が機能しているかどうかを確認します。 nslookup では仮想ネットワークの構成に使用されている DNS を利用しないため、nslookup を使うことはできません。 アクセスできない場合は、ファイアウォールが存在するか、NSG が DNS へのアクセスをブロックしているか、または DNS が停止している可能性があります。

これらの項目が問題の回答になっていない場合は、まず次のような点を確認してください。

リージョンでの仮想ネットワーク統合

  • 宛先は RFC1918 以外のアドレスであり、 [すべてルーティング] が有効になっていないこと。
  • 統合サブネットからのエグレスをブロックしている NSG は存在するか。
  • Azure ExpressRoute または VPN をまたがって移動する場合は、オンプレミスのゲートウェイがトラフィック バックアップを Azure にルーティングするように構成されているか。 仮想ネットワーク内のエンドポイントには到達できるが、オンプレミスに到達できない場合は、ルートを確認します。
  • 統合サブネットに委任を設定するための十分なアクセス許可があるか。 リージョン仮想ネットワーク統合が構成されている間、統合サブネットは Microsoft.Web/serverFarms に委任されます。 VNet 統合 UI では、Microsoft.Web/serverFarms に対するサブネットが自動的に委任されます。 アカウントに委任を設定するための十分なネットワークのアクセス許可がない場合は、サブネットを委任するために、統合サブネットに属性を設定できるユーザーが必要になります。 統合サブネットを手動で委任するには、Azure Virtual Network サブネット UI にアクセスして、Microsoft.Web/serverFarms の委任を設定します。

ゲートウェイが必要な仮想ネットワーク統合

  • ポイント対サイトのアドレス範囲が RFC 1918 の範囲 (10.0.0.0-10.255.255.255/172.16.0.0-172.31.255.255/192.168.0.0-192.168.255.255) にあるか。
  • ゲートウェイはポータル上に稼働中として表示されているか。 ゲートウェイがダウンしている場合は、再起動してください。
  • 証明書は同期していると表示されているか。または、ネットワーク構成が変更されたことが疑われるか。 証明書が同期していないか、または ASP と同期していない仮想ネットワーク構成への変更が行われたことが疑われる場合は、 [ネットワークの同期] を選択します。
  • VPN をまたがって移動する場合は、オンプレミスのゲートウェイがトラフィック バックアップを Azure にルーティングするように構成されているか。 仮想ネットワーク内のエンドポイントには到達できるが、オンプレミスに到達できない場合は、ルートを確認します。
  • ポイント対サイトと ExpressRoute の両方をサポートする共存ゲートウェイを使用しようとしているか。 仮想ネットワーク統合では、共存ゲートウェイはサポートされていません。

ホストとポートの特定の組み合わせへのアクセスが何によってブロックされているかを確認できないため、ネットワークに関する問題のデバッグは厄介です。 次のような原因が考えられます。

  • ホスト上で稼働しているファイアウォールが、ポイント対サイト IP の範囲からアプリケーション ポートへのアクセスを妨げている。 サブネットの境界を越えるには、多くの場合、パブリック アクセスが必要になります。
  • ターゲット ホストがダウンしている。
  • アプリケーションがダウンしている。
  • IP またはホスト名が誤っている。
  • アプリケーションが予期しないポートでリッスンしている。 エンドポイント ホストで "netstat-aon" を使用することで、プロセス ID と、リッスンしているポートを一致させることができます。
  • ネットワーク セキュリティ グループが、ポイント対サイト IP の範囲からアプリケーション ホストとポートへのアクセスを妨げる手法で構成されている。

アプリによって実際にどのアドレスが使用されるかを把握することはできません。 統合サブネットまたはポイント対サイトのアドレス範囲内の任意のアドレスである可能性があるため、アドレス範囲全体からのアクセスを許可する必要があります。

その他のデバッグ手順は次のとおりです。

  • 仮想ネットワーク内の VM に接続し、そこからリソースのホスト:ポートへのアクセスを試みます。 TCP アクセスのテストには、PowerShell コマンド Test-NetConnection を使用します。 の構文は次のとおりです。
Test-NetConnection hostname [optional: -Port]
  • VM 上でアプリケーションを起動し、tcpping を使用して、アプリのコンソールからそのホストとポートへのアクセスをテストします。

オンプレミスのリソース

アプリからオンプレミスのリソースにアクセスできない場合は、仮想ネットワークからリソースにアクセスできるかどうかを確認します。 TCP アクセスを確認するには、PowerShell コマンド Test-NetConnection を使用します。 VM からオンプレミス リソースに到達できない場合は、VPN または ExpressRoute 接続が正しく構成されていない可能性があります。

仮想ネットワークでホストされている VM からオンプレミス システムにアクセスでき、アプリからはアクセスできない場合、以下のいずれかの理由が原因と考えられます。

  • オンプレミスのゲートウェイで、ルートがサブネットまたはポイント対サイトのアドレス範囲に構成されていない。
  • ネットワーク セキュリティ グループによって、ポイント対サイト IP 範囲へのアクセスがブロックされている。
  • オンプレミスのファイアウォールによって、ポイント対サイト IP 範囲からのトラフィックがブロックされている。
  • リージョン仮想ネットワーク統合機能を使用して、RFC 1918 以外のアドレスへのアクセスを試みている。

VNet 統合を切断する前に App Service プランまたは Web アプリを削除する

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

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

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

上記の手順に従った後も VNet 統合に関する問題が引き続き発生する場合は、Microsoft サポートにお問い合わせください。

ネットワークのトラブルシューティング ツール

ネットワーク トラブルシューティング ツールを使用して、接続の問題を解決することもできます。 ネットワーク トラブルシューティング ツールを開くには、Azure portal のアプリに移動します。 [診断と問題の解決] を選択し、ネットワーク トラブルシューティング ツールを検索します。

接続に関する問題 - プランのすべてのインスタンスと DNS 設定にプライベート IP が割り当てられているかどうかを確認するなど、仮想ネットワーク統合の状態を確認します。 カスタム DNS が構成されていない場合は、既定の Azure DNS が適用されます。 トラブルシューティング ツールでは、Azure Storage の接続やその他のバインド依存関係など、一般的な関数アプリの依存関係も確認します。

接続に関する問題のトラブルシューティングの実行を示すスクリーンショット。

構成に関する問題 - このトラブルシューティング ツールは、サブネットが仮想ネットワーク統合に対して有効かどうかを確認します。

構成に関する問題のトラブルシューティングの実行を示すスクリーンショット。

サブネット/VNet の削除の問題 - このトラブルシューティング ツールは、サブネットにロックがあるかどうか、および VNet/サブネットの削除をブロックしている可能性がある未使用のサービス関連付けリンクがあるかどうかを確認します。

次のステップ

ネットワークと Azure Functions の詳細については、以下を参照してください。