Application Gateway に関してよく寄せられる質問

Azure Application Gateway は、サービスとしてのアプリケーション配信コントローラーを提供します。 お客様のアプリケーションで、さまざまなレイヤー 7 負荷分散機能を利用できます。 このサービスは、Azure により提供されるフル マネージド サービスであり、高可用性とスケーラビリティを備えています。

Application Gateway は、自動スケーリング、TLS オフロードとエンド ツー エンド TLS、Web アプリケーション ファイアウォール (WAF)、Cookie ベースのセッション アフィニティ、URL パスベースのルーティング、マルチサイト ホスティングなどの機能をサポートしています。 サポートされている機能の完全な一覧については、「Application Gateway の概要」をご覧ください。

Application Gateway はレイヤー 7 のロード バランサーです。つまり、Web トラフィックのみ (HTTP、HTTPS、WebSocket、HTTP/2) に対して機能します。 また、TLS 終端、Cookie ベースのセッション アフィニティ、ラウンド ロビンによるトラフィックの負荷分散などの機能をサポートします。 Load Balancer は、レイヤー 4 (TCP または UDP) でトラフィックを負荷分散するものです。

Application Gateway は、HTTP、HTTPS、HTTP/2、WebSocket をサポートします。

「HTTP/2 のサポート」を参照してください。

サポートされているバックエンド リソースに関するページを参照してください。

Application Gateway v1 (Standard および WAF) は、グローバル Azure のすべてのリージョンで利用できます。 また、21Vianet および Azure Government によって運営される Microsoft Azure でもご利用いただけます。

Application Gateway v2 (Standard_v2 と WAF_v2) の可用性については、Application Gateway v2 でサポートされているリージョンに関するページを参照してください。

Application Gateway は、お客様の仮想ネットワーク専用のデプロイメントです。

リダイレクトはサポートされます。 「Application Gateway のリダイレクトの概要」を参照してください。

「リスナーを処理する順序」を参照してください。

エンドポイントとしてパブリック IP アドレスを使用している場合には、パブリック IP アドレス リソースで IP と DNS の情報を確認できます。 または、Azure portal 内のアプリケーション ゲートウェイの概要ページで見つけることもできます。 内部 IP アドレスを使用している場合は、概要ページで情報を確認できます。 v1 SKU の場合、2023 年 5 月 1 日の後に作成されたゲートウェイには、パブリック IP リソースに自動的に関連付けられた既定の DNS 名がありません。 v2 SKU の場合は、パブリック IP リソースを開き、[構成] を選択します。 DNS 名を構成するには、[DNS 名ラベル (オプション)] フィールドを使用できます。

Keep-Alive タイムアウトでは、アプリケーション ゲートウェイで、クライアントが永続的な接続を再利用するか、または閉じる前にその接続上で別の HTTP 要求を送信するのを待機する時間が制御されます。 "TCP アイドル タイムアウト" では、アクティビティがない場合に TCP 接続が開いた状態でいる時間の長さが制御されます。

Keep-Alive タイムアウトは Application Gateway v1 SKU では 120 秒であり、v2 SKU では 75 秒です。 プライベート IP アドレスの場合、"TCP アイドル タイムアウト" の値を 5 分で構成することはできません。 TCP アイドル タイムアウトは、Application Gateway の v1 および v2 SKU 両方のフロントエンド仮想 IP (VIP) 上で既定値の 4 分となっています。 v1 および v2 Application Gateway インスタンスでの TCP アイドル タイムアウト値は、4 分から 30 分までの任意の値に構成できます。 v1 と v2 のどちらの Application Gateway インスタンスでも、ポータルでアプリケーション ゲートウェイのパブリック IP に移動し、パブリック IP の [構成] ペインで TCP アイドル タイムアウトを変更する必要があります。 次のコマンドを実行して、PowerShell からパブリック IP の TCP アイドル タイムアウト値を設定できます。

$publicIP = Get-AzPublicIpAddress -Name MyPublicIP -ResourceGroupName MyResourceGroup
$publicIP.IdleTimeoutInMinutes = "15"
Set-AzPublicIpAddress -PublicIpAddress $publicIP

Application Gateway v2 SKU のフロントエンド IP アドレスへの HTTP/2 接続の場合、アイドル タイムアウトは 180 秒に設定され、この設定を変更することはできません。

はい。 Application Gateway は、バックエンド サーバーの既存の TCP 接続を再利用します。

いいえ。 Application Gateway リソースの名前を変更する方法はありません。 別の名前で新しいリソースを作成する必要があります。

いいえ。 Application Gateway リソースまたはそのパブリック IP を削除後に復元する方法はありません。 新しいリソースを作成する必要があります。

Application Gateway v1 SKU では、アプリケーション ゲートウェイを停止して開始した場合、VIP が変わることがあります。 これに対して、アプリケーション ゲートウェイに関連付けられている DNS 名は、そのゲートウェイの有効期間全体を通して変わりません。 DNS 名が変わることはないので、CNAME エイリアスを使用し、その参照先をアプリケーション ゲートウェイの DNS アドレスにするようにしてください。 Application Gateway v2 SKU では、IP アドレスが静的であるため、アプリケーション ゲートウェイの有効期間中に IP アドレスや DNS 名が変わることはありません。

はい。 Application Gateway v2 SKU は、静的パブリック IP アドレスと静的内部 IP をサポートしています。 v1 SKU では、静的内部 IP アドレスがサポートされます。

アプリケーション ゲートウェイでは、IP プロトコルあたりパブリック IP アドレスが 1 つだけサポートされます。 アプリケーション ゲートウェイが DualStack として構成されている場合、2 つのパブリック IP をサポートできます。1 つは IPv4 用、もう 1 つは IPv6 用です。

Application Gateway のサブネットのサイズに関する考慮事項のセクションを参照してください。

はい。 特定の Application Gateway のデプロイの複数のインスタンスに加え、別の Application Gateway リソースを含む既存のサブネットに別の一意の Application Gateway リソースをプロビジョニングできます。

1 つのサブネットで v2 と v1 両方の Application Gateway SKU をサポートすることはできません。

はい。ただし、特定のシナリオのみです。 詳細については、「Application Gateway インフラストラクチャの構成」を参照してください。

はい。 「要求への変更」を参照してください。

新しい Application Gateway v1 SKU のデプロイでは、プロビジョニングに最大 20 分かかります。 インスタンスのサイズまたは数を変更しても中断が発生することはありません。ゲートウェイはその間もアクティブな状態が続きます。

v2 SKU を使用するデプロイのほとんどは、プロビジョニングに 6 分ほどかかります。 ただし、デプロイの種類によっては、このプロセスにさらに時間がかかることがあります。 たとえば、多数のインスタンスを含む複数の可用性ゾーン全体にわたるデプロイには 6 分を超える時間がかかることがあります。

Application Gateway に対して開始された更新プログラムは、一度に 1 つの更新ドメインに適用されます。 各更新ドメインのインスタンスが更新されている間、他の更新ドメイン内の残りのインスタンスは引き続きトラフィックを処理します¹。 更新が始まる前に別の更新ドメインのインスタンスへの接続を確立するために、更新中のインスタンスから最大 5 分間、アクティブな接続が適切にドレインされます。 更新中、Application Gateway は一時的に、構成されているインスタンスの数によって決定される削減された最大容量で実行されます。 更新プロセスは、現在の一連のインスタンスが正常にアップグレードされた場合にのみ、次の一連のインスタンスに進みます。

¹ 更新が適用されている間、少なくとも 1 つのインスタンスが確実にトラフィックを処理できるように、Application Gateway v1 SKU デプロイでの最小インスタンス数を 2 に構成することをお勧めします。

Application Gateway では、 Preview のレイヤー 4 プロキシを介した TLS/TCP プロトコル プロキシがサポートされています。

HTTP(S) プロトコルを使用するアプリケーション ゲートウェイのレイヤー 7 プロキシでは、SMTP、IMAP、POP3 などの電子メール プロトコルはサポートされません。 ただし、Outlook Web Access (OWA)、ActiveSync、および HTTP (S) プロトコルを使用する自動検出トラフィックなど、一部のサポート電子メール サービスでは、レイヤー 7 プロキシを使用でき、それらのトラフィックは通過する必要があります。 (注: WAF SKU を使用する場合は、WAF ルールの除外が必要になる場合があります)。

はい。 詳細については、「Azure Application Gateway と Web アプリケーション ファイアウォールを v1 から v2 に移行する」を参照してください。

はい。 Application Gateway v1 SKU は引き続きサポートされます。 v2 に移行して、その SKU の機能更新プログラムを利用することを強くお勧めします。 v1 と v2 の機能の違いの詳細については、自動スケーリングとゾーン冗長 Application Gateway v2 に関するページを参照してください。 v1-v2 移行ドキュメントに従って、Application Gateway v1 SKU デプロイを v2 に手動で移行できます。

不正解です。 Application Gateway v2 は、NTLM または Kerberos 認証を使用したプロキシ要求をサポートしていません。

要求ヘッダー名には、英数字とハイフンを含めることができます。 他の文字を含む要求ヘッダー名は、要求がバックエンド ターゲットに送信されるときに破棄されます。 応答ヘッダー名には、任意の英数字と、RFC 7230 で定義されている特定の記号を含めることができます。

はい。 Chromium ブラウザーv80 の更新では、SameSite 属性のない HTTP Cookie を SameSite=Lax として扱うことが必須になりました。 これは、サードパーティのコンテキストでは、Application Gateway アフィニティ Cookie がブラウザーによって送信されないことを意味します。

このシナリオをサポートするために、Application Gateway では、既存の ApplicationGatewayAffinity Cookie に加えて ApplicationGatewayAffinityCORS という名前の別の Cookie が挿入されます。 これらの Cookie は似ていますが、ApplicationGatewayAffinityCORS Cookie には、SameSite=None と Secure という 2 つの属性が追加されています。 これらの属性は、クロスオリジン要求でも固定セッションを維持します。 詳細については、「Cookie ベースのアフィニティ」のセクションを参照してください。

アクティブ リスナーは、ルールに関連付けられ、"かつ" バックエンド プールにトラフィックを送信するリスナーです。 トラフィックをリダイレクトするだけのリスナーはアクティブ リスナーではありません。 リダイレクト ルールに関連付けられているリスナーはアクティブとは見なされません。 リダイレクト ルールがパス ベースのルールである場合は、そのリダイレクト ルール内のすべてのパスがトラフィックをリダイレクトしているはずです。そうでない場合、そのリスナーはアクティブと見なされます。 個々のコンポーネントの制限の詳細については、「Azure サブスクリプションとサービスの制限、クォータ、制約」を参照してください。

2 つ以上のインスタンスをデプロイすると、Application Gateway v1 SKU が高可用性のシナリオをサポートします。 Azure は、これらのインスタンスを更新ドメインと障害ドメインに分散させ、全インスタンスで同時に障害が発生しないようにします。 v1 SKU では、同じゲートウェイの複数のインスタンスを追加して負荷を共有することによってスケーラビリティをサポートします。

v2 SKU では、新しいインスタンスが障害ドメインと更新ドメインに自動的に分散されるようにします。 ゾーン冗長を選択した場合は、ゾーン障害回復性を提供するために、最新のインスタンスが可用性ゾーンにも分散されます。

Azure Traffic Manager を使用して、異なるデータセンター内の複数のアプリケーション ゲートウェイにトラフィックを分散させます。

はい。 中断を発生させることなくバックエンド プール内のメンバーを変更するように接続のドレインを設定できます。 詳細については、Application Gateway の「接続のドレイン」セクションを参照してください。

はい、Application Gateway v2 SKU では、自動スケールをサポートします。 詳細については、自動スケーリングとゾーン冗長 Application Gateway に関するページを参照してください。

不正解です。 インスタンスはアップグレード ドメインと障害ドメインに分散されます。

はい。

はい。

はい。 Application Gateway は、必ず仮想ネットワーク サブネットにデプロイされます。 このサブネットにはアプリケーション ゲートウェイのみを含めることができます。 詳細については、仮想ネットワークとサブネットの要件に関するページを参照してください。

IP 接続がある場合、Application Gateway は、それが存在している仮想ネットワークの外部にあるインスタンスと通信できます。 Application Gateway は、所属しているサブスクリプションの外部にあるインスタンスとも通信できます。 バックエンド プール メンバーとして内部 IP を使用する予定の場合には、仮想ネットワーク ピアリングまたは Azure VPN Gateway を使用してください。

他のすべての DNS リゾルバーと同様に、Application Gateway リソースは、バックエンド サーバーの DNS レコードの有効期限 (TTL) 値に従います。 TTL の有効期限が切れると、ゲートウェイは検索を実行してその DNS 情報を更新します。 この検索中に、アプリケーション ゲートウェイで応答の取得時に問題が発生した場合 (または DNS レコードが見つからない場合)、ゲートウェイは最後に既知の正常な DNS 値を使用してトラフィックの処理を継続します。 詳細については、「アプリケーション ゲートウェイの動作」を参照してください。

アプリケーション ゲートウェイのインスタンスは、名前解決のために仮想ネットワークの DNS 構成を使用します。 DNS サーバーの構成を変更した後、新しい DNS サーバーを割り当てるために、アプリケーション ゲートウェイを再起動 (停止および開始) する必要があります。 それまでは、送信接続の FQDN ベースの名前解決が失敗する可能性があります。

不正解です。 もっとも、サブネット内に他のアプリケーション ゲートウェイをデプロイすることはできます。

アプリケーション ゲートウェイは、同じ仮想ネットワーク内のサブネット間でのみ移動できます。 これは、v1 ではパブリックおよびプライベート フロントエンド (動的割り当て) でサポートされ、v2 ではパブリック フロントエンドでのみサポートされています。 プライベート フロントエンド IP 構成が静的に割り当てられている場合、アプリケーション ゲートウェイを別のサブネットに移動することはできません。 このアクションを実行するには、アプリケーション ゲートウェイが "停止" 状態である必要があります。 v1 を停止または開始すると、パブリック IP が変更されます。 この操作は、Azure PowerShell と Azure CLI を使用して、次のコマンドを実行することによってのみ行うことができます。

Azure PowerShell

$VNet = Get-AzVirtualNetwork -Name "<VNetName>" -ResourceGroupName "<ResourceGroup>"
$Subnet = Get-AzVirtualNetworkSubnetConfig -Name "<NewSubnetName>" -VirtualNetwork $VNet
$AppGw = Get-AzApplicationGateway -Name "<ApplicationGatewayName>" -ResourceGroupName "<ResourceGroup>"
Stop-AzApplicationGateway -ApplicationGateway $AppGw
$AppGw = Set-AzApplicationGatewayIPConfiguration -ApplicationGateway $AppGw -Name $AppGw.GatewayIPConfigurations.Name -Subnet $Subnet
#If you have a private frontend IP configuration, uncomment and run the next line:
#$AppGw = Set-AzApplicationGatewayFrontendIPConfig -Name $AppGw.FrontendIPConfigurations.Name[1] -Subnet $Subnet -ApplicationGateway $AppGw
Set-AzApplicationGateway -ApplicationGateway $AppGw

詳細については、「Set-AzApplicationGatewayIPConfiguration」を参照してください。

Azure CLI

az network application-gateway stop -g <ResourceGroup> -n <ApplicationGatewayName>
az network application-gateway update -g <ResourceGroup> -n <ApplicationGatewayName> --set gatewayIpConfigurations[0].subnet.id=<subnetID>

アプリケーション ゲートウェイ サブネット内のネットワーク セキュリティ グループに関するセクションを参照してください。

「アプリケーション ゲートウェイ サブネットでサポートされるユーザー定義ルート」を参照してください。

いいえ。 ストレージ アカウントのサービス エンドポイント ポリシーは Application Gateway サブネットでサポートされておらず、それを構成すると Azure インフラストラクチャのトラフィックがブロックされます。

「Application Gateway の制限」を参照してください。

はい。 Application Gateway では、アプリケーション ゲートウェイごとに内部 IP と外部 IP を 1 つずつサポートできます。

はい。 仮想ネットワークのピアリングは、他の仮想ネットワークにおけるトラフィックの負荷分散に役立ちます。

はい。トラフィックが許可されている限り、通信可能です。

マイクロサービス アーキテクチャがサポートされています。 異なる複数のポートを対象にプローブを実行するには、複数のバックエンド設定を構成する必要があります。

不正解です。

「規則を処理する順序」を参照してください。

Application Gateway にマルチサイトを構成している場合は、[ホスト] フィールドによってプローブを送信する先の名前が指定されます。 それ以外の場合は、127.0.0.1 を使用します。 この値は、仮想マシンのホスト名とは異なります。 形式は、<プロトコル>://<ホスト>:<ポート><パス> です。

はい。 特定のソース IP へのアクセスの制限に関するページを参照してください。

はい。パブリック向けリスナーとプライベート向けリスナーを同じポート番号で使用して、パブリック クライアントとプライベート クライアントを同時にサポートできます。 アプリケーション ゲートウェイのサブネットにネットワーク セキュリティ グループ (NSG) が関連付けられている場合は、その構成に応じて特定の受信規則が必要になることがあります。 詳細については、こちらをご覧ください。

Application Gateway v2 は、IPv4 および IPv6 フロントエンドをサポートしています。 現在、IPv6 のサポートは、新しいアプリケーション ゲートウェイでのみ使用できます。 IPv6 をサポートするには、仮想ネットワークがデュアル スタックである必要があります。 Application Gateway v1 は、デュアル スタック仮想ネットワークをサポートしていません。

Application Gateway v1 SKU は、一般には "FIPS モード" と呼ばれる FIPS 140-2 で承認された操作モードで実行できます。FIPS モードでは、FIPS 140-2 で検証済みの暗号化モジュールが呼び出されます。これを有効にすると、暗号化、ハッシュ、署名に対して FIPS 準拠のアルゴリズムが使用されます。 FIPS モードを確実に有効にするには、FIPSmode の構成を有効にするためにサブスクリプションが登録された後に、PowerShell、Azure Resource Manager テンプレート、または REST API を使用して FIPSMode 設定を構成する必要があります。

Application Gateway v2 は現在、プライベート IP フロントエンド構成のみ (パブリック IP はなし) をパブリック プレビューでサポートしています。 詳細については、「プライベート Application Gateway デプロイ (プレビュー)」を参照してください。

一般提供サポートでは、Application Gateway v2 は次の組み合わせをサポートしています。

• プライベート IP とパブリック IP
• パブリック IP のみ

現在の機能でトラフィックをプライベート IP アドレスのみに制限するには、次のプロセスに従います。

1. パブリックとプライベートの両方のフロントエンド IP アドレスを使用してアプリケーション ゲートウェイを作成します。

2. パブリック フロントエンド IP アドレスのリスナーは作成しないでください。 リスナーが作成されていない場合、Application Gateway はパブリック IP アドレスのトラフィックをリッスンしません。

3. Application Gateway サブネットのネットワーク セキュリティ グループを次の優先順位の構成で作成してアタッチします。

   1. [ソース] のサービス タグが GatewayManager、[宛先] が [すべて]、宛先 [ポート] が 65200-65535 のトラフィックを許可します。 このポート範囲は、Azure インフラストラクチャの通信に必要です。 これらのポートは、証明書の認証によって保護 (ロック ダウン) されます。 外部エンティティ (ゲートウェイ ユーザー管理者を含む) は、適切な証明書が用意されていないと、これらのエンドポイントに対する変更を開始できません。

   2. [ソース] のサービス タグが AzureLoadBalancer、宛先 [ポート] が [すべて] のトラフィックを許可します。

   3. [ソース] のサービス タグが Internet、宛先 [ポート] が [すべて] のすべての受信トラフィックを拒否します。 この規則に受信規則の中で "最も低い優先順位" を与えます。

   4. プライベート IP アドレスでのアクセスがブロックされないように、AllowVNetInBound などの既定の規則は維持します。

   5. 送信インターネット接続はブロックできません。 そうしないと、ログ記録やメトリックに関する問題が発生します。

プライベート IP のみのアクセスの NSG 構成の例:

Azure PowerShell または Azure CLI を使用すると、Application Gateway を停止して開始できます。 Application Gateway を開始・停止した時には、 課金も停止・開始されます。 停止されたアプリケーション ゲートウェイに対して実行されるすべての PUT 操作 (タグ、正常性プローブ、リスナーの追加など) によって開始がトリガーされます。 構成が更新された後にアプリケーション ゲートウェイを停止することをお勧めします。

# Stop an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Stop-AzApplicationGateway -ApplicationGateway $appGateway       

# Start an existing Azure Application Gateway instance

$appGateway = Get-AzApplicationGateway -Name $appGatewayName -ResourceGroupName $resourceGroupName
Start-AzApplicationGateway -ApplicationGateway $appGateway           

# Stop an existing Azure Application Gateway instance

az network application-gateway stop -g MyResourceGroup -n MyAppGateway

# Start an existing Azure Application Gateway instance

az network application-gateway start -g MyResourceGroup -n MyAppGateway

Application Gateway は、自己署名証明書、証明機関 (CA) の証明書、Extended Validation (EV) 証明書、複数ドメイン (SAN) 証明書、ワイルドカード証明書をサポートしています。

Application Gateway は、次の暗号スイートをサポートしています。

• TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_DHE_RSA_WITH_AES_256_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_AES_256_GCM_SHA384
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_RSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
• TLS_DHE_DSS_WITH_AES_256_CBC_SHA
• TLS_DHE_DSS_WITH_AES_128_CBC_SHA
• TLS_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

TLS オプションのカスタマイズ方法については、「Application Gateway で SSL ポリシーのバージョンと暗号スイートを構成する」を参照してください。

はい。 Application Gateway は、バックエンドへのトラフィックを再暗号化する TLS オフロードとエンド ツー エンド TLS をサポートしています。

はい。 Application Gateway を構成して、TLS1.0、TLS1.1、TLS1.2 を拒否することができます。 SSL 2.0 および 3.0 は既定で無効になっているため、構成できません。

はい。 Application Gateway では、暗号スイートを構成できます。 カスタム ポリシーを定義するには、次の暗号スイートの少なくとも 1 つを有効にします。

• TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
• TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_128_GCM_SHA256
• TLS_RSA_WITH_AES_256_CBC_SHA256
• TLS_RSA_WITH_AES_128_CBC_SHA256

Application Gateway は、バックエンドの管理に SHA256 を使用します。

Application Gateway は、TLS または SSL 証明書を 100 件までサポートしています。

はい。Application Gateway では、サーバー証明書のための OCSP 拡張機能と OCSP ステープリングを使用した証明書がサポートされています。

Application Gateway は、認証証明書を 100 件までサポートしています。

はい、Application Gateway v2 SKU では、Key Vault をサポートします。 詳細については、「Key Vault 証明書での SSL 終了」を参照してください。

複数ドメインベース (ホストベース) のルーティングでは、マルチサイト リスナーを作成し、プロトコルとして HTTPS を使用するリスナーを設定してから、リスナーとルーティング規則を関連付けます。 詳細については、Application Gateway を使用した複数サイトのホスティングに関するページを参照してください。

いいえ。 .pfx ファイルのパスワードには英数字のみを使用してください。

CA/ブラウザーのメンバーは最近、お客様、Microsoft、大規模なテクノロジ コミュニティで使用されている CA ベンダーによって発行された、公的に信頼されている CA の業界標準に準拠していない複数の証明書を詳細に記載したレポートを公開しました。 準拠していない CA に関するレポートは、こちらで確認できます。

• バグ 1649951
• バグ 1650910

業界のコンプライアンス要件に従って、CA ベンダーは準拠していない CA を失効させ、準拠している CA を発行する作業を開始しました。そのため、お客様は証明書を再発行してもらう必要があります。 Microsoft は、Azure サービスへの潜在的な影響を最小限に抑えるために、これらのベンダーと緊密に提携しています。 ただし、自己発行証明書または Bring Your Own Certificate (BYOC) シナリオで使用される証明書は引き続き、予期せず失効するおそれがあります 。

アプリケーションで利用している証明書が失効したかどうかを確認するには、DigiCert の発表 および Certificate Revocation Tracker を参照してください。 証明書が失効したか、または失効する予定である場合は、アプリケーションで利用している CA ベンダーに新しい証明書を要求する必要があります。 証明書が予期せず失効したためにアプリケーションの可用性が中断されることを回避するか、または失効した証明書を更新するには、準拠していない証明機関の失効が顧客の Azure サービスに影響を与える可能性に関するページを参照してください。

Application Gateway に固有の情報:

いずれかの失効した ICA によって発行された証明書を使用している場合は、アプリケーションの可用性が中断される可能性があります。 アプリケーションによっては、次のようなさまざまなエラー メッセージが表示される可能性があります (ただし、これに限定されるわけではありません)。

• 無効な証明書/失効した証明書
• 接続がタイムアウトしました
• HTTP 502

この問題によるアプリケーションの中断を回避するか、または失効した CA を再発行するには、次のアクションを実行する必要があります。

1. 証明書を再発行する方法については、証明書プロバイダーにお問い合わせください。
2. 再発行されたら、完全な信頼チェーン (リーフ、中間、ルート証明書) を使用して Application Gateway/WAF で証明書を更新します。 証明書を使用している場所に基づいて、アプリケーション ゲートウェイのリスナーまたは HTTP 設定のどちらかで、この手順に従って証明書を更新します。 詳細については、記載されているドキュメント リンクを確認してください。
3. 再発行された証明書を使用するようにバックエンド アプリケーション サーバーを更新します。 使用しているバックエンド サーバーによっては、証明書の更新手順が異なる可能性があります。 ベンダーのドキュメントを確認してください。

リスナーで証明書を更新するには、次の操作を行います。

1. Azure portal で、Application Gateway リソースを開きます。
2. 証明書に関連付けられているリスナー設定を開きます。
3. [選択した証明書の更新または編集] を選択します。
4. 新しい PFX 証明書をパスワードと共にアップロードし、[保存] を選択します。
5. Web サイトにアクセスし、サイトが予想どおりに機能しているかどうか確認します。 詳細については、「Application Gateway の証明書を更新する」を参照してください。

Application Gateway リスナーで Key Vault からの証明書を参照している場合は、すばやい変更のために次の手順をお勧めします。

1. Azure portal で、アプリケーション ゲートウェイに関連付けられている Key Vault の設定に移動します。
2. 再発行された証明書をストアに追加またはインポートします。 詳細については、Azure portal を使用したキー コンテナーの作成に関するクイックスタートを参照してください。
3. 証明書がインポートされたら、Application Gateway のリスナー設定に移動し、[キー コンテナーから証明書を選択する] で [証明書] ドロップダウンを選択し、最近追加された証明書を選択します。
4. [保存] を選択します。 Key Vault 証明書を使用した Application Gateway での TLS 終端の詳細については、「Key Vault 証明書を使用した TLS 終端」を参照してください。

HTTP 設定で証明書を更新するには:

Application Gateway/WAF サービスの v1 SKU を使用している場合は、新しい証明書をバックエンド認証証明書としてアップロード必要があります。

1. Azure portal で、Application Gateway リソースを開きます。
2. 証明書に関連付けられている HTTP 設定を開きます。
3. [証明書の追加] を選択し、再発行された証明書をアップロードして [保存] を選択します。
4. 古い証明書は、後で古い証明書の横にある [...] オプション ボタンを選択して削除できます。 [削除] を選択してから [保存] を選択します。 詳細については、「ポータルで Application Gateway を使用してエンド ツー エンド TLS を構成する」を参照してください。

Application Gateway/WAF サービスの V2 SKU を使用している場合、HTTP 設定で新しい証明書をアップロードする必要はありません。これは、V2 SKU では "信頼されたルート証明書" が使用され、ここでアクションを実行する必要がないためです。

はい。 アプリケーション ゲートウェイを介したレイヤー 7 ルーティングとレイヤー 4 のルーティングは、いずれも同じフロントエンド IP 構成を使います。 これにより、すべてのクライアントを 1 つの IP アドレス (パブリックまたはプライベート) に誘導できます。また、構成したリスナー プロトコルとポートに基づいて、同じゲートウェイ リソースがルーティングを行います。

HTTP(S) トラフィックは L4 プロキシ プロトコルを介して提供することもできますが、そのようにすることはお勧めしません。 Application Gateway の L7 プロキシ ソリューションは、書き換え、セッション アフィニティ、リダイレクト、WebSocket、WAF などの高度な機能を使って、HTTP(S) プロトコルの制御とセキュリティを強化します。

レイヤー 4 機能のリソース プロパティは、レイヤー 7 機能のリソース プロパティとは異なります。 そのため、REST API または CLI を使う場合は、次のプロパティを使う必要があります。

• REST API
• CLI

いいえ。 レイヤー 4 とレイヤー 7 のプロパティをクロスリンクすることはできません。 そのため、ルーティング規則では、レイヤー 4 タイプのリスナーをレイヤー 4 タイプのバックエンド設定にリンクすることしかできません。

L7 (httpListeners) と L4 (listener) に同じ名前を使うことはできません。 これは、backendSettingsCollection や routingRules などの他の L4 プロパティにも適用されます。

そして、 レイヤー 7 プロキシと同様に、アプリケーション ゲートウェイのバックエンド プールにプライベート エンドポイントを追加できます。 このプライベート エンドポイントは、アプリケーション ゲートウェイの同じ仮想ネットワークの隣接するサブネットにデプロイする必要があります。

バックエンド接続にキープアライブは使われません。 フロントエンド リスナー接続で受信した要求ごとに、Application Gateway は新しいバックエンド接続を開始して、その要求を実行します。

バックエンド サーバーは、アプリケーション ゲートウェイの IP アドレスを認識しています。 現在、バックエンド アプリケーションが元のクライアントの IP アドレスを認識できるようにする "クライアント IP の保存" はサポートされていません。

同じ SSL ポリシー構成を、レイヤー 7 (HTTPS) とレイヤー 4 (TLS) の両方に適用できます。 現在、TLS リスナーの SSL プロファイル (リスナー固有の SSL ポリシーまたは相互認証) はサポートされていません。

いいえ。 現時点では、クライアントを同じバックエンド サーバーにルーティングすることはサポートされていません。 接続は、ラウンドロビン方式でバックエンド プール内のサーバーに分散されます。

はい。自動スケーリング機能は、TLS または TCP プロトコルのトラフィックの急増や減少にも対応できます。

Web Application Firewall (WAF) 機能は、レイヤー 4 の使用に対して機能しません。

いいえ。 現在、UDP はサポートされていません。

Kubernetes では、deployment および service リソースを作成して、ポッドのグループをクラスター内で内部的に公開できます。 同じサービスを外部に公開するには、負荷分散、TLS 終端、名前ベースの仮想ホスティングを提供する Ingress リソースが定義されます。 この Ingress リソースを満たすには、Ingress リソースへのすべての変更をリッスンし、ロード バランサー ポリシーを構成するイングレス コントローラーが必要です。

Application Gateway イングレス コントローラー (AGIC) を使用すると、Azure Kubernetes Service (AKS クラスターとも呼ばれます) 用のイングレスとして Application Gateway を使用できます。

現在は、イングレス コントローラーの 1 つのインスタンスを 1 つのアプリケーション ゲートウェイに関連付けることしかできません。

AGIC はルート テーブル リソースを Application Gateway サブネットに自動的に関連付けようとしますが、AGIC にアクセス許可がないため、それに失敗する可能性があります。 AGIC がルート テーブルを Application Gateway サブネットに関連付けることができない場合は、AGIC ログにエラーが表示されます。 この場合は、AKS クラスターによって作成されたルート テーブルを Application Gateway のサブネットに手動で関連付ける必要があります。 詳細については、「サポートされているユーザー定義のルート」を参照してください。

はい。ただし、仮想ネットワークがピアリングされていて、アドレス空間が重複していないことが条件です。 AKS を kubenet と共に実行している場合は、AKS によって生成されたルート テーブルを Application Gateway サブネットに確実に関連付けてください。

Helm 経由でデプロイされた AGIC と、AKS アドオンとしてデプロイされた AGIC の違いについては、「Helm デプロイと AKS アドオンの違い」を参照してください。

Helm 経由でデプロイされた AGIC と、AKS アドオンとしてデプロイされた AGIC の違いについては、「Helm デプロイと AKS アドオンの違い」(特に、AKS アドオンとは異なり、Helm 経由でデプロイされた AGIC でどのシナリオがサポートされるかについて説明している表) を参照してください。 一般に、Helm 経由でデプロイすると、正式リリースよりも前にベータ機能とリリース候補をテストできます。

いいえ。 AGIC アドオンはマネージド サービスです。つまり、Microsoft は、このアドオンを最新の安定バージョンに自動的に更新します。

相互認証とは、クライアントとサーバー間で行われる双方向の認証です。 現在、Application Gateway での相互認証では、要求を送信しているクライアントをゲートウェイによって検証できます。これはクライアント認証です。 通常、アプリケーション ゲートウェイを認証するのはクライアントだけです。 Application Gateway でもクライアントを認証できるようになったため、Application Gateway とクライアントで相互の認証が行われている場合は、相互認証になります。

いいえ。相互認証は現在、フロントエンド クライアントとアプリケーション ゲートウェイの間でのみ行われます。 バックエンドの相互認証は現在、サポートされていません。

Application Gateway では、次の 3 つのログを利用できます。

• ApplicationGatewayAccessLog - アクセス ログには、アプリケーション ゲートウェイ フロントエンドに送信された各要求が格納されます。 データには、呼び出し元の IP、要求された URL、応答の待ち時間、リターン コード、入出力バイトが含まれます。アプリケーション ゲートウェイ 1 つごとに 1 つのレコードが含まれます。
• ApplicationGatewayPerformanceLog: このパフォーマンス ログには、各アプリケーション ゲートウェイのパフォーマンスが記録されます。 情報には、バイト単位のスループット、処理された要求の総数、失敗した要求の数、正常および異常なバックエンド インスタンスの数などが含まれます。
• ApplicationGatewayFirewallLog: このファイアウォール ログには、WAF を構成してあるアプリケーション ゲートウェイについて、検出モードまたは防止モードを通じてログが作成された要求が記録されます。

すべてのログが 60 秒ごとに収集されます。 詳細については、Application Gateway のバックエンドの正常性、診断ログ、メトリックに関するページを参照してください。

PowerShell コマンドレット Get-AzApplicationGatewayBackendHealth とポータルのいずれかを使用することによって、正常性を確認できます。 詳細については、Application Gateway の診断に関するトピックを参照してください。

お客様のストレージ アカウントには、診断ログが送られます。 お客様は、自身の好みに応じてアイテム保持ポリシーを設定できます。 診断ログは、イベント ハブまたは Azure Monitor ログにも送信できます。 詳細については、Application Gateway の診断に関するトピックを参照してください。

ポータルで、アプリケーション ゲートウェイのメニュー ウィンドウにある [アクティビティ ログ] を選択して、監査ログにアクセスします。

はい。 Application Gateway では、メトリックに基づいてアラートを構成します。 詳細については、Application Gateway のメトリックに関するセクションと、アラート通知の受信に関するページを参照してください。

アクセス ログを確認および分析する方法はいくつかあります。 Azure Monitor ログ、Excel、Power BI などを使用します。

このほか、Application Gateway のアクセス ログに対応した人気のログ アナライザー GoAccess をインストールして実行する Resource Manager テンプレートも利用できます。 GoAccess では、ユニーク ビジター、要求されたファイル、ホスト、オペレーティング システム、ブラウザー、HTTP 状態コードなど、有益な HTTP トラフィック統計情報を確認できます。 詳細については、GitHub の Resource Manager テンプレート フォルダーにある Readme ファイルを参照してください。

通常、不明な状態は、Application Gateway サブネット上で NSG、カスタム DNS、またはユーザー定義ルーティングによってバックエンドへのアクセスがブロックされている場合に表示されます。 詳細については、Application Gateway のバックエンドの正常性、診断ログ、メトリックに関するページを参照してください。

現在のプラットフォームの制限のため、Application Gateway v2 (Standard_v2、WAF_v2) サブネット上に NSG が設定され、そこで NSG フロー ログが有効になっている場合は、不確定な動作が発生します。 このシナリオは現在サポートされていません。

Application Gateway は、それがデプロイされているリージョンから顧客データを移動したり、格納したりしません。

次のステップ

• Application Gateway の詳細については、「Azure Application Gateway とは」を参照してください。
• Application Gateway での TLS 終端とエンド ツー エンド TLS については、Azure Application Gateway でのエンド ツー エンド TLS の有効化に関するページを参照してください。