アプリケーション ゲートウェイ構成の概要Application Gateway configuration overview

Azure Application Gateway は、さまざまなシナリオに合わせて多様な方法で構成できるいくつかのコンポーネントで構成されています。Azure Application Gateway consists of several components that you can configure in various ways for different scenarios. この記事では、各コンポーネントの構成方法について説明します。This article shows you how to configure each component.

Application Gateway コンポーネントのフロー チャート

この画像は、3 つのリスナーがあるアプリケーションを示しています。This image illustrates an application that has three listeners. 最初の 2 つのリスナーは、それぞれ http://acme.com/*http://fabrikam.com/* のマルチサイト リスナーです。The first two are multi-site listeners for http://acme.com/* and http://fabrikam.com/*, respectively. いずれもポート 80 でリッスンします。Both listen on port 80. 3 つ目は、エンド ツー エンド Secure Sockets Layer (SSL) 終端を持つ基本リスナーです。The third is a basic listener that has end-to-end Secure Sockets Layer (SSL) termination.

注意

この記事は、新しい 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.

前提条件Prerequisites

Azure 仮想ネットワークと専用サブネットAzure 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.

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

Application Gateway は、インスタンスごとに 1 つのプライベート IP アドレスを使用します。さらに、プライベート フロントエンド IP を構成している場合は、もう 1 つのプライベート IP アドレスを使用します。Application Gateway consumes 1 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 5 IP addresses in each subnet for internal use: the first 4 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: 5 for internal use and 15 for the application gateway instances. そのため、/27 サブネット サイズ以上が必要です。So, you need a /27 subnet size or larger.

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, 1 for the private front end, and 5 for internal use. そのため、/26 サブネット サイズ以上が必要です。So, you need a /26 subnet size or larger.

/28 以上のサブネット サイズを使用することをお勧めします。We recommend that you use a subnet size of at least /28. このサイズでは、11 個の使用可能な IP アドレスが得られます。This size gives you 11 usable IP addresses. アプリケーションの負荷によって 10 個を超える Application Gateway インスタンスが必要な場合は、サブネット サイズ /27 または /26 を検討します。If your application load requires more than 10 Application Gateway instances, consider a /27 or /26 subnet size.

アプリケーション ゲートウェイ サブネット上のネットワーク セキュリティ グループNetwork security groups on the Application Gateway subnet

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

  • Application Gateway V1 SKU では、TCP ポート 65503-65534 での着信インターネット トラフィックと、宛先サブネットが [すべて] に設定されている V2 SKU の TCP ポート 65200-65535 を許可する必要があります。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. このポート範囲は、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 initiate changes on those endpoints without appropriate certificates in place.

  • 送信インターネット接続はブロックできません。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 outbound internet connectivity.
  • AzureLoadBalancer タグからのトラフィックを許可する必要があります。Traffic from the AzureLoadBalancer tag must be allowed.

Application Gateway アクセスを少数のソース IP に限定するAllow Application Gateway 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 サブネット全体、または構成された特定のプライベート フロントエンド IP への着信トラフィックを許可します。Allow incoming traffic from a source IP or IP range and the destination as either the entire Application Gateway subnet, or to the specific configured private front-end IP. NSG はパブリック IP では機能しません。The NSG doesn't work on a public IP.
  2. Application Gateway v1 SKU の場合はポート 65503 から 65534 への、バックエンドの正常性通信用の v2 SKU の場合はポート 65200 から 65535 への、すべてのソースからの着信要求を許可します。Allow incoming requests from all sources to ports 65503-65534 for the Application Gateway v1 SKU, and ports 65200-65535 for v2 SKU for back-end health 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.

アプリケーション ゲートウェイ サブネットでサポートされるユーザー定義ルートUser-defined routes supported on the Application Gateway subnet

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 ゲートウェイによってプロパゲートされる学習済みのルートまたは既定の 0.0.0.0/0 ルートが含まれます。This includes learned routes or default 0.0.0.0/0 routes that are propagated by Azure ExpressRoute or VPN gateways in the virtual network.

v2 SKU の場合、Application Gateway サブネット上の UDR はサポートされません。For the v2 SKU, UDRs are not supported on the Application Gateway subnet. 詳細については、Azure Application Gateway v2 SKU をご覧ください。For more information, see Azure Application Gateway v2 SKU.

注意

UDR は v2 SKU ではサポートされていません。UDRs are not supported for the v2 SKU. UDR が必要な場合、続行して v1 SKU をデプロイしてください。If you require UDRs you should continue to deploy v1 SKU.

注意

Application Gateway サブネット上で UDR を使用すると、バックエンドの正常性ビューに正常性状態が "不明" と表示されます。Using UDRs on the Application Gateway subnet causes the health status in the back-end health view to appear as "Unknown." また、Application Gateway ログとメトリックの生成が失敗します。It also causes 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.

フロントエンド IPFront-end IP

アプリケーション ゲートウェイは、パブリック IP アドレス、プライベート IP アドレス、またはその両方を持つように構成できます。You can configure the application gateway to have a public IP address, a private IP address, or both. パブリック IP が必要となるのは、インターネットに接続している仮想 IP (VIP) を介してインターネット上でクライアントがアクセスする必要があるバックエンドをホストするときです。A public IP is required when you host a back end that clients must access over the internet via an internet-facing virtual IP (VIP).

パブリック IP は、インターネットに公開されない内部エンドポイントには必要ありません。A public IP isn't required for an internal endpoint that's not exposed to the internet. これは、"内部ロード バランサー" (ILB) エンドポイントまたはプライベート フロントエンド IP と呼ばれます。That's known as an internal load-balancer (ILB) endpoint or private frontend IP. アプリケーション ゲートウェイ ILB は、インターネットに接続されていない内部の基幹業務アプリケーションで便利です。An application gateway ILB is useful for internal line-of-business applications that aren't exposed to the internet. また、インターネットに接続されていないセキュリティの境界にある多階層アプリケーション内のサービスや階層に役立ちますが、ラウンド ロビンの負荷分散、セッションの持続性、または SSL ターミネーションが必要です。It's also useful for services and tiers in a multi-tier application within a security boundary that aren't exposed to the internet but that require round-robin load distribution, session stickiness, or SSL termination.

1 つのパブリック IP アドレスまたは 1 つのプライベート IP アドレスしかサポートされません。Only 1 public IP address or 1 private IP address is supported. アプリケーション ゲートウェイを作成するときにフロントエンド IP を選択します。You choose the front-end IP when you create the application gateway.

  • パブリック IP の場合は、新しいパブリック IP アドレスの作成またはアプリケーション ゲートウェイと同じ場所にある既存のパブリック IP を使用できます。For a public IP, you can create a new public IP address or use an existing public IP in the same location as the application gateway. 詳細については、静的なパブリック IP アドレスと動的なパブリック IP アドレスに関するページを参照してください。For more information, see static vs. dynamic public IP address.

  • プライベート IP の場合は、アプリケーション ゲートウェイが作成されるサブネットのプライベート IP アドレスを指定できます。For a private IP, you can specify a private IP address from the subnet where the application gateway is created. 指定しないと、サブネットから任意の IP アドレスが自動的に選択されます。If you don't specify one, an arbitrary IP address is automatically selected from the subnet. 選択した IP アドレスの種類 (静的または動的) は後で変更できません。The IP address type that you select (static or dynamic) can't be changed later. 詳細については、内部ロード バランサーを使用したアプリケーション ゲートウェイの作成に関するページを参照してください。For more information, see Create an application gateway with an internal load balancer.

フロントエンド IP アドレスが関連付けられた "リスナー" が、フロントエンド IP での着信要求をチェックします。A front-end IP address is associated to a listener, which checks for incoming requests on the front-end IP.

リスナーListeners

リスナーは、ポート、プロトコル、ホストおよび IP アドレスを使用して着信接続要求をチェックする論理エンティティです。A listener is a logical entity that checks for incoming connection requests by using the port, protocol, host, and IP address. リスナーを構成するときは、ゲートウェイの着信要求の対応する値と同じ値をここに入力する必要があります。When you configure the listener, you must enter values for these that match the corresponding values in the incoming request on the gateway.

Azure portal を使用してアプリケーション ゲートウェイを作成するときにも、リスナーのプロトコルとポートを選択して既定のリスナーを作成します。When you create an application gateway by using the Azure portal, you also create a default listener by choosing the protocol and port for the listener. リスナー上で HTTP2 のサポートを有効にするかどうかを選択できます。You can choose whether to enable HTTP2 support on the listener. アプリケーション ゲートウェイを作成した後、この既定リスナー (appGatewayHttpListener) の設定を編集することや、新しいリスナーを作成することができます。After you create the application gateway, you can edit the settings of that default listener (appGatewayHttpListener) or create new listeners.

リスナーの種類Listener type

新しいリスナーを作成するときは、"基本" または "マルチサイト" を選択します。When you create a new listener, you choose between basic and multi-site.

  • (すべてのドメインに対する) すべての要求を受け入れ、バックエンド プールに転送する場合は、基本を選択します。If you want all of your requests (for any domain) to be accepted and forwarded to backend pools, choose basic. 基本リスナーのアプリケーション ゲートウェイを作成する方法に関するページを参照してください。Learn how to create an application gateway with a basic listener.

  • ホスト ヘッダーまたはホスト名に基づいて異なるバックエンド プールに要求を転送する場合は、マルチサイト リスナーを選択します。ここで、受信要求と一致するホスト名も指定する必要があります。If you want to forward requests to different backend pools based on the host header or hostname, choose multi-site listener, where you must also specify a hostname that matches with the incoming request. これは、アプリケーション ゲートウェイが複数の Web サイトを同じパブリック IP アドレスとポートでホストするために、HTTP 1.1 ホスト ヘッダーを利用しているためです。This is because Application Gateway relies on HTTP 1.1 host headers to host more than one website on the same public IP address and port.

リスナーを処理する順序Order of processing listeners

v1 SKU の場合、要求は、規則の順序とリスナーの種類に従って照合されます。For the v1 SKU, requests are matched according to the order of the rules and the type of listener. 基本リスナーの規則が順序の先頭にある場合、その規則が最初に処理され、そのポートと IP の組み合わせに対応するすべての要求が受け入れられます。If a rule with basic listener comes first in the order, it is processed first and will accept any request for that port and IP combination. これを回避するには、最初にマルチサイト リスナーの規則を構成し、基本リスナーの規則を一覧の最後にプッシュします。To avoid this, configure the rules with multi-site listeners first and push the rule with the basic listener to the last in the list.

v2 SKU の場合、マルチサイト リスナーは基本リスナーの前に処理されます。For the v2 SKU, multi-site listeners are processed before basic listeners.

フロントエンド IPFront-end IP

このリスナーに関連付ける予定のフロントエンド IP アドレスを選択します。Choose the front-end IP address that you plan to associate with this listener. リスナーは、この IP 上の着信要求をリッスンします。The listener will listen to incoming requests on this IP.

フロントエンド ポートFront-end port

フロントエンド ポートを選択します。Choose the front-end port. 既存のポートを選択するか、新規作成します。Select an existing port or create a new one. 許可されているポート範囲から任意の値を選択します。Choose any value from the allowed range of ports. 80 や 443 などの一般的なポートだけではなく、許可されている適切なカスタム ポートを使用できます。You can use not only well-known ports, such as 80 and 443, but any allowed custom port that's suitable. 1 つのポートは、パブリック向けリスナーまたはプライベート向けリスナーのいずれかに使用できます。A port can be used for public-facing listeners or private-facing listeners.

ProtocolProtocol

HTTP または HTTPS を選択します。Choose HTTP or HTTPS:

  • HTTP を選択すると、クライアントとアプリケーション ゲートウェイ間のトラフィックは暗号化されません。If you choose HTTP, the traffic between the client and the application gateway is unencrypted.

  • SSL 終端またはエンド ツー エンド SSL 暗号化が必要な場合は、HTTPS を選択します。Choose HTTPS if you want SSL termination or end-to-end SSL encryption. クライアントとアプリケーション ゲートウェイ間のトラフィックは暗号化されます。The traffic between the client and the application gateway is encrypted. また、SSL 接続はアプリケーション ゲートウェイで終端します。And the SSL connection terminates at the application gateway. エンド ツー エンドの SSL 暗号化が必要な場合は、HTTPS を選択してバックエンド HTTP 設定を構成する必要があります。If you want end-to-end SSL encryption, you must choose HTTPS and configure the back-end HTTP setting. これにより、トラフィックがアプリケーション ゲートウェイからバックエンドに送られるときに再暗号化されます。This ensures that traffic is re-encrypted when it travels from the application gateway to the back end.

SSL 終端とエンド ツー エンド SSL 暗号化を構成するには、リスナーに証明書を追加して、アプリケーション ゲートウェイが対称キーを派生できるようにする必要があります。To configure SSL termination and end-to-end SSL encryption, you must add a certificate to the listener to enable the application gateway to derive a symmetric key. これは SSL プロトコル仕様によって規定されています。This is dictated by the SSL protocol specification. 対称キーは、ゲートウェイに送信されたトラフィックの暗号化と暗号化の解除に使用されます。The symmetric key is used to encrypt and decrypt the traffic that's sent to the gateway. ゲートウェイ証明書は、Personal Information Exchange (PFX) 形式である必要があります。The gateway certificate must be in Personal Information Exchange (PFX) format. この形式を使用すると、ゲートウェイがトラフィックの暗号化と復号化に使用する秘密キーをエクスポートできます。This format lets you export the private key that the gateway uses to encrypt and decrypt traffic.

サポートされている証明書Supported certificates

SSL 終了でサポートされる証明書に関するページをご覧ください。See certificates supported for SSL termination.

その他のプロトコルのサポートAdditional protocol support

HTTP2 のサポートHTTP2 support

HTTP/2 プロトコルのサポートを利用できるのは、アプリケーション ゲートウェイ リスナーに接続するクライアントだけです。HTTP/2 protocol support is available to clients that connect to application gateway listeners only. バックエンド サーバー プールへの通信は、HTTP/1.1 で行われます。The communication to back-end server pools is over HTTP/1.1. 既定では、HTTP/2 のサポートは無効になっています。By default, HTTP/2 support is disabled. 次の Azure PowerShell コード スニペットは、これを有効にする方法を示しています。The following Azure PowerShell code snippet shows how to enable this:

$gw = Get-AzApplicationGateway -Name test -ResourceGroupName hm

$gw.EnableHttp2 = $true

Set-AzApplicationGateway -ApplicationGateway $gw

WebSocket のサポートWebSocket support

WebSocket のサポートは既定で有効です。WebSocket support is enabled by default. ユーザーが有効または無効に構成できる設定はありません。There's no user-configurable setting to enable or disable it. WebSocket は HTTP リスナーと HTTPS リスナーの両方で使用できます。You can use WebSockets with both HTTP and HTTPS listeners.

カスタム エラー ページCustom error pages

カスタム エラーは、グローバル レベルまたはリスナー レベルで定義できます。You can define custom error at the global level or the listener level. ただし、Azure portal からのグローバル レベル カスタム エラー ページの作成は、現在サポートされていません。But creating global-level custom error pages from the Azure portal is currently not supported. リスナー レベルで 403 Web アプリケーション ファイアウォール エラー用のカスタム エラー ページまたは 502 メンテナンス ページを構成できます。You can configure a custom error page for a 403 web application firewall error or a 502 maintenance page at the listener level. また、特定のエラー状態コード用の公的にアクセス可能な BLOB URL も指定する必要があります。You must also specify a publicly accessible blob URL for the given error status code. 詳細については、「Create Application Gateway custom error pages (Application Gateway のカスタム エラー ページを作成する)」を参照してください。For more information, see Create Application Gateway custom error pages.

Application Gateway のエラー コード

グローバル カスタム エラー ページを構成する方法については、Azure PowerShell の構成に関するページを参照してください。To configure a global custom error page, see Azure PowerShell configuration.

SSL ポリシーSSL policy

SSL 証明書の管理を一元化し、バックエンド サーバー ファームの暗号化と復号化のオーバーヘッドを減らすことができます。You can centralize SSL certificate management and reduce encryption-decryption overhead for a back-end server farm. 一元化された SSL の処理によって、お客様のセキュリティ要件に適したサーバーで中心的な役割を担う SSL ポリシーを指定することもできます。Centralized SSL handling also lets you specify a central SSL policy that's suited to your security requirements. "既定"、"定義済み"、または "カスタム" の SSL ポリシーを選択できます。You can choose default, predefined, or custom SSL policy.

SSL プロトコルのバージョンを管理する SSL ポリシーを構成します。You configure SSL policy to control SSL protocol versions. TLS1.0、TLS1.1、および TLS1.2 の TLS ハンドシェイクに最小プロトコル バージョンを使用するようにアプリケーション ゲートウェイを構成できます。You can configure an application gateway to use a minumum protocol version for TLS handshakes from TLS1.0, TLS1.1, and TLS1.2. SSL 2.0 および 3.0 は既定で無効なため、構成できません。By default, SSL 2.0 and 3.0 are disabled and aren't configurable. 詳細については、「Application Gateway の SSL ポリシーの概要」を参照してください。For more information, see Application Gateway SSL policy overview.

リスナーを作成したら、要求ルーティング規則に関連付ける必要があります。After you create a listener, you associate it with a request-routing rule. その規則で、リスナー上で受信された要求がバック エンドにルーティングされる方法が決まります。That rule determines how requests that are received on the listener are routed to the back end.

要求ルーティング規則Request routing rules

Azure portal を使用してアプリケーション ゲートウェイを作成するときに、既定の規則 (rule1) を作成します。When you create an application gateway by using the Azure portal, you create a default rule (rule1). この規則によって、既定のリスナー (appGatewayHttpListener) が既定のバックエンド プール (appGatewayBackendPool) と既定のバックエンド HTTP 設定 (appGatewayBackendHttpSettings) にバインドされます。This rule binds the default listener (appGatewayHttpListener) with the default back-end pool (appGatewayBackendPool) and the default back-end HTTP settings (appGatewayBackendHttpSettings). ゲートウェイを作成した後で、既定の規則の設定の編集や新しい規則の作成を行うことができます。After you create the gateway, you can edit the settings of the default rule or create new rules.

規則の種類Rule type

新しい規則を作成するときは、"基本" または "パス ベース" を選択します。When you create a rule, you choose between basic and path-based.

  • 関連付けられたリスナー (例: blog.contoso.com/*) に対するすべての要求を 1 つのバックエンド プールに転送する場合は、基本を選択します。Choose basic if you want to forward all requests on the associated listener (for example, blog.contoso.com/*) to a single back-end pool.
  • 特定の URL パスからの要求を特定のバックエンド プールにルーティングする場合は、パス ベースを選択します。Choose path-based if you want to route requests from specific URL paths to specific back-end pools. パスのパターンは URL のパスのみに適用され、クエリ パラメーターには適用されません。The path pattern is applied only to the path of the URL, not to its query parameters.

規則を処理する順序Order of processing rules

v1 SKU の場合、着信要求のパターン マッチングは、パスベースの規則の URL パス マップにパスが指定された順序で行われます。For the v1 SKU, pattern matching of incoming requests is processed in the order that the paths are listed in the URL path map of the path-based rule. 要求がパス マップ内の複数のパスのパターンと一致する場合、一覧の順序が最初のパスが一致します。If a request matches the pattern in two or more paths in the path map, the path that's listed first is matched. また、要求はそのパスに関連付けられたバック エンドに転送されます。And the request is forwarded to the back end that's associated with that path.

v2 SKU の場合、完全一致が URL パス マップ内のパスの順序よりも優先されます。For the v2 SKU, an exact match is higher priority than path order in the URL path map. 要求が複数のパスのパターンと一致する場合、その要求は、その要求と完全に一致するパスに関連付けられているバック エンドに転送されます。If a request matches the pattern in two or more paths, the request is forwarded to the back end that's associated with the path that exactly matches the request. 着信要求内のパスがマップ内のどのパスとも正確に一致しない場合、要求のパターン マッチングはパスベースの規則のパス マップ順序の一覧で処理されます。If the path in the incoming request doesn't exactly match any path in the map, pattern matching of the request is processed in the path map order list for the path-based rule.

関連付けられたリスナーAssociated listener

リスナーに関連付けられた "要求のルーティング規則" が評価されて、要求のルーティング先のバックエンド プールを決定できるように、リスナーを規則に関連付けます。Associate a listener to the rule so that the request-routing rule that's associated with the listener is evaluated to determine the back-end pool to route the request to.

関連付けられたバックエンド プールAssociated back-end pool

リスナーが受信する要求を処理するバックエンド ターゲットを含むバックエンド プールを規則に関連付けます。Associate to the rule the back-end pool that contains the back-end targets that serve requests that the listener receives.

  • 基本規則の場合、1 つのバックエンド プールのみが許可されます。For a basic rule, only one back-end pool is allowed. 関連付けられているリスナー上のすべての要求は、そのバックエンド プールに転送されます。All requests on the associated listener are forwarded to that back-end pool.

  • パスベースの規則の場合は、各 URL パスに対応する複数のバックエンド プールを追加します。For a path-based rule, add multiple back-end pools that correspond to each URL path. 入力した URL パスと一致する要求が、対応するバックエンド プールに転送されます。The requests that match the URL path that's entered are forwarded to the corresponding back-end pool. また、既定のバックエンド プールを追加します。Also, add a default back-end pool. 規則内のどの URL パスとも一致しない要求は、そのプールに転送されます。Requests that don't match any URL path in the rule are forwarded to that pool.

関連付けられたバックエンド HTTP 設定Associated back-end HTTP setting

各規則のバックエンド HTTP 設定を追加します。Add a back-end HTTP setting for each rule. 要求は、この設定に指定されるポート番号、プロトコル、および他の情報を使用して、アプリケーション ゲートウェイからバックエンド ターゲットにルーティングされます。Requests are routed from the application gateway to the back-end targets by using the port number, protocol, and other information that's specified in this setting.

基本規則の場合、1 つのバックエンド HTTP 設定のみが許可されます。For a basic rule, only one back-end HTTP setting is allowed. 関連付けられているリスナー上のすべての要求は、この HTTP 設定を使用して、対応するバックエンド ターゲットに転送されます。All requests on the associated listener are forwarded to the corresponding back-end targets by using this HTTP setting.

パスベースの規則の場合は、各 URL パスに対応する複数のバックエンド HTTP 設定を追加します。For a path-based rule, add multiple back-end HTTP settings that correspond to each URL path. この設定の URL パスと一致する要求は、各 URL パスに対応する HTTP 設定を使用して、対応するバックエンド ターゲットに転送されます。Requests that match the URL path in this setting are forwarded to the corresponding back-end targets by using the HTTP settings that correspond to each URL path. また、既定の HTTP 設定を追加します。Also, add a default HTTP setting. この規則のどの URL パスとも一致しない要求は、既定の HTTP 設定を使用して既定のバックエンド プールに転送されます。Requests that don't match any URL path in this rule are forwarded to the default back-end pool by using the default HTTP setting.

リダイレクト設定Redirection setting

基本規則でリダイレクトが構成されている場合、関連付けられているリスナーのすべての要求はターゲットにリダイレクトされます。If redirection is configured for a basic rule, all requests on the associated listener are redirected to the target. これは "グローバル" なリダイレクトです。This is global redirection. パスベースの規則に対してリダイレクトが構成されている場合は、特定のサイト領域内の要求のみがリダイレクトされます。If redirection is configured for a path-based rule, only requests in a specific site area are redirected. たとえば、 /cart/* で示されるショッピング カート領域です。An example is a shopping cart area that's denoted by /cart/*. これがパスベースのリダイレクトです。This is path-based redirection.

リダイレクトの詳細については、「Application Gateway のリダイレクトの概要」を参照してください。For more information about redirects, see Application Gateway redirect overview.

リダイレクトの種類Redirection type

必要なリダイレクトの種類を選択します。Permanent(301)Temporary(307)Found(302) 、または See other(303) があります。Choose the type of redirection required: Permanent(301), Temporary(307), Found(302), or See other(303).

リダイレクト ターゲットRedirection target

リダイレクトのターゲットとして別のリスナーまたは外部サイトを選択します。Choose another listener or an external site as the redirection target.

リスナーListener

ゲートウェイ上のあるリスナーから別のリスナーにトラフィックをリダイレクトするには、リダイレクト ターゲットとしてリスナーを選択します。Choose listener as the redirection target to redirect traffic from one listener to another on the gateway. この設定は、HTTP から HTTPS へのリダイレクトを有効にする場合に必要です。This setting is required when you want to enable HTTP-to-HTTPS redirection. 着信 HTTP 要求を確認するソース リスナーから、着信 HTTPS 要求を確認する宛先リスナーにトラフィックがリダイレクトされます。It redirects traffic from the source listener that checks for incoming HTTP requests to the destination listener that checks for incoming HTTPS requests. 元の要求のクエリ文字列とパスを、リダイレクト ターゲットに転送される要求に含めることもできます。You can also choose to include the query string and path from the original request in the request that's forwarded to the redirection target.

Application Gateway コンポーネントのダイアログ ボックス

HTTP から HTTPS へのリダイレクトの詳細については、以下を参照してください。For more information about HTTP-to-HTTPS redirection, see:

外部サイトExternal site

この規則に関連付けられたリスナーに対するトラフィックを外部サイトにリダイレクトするときに、外部サイトを選択します。Choose external site when you want to redirect the traffic on the listener that's associated with this rule to an external site. 元の要求のクエリ文字列を、リダイレクト ターゲットに転送される要求に含めることができます。You can choose to include the query string from the original request in the request that's forwarded to the redirection target. 元の要求内のパスを外部サイトに転送することはできません。You can't forward the path to the external site that was in the original request.

リダイレクトの詳細については、以下を参照してください。For more information about redirection, see:

HTTP ヘッダー設定を書き換えるRewrite the HTTP header setting

この設定で、要求パケットと応答パケットがクライアントとバックエンド プール間を移動する間に、HTTP 要求および応答ヘッダーが追加、削除、または更新されます。This setting adds, removes, or updates HTTP request and response headers while the request and response packets move between the client and back-end pools. 詳細については、次を参照してください。For more information, see:

HTTP 設定HTTP settings

アプリケーション ゲートウェイは、ここで指定した構成を使用してトラフィックをバックエンド サーバーにルーティングします。The application gateway routes traffic to the back-end servers by using the configuration that you specify here. HTTP 設定を作成したら、それを 1 つ以上の要求ルーティング規則に関連付ける必要があります。After you create an HTTP setting, you must associate it with one or more request-routing rules.

この機能は、同じサーバー上にユーザー セッションを保持する場合に便利です。This feature is useful when you want to keep a user session on the same server. ゲートウェイで管理される Cookie を使用すると、アプリケーション ゲートウェイは、ユーザー セッションの後続のトラフィックを処理のために同じサーバーに送信します。Gateway-managed cookies let the application gateway direct subsequent traffic from a user session to the same server for processing. この機能は、ユーザー セッションのためにセッションの状態をサーバー上でローカルに保存する場合に重要です。This is important when session state is saved locally on the server for a user session. アプリケーションが Cookie ベースのアフィニティを処理できない場合は、この機能を使用できません。If the application can't handle cookie-based affinity, you can't use this feature. 使用するには、クライアントが Cookie をサポートしている必要があります。To use it, make sure that the clients support cookies.

接続のドレインConnection draining

接続のドレインを使用すると、計画的なサービスの更新中にバックエンド プール メンバーを正常に削除することができます。Connection draining helps you gracefully remove back-end pool members during planned service updates. この設定は、規則の作成中にバックエンド プールのすべてのメンバーに適用することができます。You can apply this setting to all members of a back-end pool during rule creation. これで、バックエンド プールの登録を解除するすべてのインスタンスが新しい要求を受け取らなくなります。It ensures that all de-registering instances of a back-end pool don't receive any new requests. その間、構成された制限時間内に既存の要求を完了できます。Meanwhile, existing requests are allowed to complete within a configured time limit. 接続のドレインは、バックエンド プールから明示的に削除されるバックエンド インスタンスに適用されます。Connection draining applies to back-end instances that are explicitly removed from the back-end pool.

ProtocolProtocol

Application Gateway では、要求のバックエンド サーバーへのルーティングに対して HTTP と HTTPS の両方がサポートされます。Application Gateway supports both HTTP and HTTPS for routing requests to the back-end servers. HTTP を選択した場合、バックエンド サーバーへのトラフィックは暗号化されません。If you choose HTTP, traffic to the back-end servers is unencrypted. 暗号化されていない通信を許容できない場合は、HTTPS を選択してください。If unencrypted communication isn't acceptable, choose HTTPS.

リスナーで HTTPS と組み合わせたこの設定は、エンド ツー エンド SSL をサポートします。This setting combined with HTTPS in the listener supports end-to-end SSL. これによって、機密データを暗号化して安全にバックエンドに送信することができます。This allows you to securely transmit sensitive data encrypted to the back end. エンド ツー エンド SSL が有効になったバックエンド プール内の各バックエンド サーバーは、セキュリティで保護された通信を許可するように証明書で構成する必要があります。Each back-end server in the back-end pool that has end-to-end SSL enabled must be configured with a certificate to allow secure communication.

PortPort

この設定では、バックエンド サーバーがアプリケーション ゲートウェイからのトラフィックをリッスンするポートを指定します。This setting specifies the port where the back-end servers listen to traffic from the application gateway. 1 から 65535 までの範囲のポートを構成できます。You can configure ports ranging from 1 to 65535.

要求タイムアウトRequest timeout

この設定は、アプリケーション ゲートウェイがバックエンド サーバーからの応答の受信を待機する秒数です。This setting is the number of seconds that the application gateway waits to receive a response from the back-end server.

バックエンド パスのオーバーライドOverride back-end path

この設定を使用すると、要求がバックエンドに転送されるときに使用できる、オプションのカスタム転送パスを構成できます。This setting lets you configure an optional custom forwarding path to use when the request is forwarded to the back end. [バックエンド パスのオーバーライド] フィールドに指定したカスタム パスと一致する受信パスの部分が、転送先パスにコピーされます。Any part of the incoming path that matches the custom path in the override backend path field is copied to the forwarded path. 次の表は、この機能のしくみを示しています。The following table shows how this feature works:

  • HTTP 設定が基本の要求ルーティング規則に関連付けられている場合:When the HTTP setting is attached to a basic request-routing rule:

    元の要求Original request バックエンド パスのオーバーライドOverride back-end path バックエンドに転送される要求Request forwarded to back end
    /home//home/ /override//override/ /override/home//override/home/
    /home/secondhome//home/secondhome/ /override//override/ /override/home/secondhome//override/home/secondhome/
  • HTTP 設定がパスベースの要求ルーティング規則に関連付けられている場合:When the HTTP setting is attached to a path-based request-routing rule:

    元の要求Original request パスの規則Path rule バックエンド パスのオーバーライドOverride back-end path バックエンドに転送される要求Request forwarded to back end
    /pathrule/home//pathrule/home/ /pathrule*/pathrule* /override//override/ /override/home//override/home/
    /pathrule/home/secondhome//pathrule/home/secondhome/ /pathrule*/pathrule* /override//override/ /override/home/secondhome//override/home/secondhome/
    /home//home/ /pathrule*/pathrule* /override//override/ /override/home//override/home/
    /home/secondhome//home/secondhome/ /pathrule*/pathrule* /override//override/ /override/home/secondhome//override/home/secondhome/
    /pathrule/home//pathrule/home/ /pathrule/home*/pathrule/home* /override//override/ /override//override/
    /pathrule/home/secondhome//pathrule/home/secondhome/ /pathrule/home*/pathrule/home* /override//override/ /override/secondhome//override/secondhome/
    /pathrule//pathrule/ /pathrule//pathrule/ /override//override/ /override//override/

[App Service 用に使用します]Use for app service

これは、Azure App Service バックエンドに必要な 2 つの設定を選択する UI 専用ショートカットです。This is a UI only shortcut that selects the two required settings for the Azure App Service back end. これにより、バックエンド アドレスからホスト名を選択できます。また、新しいカスタム プローブがまだない場合は作成されます。It enables pick host name from back-end address, and it creates a new custom probe if you don't have one already. (詳細については、この記事の [バックエンド アドレスからホスト名を選択します] 設定のセクションを参照してください)。新しいプローブが作成されます。プローブのヘッダーはバックエンド メンバーのアドレスから選択されます。(For more information, see the Pick host name from back-end address setting section of this article.) A new probe is created, and the probe header is picked from the back-end member’s address.

[カスタム プローブの使用]Use custom probe

この設定で、カスタム プローブが HTTP 設定と関連付けられます。This setting associates a custom probe with an HTTP setting. カスタム プローブを 1 つだけ HTTP 設定と関連付けることができます。You can associate only one custom probe with an HTTP setting. カスタム プローブを明示的に関連付けないと、バックエンドの正常性を監視するために既定のプローブが使用されます。If you don't explicitly associate a custom probe, the default probe is used to monitor the health of the back end. バック エンドの正常性監視をきめ細かく制御するには、カスタム プローブを作成することをお勧めします。We recommend that you create a custom probe for greater control over the health monitoring of your back ends.

注意

対応する HTTP 設定が明示的にリスナーに関連付けられていない限り、カスタム プローブはバックエンド プールの正常性を監視しません。The custom probe doesn't monitor the health of the back-end pool unless the corresponding HTTP setting is explicitly associated with a listener.

バックエンド アドレスからホスト名を選択するPick host name from back-end address

この機能によって、要求の host ヘッダーが、バックエンド プールのホスト名に動的に設定されます。This capability dynamically sets the host header in the request to the host name of the back-end pool. これには IP アドレスまたは FQDN が使用されます。It uses an IP address or FQDN.

この機能が役立つのは、バックエンドのドメイン名がアプリケーション ゲートウェイの DNS 名と異なっており、バックエンドが特定のホスト ヘッダーを利用して正しいエンドポイントに解決される場合です。This feature helps when the domain name of the back end is different from the DNS name of the application gateway, and the back end relies on a specific host header to resolve to the correct endpoint.

たとえば、バックエンドとしてのマルチテナント サービスのケースなどです。An example case is multi-tenant services as the back end. アプリ サービスは、単一の IP アドレスを持つ共有領域を使用するマルチテナント サービスです。An app service is a multi-tenant service that uses a shared space with a single IP address. そのため、アプリ サービスにアクセスするには、カスタム ドメイン設定で構成されているホスト名を使用する必要があります。So, an app service can only be accessed through the hostnames that are configured in the custom domain settings.

既定ではカスタム ドメイン名は example.azurewebsites.net です。By default, the custom domain name is example.azurewebsites.net. アプリケーション ゲートウェイを使用して、App Service に明示的に登録されていないホスト名またはアプリケーション ゲートウェイの FQDN によって App Service にアクセスするには、元の要求のホスト名をオーバーライドして、アプリ サービスのホスト名にする必要があります。To access your app service by using an application gateway through a hostname that's not explicitly registered in the app service or through the application gateway’s FQDN, you override the hostname in the original request to the app service’s hostname. これを行うために、 [バックエンド アドレスからホスト名を選択します] 設定を有効にします。To do this, enable the pick host name from backend address setting.

既存のカスタム DNS 名がアプリ サービスにマップされているカスタム ドメインの場合、この設定を有効にする必要はありません。For a custom domain whose existing custom DNS name is mapped to the app service, you don't have to enable this setting.

注意

この設定は、専用のデプロイである App Service Environment には必要ありません。This setting is not required for App Service Environment, which is a dedicated deployment.

[ホスト名の上書き]Host name override

この機能によって、アプリケーション ゲートウェイの着信要求の host ヘッダーが、指定するホスト名に置き換えられます。This capability replaces the host header in the incoming request on the application gateway with the host name that you specify.

たとえば、www.contoso.com[ホスト名] 設定に指定されている場合、元の要求 * https://appgw.eastus.cloudapp.azure.com/path1 は、バックエンド サーバーに転送されるときに、* https://www.contoso.com/path1 に変更されます。For example, if www.contoso.com is specified in the Host name setting, the original request *https://appgw.eastus.cloudapp.azure.com/path1 is changed to *https://www.contoso.com/path1 when the request is forwarded to the back-end server.

バックエンド プールBack-end pool

バックエンド プールには、4 種類のバックエンド メンバー (特定の仮想マシン、仮想マシン スケール セット、IP アドレス/FQDN、または App Service) を指定できます。You can point a back-end pool to four types of backend members: a specific virtual machine, a virtual machine scale set, an IP address/FQDN, or an app service. 各バックエンド プールには、同じ種類の複数のメンバーを指定できます。Each back-end pool can point to multiple members of the same type. 同じバックエンド プール内で異なる種類のメンバーの指定はサポートされていません。Pointing to members of different types in the same back-end pool isn't supported.

バックエンド プールを作成した後で、それを 1 つ以上の要求ルーティング規則に関連付ける必要があります。After you create a back-end pool, you must associate it with one or more request-routing rules. アプリケーション ゲートウェイ上の各バックエンド プールに対して正常性プローブを構成する必要もあります。You must also configure health probes for each back-end pool on your application gateway. 要求のルーティング規則の条件が満たされると、アプリケーション ゲートウェイは、トラフィックを対応するバックエンド プール内の正常なサーバー (正常性プローブによって判別) に転送します。When a request-routing rule condition is met, the application gateway forwards the traffic to the healthy servers (as determined by the health probes) in the corresponding back-end pool.

正常性プローブHealth probes

アプリケーション ゲートウェイは、既定でバック エンドのすべてのリソースの正常性を監視します。An application gateway monitors the health of all resources in its back end by default. ただし、正常性の監視をきめ細かく制御するには、バックエンドの HTTP 設定ごとにカスタム プローブを作成することを強くお勧めします。But we strongly recommend that you create a custom probe for each back-end HTTP setting to get greater control over health monitoring. カスタム プローブを構成する方法については、「カスタムの正常性プローブの設定」を参照してください。To learn how to configure a custom probe, see Custom health probe settings.

注意

カスタムの正常性プローブを作成したら、バックエンド HTTP 設定に関連付ける必要があります。After you create a custom health probe, you need to associate it to a back-end HTTP setting. 対応する HTTP 設定が、規則を使用してリスナーに明示的に関連付けられていない限り、カスタム プローブはバックエンド プールの正常性を監視しません。A custom probe won't monitor the health of the back-end pool unless the corresponding HTTP setting is explicitly associated with a listener using a rule.

次の手順Next steps

Application Gateway コンポーネントについて学習したので、次は以下を行うことができます。Now that you know about Application Gateway components, you can: