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 バケットの場所のプレフィックス。
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
分類
分類は次のとおりです。
-
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 軽減モードを更新するには
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
に設定します。
Application Load Balancer および AWS WAF
Application Load Balancer で AWS WAF を使用して、ウェブアクセスコントロールリスト (ウェブ ACL) のルールに基づいてリクエストを許可またはブロックできます。詳細については、AWS WAF デベロッパーガイドの Working with web ACLs を参照してください。
ロードバランサーが AWS WAF と統合されているかどうかを確認するには、AWS Management Consoleでロードバランサーを選択し、[統合されたサービス] タブを選択します。
デフォルトでは、ロードバランサーが AWS WAF から応答を取得できない場合、HTTP 500 エラーが返され、リクエストは転送されません。AWS WAF に接続できない場合でも、ロードバランサーがターゲットにリクエストを転送する必要がある場合は、AWS WAF フェールオープン属性を有効にできます。
コンソールを使用して AWS WAF フェールオープンを有効にするには
Amazon EC2 コンソール (https://console.aws.amazon.com/ec2/
) を開きます。 -
ナビゲーションペインで、[ロードバランサー] を選択します。
-
ロードバランサーを選択します。
-
[属性] タブで、[編集] を選択します。
-
[トラフィック構成] で、[WAF フェイルオープン]をオンにします。
-
[変更の保存] をクリックします。
AWS CLI を使用して、AWS WAF フェールオープンを有効にするには
modify-load-balancer-attributes コマンドを使用します。この場合、waf.fail_open.enabled
属性は true
に設定します。