Azure API Management を使用して仮想ネットワークに接続する
Azure API Management を Azure 仮想ネットワーク (VNet) の内部にデプロイすると、そのネットワーク内のバックエンド サービスにアクセスできます。 VNet 接続のオプション、要件、考慮事項については、Azure API Management での仮想ネットワークの使用に関するページを参照してください。
この記事では、"外部" モードで API Management インスタンスの VNet 接続を設定する方法について説明します。このモードでは、パブリック インターネットから開発者ポータル、API ゲートウェイ、その他の API Management エンドポイントにアクセスすることができ、バックエンド サービスはネットワーク内に配置されています。
VNet 内でのみエンドポイントにアクセスできる "内部" モード固有の構成については、Azure API Management を使用した内部仮想ネットワークへの接続に関するページを参照してください。
Note
Azure を操作するには、Azure Az PowerShell モジュールを使用することをお勧めします。 作業を開始するには、Azure PowerShell のインストールに関する記事を参照してください。 Az PowerShell モジュールに移行する方法については、「AzureRM から Az への Azure PowerShell の移行」を参照してください。
可用性
重要
この機能は、API Management の Premium レベルと Developer レベルで使用できます。
前提条件
一部の前提条件は、API Management インスタンスをホストしているstv2のバージョン (stv2 または stv1) によって異なります。
ヒント
ポータルを使用して既存の API Management インスタンスのネットワーク接続を作成または更新する場合、そのインスタンスは stv2 コンピューティング プラットフォームでホストされています。
- API Management インスタンス。 詳細については、Azure API Management インスタンスの作成に関する記事を参照してください。
API Management インスタンスと同じリージョンおよびサブスクリプション内に存在する仮想ネットワークとサブネット。
- API Management インスタンスへの接続に使用されるサブネットには、他の Azure リソースの種類が含まれる場合があります。
- サブネットで委任を有効にしないでください。 サブネットの [サブネットをサービスに委任] 設定は、[なし] に設定する必要があります。
上記のサブネットに接続されたネットワーク セキュリティ グループ。 受信接続を明示的に許可するには、ネットワーク セキュリティ グループ (NSG) が必要です。これは、API Management によって内部的に使用されるロード バランサーが既定でセキュリティ保護され、すべての受信トラフィックを拒否するためです。 具体的な構成については、この記事で後述する「NSG 規則の構成」を参照してください。
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 レベルでは、処理中にダウンタイムが発生します。 Basic 以上の SKU では、処理中にダウンタイムが発生しません。
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 | VirtualNetwork/Storage | Azure Storage への依存関係 | 外部 / 内部 |
| * / 1433 | 送信 | TCP | VirtualNetwork/SQL | Azure SQL エンドポイントへのアクセス | 外部 / 内部 |
| * / 443 | 送信 | TCP | VirtualNetwork/AzureKeyVault | Azure Key Vault へのアクセス | 外部 / 内部 |
仮想ネットワーク内でホストされる 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 によってホストされている受信 IP の特定のセットを使用してルーティングされます。 トラフィックが強制的にトンネリングされると、応答はこれらの受信ソース IP に対称的にマップされなくなり、管理エンドポイントへの接続が失われます。 この制限を克服するには、次ホップの種類が "インターネット" に設定されたこれらの受信 IP のユーザー定義ルート (UDR) を構成して、トラフィックを Azure に戻します。 ApiManagement サービス タグを構成するか、「コントロール プレーンの IP アドレス」に記載されているコントロール プレーン トラフィックの受信 IP のセットを確認します。
重要
コントロール プレーンの IP アドレスは、特定のネットワーク シナリオで必要な場合にのみ、ネットワーク アクセス ルールおよびルートに合わせて構成します。 インフラストラクチャの改善によって IP アドレスの変更が必要になった場合にダウンタイムが発生しないよう、コントロール プレーンの IP アドレスの代わりに ApiManagement サービス タグを使用することをお勧めします。
注意
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 つずつ検証します。
重要
接続を検証した後、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 インスタンスに適用するには:
- インスタンスの左側のメニューにある [デプロイとインフラストラクチャ] で、[仮想ネットワーク] を選択します。
- [ネットワーク構成の適用] を選択します。
リソース ナビゲーション リンク
コンピューティング プラットフォームでホストされている APIM インスタンスは、Resource Manager VNET サブネットにデプロイされるとき、リソース ナビゲーション リンクを作成することによってサブネットを予約します。 サブネットに別のプロバイダーのリソースが既に含まれている場合、デプロイは失敗します。 同様に、API Management サービスを削除するか、別のサブネットに移動すると、リソース ナビゲーション リンクは削除されます。APIM インスタンスを以前のサブネットに再割り当てする場合に発生する課題
- APIM インスタンスを元のサブネットに戻す場合、VNET ロックがかかっているため、すぐに再割り当てができない場合があります (解除には最大 6 時間かかります)。 元のサブネットに他の APIM サービス (クラウド サービス ベース) がある場合、VMSS ベースのサービスを同じサブネットにデプロイするには、それらを削除して 6 時間待つ必要があります。
- また、リソース グループ レベル以上にスコープ ロックが存在し、これによってリソース ナビゲーション リンクの削除プロセスが妨げられるというシナリオも、考慮すべきシナリオの 1 つです。 これを解決するには、スコープ ロックを解除し、ロック解除前に APIM サービスが元のサブネットからリンク解除するまでに約 4 から 6 時間の遅延を設け、目的のサブネットにデプロイできるようにします。
次のステップ
各項目の詳細情報