Application Load Balancer - Elastic Load Balancing

Application Load Balancer

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

詳細については、Elastic Load Balancing ユーザーガイド の「Elastic Load Balancing の仕組み」を参照してください。

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

Application Load Balancer を作成するときは、アベイラビリティーゾーン、ローカルゾーン、または Outpost のいずれかのタイプのサブネットを指定する必要があります。

アベイラビリティーゾーン

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

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

  • ロードバランサーが正しくスケールできるように、ロードバランサーのアベイラビリティーゾーンサブネットごとに CIDR ブロックを最低でも /27 ビットマスク (例: 10.0.0.0/27) にし、少なくとも 8 個の空き IP アドレスを用意してください。ロードバランサーはこれらの IP アドレスを使用して、ターゲットとの接続を確立します。

ローカルゾーン

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

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

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

Outposts

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

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

  • ロードバランサーでは、ロードバランサーノードの Outpost に 2 つのインスタンスが必要です。サポートされるインスタンスは、汎用インスタンス、コンピューティング最適化インスタンス、およびメモリ最適化インスタンスです。最初は、インスタンスは large インスタンスです。ロードバランサーは、必要に応じて large から xlarge に、xlarge から 2xlarge に、そして 2xlarge から 4xlarge にスケールされます。追加の容量が必要な場合は、ロードバランサーが 4xlarge インスタンスを追加します。ロードバランサーをスケールするのに十分なインスタンス容量または使用可能な IP アドレスがない場合、ロードバランサーは AWS Personal Health Dashboard にイベントを報告し、ロードバランサーの状態は active_impaired になります。

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

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

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

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

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

ロードバランサーの状態

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

provisioning

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

active

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

active_impaired

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

failed

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

ロードバランサーの属性

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

access_logs.s3.enabled

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

access_logs.s3.bucket

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

access_logs.s3.prefix

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

deletion_protection.enabled

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

idle_timeout.timeout_seconds

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

routing.http.desync_mitigation_mode

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

routing.http.drop_invalid_header_fields.enabled

有効ではないヘッダーフィールドを持つ HTTP ヘッダーがロードバランサーによって削除されるか (true)、ターゲットにルーティングされるか (false) を示します。デフォルトは false です。Elastic Load Balancing では、メッセージヘッダー名に英数字とハイフンのみを含める必要があります。

routing.http2.enabled

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

IP アドレスタイプ

クライアントがインターネット向けロードバランサーで使用できる IP アドレスの種類を設定できます。クライアントは、内部ロードバランサーで IPv4 アドレスを使用する必要があります。

IP アドレスの種類を次に示します。

ipv4

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

dualstack

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

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

クライアントとロードバランサーとの通信方法に関係なく、ロードバランサーは IPv4 アドレスを使用してターゲットと通信します。したがって、ターゲットは IPv6 アドレスを必要としません。

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

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

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

バックエンド接続では EC2 インスタンスに HTTP キープアライブオプションを有効にすることが推奨されます。EC2 インスタンスのウェブサーバー設定で HTTP キープアライブを有効にできます。HTTP キープアライブを有効にすると、ロードバランサーはキープアライブのタイムアウト期間が終了するまで、バックエンド接続を再利用できます。また、アプリケーションのアイドルタイムアウトは、ロードバランサーに設定されたアイドルタイムアウトよりも大きな値に設定することをお勧めします。

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

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

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

  2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します。

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

  4. [Description] タブで、[Edit attributes] を選択します。

  5. [Edit load balancer attributes (ロードバランサーの属性を編集)] ページで、[Idle timeout (アイドルタイムアウト)] の値を秒単位で入力します。有効な範囲は 1 ~ 4000 です。

  6. [保存] を選択します。

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

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

削除保護

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

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

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

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

  2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します。

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

  4. [Description] タブで、[Edit attributes] を選択します。

  5. [ロードバランサー属性の編集] ページで、[削除保護] の [有効] を選択し、[保存] を選択します。

  6. [Save] を選択します。

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

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

  2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します。

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

  4. [Description] タブで、[Edit attributes] を選択します。

  5. [ロードバランサー属性の編集] ページで、[削除保護] の [有効] の選択を解除し、[保存] を選択します。

  6. [Save] を選択します。

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 軽減モードを更新するには

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

  2. ナビゲーションペインの [LOAD BALANCING] で [Load Balancers] を選択します。

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

  4. [Description] タブで、[Edit attributes] を選択します。

  5. [desync 軽減モードの設定] ページで、[モニタリング]、[防御]、[厳密] のいずれかを選択します。

  6. [保存] を選択します。

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

modify-load-balancer-attributes コマンドを使用します。この場合、routing.http.desync_mitigation_mode 属性は monitordefensivestrictest のいずれかに設定します。

Application Load Balancer および AWS WAF

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

ロードバランサーが AWS WAF と統合されているかどうかを確認するには、AWS マネジメントコンソールでロードバランサーを選択し、[統合されたサービス] タブを選択します。