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 つのアベイラビリティーゾーンサブネットを選択する必要があります。以下の制限が適用されます。

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

  • ロードバランサーが適切にスケーリングされるようにするには、ロードバランサーの各アベイラビリティーゾーンサブネットに、少なくとも 1 つの/27ビットマスク ( など10.0.0.0/27) とサブネットごとに少なくとも 8 つの空き IP アドレスを持つCIDRブロックがあることを確認します。これらの 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フィールド名レジストリで説明されているように[-A-Za-z0-9]+、有効なHTTPヘッダー名が正規表現 に準拠している必要があります。それぞれの名前は英数字またはハイフンで構成されます。このパターンに準拠しない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ヘッダーにはクライアントとネゴシエートされた暗号スイートに関する情報があります。どちらのヘッダーも Open SSL形式です。この属性に指定できる値は 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 は X-Forward-For ヘッダーをHTTPリクエストに保持し、変更を加えることなくターゲットに送信します。

  • 値が の場合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 アドレスを使用してロードバランサーと通信するクライアントは、AAAADNSレコードを解決します。

  • インターネットゲートウェイを経由する内部デュアルスタックロードバランサーへのアクセスがブロックされ、意図しないインターネットアクセスを防止します。ただし、これにより (ピアリング、Transit Gateway、 など) 以外のIGWインターネットアクセスが妨げられることはありません 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アドレスがないと、ロードバランサーは認証プロセスを完了できず、HTTP500 エラーが発生します。

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. [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 Route 53 Application Recovery Controller デベロッパーガイド」の「クライアントがエンドポイントに接続したままになる時間を制限する」を参照してください。

注記

ロードバランサーが 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 コマンドを使用します。

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

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

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

削除保護

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

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

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

  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。

Application Load Balancer と AWS WAF

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

デフォルトでは、ロードバランサーが からレスポンスを取得できない場合 AWS WAF、HTTP500 エラーが返され、リクエストは転送されません。に接続できない場合でも、ロードバランサーがターゲットにリクエストを転送する必要がある場合は 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 ‐ コアルールセット (CRS) ルールグループは、OWASPTop 10 などのOWASP出版物で説明されている高リスクおよび一般的に発生する脆弱性の一部を含む、幅広い脆弱性の悪用に対する保護を提供します。詳細については、「 デベロッパーガイド」の「コアルールセット (CRS) マネージドルールグループ」を参照してください。 AWS WAF

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

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

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

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

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

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

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

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

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

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

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