Azure API Management で仮想ネットワークを使用する方法How to use Azure API Management with virtual networks

Azure Virtual Network (VNET) を使用すると、任意の Azure リソースをインターネット以外のルーティング可能なネットワークに配置し、アクセスを制御できます。Azure Virtual Networks (VNETs) allow you to place any of your Azure resources in a non-internet routeable network that you control access to. これらのネットワークは、さまざまな VPN テクノロジを使用して、オンプレミスのネットワークに接続できます。These networks can then be connected to your on-premises networks using various VPN technologies. Azure Virtual Network の詳細については、まず Azure Virtual Network の概要に関するページに記載されている情報をご覧ください。To learn more about Azure Virtual Networks start with the information here: Azure Virtual Network Overview.

Azure API Management は、仮想ネットワーク (VNET) の内部でデプロイできるため、ネットワーク内でバックエンド サービスにアクセスできます。Azure API Management can be deployed inside the virtual network (VNET), so it can access backend services within the network. 開発者ポータルと API ゲートウェイは、インターネットから、または仮想ネットワーク内でのみアクセスできるように構成可能です。The developer portal and API gateway, can be configured to be accessible either from the Internet or only within the virtual network.

注意

Azure API Management では、従来型および Azure Resource Manager の両方の VNet がサポートされています。Azure API Management supports both classic and Azure Resource Manager VNets.

可用性Availability

重要

この機能は、API Management の Premium レベルと Developer レベルで使用できます。This feature is available in the Premium and Developer tiers of API Management.

前提条件Prerequisites

この記事で説明されている手順を実行するには、以下が必要です。To perform the steps described in this article, you must have:

VNET 接続の有効化 Enable VNET connection

Azure ポータルを使用して VNET 接続を有効にするEnable VNET connectivity using the Azure portal

  1. Azure ポータルで、APIM インスタンスに移動します。Navigate to your APIM instance in the Azure portal.
  2. [仮想ネットワーク] を選択します。Select Virtual Network.
  3. 仮想ネットワーク内にデプロイされる API Management インスタンスを構成します。Configure the API Management instance to be deployed inside a Virtual network.

    API Management の [仮想ネットワーク] メニュー

  4. 目的のアクセスの種類を選択します。Select the desired access type:

    • 外部: API Management のゲートウェイと開発者ポータルには、パブリック インターネットから外部ロード バランサーを使用してアクセスできます。External: the API Management gateway and developer portal are accessible from the public internet via an external load balancer. ゲートウェイは、仮想ネットワーク内のリソースにアクセスできます。The gateway can access resources within the virtual network.

      パブリック ピアリング

    • 内部: API Management のゲートウェイと開発者ポータルには、仮想ネットワークから内部ロード バランサーを使用してアクセスできます。Internal: the API Management gateway and developer portal are accessible only from within the virtual network via an internal load balancer. ゲートウェイは、仮想ネットワーク内のリソースにアクセスできます。The gateway can access resources within the virtual network.

      プライベート ピアリング`

      API Management サービスがプロビジョニングされているすべてのリージョンの一覧が表示されます。You will now see a list of all regions where your API Management service is provisioned. すべてのリージョンについて、VNET とサブネットを選択します。Select a VNET and subnet for every region. この一覧には、構成しているリージョンで設定された Azure サブスクリプションで使用できる従来型および Resource Manager の仮想ネットワークが含まれます。The list is populated with both classic and Resource Manager virtual networks available in your Azure subscriptions that are setup in the region you are configuring.

      注意

      上の図のサービス エンドポイントには、ゲートウェイ/プロキシ、Azure Portal、開発者ポータル、GIT、およびダイレクト管理エンドポイントが含まれています。Service Endpoint in the above diagram includes Gateway/Proxy, the Azure portal, the Developer portal, GIT, and the Direct Management Endpoint. 上の図の管理エンドポイントは、Azure Portal と Powershell を使用して構成を管理するためにサービスでホストされるエンドポイントです。Management Endpoint in the above diagram is the endpoint hosted on the service to manage configuration via Azure portal and Powershell. さらに、図にはさまざまなエンドポイントの IP アドレスが示されていますが、API Management サービスは、構成済みのホスト名でのみで応答することに注意してください。Also, note, that, even though, the diagram shows IP Addresses for its various endpoints, API Management service only responds on its configured Hostnames.

      重要

      Azure API Management インスタンスを Resource Manager VNET にデプロイする場合、サービスは Azure API Management インスタンス以外のリソースを含まない専用サブネットにある必要があります。When deploying an Azure API Management instance to a Resource Manager VNET, the service must be in a dedicated subnet that contains no other resources except for Azure API Management instances. 他のリソースが含まれる Resource Manager VNET サブネットに Azure API Management インスタンスをデプロイしようとすると、そのデプロイは失敗します。If an attempt is made to deploy an Azure API Management instance to a Resource Manager VNET subnet that contains other resources, the deployment will fail.

      VPN の選択

  5. 画面の上部にある [保存] をクリックします。Click Save at the top of the screen.

注意

API Management インスタンスの VIP アドレスは VNET を有効または無効にするたびに変更されます。The VIP address of the API Management instance will change each time VNET is enabled or disabled. また、VIP アドレスは、API Management が外部から内部に、またはその逆に移動された場合にも変更されます。The VIP address will also change when API Management is moved from External to Internal or vice-versa

重要

VNET から API Management を削除するか、VNET にデプロイされる API Management を変更した場合、それまで使用されていた VNET が最大 2 時間ロックされる可能性があります。If you remove API Management from a VNET or change the one it is deployed in, the previously used VNET can remain locked for up to two hours. この期間中は、VNET の削除も、新しいリソースのデプロイも実行できません。During this period it will not be possible to delete the VNET or deploy a new resource to it.

PowerShell コマンドレットを使用して VNET 接続を有効にする Enable VNET connection using PowerShell cmdlets

PowerShell コマンドレットを使用して VNET 接続を有効にすることもできます。You can also enable VNET connectivity using the PowerShell cmdlets

  • VNET 内に API Management サービスを作成する: コマンドレット New-AzureRmApiManagement を使用して、VNET 内に Azure API Management サービスを作成します。Create an API Management service inside a VNET: Use the cmdlet New-AzureRmApiManagement to create an Azure API Management service inside a VNET.

  • VNET 内に既存の API Management サービスをデプロイする: コマンドレット Update-AzureRmApiManagementDeployment を使用して、既存の Azure API Management サービスを Virtual Network 内に移動します。Deploy an existing API Management service inside a VNET: Use the cmdlet Update-AzureRmApiManagementDeployment to move an existing Azure API Management service inside a Virtual Network.

仮想ネットワーク内でホストされる Web サービスに接続する Connect to a web service hosted within a virtual Network

API Management サービスが VNET に接続された後で VNET 内のバックエンド サービスにアクセスする方法は、パブリック サービスにアクセスする方法と同じです。After your API Management service is connected to the VNET, accessing backend services within it is no different than accessing public services. 単に、新しい API を作成するときや既存の API を編集するときに Web サービスのローカル IP アドレスまたはホスト名 (VNET に対して DNS サーバーが構成されている場合) を [Web サービスの URL] ボックスに入力するだけです。Just type in the local IP address or the host name (if a DNS server is configured for the VNET) of your web service into the Web service URL field when creating a new API or editing an existing one.

VPN からの API の追加

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

API Management サービスを Virtual Network にデプロイするときに発生する可能性のある一般的な誤った構成の一覧を以下に示します。Following is a list of common misconfiguration issues that can occur while deploying API Management service into a Virtual Network.

  • カスタム DNS サーバーのセットアップ: API Management サービスは、複数の Azure サービスに依存します。Custom DNS server setup: The API Management service depends on several Azure services. カスタム DNS サーバーを使用して VNET で API Management をホストする場合、その DNS サーバーはこれらの Azure サービスのホスト名を解決する必要があります。When API Management is hosted in a VNET with a custom DNS server, it needs to resolve the hostnames of those Azure services. カスタム DNS のセットアップについては、 こちらの ガイダンスに従ってください。Please follow this guidance on custom DNS setup. 下にあるポートの表とその他のネットワーク要件を参照してください。See the ports table below and other network requirements for reference.

重要

VNET でカスタム DNS サーバーを使用する予定の場合は、API Management サービスをデプロイするにサーバーをセットアップします。If you plan to use a Custom DNS Server(s) for the VNET, you should set it up before deploying an API Management service into it. それ以外の場合、ネットワーク構成の処理の適用を実行して DNS サーバーを変更するたびに API Management サービスを更新する必要があります。Otherwise you need to update the API Management service each time you change the DNS Server(s) by running the Apply Network Configuration Operation

  • API Management に必要なポート: API Management がデプロイされるサブネットへの受信トラフィックと送信トラフィックはネットワーク セキュリティ グループを使用して制御できます。Ports required for API Management: Inbound and Outbound traffic into the Subnet in which API Management is deployed can be controlled using Network Security Group. これらのポートのいずれかが利用できない場合、API Management は正しく動作しない可能性があり、アクセス不能になる場合があります。If any of these ports are unavailable, API Management may not operate properly and may become inaccessible. VNET で API Management を使用した場合の不正な構成に関するその他の一般的な問題として、これらの 1 つまたは複数のポートがブロックされていることが挙げられます。Having one or more of these ports blocked is another common misconfiguration issue when using API Management with a VNET.

API Management サービス インスタンスが VNET でホストされている場合は、次の表のポートが使用されます。When an API Management service instance is hosted in a VNET, the ports in the following table are used.

ソース / ターゲット ポートSource / Destination Port(s) 方向Direction トランスポート プロトコルTransport protocol サービス タグService Tags
ソース / ターゲットSource / Destination
目的 ( * )Purpose (*) 仮想ネットワークの種類Virtual Network type
* / 80, 443* / 80, 443 受信Inbound TCPTCP INTERNET / VIRTUAL_NETWORKINTERNET / VIRTUAL_NETWORK API Management へのクライアント通信Client communication to API Management 外部External
* / 3443* / 3443 受信Inbound TCPTCP ApiManagement / VIRTUAL_NETWORKApiManagement / VIRTUAL_NETWORK Azure Portal と Powershell 用の管理エンドポイントManagement endpoint for Azure portal and Powershell 外部 / 内部External & Internal
* / 80, 443* / 80, 443 送信Outbound TCPTCP VIRTUAL_NETWORK / StorageVIRTUAL_NETWORK / Storage Azure Storage への依存関係Dependency on Azure Storage 外部 / 内部External & Internal
* / 80, 443* / 80, 443 送信Outbound TCPTCP VIRTUAL_NETWORK / AzureActiveDirectoryVIRTUAL_NETWORK / AzureActiveDirectory Azure Active Directory (該当する場合)Azure Active Directory (where applicable) 外部 / 内部External & Internal
* / 1433* / 1433 送信Outbound TCPTCP VIRTUAL_NETWORK / SQLVIRTUAL_NETWORK / SQL Azure SQL エンドポイントへのアクセスAccess to Azure SQL endpoints 外部 / 内部External & Internal
* / 5672* / 5672 送信Outbound TCPTCP VIRTUAL_NETWORK / EventHubVIRTUAL_NETWORK / EventHub Event Hub へのログ ポリシーおよび監視エージェントの依存関係Dependency for Log to Event Hub policy and monitoring agent 外部 / 内部External & Internal
* / 445* / 445 送信Outbound TCPTCP VIRTUAL_NETWORK / StorageVIRTUAL_NETWORK / Storage GIT のための Azure ファイル共有への依存関係Dependency on Azure File Share for GIT 外部 / 内部External & Internal
* / 1886* / 1886 送信Outbound TCPTCP VIRTUAL_NETWORK / INTERNETVIRTUAL_NETWORK / INTERNET 正常性の状態を Resource Health に公開するために必要Needed to publish Health status to Resource Health 外部 / 内部External & Internal
* / 443* / 443 送信Outbound TCPTCP VIRTUAL_NETWORK / AzureMonitorVIRTUAL_NETWORK / AzureMonitor 診断ログとメトリックの公開Publish Diagnostics Logs and Metrics 外部 / 内部External & Internal
* / 25* / 25 送信Outbound TCPTCP VIRTUAL_NETWORK / INTERNETVIRTUAL_NETWORK / INTERNET 電子メールを送信するために SMTP リレーに接続するConnect to SMTP Relay for sending e-mails 外部 / 内部External & Internal
* / 587* / 587 送信Outbound TCPTCP VIRTUAL_NETWORK / INTERNETVIRTUAL_NETWORK / INTERNET 電子メールを送信するために SMTP リレーに接続するConnect to SMTP Relay for sending e-mails 外部 / 内部External & Internal
* / 25028* / 25028 送信Outbound TCPTCP VIRTUAL_NETWORK / INTERNETVIRTUAL_NETWORK / INTERNET 電子メールを送信するために SMTP リレーに接続するConnect to SMTP Relay for sending e-mails 外部 / 内部External & Internal
* / 6381 - 6383* / 6381 - 6383 受信および送信Inbound & Outbound TCPTCP VIRTUAL_NETWORK / VIRTUAL_NETWORKVIRTUAL_NETWORK / VIRTUAL_NETWORK Role インスタンス間での Redis Cache インスタンスへのアクセスAccess Redis Cache Instances between RoleInstances 外部 / 内部External & Internal
* / ** / * 受信Inbound TCPTCP AZURE_LOAD_BALANCER / VIRTUAL_NETWORKAZURE_LOAD_BALANCER / VIRTUAL_NETWORK Azure インフラストラクチャの Load BalancerAzure Infrastructure Load Balancer 外部 / 内部External & Internal

重要

"目的" が太字になっているポートは、API Management サービスの正常なデプロイを必要とします。The Ports for which the Purpose is bold are required for API Management service to be deployed successfully. ただし、その他のポートをブロックすると、実行中のサービスの使用と監視を行う能力が低下します。Blocking the other ports however will cause degradation in the ability to use and monitor the running service.

  • SSL 機能: SSL 証明書チェーンの構築と検証を有効にするには、API Management サービスに ocsp.msocsp.com、mscrl.microsoft.com、および crl.microsoft.com に対する送信ネットワーク接続が必要です。SSL functionality: To enable SSL certificate chain building and validation the API Management service needs Outbound network connectivity to ocsp.msocsp.com, mscrl.microsoft.com and crl.microsoft.com. API Management にアップロードする任意の証明書に CA ルートへの完全なチェーンが含まれている場合、この依存関係は必要ありません。This dependency is not required, if any certificate you upload to API Management contain the full chain to the CA root.

  • DNS アクセス: DNS サーバーとの通信には、ポート 53 での発信アクセスが必要です。DNS Access: Outbound access on port 53 is required for communication with DNS servers. カスタム DNS サーバーが VPN ゲートウェイの相手側にある場合、DNS サーバーは API Management をホストしているサブネットから到達できる必要があります。If a custom DNS server exists on the other end of a VPN gateway, the DNS server must be reachable from the subnet hosting API Management.

  • メトリックと正常性の監視: Azure Monitoring エンドポイントへの発信ネットワーク接続、次のドメインで解決されます:Metrics and Health Monitoring: Outbound network connectivity to Azure Monitoring endpoints, which resolve under the following domains:

    Azure 環境Azure Environment エンドポイントEndpoints
    Azure PublicAzure Public
    • prod.warmpath.msftcloudes.comprod.warmpath.msftcloudes.com
    • shoebox2.metrics.nsatc.netshoebox2.metrics.nsatc.net
    • prod3.metrics.nsatc.netprod3.metrics.nsatc.net
    • prod3-black.prod3.metrics.nsatc.netprod3-black.prod3.metrics.nsatc.net
    • prod3-red.prod3.metrics.nsatc.netprod3-red.prod3.metrics.nsatc.net
    • prod.warm.ingestion.msftcloudes.comprod.warm.ingestion.msftcloudes.com
    • East US 2 が eastus2.warm.ingestion.msftcloudes.com である azure region.warm.ingestion.msftcloudes.comazure region.warm.ingestion.msftcloudes.com where East US 2 is eastus2.warm.ingestion.msftcloudes.com
    Azure GovernmentAzure Government
    • fairfax.warmpath.usgovcloudapi.netfairfax.warmpath.usgovcloudapi.net
    • shoebox2.metrics.nsatc.netshoebox2.metrics.nsatc.net
    • prod3.metrics.nsatc.netprod3.metrics.nsatc.net
    Azure ChinaAzure China
    • mooncake.warmpath.chinacloudapi.cnmooncake.warmpath.chinacloudapi.cn
    • shoebox2.metrics.nsatc.netshoebox2.metrics.nsatc.net
    • prod3.metrics.nsatc.netprod3.metrics.nsatc.net
  • SMTP リレー: SMTP リレー用の発信ネットワーク接続。ies.global.microsoft.com ホストで解決されます。SMTP Relay: Outbound network connectivity for the SMTP Relay, which resolves under the host ies.global.microsoft.com.

  • Azure portal 診断: 仮想ネットワーク内から API Management 拡張機能を使用しているときに、Azure portal から診断ログのフローを有効にするには、ポート 443 での dc.services.visualstudio.com への送信アクセスが必要です。Azure portal Diagnostics: To enable the flow of diagnostic logs from Azure portal when using the API Management extension from inside a Virtual Network, outbound access to dc.services.visualstudio.com on port 443 is required. これは、拡張機能の使用時に発生する可能性がある問題のトラブルシューティングに役立ちます。This helps in troubleshooting issues you might face when using extension.

  • Express Route セットアップ: 顧客の一般的な構成として、発信インターネット トラフィックを強制的にオンプレミスにフローさせる独自の既定のルート (0.0.0.0/0) を定義します。Express Route Setup: A common customer configuration is to define their own default route (0.0.0.0/0) which forces outbound Internet traffic to instead flow on-premises. このトラフィック フローでは、Azure API Management を使用した接続は必ず切断されます。これは、発信トラフィックがオンプレミスでブロックされるか、さまざまな Azure エンドポイントで有効ではなくなった、認識できないアドレス セットに NAT 処理されることが原因です。This traffic flow invariably breaks connectivity with Azure API Management because the outbound traffic is either blocked on-premises, or NAT'd to an unrecognizable set of addresses that no longer work with various Azure endpoints. 解決策は、Azure API Management を含むサブネット上で 1 つ (以上) のユーザー定義ルート (UDR) を定義することです。The solution is to define one (or more) user-defined routes (UDRs) on the subnet that contains the Azure API Management. UDR は、既定のルートに優先するサブネット固有のルートを定義します。A UDR defines subnet-specific routes that will be honored instead of the default route. 可能であれば、次の構成を使用することをお勧めします。If possible, it is recommended to use the following configuration:

    • ExpressRoute 構成は 0.0.0.0/0 をアドバタイズし、既定でオンプレミスのすべての発信トラフィックを強制的にトンネリングします。The ExpressRoute configuration advertises 0.0.0.0/0 and by default force tunnels all outbound traffic on-premises.
    • Azure API Management を含むサブネットに適用される UDR では、次ホップの種類がインターネットである 0.0.0.0/0 を定義します。The UDR applied to the subnet containing the Azure API Management defines 0.0.0.0/0 with a next hop type of Internet. これらの手順を組み合わせた結果として、サブネット レベル UDR は ExpressRoute 強制トンネリングよりも優先されるので、Azure API Management からの発信インターネット アクセスを確保できます。The combined effect of these steps is that the subnet level UDR takes precedence over the ExpressRoute forced tunneling, thus ensuring outbound Internet access from the Azure API Management.
  • ネットワーク仮想アプライアンス経由のルーティング: 既定ルート (0.0.0.0/0) の UDR を使って API Management サブネットから Azure 内で実行されているネットワーク仮想アプライアンスを介し、インターネット宛てトラフィックをルーティングする構成では、仮想ネットワーク サブネット内にデプロイされた API Management サービス インスタンスにインターネットから着信する管理トラフィックがブロックされます。Routing through network virtual appliances: Configurations that use a UDR with a default route (0.0.0.0/0) to route internet destined traffic from the API Management subnet through a network virtual appliance running in Azure will block management traffic coming from Internet to the API Management service instance deployed inside the virtual network subnet. この構成はサポートされていません。This configuration is not supported.

警告

Azure API Management は、パブリック ピアリング パスからプライベート ピアリング パスにルートを正しくクロスアドバタイズしていない ExpressRoute 構成ではサポートされません。Azure API Management is not supported with ExpressRoute configurations that incorrectly cross-advertise routes from the public peering path to the private peering path. パブリック ピアリングが構成された ExpressRoute 構成は、大規模な Microsoft Azure の IP アドレス範囲について Microsoft からルート アドバタイズを受信します。ExpressRoute configurations that have public peering configured, will receive route advertisements from Microsoft for a large set of Microsoft Azure IP address ranges. これらのアドレス範囲がプライベート ピアリング パスで誤ってクロスアドバタイズされている場合、Azure API Management インスタンスのサブネットからのすべての発信ネットワーク パケットは、誤って顧客のオンプレミス ネットワーク インフラストラクチャに強制的にトンネリングされます。If these address ranges are incorrectly cross-advertised on the private peering path, the end result is that all outbound network packets from the Azure API Management instance's subnet are incorrectly force-tunneled to a customer's on-premises network infrastructure. このネットワーク フローでは、Azure API Management が機能しません。This network flow breaks Azure API Management. この問題を解決するには、パブリック ピアリング パスからプライベート ピアリング パスへのルートのクロスアドバタイズを停止します。The solution to this problem is to stop cross-advertising routes from the public peering path to the private peering path.

トラブルシューティング Troubleshooting

  • 初回のセットアップ: API Management サービスのサブネットへの初回のデプロイが成功しなかった場合は、同じサブネットに仮想マシンを先にデプロイすることをお勧めします。Initial Setup: When the initial deployment of API Management service into a subnet does not succeed, it is advised to first deploy a virtual machine into the same subnet. 次に、リモート デスクトップを仮想マシンにデプロイし、Azure サブスクリプション内の次のリソースのいずれかに接続できることを確認します。Next remote desktop into the virtual machine and validate that there is connectivity to one of each resource below in your azure subscription

    • Azure Storage BLOBAzure Storage blob
    • Azure SQL DatabaseAzure SQL Database
    • Azure Storage TableAzure Storage Table

    重要

    接続を確認したら、サブネットにデプロイされているすべてのリソースを必ず削除してから、サブネットに API Management をデプロイしてください。After you have validated the connectivity, make sure to remove all the resources deployed in the subnet, before deploying API Management into the subnet.

  • 増分更新: ネットワークを変更するときは、NetworkStatus API を参照して、API Management サービスが依存している重要なリソースへのアクセスが失われていないことを確認してください。Incremental Updates: When making changes to your network, refer to NetworkStatus API, to verify that the API Management service has not lost access to any of the critical resources which it depends upon. 接続状態は、15 分間隔で更新されます。The connectivity status should be updated every 15 minutes.

  • リソース ナビゲーション リンク: Resource Manager スタイルの VNET サブネットにデプロイすると、API Management は、リソース ナビゲーション リンクを作成することでサブネットを予約します。Resource Navigation Links: When deploying into Resource Manager style vnet subnet, API Management reserves the subnet, by creating a resource navigation Link. サブネットに別のプロバイダーのリソースが既に含まれている場合、デプロイは失敗します。If the subnet already contains a resource from a different provider, deployment will fail. 同様に、API Management サービスを別のサブネットに 移動するか削除すると、そのリソース ナビゲーション リンクが削除されます。Similarly, when you move an API Management service to a different subnet or delete it, we will remove that resource navigation link.

サブネットのサイズ要件 Subnet Size Requirement

Azure は、各サブネット内で一部の IP アドレスを予約し、これらのアドレスを使用することはできません。Azure reserves some IP addresses within each subnet, and these addresses can't be used. サブネットの最初と最後の IP アドレスは、Azure サービスで使用される 3 つ以上のアドレスと共に、プロトコル準拠に予約されます。The first and last IP addresses of the subnets are reserved for protocol conformance, along with three more addresses used for Azure services. 詳細については、「 これらのサブネット内の IP アドレスの使用に関する制限はありますかFor more information, see Are there any restrictions on using IP addresses within these subnets?

Azure VNET インフラストラクチャによって使用される IP アドレスに加えて、サブネットの各 API Management インスタンスは、Premium SKU のユニットごとに 2 つの IP アドレス、または Developer SKU 用に 1 つの IP アドレスを使用します。In addition to the IP addresses used by the Azure VNET infrastructure, each Api Management instance in the subnet uses two IP addresses per unit of Premium SKU or one IP address for the Developer SKU. 各インスタンスによって、外部ロード バランサー用の IP アドレスが別途予約されています。Each instance reserves an additional IP address for the external load balancer. 内部 VNET に展開する場合は、内部ロード バランサー用に追加の IP アドレスが必要です。When deploying into Internal vnet, it requires an additional IP address for the internal load balancer.

前述の計算によると、API Management で展開できるサブネットの最小サイズは /29 で、3 つの IP アドレスを提供します。Given the calculation above the minimum size of the subnet, in which API Management can be deployed is /29 which gives 3 IP addresses.

ルーティング Routing

  • 負荷分散されたパブリック IP アドレス (VIP) は、すべてのサービス エンドポイントへのアクセスを提供するために予約されます。A load balanced public IP address (VIP) will be reserved to provide access to all service endpoints.
  • サブネット IP 範囲 (DIP) の IP アドレスは VNET 内のリソースにアクセスするために使用され、パブリック IP アドレス (VIP) は VNET の外部のリソースにアクセスするために使用されます。An IP address from a subnet IP range (DIP) will be used to access resources within the vnet and a public IP address (VIP) will be used to access resources outside the vnet.
  • 負荷分散されたパブリック IP アドレスは、Azure Portal の [概要]/[要点] ブレードで確認できます。Load balanced public IP address can be found on the Overview/Essentials blade in the Azure portal.

制限事項 Limitations

  • API Management インスタンスが含まれるサブネットには、その他の Azure リソースの種類を含めることはできません。A subnet containing API Management instances cannot contain any other Azure resource types.
  • サブネットと API Management サービスは、同じサブスクリプション内になければなりません。The subnet and the API Management service must be in the same subscription.
  • API Management インスタンスが含まれるサブネットは、サブスクリプション間で移動できません。A subnet containing API Management instances cannot be moved across subscriptions.
  • 内部仮想ネットワーク モードで構成された複数リージョンの API Management デプロイでは、ルーティングを設定するユーザーが分散負荷の管理を担当します。デプロイでは、ユーザーが、ルーティングを担当するように、複数のリージョンの負荷分散の管理を担当します。For multi-region API Management deployments configured in Internal virtual network mode, users are responsible for managing the load balancing across multiple regions, as they own the routing.
  • 別のリージョン内にあるグローバルにピアリングされた VNET 内のリソースから、内部モードの API Management サービスへの接続は、プラットフォームの制限により機能しません。Connectivity from a resource in a globally peered VNET in another region to API Management service in Internal mode will not work due to platform limitation. 詳しくは、ある仮想ネットワーク内のリソースは、ピアリングされた仮想ネットワークの Azure 内部ロード バランサーと通信できないことに関するページをご覧ください。For more information, see Resources in one virtual network cannot communicate with Azure internal load balancer in peered virtual network

関連コンテンツ Related content