次の方法で共有

Azure API Management インスタンスを仮想ネットワークにデプロイする - 外部モード

  • [アーティクル]

適用対象: Developer | Premium

Azure API Management を Azure 仮想ネットワーク (VNet) の内部にデプロイ (挿入) すると、そのネットワーク内のバックエンド サービスにアクセスできます。 VNET 接続のオプション、要件、考慮事項については、次のページを参照してください。

この記事では、"外部" モードで API Management インスタンスの VNet 接続を設定する方法について説明します。このモードでは、パブリック インターネットから開発者ポータル、API ゲートウェイ、その他の API Management エンドポイントにアクセスすることができ、バックエンド サービスはネットワーク内に配置されています。

外部 VNET に接続する

VNet 内でのみエンドポイントにアクセスできる "内部" モード固有の構成については、Azure API Management を仮想ネットワークにデプロイする - 内部モードに関するページを参照してください。

注意

Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を始めるには、「Azure PowerShell をインストールする」を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。

前提条件

開始前に、「仮想ネットワークへの API Management インジェクションのネットワーク リソース要件」を確認してください。

一部の前提条件は、API Management インスタンスをホストしているstv2のバージョン (stv2 または stv1) によって異なります。

ヒント

ポータルを使用して既存の API Management インスタンスのネットワーク接続を作成または更新する場合、そのインスタンスは stv2 コンピューティング プラットフォームでホストされています。

  • API Management インスタンスと同じリージョンおよびサブスクリプション内に存在する仮想ネットワークとサブネット。

    • API Management インスタンスへの接続に使用されるサブネットには、他の Azure リソースの種類が含まれる場合があります。
    • サブネットで委任を有効にしないでください。 サブネットの [サブネットをサービスに委任] 設定は、[なし] に設定する必要があります。

  • 上記のサブネットに接続されたネットワーク セキュリティ グループ。 受信接続を明示的に許可するには、ネットワーク セキュリティ グループ (NSG) が必要です。これは、API Management によって内部的に使用されるロード バランサーが既定でセキュリティ保護され、すべての受信トラフィックを拒否するためです。 具体的な構成については、この記事で後述する「NSG 規則の構成」を参照してください。

  • 特定のシナリオでは、Azure Storage や Azure SQL などの依存サービスに対してサブネットでサービス エンドポイントを有効にします。 詳細については、この記事の後半の「ExpressRoute またはネットワーク仮想アプライアンスを使用したオンプレミス ファイアウォールへのトラフィックの強制トンネリング」を参照してください。

  • (省略可能) Standard SKU のパブリック IPv4 アドレス。

    重要

    • 2024 年 5 月以降、内部モードの VNet に API Management インスタンスをデプロイ (インジェクション) するとき、または内部 VNet 構成を新しいサブネットに移行するときに、パブリック IP アドレス リソースは "不要になります"。 外部 VNet モードでは、パブリック IP アドレスの指定は "オプション" です。指定しない場合は、Azure マネージド パブリック IP アドレスが自動的に構成され、ランタイム API トラフィックに使用されます。 インターネットの受信または送信コミュニケーションに使用されるパブリック IP アドレスを所有および制御したい場合にのみ、パブリック IP アドレスを指定します。

    • 指定する場合、この IP アドレスは、API Management インスタンスおよび仮想ネットワークと同じリージョンおよびサブスクリプションにある必要があります。

    • パブリック IP アドレス リソースの作成時には、それに必ず DNS 名ラベルを割り当ててください。 一般に、API Management インスタンスと同じ DNS 名を使用する必要があります。 変更した場合は、新しい DNS ラベルが適用されるようにインスタンスを再デプロイします。

    • 最高のネットワーク パフォーマンスを得るには、既定のルーティングの優先順位: Microsoft ネットワークを使用することをお勧めします。

    • API Management インスタンスのゾーン冗長性を有効にする予定のリージョンでパブリック IP アドレスを作成する場合は、ゾーン冗長設定を構成します。

    • IP アドレスの値は、そのリージョンの API Management インスタンスの仮想パブリック IPv4 アドレスとして割り当てられます。

  • 複数リージョンの API Management デプロイの場合、場所ごとに仮想ネットワーク リソースを個別に構成します。

VNet 接続を有効にする

Azure portal を使用して VNet 接続を有効にする (stv2 コンピューティング プラットフォーム)

  1. Azure portal に移動し、お使いの API Management インスタンスを検索します。 API Management サービスを検索して選択します。

  2. お使いの API Management インスタンスを選択します。

  3. [ネットワーク] を選択します。

  4. [外部] のアクセスの種類を選択します。 Azure portal で VNET を選択する。

  5. API Management サービスがプロビジョニングされている場所 (リージョン) のリストで、次の手順に従います。

    1. [場所] を選択します。
    2. [仮想ネットワーク]、[サブネット]、(省略可能)[IP アドレス] を選択します。

    • VNet の一覧には、構成中のリージョンで設定されている、Azure サブスクリプションで使用できる Resource Manager の VNet が表示されます。

      ポータルでの VNET の設定。

  6. [適用] を選択します。 API Management インスタンスの [ネットワーク] ページが、新しい VNet とサブネットの選択によって更新されます。

  7. API Management インスタンスの残りの場所に対して、VNet 設定の構成を続行します。

  8. 上部のナビゲーション バーで、[保存] を選択します。

API Management インスタンスを更新するのに 15 分から 45 分かかることがあります。 Developer レベルのインスタンスでは、処理中にダウンタイムが発生します。 Premium レベルのインスタンスでは、処理中にダウンタイムが発生します。

Resource Manager テンプレートを使用して接続を有効にする (stv2 コンピューティング プラットフォーム)

Azure PowerShell コマンドレットを使用して接続を有効にする (stv1 プラットフォーム)

VNet で API Management インスタンスを作成または更新します。

NSG 規則の構成

API Management インスタンスに対するトラフィックをフィルター処理するには、API Management サブネットでカスタム ネットワーク規則を構成します。 "少なくとも"、インスタンスに対して適切な操作とアクセスが行われるようにする以下の NSG 規則ルールをお勧めします。 環境を詳しく確認し、必要となる可能性があるその他のルールを特定します。

重要

キャッシュやその他の機能の使用によっては、次の表の最低限の NSG 規則以外に追加の規則を構成する必要がある場合があります。 詳細な設定については、仮想ネットワークの構成のリファレンスを参照してください。

  • ほとんどの場合、サービスの IP アドレスではなく、示されているサービス タグを使用してネットワークのソースとターゲットを指定してください。
  • これらの規則の優先順位は、既定の規則よりも高く設定します。
ソース / ターゲット ポート Direction トランスポート プロトコル サービス タグ
ソース / ターゲット		 目的 VNet の種類
* / [80]、443 受信 TCP インターネット/VirtualNetwork API Management へのクライアント通信 外部のみ
* / 3443 受信 TCP ApiManagement/VirtualNetwork Azure Portal と PowerShell 用の管理エンドポイント 外部 / 内部
* / 6390 受信 TCP AzureLoadBalancer/VirtualNetwork Azure インフラストラクチャの Load Balancer 外部 / 内部
* / 443 受信 TCP AzureTrafficManager / VirtualNetwork 複数リージョンへのデプロイ用の Azure Traffic Manager ルーティング 外部のみ
* / 443 送信 TCP VirtualNetwork/Storage コア サービス機能向け Azure Storage への依存関係 外部 / 内部
* / 1433 送信 TCP VirtualNetwork/SQL コア サービス機能向け Azure SQL エンドポイントへのアクセス 外部 / 内部
* / 443 送信 TCP VirtualNetwork/AzureKeyVault コア サービス機能向け Azure Key Vault へのアクセス 外部 / 内部
* / 1886、443 送信 TCP VirtualNetwork / AzureMonitor 診断ログとメトリック、Resource Health、Application Insights を公開する 外部 / 内部

仮想ネットワーク内でホストされる Web サービスに接続する

API Management サービスを VNet に接続すると、パブリック サービスの場合と同様に、その VNet 内のバックエンド サービスにアクセスできます。 API を作成または編集するときは、Web サービスのローカル IP アドレスまたはホスト名 (VNet に対して DNS サーバーが構成されている場合) を [Web サービスの URL] フィールドに入力します。

VNET から API を追加する

カスタム DNS サーバーのセットアップ

外部 VNet モードでは、DNS は Azure によって管理されます。 必要に応じて、カスタム DNS サーバーを構成できます。

API Management サービスは、複数の Azure サービスに依存します。 カスタム DNS サーバーを使用して VNet 内に API Management をホストする場合、それらの Azure サービスのホスト名はサーバーで解決する必要があります。

重要

VNet でカスタム DNS サーバーを使用する予定の場合は、VNet に API Management サービスをデプロイする前にサーバーをセットアップします。 それ以外の場合は、DNS サーバーを変更するたびに [ネットワーク構成の適用] 操作を実行して API Management サービスを更新する必要があります。

ルーティング

  • 負荷分散されたパブリック IP アドレス (VIP) は、VNet の外部にある API 管理エンドポイントとリソースへのアクセスを提供するために予約されます。
    • パブリック IP アドレスは、Azure portal の [概要]/[要点] ブレードで確認できます。

詳細および考慮事項については、「Azure API Management の IP アドレス」を参照してください。

VIP アドレスと DIP アドレス

動的 IP (DIP) アドレスは、サービス内の基盤となる各仮想マシンに割り当てられ、VNet およびピアリングされた VNet 内にあるエンドポイントとリソースへのアクセスに使用されます。 API Management サービスのパブリック仮想 IP (VIP) アドレスは、パブリック リソースにアクセスするために使用されます。

IP 制限リストを使用して VNet またはピアリングされた VNet 内のリソースをセキュリティで保護する場合は、API Management サービスがデプロイされるサブネットの範囲全体に対して、サービスからのアクセスを許可するか制限するように指定することをお勧めします。

推奨されるサブネット サイズについて説明します。

ExpressRoute またはネットワーク仮想アプライアンスを使用したオンプレミス ファイアウォールへのトラフィックの強制トンネリング

強制トンネリングでは、検査および監査のために、サブネットからのインターネットにバインドされたトラフィックがすべてオンプレミスにリダイレクトまたは「強制的に」戻されます。 通常は、API Management サブネットからのすべてのトラフィックを、オンプレミスのファイアウォールまたはネットワーク仮想アプライアンスに強制的に流す、独自の既定のルート (0.0.0.0/0) を構成して定義します。 このトラフィック フローでは、API Management を使用した接続は切断されます。これは、発信トラフィックがオンプレミスでブロックされるか、さまざまな Azure エンドポイントで使用されなくなった認識できないアドレス セットに NAT 変換されるためです。 次の方法でこの問題を解決することができます。

  • API Management サービスがデプロイされているサブネット上で、次のサービス エンドポイントを有効にします。

    • Azure SQL (API Management サービスが複数のリージョンにデプロイされている場合にプライマリ リージョンでのみ必要)
    • Azure Storage
    • Azure Event Hubs
    • Azure Key Vault (API Management が stv2 プラットフォームにデプロイされている場合に必要)

    これらのサービスに対して API Management サブネットから直接エンドポイントを有効にすることで、Microsoft Azure のバックボーン ネットワークを使用して、サービス トラフィックの最適なルーティングを提供できます。 トンネリングが強制された API Management でサービス エンドポイントを使用する場合、上記の Azure サービスのトラフィックは強制的にトンネリングされません。 ただし、API Management サービスの他の依存関係トラフィックは引き続き強制的にトンネリングされます。 ファイアウォールまたは仮想アプライアンスがこのトラフィックをブロックしていないか、または API Management サービスが正しく機能しているかどうかを確認します。

    Note

    API Management のサブネットから直接、それらをサポートする依存サービス (Azure SQL や Azure Storage など) へのサービス エンドポイントを有効にすることを強くお勧めします。 ただし、API Management サブネットからのすべてのトラフィックを強制的にトンネリングすることを要件としている組織も中にはあるでしょう。 その場合は、このトラフィックを許可するようにファイアウォールまたは仮想アプライアンスを構成してください。 各依存サービスの完全な IP アドレス範囲を許可すると共に、Azure インフラストラクチャが変更されても、この構成を最新の状態に保つ必要があります。 このネットワーク トラフィックの強制トンネリングが原因で、API Management サービスに待ち時間や予期しないタイムアウトが発生することもあります。

  • インターネットから API Management サービスの管理エンドポイントへのすべてのコントロール プレーン トラフィックは、API Management によってホストされ、ApiManagement サービス タグによって包含されている受信 IP の特定のセットを使用してルーティングされます。 トラフィックが強制的にトンネリングされると、応答はこれらの受信ソース IP に対称的にマップされなくなり、管理エンドポイントへの接続が失われます。 この制限を回避するには、ネクスト ホップの種類が "インターネット" に設定された ApiManagement サービス タグのユーザー定義ルート (UDR) を構成して、トラフィックを Azure に戻します。

    Note

    API Management 管理トラフィックがオンプレミスのファイアウォールまたはネットワーク仮想アプライアンスをバイパスすることを許可しても、重大なセキュリティ リスクとは見なされません。 API Management サブネットに推奨される構成では、ApiManagement サービス タグに含まれる一連の Azure IP アドレスからの受信管理トラフィックのみをポート 3443 で許可します。 推奨される UDR 構成は、この Azure トラフィックのリターン パスのみを対象とします。

  • (外部 VNet モード) インターネットから API Management ゲートウェイと開発者ポータルに到達しようとしているクライアントのデータ プレーン トラフィックも、強制トンネリングによって導入された非対称ルーティングのため、既定でドロップされます。 アクセスを必要とするクライアントごとに、次ホップの種類が "インターネット" の明示的な UDR を構成し、ファイアウォールまたは仮想ネットワーク アプライアンスをバイパスするようにします。

  • 強制的にトンネリングされる API Management サービスの他の依存関係については、ホスト名を解決してエンドポイントに到達します。 これには以下が含まれます。

    • メトリックと正常性の監視
    • Azure portal の診断
    • SMTP リレー
    • 開発者ポータル CAPTCHA
    • Azure KMS サーバー

詳細については、仮想ネットワークの構成のリファレンスを参照してください。

ネットワーク構成に関する一般的な問題

このセクションは移動されました。 仮想ネットワークの構成のリファレンスを参照してください。

トラブルシューティング

API Management サービスのサブネットへの初期のデプロイが失敗する

  • 同じサブネットに仮想マシンをデプロイします。
  • その仮想マシンに接続し、Azure サブスクリプション内の次の各リソースへの接続を 1 つずつ検証します。
    • Azure Storage BLOB
    • Azure SQL データベース
    • Azure Storage Table
    • Azure Key Vault (stv2 プラットフォームでホストされている API Management インスタンスの場合)

重要

接続を検証した後、API Management をサブネットにデプロイする前に、そのサブネット内のすべてのリソースを削除してください (API Management が stv1 プラットフォームでホストされている場合に必要)。

ネットワークの状態を確認する

  • API Management をサブネットにデプロイした後、ポータルを使用して、Azure Storage などの依存関係へのインスタンスの接続を確認します。

  • ポータルの左側のメニューにある [デプロイとインフラストラクチャ] で、[ネットワーク]>[ネットワークの状態] の順に選択します。

    ポータルでのネットワーク接続状況の確認画面。

Assert 説明
必須 API Management に必要な Azure サービスへの接続を確認する場合に選択します。 エラーは、そのインスタンスが API を管理するためのコア操作を実行できないことを示します。
Optional オプションのサービスへの接続を確認する場合に選択します。 エラーは、特定の機能 (SMTP など) が機能しないことのみを示します。 エラーが発生すると、API Management インスタンスを使用と監視を行う機能や、確約された SLA を提供する機能が低下する可能性があります。

接続問題のトラブルシューティングに役立てるためには、以下を選択してください。

  • メトリック - ネットワーク接続状態メトリックを確認する

  • 診断 - 期間を指定して仮想ネットワーク検証ツールを実行する

接続の問題に対処するには、ネットワーク構成設定を確認し、必要なネットワーク設定を修正します。

増分更新

ネットワークを変更するときは、NetworkStatus API を参照して、API Management サービスで重要なリソースへのアクセスが失われていないことを確認してください。 接続状態は、15 分間隔で更新されます。

ポータルを使用してネットワーク構成の変更を API Management インスタンスに適用するには:

  1. インスタンスの左側のメニューにある [デプロイとインフラストラクチャ] で、[ネットワーク] > [仮想ネットワーク] の順に選択します。
  2. [ネットワーク構成の適用] を選択します。

stv1 コンピューティング プラットフォームでホストされている API Management のインスタンスは、Resource Manager VNet サブネットにデプロイされるときに、リソース ナビゲーション リンクを作成することによってサブネットを予約します。 サブネットに別のプロバイダーのリソースが既に含まれている場合、デプロイは失敗します。 同様に、API Management サービスを削除するか、別のサブネットに移動すると、リソース ナビゲーション リンクは削除されます。

API Management のインスタンスを以前のサブネットに割り当て直す場合に発生する問題

  • VNet ロック - API Management インスタンスを元のサブネットに戻す際には、VNet ロックのため、即座の再割り当てが不可能な場合があります。ロックの削除には最大 1 時間かかります。 元のサブネットに他の stv1 プラットフォームベースの API Management サービス (クラウド サービス ベース) がある場合、同じサブネット内に stv2 プラットフォームベースのサービスをデプロイするには、それらを削除してしばらく待つ必要があります。
  • リソース グループ ロック - また、リソース グループ レベル以上にスコープ ロックが存在し、これによってリソース ナビゲーション リンクの削除プロセスが妨げられるというシナリオも、考慮すべきシナリオの 1 つです。 これを解決するには、スコープのロックを解除する前に、API Management サービスが元のサブネットからリンク解除するために約 4 から 6 時間の遅延を設け、目的のサブネットにデプロイできるようにします。

VNet 内から Microsoft Graph への接続のトラブルシューティング

Microsoft Entra ID プロバイダーを使用した開発者ポータルへのユーザー サインインなどの機能には、Microsoft Graph へのネットワーク接続が必要です。

VNet 内から Microsoft Graph への接続のトラブルシューティングには、次の操作を行います。

  • NSG およびその他のネットワーク規則が、API Management インスタンスから Microsoft Graph への送信接続用に構成されていることを確認します (AzureActiveDirectory サービス タグを使用)。

  • VNet 内から graph.microsoft.com への DNS 解決とネットワーク アクセスを確認してください。 たとえば、VNet 内で新しい VM をプロビジョニングし、その VM に接続し、ブラウザーから、または cURL、PowerShell、その他のツールを使用して GET https://graph.microsoft.com/v1.0/$metadata を試します。

次のステップ

各項目の詳細情報