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

Application Load Balancer

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

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

ロードバランサーのサブネット
ロードバランサーのセキュリティグループ
ロードバランサーの状態
ロードバランサーの属性
IP アドレスタイプ
クロスゾーンロードバランサー
接続のアイドルタイムアウト
削除保護
Desync 軽減モード
ホストヘッダーの保持
AWS WAF
ロードバランサーの作成
アベイラビリティーゾーンの更新
セキュリティグループの更新
アドレスタイプの更新
タグの更新
ロードバランサーの削除
ゾーンシフト

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

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 バケットの場所のプレフィックス。

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 アドレスのタイプは、ユーザーが設定できます。

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 レコードを解決します。
インターネットゲートウェイを経由する内部デュアルスタックロードバランサーへのアクセスがブロックされ、意図しないインターネットアクセスを防止します。ただし、これはインターネットゲートウェイ以外のインターネットアクセス（ピアリング、Transit Gateway、AWS Direct Connect、AWS VPN などを経由）を妨げることはありません。

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

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

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

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

クライアントがロードバランサーを通じて行うリクエストごとに、ロードバランサーは 2 つの接続を維持します。フロントエンド接続は、クライアントとロードバランサーの間にあります。バックエンド接続は、ロードバランサーとターゲットの間です。ロードバランサーには、その接続に適用される設定済みのアイドルタイムアウト期間があります。アイドルタイムアウトが経過するまでデータが送受信されなかった場合、ロードバランサーは接続を閉じます。ファイルのアップロードなどの長いオペレーションで、完了までの時間を確保するため、各アイドルタイムアウト期間が経過するまでに少なくても 1 バイトのデータを送信し、必要に応じてアイドルタイムアウトの長さを増やします。

バックエンド接続では EC2 インスタンスで HTTP キープアライブオプションを有効にすることが推奨されます。EC2 インスタンスのウェブサーバー設定で HTTP キープアライブを有効にできます。HTTP キープアライブを有効にすると、ロードバランサーはキープアライブのタイムアウト期間が終了するまで、バックエンド接続を再利用できます。また、アプリケーションのアイドルタイムアウトは、ロードバランサーに設定されたアイドルタイムアウトよりも大きな値に設定することをお勧めします。そうしないと、アプリケーションがロードバランサーへの TCP 接続を正常に閉じない場合、ロードバランサーは、接続が閉じられたことを示すパケットを受信する前に、アプリケーションにリクエストを送信することがあります。この場合、ロードバランサーは HTTP 502 Bad Gateway エラーをクライアントに送信します。

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[ロードバランサー] を選択します。
ロードバランサーを選択します。
[属性] タブで、[編集] を選択します。
[トラフィック設定] に、[アイドルタイムアウト] の値を秒単位で入力します。有効な範囲は 1～4000 です。
[変更の保存] をクリックします。

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

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

削除保護

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

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[ロードバランサー] を選択します。
ロードバランサーを選択します。
[属性] タブで、[編集] を選択します。
[構成] で、[削除保護] をオンにします。
[変更の保存] をクリックします。

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[ロードバランサー] を選択します。
ロードバランサーを選択します。
[属性] タブで、[編集] を選択します。
[構成] ページで、[削除保護] をオンにします。
[変更の保存] をクリックします。

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

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

Desync 軽減モード

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

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

モード

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

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

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

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

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[ロードバランサー] を選択します。
ロードバランサーを選択します。
[属性] タブで、[編集] を選択します。
[パケット処理] の [非同期緩和モード] で、[防御]、[厳密]、または [モニタリング] を選択します。
[変更の保存] をクリックします。

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

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

ホストヘッダーの保持を有効にするには

Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/) を開きます。
ナビゲーションペインで、[ロードバランサー] を選択します。
ロードバランサーを選択します。
[属性] タブで、[編集] を選択します。
[パケット処理] で [ホストヘッダーを保存] をオンにします。
[変更の保存] をクリックします。

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

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