Azure API Management インスタンスを仮想ネットワークにデプロイする - 外部モード
適用対象: Developer | Premium
Azure API Management を Azure 仮想ネットワーク (VNet) の内部にデプロイ (挿入) すると、そのネットワーク内のバックエンド サービスにアクセスできます。 VNET 接続のオプション、要件、考慮事項については、次のページを参照してください。
この記事では、"外部" モードで API Management インスタンスの VNet 接続を設定する方法について説明します。このモードでは、パブリック インターネットから開発者ポータル、API ゲートウェイ、その他の API Management エンドポイントにアクセスすることができ、バックエンド サービスはネットワーク内に配置されています。
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 インスタンス。 詳細については、Azure API Management インスタンスの作成に関する記事を参照してください。
API Management インスタンスと同じリージョンおよびサブスクリプション内に存在する仮想ネットワークとサブネット。
- API Management インスタンスへの接続に使用されるサブネットには、他の Azure リソースの種類が含まれる場合があります。
- サブネットで委任を有効にしないでください。 サブネットの [サブネットをサービスに委任] 設定は、[なし] に設定する必要があります。
上記のサブネットに接続されたネットワーク セキュリティ グループ。 受信接続を明示的に許可するには、ネットワーク セキュリティ グループ (NSG) が必要です。これは、API Management によって内部的に使用されるロード バランサーが既定でセキュリティ保護され、すべての受信トラフィックを拒否するためです。 具体的な構成については、この記事で後述する「NSG 規則の構成」を参照してください。
特定のシナリオでは、Azure Storage や Azure SQL などの依存サービスに対してサブネットでサービス エンドポイントを有効にします。 詳細については、この記事の後半の「ExpressRoute またはネットワーク仮想アプライアンスを使用したオンプレミス ファイアウォールへのトラフィックの強制トンネリング」を参照してください。
Standard SKU のパブリック IPv4 アドレス。 パブリック IP アドレス リソースは、外部または内部アクセスのいずれかに対して仮想ネットワークを設定するときに必要です。 内部仮想ネットワークでは、パブリック IP アドレスは管理操作にのみ使用されます。 詳細は「Azure API Management の IP アドレス」を参照してください。
この IP アドレスは、API Management インスタンスおよび仮想ネットワークと同じリージョンおよびサブスクリプションにある必要があります。
パブリック IP アドレス リソースの作成時には、それに必ず DNS 名ラベルを割り当ててください。 使用するラベルは重要ではありませんが、このリソースを API Management サービスに割り当てる場合はラベルが必要です。
最高のネットワーク パフォーマンスを得るには、既定のルーティングの優先順位: Microsoft ネットワークを使用することをお勧めします。
API Management インスタンスのゾーン冗長性を有効にする予定のリージョンでパブリック IP アドレスを作成する場合は、ゾーン冗長設定を構成します。
IP アドレスの値は、そのリージョンの API Management インスタンスの仮想パブリック IPv4 アドレスとして割り当てられます。
外部から内部の仮想ネットワーク (またはその逆) に変更する場合、ネットワーク内のサブネットを変更する場合、または API Management インスタンスの可用性ゾーンを更新する場合は、別のパブリック IP アドレスを構成する必要があります。
VNet 接続を有効にする
Azure portal を使用して VNet 接続を有効にする (stv2 コンピューティング プラットフォーム)
Azure portal に移動し、お使いの API Management インスタンスを検索します。 API Management サービスを検索して選択します。
お使いの API Management インスタンスを選択します。
[ネットワーク] を選択します。
[外部] のアクセスの種類を選択します。
API Management サービスがプロビジョニングされている場所 (リージョン) のリストで、次の手順に従います。
- [場所] を選択します。
- 仮想ネットワーク、サブネット、IP アドレスを選択します。
VNet の一覧には、構成中のリージョンで設定されている、Azure サブスクリプションで使用できる Resource Manager の VNet が表示されます。
[適用] を選択します。 API Management インスタンスの [ネットワーク] ページが、新しい VNet とサブネットの選択によって更新されます。
API Management インスタンスの残りの場所に対して、VNet 設定の構成を続行します。
上部のナビゲーション バーで、 [保存] を選択してから、 [ネットワーク構成の適用] を選択します。
API Management インスタンスを更新するのに 15 分から 45 分かかることがあります。 Developer レベルのインスタンスでは、処理中にダウンタイムが発生します。 Premium レベルのインスタンスでは、処理中にダウンタイムが発生します。
Resource Manager テンプレートを使用して接続を有効にする (stv2 コンピューティング プラットフォーム)
Azure Resource Manager テンプレート (API バージョン 2021-08-01)
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] フィールドに入力します。
カスタム DNS サーバーのセットアップ
外部 VNet モードでは、DNS は Azure によって管理されます。 必要に応じて、カスタム DNS サーバーを構成できます。
API Management サービスは、複数の Azure サービスに依存します。 カスタム DNS サーバーを使用して VNet 内に API Management をホストする場合、それらの Azure サービスのホスト名はサーバーで解決する必要があります。
- Azure で提供されるホスト名の転送を含め、カスタム DNS 設定のガイダンスについては、Azure 仮想ネットワーク内のリソースの名前解決に関するページを参照してください。
- DNS サーバーとの通信には、ポート
53での送信ネットワーク アクセスが必要です。 詳細な設定については、仮想ネットワークの構成のリファレンスを参照してください。
重要
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 インスタンスに適用するには:
- インスタンスの左側のメニューにある [デプロイとインフラストラクチャ] で、[ネットワーク] > [仮想ネットワーク] の順に選択します。
- [ネットワーク構成の適用] を選択します。
リソース ナビゲーション リンク
stv1 コンピューティング プラットフォームでホストされている API Management のインスタンスは、Resource Manager VNet サブネットにデプロイされるときに、リソース ナビゲーション リンクを作成することによってサブネットを予約します。 サブネットに別のプロバイダーのリソースが既に含まれている場合、デプロイは失敗します。 同様に、API Management サービスを削除するか、別のサブネットに移動すると、リソース ナビゲーション リンクは削除されます。
API Management のインスタンスを以前のサブネットに割り当て直す場合に発生する問題
- VNet ロック - API Management のインスタンスを元のサブネットに戻す場合、VNet ロックのため、再割り当てがすぐにできない場合があり、解除には最大 6 時間かかります。 元のサブネットに他の
stv1プラットフォームベースの API Management サービス (クラウド サービス ベース) がある場合、stv2プラットフォームベースのサービスを同じサブネットにデプロイするには、それらを削除して 6 時間待つ必要があります。 - リソース グループ ロック - また、リソース グループ レベル以上にスコープ ロックが存在し、これによってリソース ナビゲーション リンクの削除プロセスが妨げられるというシナリオも、考慮すべきシナリオの 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を試します。
次のステップ
各項目の詳細情報