Azure API Management インスタンスを仮想ネットワークにデプロイする - 内部モード
適用対象: Developer | Premium
Azure API Management を Azure 仮想ネットワーク (VNet) の内部にデプロイ (挿入) すると、そのネットワーク内のバックエンド サービスにアクセスできます。 VNET 接続のオプション、要件、考慮事項については、次のページを参照してください。
この記事では、内部モードで API Management インスタンスの VNet 接続を設定する方法について説明します。 このモードでアクセスできるのは、自分がアクセスを制御している VNET 内にある次の API Management エンドポイントだけです。
- API ゲートウェイ
- 開発者ポータル
- ダイレクト管理
- Git
Note
API Management を内部モードで使用するのは、次のようなケースです。
- Azure VPN 接続または Azure ExpressRoute を使用することで、プライベート データセンターでホストされている API へのアクセスを、外部のサード パーティが安全に行うことができるようにします。
- 一般的なゲートウェイを通じてクラウド ベースの API とオンプレミスの API を公開することによって、ハイブリッド クラウドのシナリオを有効にします。
- 単一のゲートウェイ エンドポイントを使用して複数の地理的な場所でホストされている API を管理します。
"外部" モード (パブリック インターネットから API Management エンドポイントにアクセスでき、そのネットワーク内にバックエンド サービスが配置される) に固有の構成については、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 アドレス。
重要
- 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 プラットフォーム)
Azure portal に移動し、お使いの API Management インスタンスを検索します。 API Management サービスを検索して選択します。
お使いの API Management インスタンスを選択します。
[ネットワーク]>[仮想ネットワーク] の順に選択します。
アクセスの種類として [内部] を選択します。
API Management サービスがプロビジョニングされている場所 (リージョン) のリストで、次の手順に従います。
- [場所] を選択します。
- [仮想ネットワーク] と [サブネット] を選択します。
- VNet の一覧には、構成しているリージョンで設定された Azure サブスクリプションで使用できる Resource Manager の VNet が設定されます。
[適用] を選択します。 API Management インスタンスの [仮想ネットワーク] ページが、新しい VNet とサブネットの選択によって更新されます。
API Management インスタンスの残りの場所に対して、VNet 設定の構成を続行します。
上部のナビゲーション バーで、[保存] を選択します。
API Management インスタンスを更新するのに 15 分から 45 分かかることがあります。 Developer レベルでは、処理中にダウンタイムが発生します。 Basic 以上の SKU では、処理中にダウンタイムが発生しません。
デプロイが成功すると、 [概要] ブレードに、API Management サービスのプライベート仮想 IP アドレスとパブリック仮想 IP アドレスが表示されます。 IP アドレスの詳細については、この記事の「ルーティング」を参照してください。
注意
ゲートウェイ URL はパブリック DNS には登録されないため、Azure portal で利用可能なテスト コンソールは、内部 VNet にデプロイされたサービスでは機能しません。 開発者ポータルで提供されるテスト コンソールを使用してください。
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 を公開する | 外部 / 内部 |
DNS の構成
内部 VNet モードでは、独自の DNS を管理して、API Management エンドポイントへの受信アクセスを有効にする必要があります。
以下のことが推奨されます。
- Azure DNS プライベート ゾーンを構成します。
- その Azure DNS プライベート ゾーンを API Management サービスのデプロイ先 VNet にリンクします。
Azure DNS でのプライベート ゾーンの設定方法を確認してください。
Note
API Management サービスは、その IP アドレス上の要求をリッスンしません。 エンドポイントで構成されたホスト名に対する要求のみに応答します。 たとえば、次のエンドポイントが該当します。
- API ゲートウェイ
- Azure ポータル
- 開発者ポータル
- ダイレクト管理エンドポイント
- Git
既定のホスト名でのアクセス
API Management サービス (たとえば contosointernalvnet) を作成すると、次のエンドポイントが既定で構成されます。
| エンドポイント | エンドポイントの構成 |
|---|---|
| API ゲートウェイ | contosointernalvnet.azure-api.net |
| 開発者ポータル | contosointernalvnet.portal.azure-api.net |
| 新しい開発者ポータル | contosointernalvnet.developer.azure-api.net |
| ダイレクト管理エンドポイント | contosointernalvnet.management.azure-api.net |
| Git | contosointernalvnet.scm.azure-api.net |
カスタム ドメイン名でのアクセス
既定のホスト名を持つ API Management サービスにアクセスしたくない場合は、次の図に示すように、すべてのエンドポイントのカスタム ドメイン名を設定できます。
DNS レコードを構成する
VNet 内からアクセスできるエンドポイントにアクセスするためのレコードを DNS サーバーに作成します。 エンドポイント レコードをサービスのプライベート仮想 IP アドレスにマップします。
テスト目的で、API Management がデプロイされている VNet に接続されているサブネット内の仮想マシン上のホスト ファイルを更新できます。 サービスのプライベート仮想 IP アドレスを 10.1.0.5 と仮定すると、ホスト ファイルを次のようにマッピングできます。 hosts マッピング ファイルは、%SystemDrive%\drivers\etc\hosts (Windows) または /etc/hosts (Linux、macOS) にあります。
| 内部仮想 IP アドレス | エンドポイントの構成 |
|---|---|
| 10.1.0.5 | contosointernalvnet.azure-api.net |
| 10.1.0.5 | contosointernalvnet.portal.azure-api.net |
| 10.1.0.5 | contosointernalvnet.developer.azure-api.net |
| 10.1.0.5 | contosointernalvnet.management.azure-api.net |
| 10.1.0.5 | contosointernalvnet.scm.azure-api.net |
これで、すべての API Management エンドポイントに、作成した仮想マシンからアクセスできるようになります。
ルート指定
次の仮想 IP アドレスは、内部仮想ネットワーク内の API Management インスタンス用に構成されています。
| Virtual IP address | 説明 |
|---|---|
| プライベート仮想 IP アドレス | API Management インスタンスのサブネット範囲 (DIP) 内の負荷分散された IP アドレス。このアドレスを介して、API ゲートウェイ、開発者ポータル、管理、および Git エンドポイントにアクセスできます。 このアドレスは、VNet で使用される DNS サーバーに登録します。 |
| パブリック仮想 IP アドレス | ポート 3443 を介した管理エンドポイントへのコントロール プレーン トラフィックに "のみ" 使用されます。 ApiManagement サービス タグにロック ダウンすることができます。 |
負荷分散されたパブリック IP アドレスとプライベート IP アドレスは、Azure portal の [概要] ブレードで確認できます。
詳細および考慮事項については、「Azure API Management の IP アドレス」を参照してください。
VIP アドレスと DIP アドレス
動的 IP (DIP) アドレスは、サービス内の基盤となる各仮想マシンに割り当てられ、VNet およびピアリングされた VNet 内にあるエンドポイントとリソースへのアクセスに使用されます。 API Management サービスのパブリック仮想 IP (VIP) アドレスは、パブリック リソースにアクセスするために使用されます。
IP 制限リストを使用して VNet またはピアリングされた VNet 内のリソースをセキュリティで保護する場合は、API Management サービスがデプロイされるサブネットの範囲全体に対して、サービスからのアクセスを許可するか制限するように指定することをお勧めします。
推奨されるサブネット サイズについて説明します。
例
内部 VNet の Premium レベルに API Management の 1 つの容量ユニットをデプロイすると、3 つの IP アドレスが使用されます。1 つはプライベート VIP 用で、残りは 2 つの VM の各 DIP 用です。 4 つのユニットにスケールアウトすると、サブネットからの追加の DIP にさらに多くの IP が使用されます。
宛先エンドポイントで、固定された DIP のセットのみが許可リストに含まれている場合は、今後新しいユニットを追加すると接続エラーが発生します。 この理由により、また、サブネットは完全に制御可能であるため、バックエンドでサブネット全体を許可リストに含めることをお勧めします。
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 ロックのため、即座の再割り当てが不可能な場合があります。ロックの削除には最大 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を試します。
次のステップ
各項目の詳細情報