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

  • [アーティクル]

この記事では、Azure Functions のホスティング オプションで利用できるネットワーク機能について説明します。 以下に示すネットワーク オプションではすべて、インターネットのルーティング可能アドレスを使用せずにリソースにアクセスする機能、または関数アプリへのインターネット アクセスを制限する機能が提供されます。

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

関数アプリは、いくつかの方法でホストできます。

  • さまざまなレベルの仮想ネットワーク接続性とスケーリングのオプションを備えた、マルチテナント インフラストラクチャ上で実行されるプラン オプションから選択できます。
    • 従量課金プラン。負荷に応じて動的なスケーリングが行われ、最小限のネットワークの分離オプションが提供されます。
    • Premium プラン。やはり動的なスケーリングが行われますが、より包括的なネットワークの分離が提供されます。
    • App Service プラン。固定されたスケールで動作し、Premium プランと同様のネットワークの分離が提供されます。
  • App Service Environment で関数を実行できます。 この方法では、関数を仮想ネットワークにデプロイし、完全なネットワーク制御と分離を提供します。

ネットワーク機能のマトリックス

特徴量 従量課金プラン Premium プラン 専用プラン ASE
受信 IP の制限 ✅はい ✅はい ✅はい ✅はい
受信プライベート エンドポイント ❌なし ✅はい ✅はい ✅はい
仮想ネットワークの統合 ❌なし ✅あり (リージョン) ✅はい (リージョンとゲートウェイ) ✅はい
仮想ネットワーク トリガー (非 HTTP) ❌なし ✅はい ✅はい ✅はい
ハイブリッド接続 (Windows のみ) ❌なし ✅はい ✅はい ✅はい
送信 IP の制限 ❌なし ✅はい ✅はい ✅はい

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

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

受信ネットワークの機能

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

受信アクセス制限

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

アクセス制限は、Premium、従量課金、App Service で利用できます。

Note

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

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

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

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

Premium および App Service の各プランでホストされている機能にプライベート エンドポイントを使用することができます。

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

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

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

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

サービス エンドポイント

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

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

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

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

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

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

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

Screenshot of the

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

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

仮想ネットワークの統合

仮想ネットワーク統合により、関数アプリは仮想ネットワーク内のリソースにアクセスできます。 Azure Functions では、2 種類の仮想ネットワーク統合がサポートされています。

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

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

仮想ネットワーク統合により、アプリから仮想ネットワーク内のリソースにアクセスできるようになりますが、仮想ネットワークからそのアプリへの受信プライベート アクセスが許可されるわけではありません。 プライベート サイト アクセスとは、Azure 仮想ネットワーク内など、プライベート ネットワークのみからアプリにアクセスできるようにすることです。 仮想ネットワーク統合は、アプリから仮想ネットワークへの送信呼び出しを行うためだけに使用されます。 Virtual Network 統合機能は、同じリージョン内の仮想ネットワークで使用する場合と、他のリージョン内の仮想ネットワークで使用する場合とで、動作が異なります。 仮想ネットワーク統合機能には 2 つのバリエーションがあります。

  • リージョン仮想ネットワーク統合: 同じリージョン内の仮想ネットワークに接続するときは、統合する仮想ネットワークに専用のサブネットが必要です。
  • ゲートウェイが必要な仮想ネットワーク統合: 他のリージョン内の仮想ネットワークまたは同じリージョン内のクラシック仮想ネットワークに直接接続する場合、ターゲットの仮想ネットワークに作成された Azure Virtual Network ゲートウェイが必要です。

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

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

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

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

ゲートウェイが必要な仮想ネットワーク統合では、ターゲット仮想ネットワーク内、あるいはピアリングまたは VPN を使用してターゲット仮想ネットワークに接続されているネットワーク内のリソースのみにアクセスできます。 ゲートウェイが必要な仮想ネットワーク統合では、Azure ExpressRoute 接続全体で利用可能なリソースへのアクセスを有効にしたり、サービス エンドポイントと連携したりすることはできません。

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

Azure Functions の仮想ネットワーク統合では、App Service Web アプリと共有インフラストラクチャを使用します。 2 種類の仮想ネットワーク統合の詳細については、次を参照してください。

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

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

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

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

    Select VNet Integration

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

    Select the VNet

    • Functions Premium プランでは、リージョンの仮想ネットワーク統合のみがサポートされています。 同じリージョン内の仮想ネットワークの場合は、新しいサブネットを作成するか、空の既存のサブネットを選択します。

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

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

プライベート トラフィック (RFC1918 トラフィック) のみをルーティングする場合は、App Service のドキュメントに記載されている手順に従ってください。

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

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

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

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

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

Note

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

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

仮想ネットワークの使用には、いくつかの制限があります。

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

サブネット

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

サイズをスケールアップまたはスケールダウンすると、必要なアドレス空間が短期間に 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 の最小サイズが必要です。

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

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

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

ネットワーク セキュリティ グループを使用して、仮想ネットワーク内のリソースへの受信および送信トラフィックをブロックできます。 リージョン仮想ネットワーク統合を使用するアプリでは、ネットワーク セキュリティ グループを使用して、仮想ネットワークまたはインターネット内のリソースへの送信トラフィックをブロックできます。 パブリック アドレスへのトラフィックをブロックするには、[すべてをルーティング] が有効になっている仮想ネットワーク統合を使用する必要があります。 仮想ネットワーク統合はアプリからの送信トラフィックのみに影響を与えるため、NSG での受信規則はアプリに適用されません。

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

ルート

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

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

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

Azure DNS プライベート ゾーン

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

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

注意

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

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

この機能は、Dedicated (App Service) プランおよび Premium プランのすべての Windows および Linux 仮想ネットワーク対応 SKU でサポートされています。 従量課金プランはサポートされていません。 プライベート ネットワークに制限されたストレージ アカウントを使用して関数を設定する方法については、「お使いのストレージ アカウントを仮想ネットワークに制限する」を参照してください。

Key Vault 参照を使用する

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

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

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

現時点では、次の 2 つの方法のいずれかで、仮想ネットワーク内から非 HTTP トリガー関数を使用できます。

  • Premium プランで関数アプリを実行し、仮想ネットワーク トリガーのサポートを有効にする。
  • App Service プランまたは 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 のいずれかで実行する場合は、非 HTTP トリガー関数を使用できます。 関数が正しくトリガーされるようにするには、トリガー接続で定義されているリソースにアクセスできる仮想ネットワークに接続する必要があります。

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

ハイブリッド接続

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

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

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

重要

ハイブリッド接続は、Windows プランでのみサポートされています。 Linux はサポートされていません。

送信 IP の制限

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

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

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

オートメーション

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

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

テストに関する考慮事項

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

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

トラブルシューティング

機能は簡単にセットアップできますが、問題が発生しないという意味ではありません。 目的のエンドポイントへのアクセスに関して問題が発生した場合は、アプリのコンソールからの接続をテストするために、いくつかのユーティリティを利用できます。 利用できるコンソールが 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 サーバーをコンソール上で確認できます。

Note

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 の接続やその他のバインド依存関係など、一般的な関数アプリの依存関係も確認します。

Screenshot that shows running troubleshooter for connection issues.

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

Screenshot that shows running troubleshooter for configuration issues.

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

次のステップ

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