Network Load Balancer の属性を編集する - Elastic Load Balancing

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

Network Load Balancer の属性を編集する

Network 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「Desync Guardian」を参照してください GitHub。

分類

分類は次のとおりです。

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

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

  • あいまい — リクエストは 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

routing.http.desync_mitigation_mode 属性を monitor、、defensiveまたは に設定して modify-load-balancer-attributes コマンドを使用します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