Application Load Balancer - Elastic Load Balancing

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

Application Load Balancer

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

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

リソースマップを使用してリソースを視覚化する

リソースマップは、ロードバランサーのすべてのリソースをビジュアル形式で表示します。これには、リソース間の関係やルーティングパスが含まれます。

次のロードバランサーリソースがリソースマップに表示されます。

  • リスナー

  • ルール

  • ターゲットグループ

  • ターゲット

リソースマップを使用して、ロードバランサーのアーキテクチャを理解し、ロードバランサーのリスナー数、リスナーに転送するルール、ターゲットをルーティングするターゲットグループを確認できます。

リソースマップを使用して、望ましくない設定や不正な設定、異常なターゲットを特定することもできます。ルールなどのリソースマップ内のリソースを選択すると、それらのリソースの設定を編集するリンクが表示されます。

ロードバランサーのリソースを視覚化するには
  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

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

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

  4. [リソースマップ] タブを選択すると、視覚化されたリソースが表示されます。

    リソースマップのナビゲーション
    • リソースタイルにカーソルを合わせるか選択して、そのタイルと他のリソースとの関係を強調表示します。

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

    • タイル内のリソース名を選択して、そのリソースの詳細ページにアクセスします。

  5. リソースの詳細を表示 を有効にして、すべてのリソースの追加情報を表示します。

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

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

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

  6. (オプション) 異常なターゲットマップを選択すると、現在異常なターゲットとそれに関連付けられているリソースがすべて表示されます。

  7. (オプション) エクスポートを選択すると、Application Load Balancer のリソースマップの現在のビューを PDF としてエクスポートできます。

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

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

アプリケーションにセキュリティ上のリスクをもたらす可能性があるリクエストをロードバランサーで処理する方法を指定します。指定できる値は、monitordefensive、および 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 形式です。この属性に指定できる値は truefalse です。デフォルト: 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 ヘッダーを変更、保持、または削除できるようにします。指定できる値は、appendpreserve、および 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 アドレスのタイプは、ユーザーが設定できます。

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 レコードを解決します。

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

ロードバランサー接続

リクエストを処理する場合、ロードバランサーは 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 は、最初の接続中に HTTP クライアントのキープアライブ期間を 1 回割り当てます。HTTP クライアントのキープアライブ期間を更新すると、HTTP クライアントのキープアライブ期間の値が異なる同時接続が発生する可能性があります。既存の接続では、最初の接続時に適用された HTTP クライアントのキープアライブ期間の値を保持し、新しい接続では更新された HTTP クライアントのキープアライブ期間の値を受け取ります。

コンソールを使用してクライアントキープアライブ期間の値を更新するには
  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

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

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

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

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

  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 TAK」を参照してください 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. [変更の保存] をクリックします。

を使用して desync 軽減モードを更新するには AWS CLI

routing.http.desync_mitigation_mode 属性を monitor、、または に設定してdefensivemodify-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) を使用しない場合、クライアントによってポート番号が追加されなければ、ホストヘッダーにポート番号を追加します。例えば、リスナーポートが 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:8080 example.com example.com:8080 example.com
ホストヘッダーの保持を有効にするには
  1. Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。

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

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

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

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

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

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

routing.http.preserve_host_header.enabled 属性を に設定して modify-load-balancer-attributes コマンドを使用します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 デベロッパーガイド」の「コアルールセット (DCR) マネージドルールグループ」を参照してください。

  • 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

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