Application Load Balancer (ALB) の属性を整理してみた

Application Load Balancer（ALB）の属性を整理したい

おのやんです。

みなさん、Application Load Balancer（以下,ALB）の属性を整理してみたくないですか？私は整理してみたいです。

ALBは、属性を設定することで細かい動作を設定可能です。アプリケーションの要件によっては、この属性の設定が必要になる場合もあります。

という事で、今回はALBの属性で設定できる各項目について整理したいと思います。

注意

ALBの各属性の設定は、アプリケーションの要件によって大きく変わります。
今回紹介する設定値やユースケースは、あくまで一例です。
実際にALBの属性を検討する場合には、各自の環境や要件に合わせて値を設定するようにしてください。

ALBの属性の概要

ALBの属性は、ALB詳細画面の「属性」タブから確認できます。

ALBに設定できる項目は以下のとおりです。なお英語からの機械翻訳なのか、公式ドキュメントとAWSマネジメントコンソールで表現が異なる項目・設定値があります。今回はAWS マネジメントコンソール上の表記で統一したいと思います。

TLS バージョンと暗号ヘッダー

こちらの項目をオンにすると、クライアントからリクエストが来た時に、そのリクエストにx-amzn-tls-versionヘッダーとx-amzn-tls-cipher-suiteヘッダーを追加して、ターゲットに流します。このヘッダーには、公式ドキュメントの表記でいう「ネゴシエートされたTLSバージョンと暗号スイートに関する情報」が含まれています。こちらはデフォルトではオフになっています。

「ネゴシエートされたTLSバージョンと暗号スイートに関する情報」によってアプリケーションの処理を変えたり、この情報を別のリソースに送信する場合は、オンにするのがいいかと思われます。

HTTP/2

こちらの項目をオンにすると、ALBへのリクエストにHTTP2が使えるようになります。こちらはデフォルトではオンになっています。

クライアントやシステムがHTTP2に対応していなかったり、デバッグなどの特殊な状況でHTTP2以外の通信が必要な場合は、こちらの項目をオフにするかと思われます。

WAFのフェイルオープン

こちらの項目をオンにすると、WAFが障害などで落ちている際にクライアントからのリクエストをそのままターゲットに流すかを表します。デフォルトではオフになっています。

こちらを設定する場合は、セキュリティ要件と可用性の要件のバランスを考えます。WAFのセキュリティ対策が一時的に無効になってでも、サービスが止まらないことを優先する場合は、こちらの項目をオンにするのがいいかと思われます。

アイドルタイムアウト

こちらの項目は、クライアントとALB間、あるいはALBとターゲット間の接続がアイドル（無通信）状態になってから接続が自動的に切断されるまでの時間です。こちらはデフォルトで60秒に設定されています。

アプリケーションの要件に長時間双方向通信（例えば、ストリーミングやリアルタイムのチャットなど）などがある場合は、アイドルタイムアウトの時間を長く設定して、接続が不必要に切断されることを防ぎます。

逆に大量の接続が短時間で開閉されるようなトラフィックパターンの場合は、短いアイドルタイムアウトを設定して、リソースの使用を最適化できます。

アプリケーションやミドルウェアの要件に合わせて、アイドル状態の接続を適切なタイミングで切断するようにアイドルタイムアウトを調整することが必要です。

Desync 緩和モード

こちらの項目は、HTTP Desync攻撃を防ぐ度合いを表します。「防御的」「最も厳格」「モニタリング」の3つの値から1つを設定できます。デフォルトは「防御的」です。

Desync緩和モードやHTTP Desync攻撃については、こちらのブログで詳細に解説されています。

「防御的」を設定した場合、セキュリティリスクの高いリクエストをブロックします。言わば「ほとんどの正常なリクエストを許可し、ほとんどの危険なリクエストをブロックする」のが「防御的」です。

これに対し、ちょっとでも怪しいリクエストも問答無用でブロックするのが「最も厳格」です。こちらは、「防御的」に対してより高いセキュリティを実現できる一方で、正常なリクエストもブロックする可能性があります。

ある程度セキュリティリスクを抑えながらアプリケーションの可用性も確保したい場合は、「防御的」を設定します。一方でアプリケーションが止まることを許容してでもセキュリティを確保したい場合は、「最も厳格」を設定するとよいでしょう。

ちなみに、「モニタリング」に設定した場合は全てのトラフィックを許可します。セキュリティリスクのあるリクエストも含めて一切ブロックしません。こちらはセキュリティリスクにつながるため、基本的に設定しないのがいいかと思われます。

無効なヘッダーフィールドを削除

こちらの項目を有効にすると、[-A-Za-z0-9]+の正規表現に準拠しないヘッダーを持つHHTPリクエストを不正なリクエストとしてブロックします。デフォルトはオフになっています。

[-A-Za-z0-9]+の正規表現に準拠していないヘッダーは、一般的にターゲットへの攻撃の場合が多いです。その一方で、「[-A-Za-z0-9]+に準拠していないヘッダーだが、正常なリクエスト」もブロックしてしまいます。そのため、ある程度のアクセスブロックは許容して、ターゲットのセキュリティをもっと高めたい場合は、こちらをオンにするのがいいかと思われます。

X-Forwarded-For ヘッダー

こちらの項目は、ターゲットへ流すリクエストのX-Forwarded-Forヘッダーに対する操作を表しています。こちらの項目は「付加」「保持」「削除」の3つの値から設定できます。デフォルトは「付加」です。

「付加」に設定した場合、クライアントのIPアドレスを X-Forwarded-For ヘッダーに追加します。ログ記録、セキュリティ分析、地理的な制限などでクライアントの実際のIPアドレスを知りたい場合は、付加を選択するのが良いかと思われます。

「保持」に設定した場合、リクエストに含まれている X-Forwarded-Forヘッダーの値をそのまま残します。ALBはIPアドレスを追加したり変更したりしません。何らかの要件により、リクエストの送信元クライアントのIPアドレスを維持したりする場合は、こちらを設定するのが良いかと思われます。

「削除」に設定した場合、リクエストの X-Forwarded-For ヘッダーをALBが削除します。セキュリティなどの関係でクライアントのIPアドレスの情報を保護する必要がある場合は、こちらを設定するのが良いかと思われます。

クライアントポートの保持

こちらの項目は、クライアントの元のポート番号を保持するかどうかを表します。デフォルトはオフになっています。

セキュリティまたはコンプライアンスの要件でポート番号が必要だったり、ポート番号によってアプリケーションの処理が変わる場合などでは、オンにするのがいいかと思われます。

ホストヘッダーを保持

こちらの項目は、HTTP リクエストのホストヘッダーを保持し、変更を加えずにそのままターゲットに送信するかどうかを表します。デフォルトはオンです。

アプリケーションがリクエストに基づいたルーティングを行っていたり、正確なホストヘッダーが必要になる場合は、こちらをオンにするのかいい<かと思われます。

逆に、特定の要件で、ターゲットにホストヘッダを渡せない場合は、オフにするのがいいかと思われます。

クロスゾーン負荷分散

こちらはALBでは設定不可となっていますが、オプションで有効にすることもできます。

こちらがオンになっていると、設定されている全AZ上のターゲットに対してトラフィックを分散します。逆にオフの時は、ALBが動いているAZ上のターゲットにのみトラフィックを流します。こちらは可用性などの面でオンにすることが多いですが、料金・レイテンシーの観点からオフにする場合もゼロではないようです。

Q. クロスゾーン負荷分散を有効にする際のデメリットはどういう点がありますか？
A. クロスゾーン負荷分散は、アベイラビリティーゾーンにまたがって負荷を分散するため、各 EC2 インスタンスへの負荷を平均化できますが、唯一考えられるデメリットとしてはAZ間で通信が発生するため、AZ間ネットワーク料金がかかることと多少の Latency が発生するということです。

クロスゾーン負荷分散については、こちらも参考になります。

アクセスログ

こちらの項目は、ロードバランサーに送信されるリクエストのログを記録するかどうかを表します。ログはS3バケットに保存されます。デフォルトはオフです。

何らかの原因で障害が発生した場合にログを見に行くので、基本的にはオンにしておくとよいでしょう。

接続ログ

こちらの項目は、TLS接続をログ記録するかどうか設定できます。デフォルトではオフです。

TLSクライアント認証が何らかの原因で失敗した際に、こちらのログを見に行くことになるかと思います。TLSクライアント認証(mTLS)のトラストストアの検証や接続失敗時のログ確認、TLSネゴシエーションエラーの調査などが必要な場合には、こちらの項目をオンにするとよいでしょう。

削除保護

こちらの項目は、ALBの削除保護を有効にするかどうかを表しています。デフォルトではオフになっています。

こちらをオンにすると、マネジメントコンソールから「削除する」だけを選択して削除することができなくなります。ALBを削除する前に、この削除保護を無効にするプロセスが必要になります。

削除保護をオンにすることで、マネジメントコンソール上での操作ミスでALBを削除してしまうような事故を大きく減らすことができます。特に本番環境で運用している場合など、削除すると大きな影響が予想されるALBには、削除保護を設定しておきましょう。

最後に

今回はALBの属性の項目を整理しましたが、これらの値はアプリケーションの要件によって大きく変わってきます。

アプリケーションの要件を考えた上で、必要な属性値を設定できるように、いまいちど内容などを確認しておくといいと思います。では！