Application Load Balancer - Elastic Load Balancing
ロードバランサーのサブネットロードバランサーのセキュリティグループロードバランサーの状態ロードバランサーの属性IP アドレスタイプロードバランサーリソースマップロードバランサー接続クロスゾーンロードバランサー削除保護Desync 軽減モードホストヘッダーの保持AWS WAF

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

Application Load Balancer

ロードバランサーは、クライアントにとって単一の通信先として機能します。クライアントはロードバランサーにリクエストを送信し、ロードバランサーはターゲット (EC2 インスタンスなど) にそれらのリクエストを送信します。ロードバランサーを設定するには、ターゲットグループを作成し、ターゲットグループにターゲットを登録します。さらに、リスナーを作成してクライアントからの接続リクエストがないかチェックし、リスナールールを作成してリクエストをクライアントから 1 つ以上のターゲットグループ内のターゲットにルーティングします。

詳細については、Elastic Load Balancing ユーザーガイドの How Elastic Load Balancing works を参照してください。

目次

ロードバランサーのサブネット

Application Load Balancer を作成するときは、ターゲットを含むゾーンを有効にする必要があります。ゾーンを有効にするには、ゾーン内のサブネットを指定します。Elastic Load Balancing は、指定した各ゾーンにロードバランサーノードを作成します。

考慮事項

  • 有効な各ゾーンに 1 つ以上の登録済みターゲットが含まれるようにすると、ロードバランサーは最も効果的に機能します。

  • ターゲットをアベイラビリティーゾーンに登録したが、ゾーンを有効にしていない場合、登録したターゲットはロードバランサーからのトラフィックを受信しません。

  • ロードバランサーで複数のゾーンを有効にする場合、ゾーンは同じタイプでなければなりません。例えば、アベイラビリティーゾーンとローカルゾーンの両方を有効にすることはできません。

  • 自分と共有しているサブネットを指定できます。

Application Load Balancer では、次の タイプのサブネットがサポートされます。

アベイラビリティーゾーンサブネット

少なくとも 2 つのアベイラビリティーゾーンサブネットを選択する必要があります。以下の制限が適用されます。

  • それぞれのサブネットは、異なるアベイラビリティーゾーンに属している必要があります。

  • ロードバランサーが正しくスケールできるように、ロードバランサーのアベイラビリティーゾーンサブネットごとに CIDR ブロックを最低でも /27 ビットマスク (例: 10.0.0.0/27) にし、少なくとも各サブネットにつき 8 個の空き IP アドレスを用意してください。これらの 8 個の IP アドレスは、ロードバランサーが必要に応じてスケールアウトできるようにするために必要です。ロードバランサーはこれらの IP アドレスを使用して、ターゲットとの接続を確立します。それらがないと、Application Load Balancer ではノード交換の試行で問題が発生し、失敗状態になる可能性があります。

    注: スケールの試行中に Application Load Balancer サブネットが使用可能な IP アドレスを使い果たした場合、Application Load Balancer は不十分なキャパシティで実行されます。この間、古いノードは引き続きトラフィックを処理しますが、スケーリングの試行が停止すると、接続の確立を試行する際に 5xx エラーまたはタイムアウトが発生する可能性があります。

ローカルゾーンサブネット

1 つ以上のローカルゾーンサブネットを指定できます。以下の制限が適用されます。

  • ロードバランサー AWS WAF で を使用することはできません。

  • Lambda 関数をターゲットとして使用することはできません。

  • スティッキーセッションやアプリケーションの維持を使用することはできません。

Outpost サブネット

1 つの Outpost サブネットを指定できます。以下の制限が適用されます。

  • オンプレミスのデータセンターに Outpost をインストールして設定しておく必要があります。Outpost と AWS リージョンの間に信頼できるネットワーク接続が必要です。詳細については、AWS Outposts ユーザーガイドを参照してください。

  • ロードバランサーでは、ロードバランサーノードの Outpost に 2 つの large インスタンスが必要です。サポートされているインスタンスタイプを以下の表に示します。ロードバランサーは必要に応じてスケールし、一度に 1 サイズずつノードのサイズ変更を行います (large から xlarge に変更、xlarge から 2xlarge に変更、あるいは 2xlarge から4xlarge に変更)。ノードを最大のインスタンスサイズにスケールした後、追加の容量が必要な場合は、4xlarge インスタンスをロードバランサーノードとして追加します。ロードバランサーをスケールするのに十分なインスタンス容量または使用可能な IP アドレスがない場合、ロードバランサーは AWS Health Dashboard にイベントを報告し、ロードバランサーの状態は active_impaired になります。

  • インスタンス ID または IP アドレスでターゲットを登録できます。Outpost の AWS リージョンにターゲットを登録する場合、ターゲットは使用されません。

  • ターゲットとしての Lambda 機能、 AWS WAF 統合、スティッキーセッション、認証サポート、および AWS Global Acceleratorとの統合は使用できません。

Application Load Balancer は、Outpost の c5/c5d、m5/m5d、または r5/r5d インスタンスにデプロイできます。次の表は、ロードバランサーが Outpost で使用できるインスタンスタイプごとのサイズと EBS ボリュームを示しています。

インスタンスタイプとサイズ EBS ボリューム (GB)
c5/c5d
large 50
xlarge 50
2xlarge 50
4xlarge 100
m5/m5d
large 50
xlarge 50
2xlarge 100
4xlarge 100
r5/r5d
large 50
xlarge 100
2xlarge 100
4xlarge 100

ロードバランサーのセキュリティグループ

セキュリティグループは、ロードバランサーとの間で許可されているトラフィックを制御するファイアウォールとして機能します。インバウンドトラフィックとアウトバウンドトラフィックの両方を許可するポートとプロトコルを選択できます。

ロードバランサーに関連付けられたセキュリティグループのルールは、リスナーポートとヘルスチェックポートの両方における両方向のトラフィックを許可する必要があります。リスナーをロードバランサーに追加するとき、またはターゲットグループのヘルスチェックポートを更新するときは必ず、セキュリティグループルールを見直し、新しいポートで両方向のトラフィックが許可されていることを確認する必要があります。詳細については、「推奨ルール」を参照してください。

ロードバランサーの状態

ロードバランサーの状態は次のいずれかです。

provisioning

ロードバランサーはセットアップ中です。

active

ロードバランサーは完全にセットアップされており、トラフィックをルーティングする準備ができています。

active_impaired

ロードバランサーはトラフィックをルーティングしていますが、スケールするのに必要なリソースがありません。

failed

ロードバランサークラウドをセットアップできませんでした。

ロードバランサーの属性

ロードバランサーの属性は以下のとおりです。

access_logs.s3.enabled

Amazon S3 に保存されたアクセスログが有効かどうかを示します。デフォルト: false。

access_logs.s3.bucket

アクセスログの Amazon S3 バケットの名前。この属性は、アクセスログが有効になっている場合は必須です。詳細については、「アクセスログの有効化」を参照してください。

access_logs.s3.prefix

Amazon S3 バケットの場所のプレフィックス。

client_keep_alive.seconds

クライアントのキープアライブ値を秒単位で表します。デフォルトは 3600 秒です。

deletion_protection.enabled

削除保護が有効化されているかどうかを示します。デフォルト: false。

idle_timeout.timeout_seconds

アイドルタイムアウト値 (秒単位)。デフォルト値は 60 秒です。

ipv6.deny_all_igw_traffic

ロードバランサーへのインターネットゲートウェイ (IGW) アクセスをブロックし、インターネットゲートウェイ経由の内部ロードバランサーへの意図しないアクセスを防止します。インターネット向けロードバランサーでは false、内部ロードバランサーでは true に設定されます。この属性は、IGW 以外のインターネットアクセス (ピアリング、Transit Gateway、、 AWS Direct Connectなど) を妨げません AWS VPN。

routing.http.desync_mitigation_mode

アプリケーションにセキュリティ上のリスクをもたらす可能性があるリクエストをロードバランサーで処理する方法を指定します。指定できる値は、monitor、defensive、および strictest です。デフォルト: defensive。

routing.http.drop_invalid_header_fields.enabled

有効ではないヘッダーフィールドを持つ HTTP ヘッダーがロードバランサーによって削除されるか (true)、ターゲットにルーティングされるか (false) を示します。デフォルト: false。Elastic Load Balancing では、HTTP フィールド名レジストリに記載されているとおり、有効な HTTP ヘッダー名が正規表現 [-A-Za-z0-9]+ に準拠している必要があります。それぞれの名前は英数字またはハイフンで構成されます。このパターンに適合しない HTTP ヘッダーをリクエストから削除したい場合は、true を選択します。

routing.http.preserve_host_header.enabled

Application Load Balancer が HTTP リクエストに Host ヘッダーを保持し、変更を加えずターゲットに送信するかどうかを示します。指定できる値は true および false です。デフォルトは false です。

routing.http.x_amzn_tls_version_and_cipher_suite.enabled

ネゴシエートされた TLS バージョンと暗号スイートに関する情報を含む 2 つのヘッダー (x-amzn-tls-version および x-amzn-tls-cipher-suite) が、ターゲットに送信される前にクライアントのリクエストに追加されるかどうかを指定します x-amzn-tls-version ヘッダーには、クライアントとネゴシエートされた TLS プロトコルのバージョンに関する情報があり、x-amzn-tls-cipher-suite ヘッダーには、クライアントとネゴシエートされた暗号スイートに関する情報があります。どちらのヘッダーも OpenSSL 形式です。この属性に指定できる値は true と false です。デフォルト: false。

routing.http.xff_client_port.enabled

X-Forwarded-For ヘッダーが、クライアントがロードバランサーへの接続に使用したソースポートを保持するかどうかを指定します。指定できる値は true および false です。デフォルトは false です。

routing.http.xff_header_processing.mode

Application Load Balancer がターゲットにリクエストを送信する前に、HTTP リクエストの X-Forward-For ヘッダーを変更、保持、または削除できるようにします。指定できる値は、append、preserve、および remove です。デフォルト: append。

  • 値が append の場合、Application Load Balancer は、(ラストホップの) クライアント IP アドレスを HTTP リクエストの X-Forward-For ヘッダーに追加してからターゲットに送信します。

  • 値が preserve の場合、Application Load Balancer は、HTTP リクエストの X-Forward-For ヘッダーを保持し、変更を加えずにターゲットに送信します。

  • 値が remove の場合、Application Load Balancer は、HTTP リクエストの X-Forward-For ヘッダーを削除してからターゲットに送信します。

routing.http2.enabled

HTTP/2 が有効化されているかどうかを示します。デフォルト: true。

waf.fail_open.enabled

リクエストを に転送できない場合に、 AWS WAFが有効なロードバランサーがターゲットにリクエストをルーティングできるようにするかどうかを示します AWS WAF。指定できる値は true および false です。デフォルトは false です。

注記

routing.http.drop_invalid_header_fields.enabled 属性は HTTP 非同期保護を提供するために導入されました。routing.http.desync_mitigation_mode 属性は、アプリケーションの HTTP 非同期からのより包括的な保護を提供するために追加されました。両方の属性を使用する必要はなく、アプリケーションの要件に応じてどちらかを選択できます。

IP アドレスタイプ

インターネット向けや内部のロードバランサーへのアクセスにクライアントが使用できる IP アドレスのタイプは、ユーザーが設定できます。

Application Load Balancer は、次の IP アドレスタイプをサポートしています。

ipv4

クライアントは IPv4 アドレス (192.0.2.1 など) を使用してロードバランサーに接続する必要があります。

dualstack

クライアントは、IPv4 アドレス (192.0.2.1 など) と IPv6 アドレス (たとえば、2001:0db8:85a3:0:0:8a2e:0370:7334) の両方を使用してロードバランサーに接続できます。

考慮事項

  • ロードバランサーは、ターゲットグループの IP アドレスのタイプに基づいてターゲットと通信します。

  • ロードバランサーのデュアルスタックモードを有効にすると、Elastic Load Balancing がロードバランサーの AAAA DNS レコードを提供します。IPv4 アドレスを使用してロードバランサーと通信するクライアントは、A DNS レコードを解決します。IPv6 アドレスを使用してロードバランサーと通信するクライアントは、AAAA DNS レコードを解決します。

  • インターネットゲートウェイを経由する内部デュアルスタックロードバランサーへのアクセスがブロックされ、意図しないインターネットアクセスを防止します。ただし、IGW 以外のインターネットアクセス (ピアリング、Transit Gateway、 など) AWS Direct Connectは妨げられません AWS VPN。

dualstack-without-public-ipv4

クライアントは、IPv6 アドレス (2001:0db8:85a3:0:0:8a2e:0370:7334 など) を使用してロードバランサーに接続する必要があります。

考慮事項

  • Application Load Balancer 認証は、ID プロバイダー (IdP) または Amazon Cognito エンドポイントに接続する場合にのみ IPv4 をサポートします。パブリック IPv4 アドレスがないと、ロードバランサーは認証プロセスを完了できず、HTTP 500 エラーが発生します。

IP アドレスタイプの詳細については、「」を参照してくださいApplication Load Balancer の IP アドレスタイプ。

Application Load Balancer リソースマップ

Application Load Balancer リソースマップは、関連するリスナー、ルール、ターゲットグループ、ターゲットなど、ロードバランサーのアーキテクチャをインタラクティブに表示します。リソースマップでは、すべてのリソース間の関係とルーティングパスも強調表示され、ロードバランサーの設定が視覚的に表示されます。

コンソールを使用して Application Load Balancer のリソースマップを表示するには

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

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

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

  4. リソースマップタブを選択して、ロードバランサーのリソースマップを表示します。

リソースマップコンポーネント

マップビュー

Application Load Balancer リソースマップには、概要 と異常なターゲットマップ の 2 つのビューがあります。 概要はデフォルトで選択され、ロードバランサーのすべてのリソースが表示されます。異常なターゲットマップビューを選択すると、異常なターゲットとそれらに関連付けられたリソースのみが表示されます。

異常なターゲットマップビューは、ヘルスチェックに失敗したターゲットのトラブルシューティングに使用できます。詳細については、「リソースマップを使用した異常なターゲットのトラブルシューティング」を参照してください。

Resource Groups

Application Load Balancer リソースマップには、リソースタイプごとに 1 つずつ、4 つのリソースグループが含まれています。リソースグループは、リスナー 、ルール 、ターゲットグループ 、ターゲット です。

リソースタイル

グループ内の各リソースには独自のタイルがあり、その特定のリソースの詳細が表示されます。

  • リソースタイルにカーソルを合わせると、そのタイルと他のリソースとの関係が強調表示されます。

  • リソースタイルを選択すると、そのタイルと他のリソースとの関係が強調表示され、そのリソースに関する追加の詳細が表示されます。

    • ルール条件： 各ルールの条件。

    • ターゲットグループのヘルスサマリー： 各ヘルスステータスの登録済みターゲットの数。

    • ターゲットヘルスステータス ターゲットの現在のヘルスステータスと説明。

    注記

    リソース詳細の表示をオフにすると、リソースマップ内の追加の詳細を非表示にできます。

  • 各リソースタイルには、選択したときにそのリソースの詳細ページに移動するリンクが含まれています。

    • リスナー - リスナープロトコル：ポートを選択します。例えば、次のようになります: HTTP:80

    • ルール - ルールアクションを選択します。例えば、次のようになります: Forward to target group

    • ターゲットグループ - ターゲットグループ名を選択します。例えば、次のようになります: my-target-group

    • ターゲット - ターゲット ID を選択します。例えば、次のようになります: i-1234567890abcdef0

リソースマップをエクスポートする

Export を選択すると、Application Load Balancer のリソースマップの現在のビューを PDF としてエクスポートできます。

ロードバランサー接続

リクエストを処理するとき、ロードバランサーは 2 つの接続を維持します。1 つはクライアントとの接続、もう 1 つはターゲットとの接続です。ロードバランサーとクライアント間の接続は、フロントエンド接続とも呼ばれます。ロードバランサーとターゲット間の接続は、バックエンド接続とも呼ばれます。

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

接続アイドルタイムアウトは、ロードバランサーが接続を閉じる前に、既存のクライアントまたはターゲット接続を非アクティブのままにして、データの送受信を行わない期間です。

ファイルのアップロードなどの長い操作を完了させるには、各アイドルタイムアウト期間が経過する前に少なくとも 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. [変更の保存] をクリックします。

を使用してアイドルタイムアウト値を更新するには 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 クライアントのキープアライブ期間を開始します。期間は、トラフィックがない場合も実行され続け、新しい接続が確立されるまでリセットされません。

注記

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

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

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

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

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

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

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

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

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

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

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

クロスゾーンロードバランサー

クロスゾーン負荷分散は、Application Load Balancer のデフォルト状態でオンになっており、ロードバランサーレベルでは変更できません。詳細については、「Elastic Load Balancing ユーザーガイド」の「クロスゾーン負荷分散」を参照してください。

クロスゾーン負荷分散は、ターゲットグループレベルでオフにすることができます。詳細については、「クロスゾーン負荷分散をオフにする」を参照してください。

削除保護

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Desync 軽減モード

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

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

分類

分類は次のとおりです。

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

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

  • Ambiguous — リクエストは RFC 7230 に準拠しておらず、ウェブサーバーやプロキシごとに処理方法が異なる場合、リスクが生じます。

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

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

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

モード

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

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

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

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

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

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

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

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

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

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

を使用して非同期緩和モードを更新するには 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) を使用しない場合、クライアントによってポート番号が追加されなければ、ホストヘッダーにポート番号を追加します。例えば、リスナーポートが 8080 などのデフォルト以外のポートである場合、Host: www.example.com を含む HTTP リクエストの Host ヘッダが Host: www.example.com:8080 に変更されます。

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

次の表では、Application Load Balancers がリスナーポートに基づいて 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. [変更の保存] をクリックします。

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

modify-load-balancer-attributes コマンドを使用します。この場合、routing.http.preserve_host_header.enabled 属性は true に設定します。

Application Load Balancer と AWS WAF

Application Load Balancer AWS WAF で を使用すると、ウェブアクセスコントロールリスト (ウェブ ACL) のルールに基づいてリクエストを許可またはブロックできます。詳細については、AWS WAF デベロッパーガイドの Working with web ACLs を参照してください。

デフォルトでは、ロードバランサーが からレスポンスを取得できない場合 AWS WAF、HTTP 500 エラーが返され、リクエストは転送されません。に接続できない場合でも、ロードバランサーがターゲットにリクエストを転送する必要がある場合は AWS WAF、 AWS WAF 統合を有効にできます。ロードバランサーが と統合されているかどうかを確認するには AWS WAF、 でロードバランサー AWS Management Console を選択し、統合サービスタブを選択します。

事前定義されたウェブ ACLs

AWS WAF 統合を有効にするときに、事前定義されたルールを使用して新しいウェブ ACL を自動的に作成することを選択できます。事前定義されたウェブ ACL には、最も一般的なセキュリティ脅威に対する保護を提供する 3 つの AWS マネージドルールが含まれています。

  • AWSManagedRulesAmazonIpReputationList ‐ Amazon IP 評価リストのルールグループは、ボットやその他の脅威に通常関連付けられている IP アドレスをブロックします。詳細については、「 AWS WAF デベロッパーガイド」の「Amazon IP 評価リストマネージドルールグループ」を参照してください。

  • AWSManagedRulesCommonRuleSet - コアルールセット (DCR) ルールグループは、OWTAK Top 10 で説明されている高リスクで一般的に発生する脆弱性の一部を含む、さまざまな脆弱性の悪用に対する保護を提供します。詳細については、「 AWS WAF デベロッパーガイド」の「コアルールセット (CRS) マネージドルールグループ」を参照してください。

  • AWSManagedRulesKnownBadInputsRuleSet ‐ 既知の不正な入力ルールグループは、無効であることがわかっており、脆弱性の悪用または検出に関連するリクエストパターンをブロックします。詳細については、「 AWS WAF デベロッパーガイド」の「既知の不正な入力マネージドルールグループ」を参照してください。

コンソール AWS WAF を使用して を有効にするには

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

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

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

  4. 統合 タブで、AWS ウェブアプリケーションファイアウォール (WAF) を展開し、WAF ウェブ ACL の関連付け を選択します。

  5. ウェブ ACL で、事前定義されたウェブ ACL の自動作成 を選択するか、既存のウェブ ACL を選択します。

  6. ルールアクション で、ブロック またはカウント を選択します。

  7. [確認] を選択します。

を使用して AWS WAF フェイルオープンを有効にするには AWS CLI

modify-load-balancer-attributes コマンドを使用します。この場合、waf.fail_open.enabled 属性は true に設定します。