Application Gateway インフラストラクチャの構成Application Gateway infrastructure configuration

アプリケーション ゲートウェイのインフラストラクチャには、仮想ネットワーク、サブネット、ネットワーク セキュリティ グループ、ユーザー定義ルートが含まれます。The application gateway infrastructure includes the virtual network, subnets, network security groups, and user defined routes.

仮想ネットワークと専用サブネットVirtual network and dedicated subnet

アプリケーション ゲートウェイは、お客様の仮想ネットワーク内の専用デプロイメントです。An application gateway is a dedicated deployment in your virtual network. 仮想ネットワーク内では、ご使用のアプリケーション ゲートウェイのために専用サブネットが必要です。Within your virtual network, a dedicated subnet is required for the application gateway. 1 つのサブネットに特定のアプリケーション ゲートウェイ デプロイの複数インスタンスを配置できます。You can have multiple instances of a given application gateway deployment in a subnet. また、サブネット内に他のアプリケーション ゲートウェイをデプロイすることもできます。You can also deploy other application gateways in the subnet. ただし、アプリケーション ゲートウェイ サブネットに他のリソースをデプロイすることはできません。But you can't deploy any other resource in the application gateway subnet. 同じサブネット上に Standard_v2 と Standard Azure Application Gateway を混在することはできません。You can't mix Standard_v2 and Standard Azure Application Gateway on the same subnet.


仮想ネットワーク サービス エンドポイント ポリシーは現在、Application Gateway のサブネットではサポートされません。Virtual network service endpoint policies are currently not supported in an Application Gateway subnet.

サブネットのサイズSize of the subnet

Application Gateway は、インスタンスごとに 1 つのプライベート IP アドレスを使用します。さらに、プライベート フロントエンド IP を構成している場合は、もう 1 つのプライベート IP アドレスを使用します。Application Gateway uses one private IP address per instance, plus another private IP address if a private front-end IP is configured.

また、Azure は内部使用のために各サブネットに 5 個の IP アドレス (最初の 4 個の IP アドレスと最後の IP アドレス) を予約しています。Azure also reserves five IP addresses in each subnet for internal use: the first four and the last IP addresses. たとえば、プライベート フロントエンド IP がない 15 個のアプリケーション ゲートウェイ インスタンスがあるとします。For example, consider 15 application gateway instances with no private front-end IP. このサブネットには少なくとも 20 個の IP アドレスが必要です。内部使用のために 5 個、アプリケーション ゲートウェイ インスタンスのために 15 個です。You need at least 20 IP addresses for this subnet: five for internal use and 15 for the application gateway instances.

27 個のアプリケーション ゲートウェイ インスタンスと、プライベート フロントエンド IP 用の IP アドレスが 1 個あるサブネットがあるとします。Consider a subnet that has 27 application gateway instances and an IP address for a private front-end IP. この場合、33 個の IP アドレスが必要です。アプリケーション ゲートウェイ インスタンスのために 27 個、プライベート フロント エンドのために 1 個、内部使用のために 5 個です。In this case, you need 33 IP addresses: 27 for the application gateway instances, one for the private front end, and five for internal use.

Application Gateway (Standard または WAF) SKU では、最大 32 のインスタンス (32 のインスタンス IP アドレス + 1 つのプライベート フロントエンド IP + 5 つの予約済み Azure) をサポートできます。そのため、最小サブネット サイズは /26 をお勧めします。Application Gateway (Standard or WAF) SKU can support up to 32 instances (32 instance IP addresses + 1 private front-end IP + 5 Azure reserved) – so a minimum subnet size of /26 is recommended

Application Gateway (Standard_v2 または WAF_v2) SKU では、最大 125 のインスタンス (125 のインスタンス IP アドレス + 1 つのプライベート フロントエンド IP + 5 つの予約済み Azure) をサポートできます。そのため、最小サブネット サイズは /24 をお勧めします。Application Gateway (Standard_v2 or WAF_v2 SKU) can support up to 125 instances (125 instance IP addresses + 1 private front-end IP + 5 Azure reserved) – so a minimum subnet size of /24 is recommended

ネットワーク セキュリティ グループNetwork security groups

ネットワーク セキュリティ グループ (NSG) は、Application Gateway でサポートされています。Network security groups (NSGs) are supported on Application Gateway. ただし、いくつかの制限が適用されます。But there are some restrictions:

  • Application Gateway v1 SKU の TCP ポート 65503 ~ 65534 と、v2 SKU の TCP ポート 65200 ~ 65535 で、宛先サブネットが [すべて] 、ソースが GatewayManager サービス タグである着信インターネット トラフィックを許可する必要があります。You must allow incoming Internet traffic on TCP ports 65503-65534 for the Application Gateway v1 SKU, and TCP ports 65200-65535 for the v2 SKU with the destination subnet as Any and source as GatewayManager service tag. このポート範囲は、Azure インフラストラクチャの通信に必要です。This port range is required for Azure infrastructure communication. これらのポートは、Azure の証明書によって保護 (ロックダウン) されます。These ports are protected (locked down) by Azure certificates. それらのゲートウェイの顧客を含む外部エンティティは、これらのエンドポイントで通信できません。External entities, including the customers of those gateways, can't communicate on these endpoints.

  • 送信インターネット接続はブロックできません。Outbound Internet connectivity can't be blocked. NSG の既定のアウトバウンド規則ではインターネット接続が許可されています。Default outbound rules in the NSG allow Internet connectivity. 推奨事項は次のとおりです。We recommend that you:

    • 既定のアウトバウンド規則は削除しないでください。Don't remove the default outbound rules.
    • アウトバウンド接続を拒否する他のアウトバウンド規則は作成しないでください。Don't create other outbound rules that deny any outbound connectivity.
  • AzureLoadBalancer タグからで宛先サブネットが [すべて] のトラフィックを許可する必要があります。Traffic from the AzureLoadBalancer tag with the destination subnet as Any must be allowed.

いくつかのソース IP へのアクセスを許可するAllow access to a few source IPs

このシナリオでは、Application Gateway サブネット上の NSG を使用します。For this scenario, use NSGs on the Application Gateway subnet. 次の制約は、この優先順位でサブネットに適用します。Put the following restrictions on the subnet in this order of priority:

  1. ソース IP または IP 範囲からの着信トラフィックで、宛先が Application Gateway のサブネット アドレス範囲全体であり、宛先ポートがご使用の着信アクセス ポート (たとえば、HTTP アクセス用のポート 80) であるものを許可します。Allow incoming traffic from a source IP or IP range with the destination as the entire Application Gateway subnet address range and destination port as your inbound access port, for example, port 80 for HTTP access.
  2. バックエンド正常性状態通信のために、ソースが GatewayManager サービス タグ、宛先が [すべて] 、宛先ポートが Application Gateway v1 SKU の 65503 ~ 65534、および v2 SKU のポート 65200 ~ 65535 である着信要求を許可します。Allow incoming requests from source as GatewayManager service tag and destination as Any and destination ports as 65503-65534 for the Application Gateway v1 SKU, and ports 65200-65535 for v2 SKU for back-end health status communication. このポート範囲は、Azure インフラストラクチャの通信に必要です。This port range is required for Azure infrastructure communication. これらのポートは、Azure の証明書によって保護 (ロックダウン) されます。These ports are protected (locked down) by Azure certificates. 適切な証明書が配置されていない外部エンティティは、そのようなエンドポイントに対する変更を開始できません。Without appropriate certificates in place, external entities can't initiate changes on those endpoints.
  3. ネットワーク セキュリティ グループで Azure Load Balancer プローブ ( AzureLoadBalancer タグ) と仮想ネットワーク通信 ( VirtualNetwork タグ) を受信方向で許可します。Allow incoming Azure Load Balancer probes ( AzureLoadBalancer tag) and inbound virtual network traffic ( VirtualNetwork tag) on the network security group.
  4. 「すべて拒否」の規則を使用して、その他すべての着信トラフィックをブロックします。Block all other incoming traffic by using a deny-all rule.
  5. すべての宛先に対してインターネットへの送信トラフィックを許可します。Allow outbound traffic to the Internet for all destinations.

サポートされているユーザー定義ルートSupported user-defined routes


Application Gateway サブネット上で UDR を使用すると、 バックエンドの正常性ビューに正常性状態が 不明 と表示される場合があります。Using UDRs on the Application Gateway subnet might cause the health status in the back-end health view to appear as Unknown. また、Application Gateway ログとメトリックの生成が失敗する場合があります。It also might cause generation of Application Gateway logs and metrics to fail. バックエンドの正常性、ログ、およびメトリックを表示できるように、Application Gateway サブネット上で UDR を使用しないことをお勧めします。We recommend that you don't use UDRs on the Application Gateway subnet so that you can view the back-end health, logs, and metrics.

  • v1v1

    v1 SKU の場合、ユーザー定義ルート (UDR) は、エンド ツー エンドの要求/応答の通信を変えない限り、Application Gateway サブネットでサポートされます。For the v1 SKU, user-defined routes (UDRs) are supported on the Application Gateway subnet, as long as they don't alter end-to-end request/response communication. たとえば、パケットの検査のためにファイアウォール アプライアンスを指すように Application Gateway サブネットの UDR を設定できます。For example, you can set up a UDR in the Application Gateway subnet to point to a firewall appliance for packet inspection. ただし、検査後にパケットが目的の宛先に到達できることを確認する必要があります。But you must make sure that the packet can reach its intended destination after inspection. これに失敗すると、不適切な正常性プローブやトラフィック ルーティング動作が発生する場合があります。Failure to do so might result in incorrect health-probe or traffic-routing behavior. これには仮想ネットワークの Azure ExpressRoute や VPN ゲートウェイによってプロパゲートされる学習済みのルートまたは既定の ルートが含まれます。This includes learned routes or default routes that are propagated by Azure ExpressRoute or VPN gateways in the virtual network. をオンプレミスにリダイレクトする必要があるシナリオ (強制トンネリング) は、v1 ではサポートされていません。Any scenario in which needs to be redirected on-premises (forced tunneling) isn't supported for v1.

  • v2v2

    v2 SKU の場合、サポートされるシナリオとサポートされないシナリオがあります。For the v2 SKU, there are supported and unsupported scenarios:

    v2 でサポートされるシナリオv2 supported scenarios


    ルート テーブルの構成が正しくないと Application Gateway v2 で非対称ルーティングが発生する可能性があります。An incorrect configuration of the route table could result in asymmetrical routing in Application Gateway v2. すべての管理/コントロール プレーン トラフィックが、仮想アプライアンス経由ではなく、インターネットに直接送信されることを確認します。Ensure that all management/control plane traffic is sent directly to the Internet and not through a virtual appliance. ログ記録とメトリックも影響を受ける可能性があります。Logging and metrics could also be affected.

    シナリオ 1 : Application Gateway サブネットへの Border Gateway Protocol (BGP) ルート伝達を無効にする UDRScenario 1 : UDR to disable Border Gateway Protocol (BGP) Route Propagation to the Application Gateway subnet

    既定のゲートウェイ ルート ( は、Application Gateway 仮想ネットワークに関連付けられている ExpressRoute または VPN ゲートウェイ経由でアドバタイズされる場合があります。Sometimes the default gateway route ( is advertised via the ExpressRoute or VPN gateways associated with the Application Gateway virtual network. これにより、管理プレーン トラフィックが中断され、インターネットへの直接パスが必要になります。This breaks management plane traffic, which requires a direct path to the Internet. このようなシナリオでは、UDR を使用して、BGP ルート伝達を無効にすることができます。In such scenarios, a UDR can be used to disable BGP route propagation.

    BGP ルート伝達を無効にするには、次の手順に従います。To disable BGP route propagation, use the following steps:

    1. Azure でルート テーブル リソースを作成します。Create a Route Table resource in Azure.
    2. 仮想ネットワーク ゲートウェイのルート伝達 パラメーターを無効にします。Disable the Virtual network gateway route propagation parameter.
    3. ルート テーブルを適切なサブネットに関連付けます。Associate the Route Table to the appropriate subnet.

    このシナリオで UDR を有効にすると、既存のセットアップが中断されないはずです。Enabling the UDR for this scenario shouldn't break any existing setups.

    シナリオ 2 : をインターネットに送信する UDRScenario 2 : UDR to direct to the Internet トラフィックをインターネットに直接送信する UDR を作成できます。You can create a UDR to send traffic directly to the Internet.

    シナリオ 3 :Azure Kubernetes Service と kubenet の UDRScenario 3 : UDR for Azure Kubernetes Service with kubenet

    Azure Kubernetes Service (AKS) と Application Gateway Ingress Controller (AGIC) で kubenet を使用している場合は、アプリケーション ゲートウェイからポッドに送信されたトラフィックが正しいノードにルーティングされるように、ルート テーブルが必要になります。If you're using kubenet with Azure Kubernetes Service (AKS) and Application Gateway Ingress Controller (AGIC), you'll need a route table to allow traffic sent to the pods from Application Gateway to be routed to the correct node. これは、Azure CNI を使用する場合は必要ありません。This won't be necessary if you use Azure CNI.

    kubenet が機能するようにルート テーブルを使用するには、次の手順に従います。To use the route table to allow kubenet to work, follow the steps below:

    1. AKS によって作成されたリソース グループに移動します (リソース グループの名前は "MC_" で始まるはずです)Go to the resource group created by AKS (the name of the resource group should begin with "MC_")
    2. そのリソース グループで AKS によって作成されたルート テーブルを探します。Find the route table created by AKS in that resource group. ルート テーブルには次の情報が入ります。The route table should be populated with the following information:
      • アドレス プレフィックスは、AKS でアクセスするポッドの IP 範囲にする必要があります。Address prefix should be the IP range of the pods you want to reach in AKS.
      • 次ホップの種類は [仮想アプライアンス] にする必要があります。Next hop type should be Virtual Appliance.
      • 次ホップ アドレスは、ポッドをホストしているノードの IP アドレスになります。Next hop address should be the IP address of the node hosting the pods.
    3. このルートテーブルを Application Gateway サブネットに関連付けます。Associate this route table to the Application Gateway subnet.

    v2 でサポートされないシナリオv2 unsupported scenarios

    シナリオ 1 : 仮想アプライアンスの UDRScenario 1 : UDR for Virtual Appliances

    v2 では、仮想アプライアンス、ハブ/スポーク仮想ネットワーク、またはオンプレミス (強制トンネリング) を介して をリダイレクトする必要があるシナリオはサポートされません。Any scenario where needs to be redirected through any virtual appliance, a hub/spoke virtual network, or on-premise (forced tunneling) isn't supported for V2.

次の手順Next steps