Application Load Balancer の属性を編集する - Elastic Load Balancing
接続のアイドルタイムアウトHTTP クライアントキープアライブ期間削除保護Desync 軽減モードホストヘッダーの保持

翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。

Application Load Balancer の属性を編集する

Application Load Balancer を作成するとその属性を編集できます。

接続のアイドルタイムアウト

接続アイドルタイムアウトとは、ロードバランサーが接続を終了する前の、既存のクライアントまたはターゲット接続が非アクティブのままでデータの送受信が行われない時間のことです。

ファイルのアップロードなどの時間がかかるオペレーションでは、完了までの時間を確保するため、各アイドルタイムアウト期間が経過するまでに少なとも 1 バイトのデータを送信し、必要に応じてアイドルタイムアウトの長さを増やします。また、アプリケーションのアイドルタイムアウトは、ロードバランサーに設定されたアイドルタイムアウトよりも大きな値に設定することをお勧めします。そうしないと、アプリケーションがロードバランサーTCPへの接続を不適切に閉じた場合、ロードバランサーは接続が閉じられたことを示すパケットを受信する前にアプリケーションにリクエストを送信する可能性があります。この場合、ロードバランサーは HTTP 502 Bad Gateway エラーをクライアントに送信します。

Elastic Load Balancing では、ロードバランサーのアイドルタイムアウト値はデフォルトで 60 秒 (1 分) に設定されています。別のアイドルタイムアウト値を設定するには、以下の手順を使用します。

コンソールを使用して接続アイドルタイムアウト値を更新するには

  1. で Amazon EC2コンソールを開きますhttps://console.aws.amazon.com/ec2/。

  2. ナビゲーションペインで、[ロードバランサー] を選択します。

  3. ロードバランサーを選択します。

  4. [属性] タブで、[編集] を選択します。

  5. [トラフィック設定] に [接続アイドルタイムアウト] の値を入力します。有効な範囲は 1～4000 秒です。

  6. [Save changes] (変更の保存) をクリックします。

を使用してアイドルタイムアウト値を更新するには AWS CLI

idle_timeout.timeout_seconds 属性を指定して modify-load-balancer-attributes コマンドを使用します。

HTTP クライアントキープアライブ期間

HTTP クライアントキープアライブ期間は、Application Load Balancer がクライアントへの永続的なHTTP接続を維持する最大時間です。設定されたHTTPクライアントキープアライブ期間が経過すると、Application Load Balancer はもう 1 つのリクエストを受け入れ、接続を適切に閉じるレスポンスを返します。

ロードバランサーによって送信されるレスポンスのタイプは、クライアント接続で使用されるHTTPバージョンによって異なります。

  • HTTP 1.x を使用して接続されたクライアントの場合、ロードバランサーはフィールド を含む HTTPヘッダーを送信しますConnection: close。

  • HTTP/2 を使用して接続されたクライアントの場合、ロードバランサーはGOAWAYフレームを送信します。

デフォルトでは、Application Load Balancer はロードバランサーのHTTPクライアントキープアライブ期間値を 3600 秒、つまり 1 時間に設定します。HTTP クライアントキープアライブ期間をオフにしたり、最小 60 秒未満に設定したりすることはできませんが、HTTPクライアントキープアライブ期間を最大 604,800 秒、つまり 7 日間まで延長できます。Application Load Balancer は、HTTPクライアントHTTPへの接続が最初に確立されたときに、クライアントキープアライブ期間を開始します。この期間は、トラフィックがない間は継続し、新しい接続が確立されるまでリセットされません。

ゾーンシフトまたはゾーンオートシフトを使用して、ロードバランサーのトラフィックを障害の発生しているアベイラビリティーゾーンから回避させると、既存のオープン接続を使用しているクライアントは、クライアントが再度接続するまで、障害の発生している場所へのリクエストを継続する可能性があります。高速リカバリをサポートするには、キープアライブ期間の値を低く設定して、クライアントがロードバランサーへの接続を継続する時間を制限するようにします。詳細については、「Amazon Application Recovery Controller (ARC) デベロッパーガイド」の「クライアントがエンドポイントに接続したままになる時間を制限する」を参照してください。

注記

ロードバランサーが Application Load Balancer の IP アドレスタイプを dualstack-without-public-ipv4 に切り替えると、ロードバランサーはすべてのアクティブな接続が完了するまで待機します。Application Load Balancer の IP アドレスタイプの切り替えにかかる時間を短縮するには、HTTPクライアントのキープアライブ期間を短くすることを検討してください。

Application Load Balancer は、最初の接続中にHTTPクライアントキープアライブ期間値を割り当てます。HTTP クライアントキープアライブ期間を更新すると、HTTPクライアントキープアライブ期間の値が異なる同時接続が発生する可能性があります。既存の接続は、最初の接続中に適用されるHTTPクライアントキープアライブ期間値を保持します。新しい接続は、更新されたHTTPクライアントキープアライブ期間値を受け取ります。

コンソールを使用してキープアライブ期間の値を更新するには

  1. で Amazon EC2コンソールを開きますhttps://console.aws.amazon.com/ec2/。

  2. ナビゲーションペインで、[ロードバランサー] を選択します。

  3. ロードバランサーを選択します。

  4. [属性] タブで、[編集] を選択します。

  5. トラフィック設定で、HTTPクライアントキープアライブ期間の値を入力します。有効な範囲は 60～604800 秒です。

  6. [Save changes] (変更の保存) をクリックします。

を使用してクライアントキープアライブ期間の値を更新するには AWS CLI

client_keep_alive.seconds 属性を指定して modify-load-balancer-attributes コマンドを使用します。

削除保護

ロードバランサーが誤って削除されるのを防ぐため、削除保護を有効にできます。デフォルトでは、ロードバランサーで削除保護が無効になっています。

ロードバランサーの削除保護を有効にした場合、ロードバランサーを削除する前に無効にする必要があります。

コンソールを使用して削除保護を有効にするには

  1. で Amazon EC2コンソールを開きますhttps://console.aws.amazon.com/ec2/。

  2. ナビゲーションペインで、[ロードバランサー] を選択します。

  3. ロードバランサーを選択します。

  4. [属性] タブで、[編集] を選択します。

  5. [構成] で、[削除保護] をオンにします。

  6. [Save changes] (変更の保存) をクリックします。

コンソールを使用して削除保護を無効にするには

  1. で Amazon EC2コンソールを開きますhttps://console.aws.amazon.com/ec2/。

  2. ナビゲーションペインで、[ロードバランサー] を選択します。

  3. ロードバランサーを選択します。

  4. [属性] タブで、[編集] を選択します。

  5. [構成] ページで、[削除保護] をオンにします。

  6. [Save changes] (変更の保存) をクリックします。

を使用して削除保護を有効または無効にするには AWS CLI

deletion_protection.enabled 属性を指定して modify-load-balancer-attributes コマンドを使用します。

Desync 軽減モード

非同期緩和モードは、HTTP非同期による問題からアプリケーションを保護します。ロードバランサーは、脅威レベルに基づいて各リクエストを分類します。安全なリクエストは許可し、指定した軽減モードで指定されたリスクに対しては軽減処理を行います。Desync 軽減モードの種類は、モニタリングモード、防御モード、厳密モードです。デフォルトは防御モードです。これは、アプリケーションの可用性を維持しながらHTTP、非同期に対する永続的な緩和を提供します。最も厳密なモードに切り替えて、アプリケーションが RFC7230 に準拠するリクエストのみを受信するようにできます。

http_desync_guardian ライブラリはHTTP、リクエストを分析してHTTP非同期攻撃を防ぎます。詳細については、HTTP「 の同期解除」を参照してください GitHub。

分類

分類は次のとおりです。

  • 準拠 — リクエストは RFC 7230 に準拠しており、既知のセキュリティ脅威はありません。

  • 許容可能 — リクエストは RFC 7230 に準拠していませんが、既知のセキュリティ脅威は発生しません。

  • あいまい — リクエストは 7230 RFC に準拠していませんが、さまざまなウェブサーバーやプロキシで異なる処理が行われる可能性があるため、リスクがあります。

  • Severe — リクエストは高いセキュリティリスクをもたらしています。ロードバランサーはリクエストをブロックし、クライアントに 400 レスポンスを提供し、クライアント接続を閉じます。

リクエストが 7230 RFC に準拠していない場合、ロードバランサーは DesyncMitigationMode_NonCompliant_Request_Countメトリクスを増分します。詳細については、「Application Load Balancer のメトリック」を参照してください。

各リクエストの分類は、ロードバランサーのアクセスログに含まれます。リクエストが準拠しない場合、アクセスログには分類理由コードが含まれます。詳細については、「分類の理由」を参照してください。

モード

次の表は、Application Load Balancer で、リクエストがモードと分類に基づきどのように処理されるかを示しています。

分類 モニタリングモード 防御モード 厳密モード
準拠 許可 許可 許可
Acceptable 許可 許可 ブロック
Ambiguous 許可 許可¹ ブロック
Severe 許可 ブロック ブロック

¹ リクエストはルーティングされますが、クライアントとターゲットの接続は閉じられます。ロードバランサーが防御モードで多数のあいまいなリクエストを受信すると、追加料金が発生する可能性があります。これは、1 秒あたりの新しい接続数の増加が、1 時間あたりに使用されるLoad Balancerキャパシティーユニット (LCU) に影響するためです。NewConnectionCount メトリクスを使用すると、モニタリングモードと防御モードで、ロードバランサーによってどのように新しい接続が確立されているかを比較できます。

コンソールを使用して Desync 軽減モードを更新するには

  1. で Amazon EC2コンソールを開きますhttps://console.aws.amazon.com/ec2/。

  2. ナビゲーションペインで、[ロードバランサー] を選択します。

  3. ロードバランサーを選択します。

  4. [属性] タブで、[編集] を選択します。

  5. [パケット処理] の [非同期緩和モード] で、[防御]、[厳密]、または [モニタリング] を選択します。

  6. [Save changes] (変更の保存) をクリックします。

を使用して非同期緩和モードを更新するには AWS CLI

modify-load-balancer-attributes routing.http.desync_mitigation_mode 属性を monitor、、または に設定して defensiveコマンドを使用しますstrictest。

ホストヘッダーの保持

Preserve host header 属性を有効にすると、Application Load Balancer はHTTPリクエスト内の Hostヘッダーを保持し、変更せずにターゲットに ヘッダーを送信します。Application Load Balancer が複数の Host ヘッダーを受信した場合、すべてが保持されます。リスナールールは最初に受信した Host ヘッダーにのみ適用されます。

デフォルトで、Preserve host header (ホストヘッダーの保持) 属性が有効になっていない場合、Application Load Balancer は Host ヘッダーを次のように変更します。

ホストヘッダーの保持が有効になっておらず、リスナーポートがデフォルト以外のポートである場合: デフォルトポート (ポート 80 または 443) を使用しない場合、クライアントによってポート番号が追加されなければ、ホストヘッダーにポート番号を追加します。たとえば、リスナーポートが などのデフォルト以外のポートである場合Host: www.example.com:8080、 を使用したHTTPリクエストの Hostヘッダーは に変更Host: www.example.comされます8080。

ホストヘッダーの保持が有効になっておらず、リスナーポートがデフォルトポート (ポート 80 または 443) の場合: デフォルトのリスナーポート (ポート 80 または 443) の場合、送信されるホストヘッダーにポート番号を追加しません。受信したホストヘッダーに含まれていたポート番号はすべて削除されます。

次の表は、Application Load Balancer がリスナーポートに基づいてHTTPリクエスト内のホストヘッダーを処理する方法の例を示しています。

リスナーポート リクエストの例 リクエストのホストヘッダー ホストヘッダーの保持が無効です (デフォルト動作) ホストヘッダーの保持が有効です
リクエストはデフォルト HTTP/HTTPS リスナーで送信されます。 GET /index.html HTTP/1.1 Host: example.com example.com example.com example.com
リクエストはデフォルトのHTTPリスナーで送信され、ホストヘッダーにはポート (80 や 443 など) があります。 GET /index.html HTTP/1.1 Host: example.com:80 example.com:80 example.com example.com:80
リクエストには絶対パスが含まれます。 GET https://dns_name/index.html HTTP/1.1 Host: example.com example.com dns_name example.com
リクエストはデフォルト以外のリスナーポート (8080 など) で送信されます。 GET /index.html HTTP/1.1 Host: example.com example.com example.com:8080 example.com
リクエストはデフォルト以外のリスナーポートで送信され、ホストヘッダーにはポート (例えば、8080) が含まれます。 GET /index.html HTTP/1.1 Host: example.com:8080 example.com:8080 example.com:8080 example.com:8080
コンソールを使用してホストヘッダーの保持を有効にするには

  1. で Amazon EC2コンソールを開きますhttps://console.aws.amazon.com/ec2/。

  2. ナビゲーションペインで、[ロードバランサー] を選択します。

  3. ロードバランサーを選択します。

  4. [属性] タブで、[編集] を選択します。

  5. [パケット処理] で [ホストヘッダーを保存] をオンにします。

  6. [Save changes] (変更の保存) をクリックします。

を使用してホストヘッダーの保存を有効にするには AWS CLI

routing.http.preserve_host_header.enabled 属性を に設定して modify-load-balancer-attributes コマンドを使用しますtrue。