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.

注意

この記事は、新しい Azure PowerShell Az モジュールを使用するために更新されました。This article has been updated to use the new Azure PowerShell Az module. AzureRM モジュールはまだ使用でき、少なくとも 2020 年 12 月までは引き続きバグ修正が行われます。You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Az モジュールと AzureRM の互換性の詳細については、「Introducing the new Azure PowerShell Az module (新しい Azure PowerShell Az モジュールの概要)」を参照してください。To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Az モジュールのインストール手順については、Azure PowerShell のインストールを参照してください。For Az module installation instructions, see Install Azure PowerShell.

可用性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 in the top navigation bar.

  6. 上部のナビゲーション バーの [ネットワーク構成の適用] をクリックします。Click Apply network configuration in the top navigation bar.

注意

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-AzApiManagement を使用して、VNET 内に Azure API Management サービスを作成します。Create an API Management service inside a VNET: Use the cmdlet New-AzApiManagement to create an Azure API Management service inside a VNET.

  • VNET 内に既存の API Management サービスをデプロイする:コマンドレット Update-AzApiManagementRegion を使用して、既存の Azure API Management サービスを仮想ネットワーク内に移動します。Deploy an existing API Management service inside a VNET: Use the cmdlet Update-AzApiManagementRegion 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) DirectionDirection トランスポート プロトコル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 ロール インスタンス間での Azure Cache for Redis インスタンスへのアクセスAccess Azure Cache for Redis 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 リレー用の送信ネットワーク接続。smtpi-co1.msn.comsmtpi-ch1.msn.comsmtpi-db3.msn.comsmtpi-sin.msn.comies.global.microsoft.com の各ホストで解決されます。SMTP Relay: Outbound network connectivity for the SMTP Relay, which resolves under the host smtpi-co1.msn.com, smtpi-ch1.msn.com, smtpi-db3.msn.com, smtpi-sin.msn.com and ies.global.microsoft.com

  • 開発者ポータル CAPTCHA: 開発者ポータルの CAPTCHA 用の発信ネットワーク接続。ホスト client.hip.live.com で解決されます。Developer portal CAPTCHA: Outbound network connectivity for the developer portal's CAPTCHA, which resolves under the host client.hip.live.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 またはネットワーク仮想アプライアンスを使用したオンプレミスのファイアウォールへのトラフィックの強制トンネリング: 顧客の一般的な構成では、API Management の委任されたサブネットからのすべてのトラフィックを、オンプレミスのファイアウォールまたはネットワーク仮想アプライアンスに強制的に流す、独自の既定のルート (0.0.0.0/0) が定義されています。Force Tunneling Traffic to On-prem Firewall Using Express Route or Network Virtual Appliance: A common customer configuration is to define their own default route (0.0.0.0/0) which forces all traffic from the API Management delegated subnet to flow through an on-premises firewall or to an Network virtual appliance. このトラフィック フローでは、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. これを解決するには、いくつかのことを実行する必要があります。The solution requires you to do a couple of things:

    • API Management サービスがデプロイされているサブネット上でサービス エンドポイントを有効にします。Enable service endpoints on the subnet in which the API Management service is deployed. Azure SQL、Azure Storage、Azure EventHub、Azure ServiceBus のサービス エンドポイントを有効にする必要があります。Service Endpoints need to be enabled for Azure Sql, Azure Storage, Azure EventHub and Azure ServiceBus. これらのサービスに対して、API Management の委任されたサブネットからエンドポイントを直接有効にすると、サービス トラフィックの最適なルーティングを提供する Microsoft Azure バックボーン ネットワークを使用できるようになります。Enabling endpoints directly from API Management delegated subnet to these services allows them to use the Microsoft Azure backbone network providing optimal routing for service traffic. トンネリングが強制された API Management でサービス エンドポイントを使用すると、上記の Azure サービス のトラフィックが強制的にトンネリングされることはありません。If you use Service Endpoints with a forced tunneled Api Management, the above Azure services traffic isn't forced tunneled. API Management サービスの他の 依存関係トラフィックは強制的にトンネリングされ、失われることはありません。依存関係トラフィックが失われた場合、API Management サービスが適切に機能しなくなります。The other API Management service dependency traffic is forced tunneled and can't be lost or the API Management service would not function properly.

    • インターネットから API Management サービスの管理エンドポイントへのすべてのコントロール プレーン トラフィックは、API Management によってホストされている受信 IP の特定のセットを使用してルーティングされます。All the control plane traffic from Internet to the management endpoint of your API Management service are routed through a specific set of Inbound IPs hosted by API Management. トラフィックが強制的にトンネリングされると、応答がこれらの受信送信元 IP に対称的にマップされなくなります。When the traffic is force tunneled the responses will not symmetrically map back to these Inbound source IPs. この制限を克服するには、次のユーザー定義ルート (UDR) を追加し、これらのホスト ルートの宛先を "Internet" に設定することによってトラフィックを Azure に誘導する必要があります。To overcome the limitation, we need to add the following user-defined routes (UDRs) to steer traffic back to Azure by setting the destination of these host routes to "Internet". コントロール プレーン トラフィックの受信 IP のセットは次のとおりです。The set of Inbound IPs for control Plane traffic is as follows:

      13.84.189.17/32、13.85.22.63/32、23.96.224.175/32、23.101.166.38/32、52.162.110.80/32、104.214.19.224/32、13.64.39.16/32、40.81.47.216/32、51.145.179.78/32、52.142.95.35/32、40.90.185.46/32、20.40.125.155/3213.84.189.17/32, 13.85.22.63/32, 23.96.224.175/32, 23.101.166.38/32, 52.162.110.80/32, 104.214.19.224/32, 13.64.39.16/32, 40.81.47.216/32, 51.145.179.78/32, 52.142.95.35/32, 40.90.185.46/32, 20.40.125.155/32

    • 強制的にトンネリングされる、API Management サービスの他の依存関係については、ホスト名を解決し、エンドポイントに到達するための方法が必要です。For other API Management service dependencies which are force tunneled, there should be a way to resolve the hostname and reach out to the endpoint. 次のような方法があります。These include

      • メトリックと正常性の監視Metrics and Health Monitoring
      • Azure portal 診断Azure portal Diagnostics
      • SMTP リレーSMTP Relay
      • 開発者ポータル CAPTCHADeveloper portal CAPTCHA

トラブルシューティング 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 three 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