NLB 設定値メモ（Terraform）
概要
Terraform で NLB を構成する必要があった（UDP要件）が、いくつかの設定値がドキュメントを見ただけではすんなり理解ができなかったため、多少深掘りが必要となった値をメモ📝
設定値
desync_mitigation_mode
デフォルトdefensive、特に厳しいセキュリティ要件がなければデフォルトのままでよい
HTTP リクエストスマグリングの対策のためのオプション
値はmonitor, defensive, strictestの3つで、HTTPリクエストの安全性の分類レベルをどこまで許可するかが異なる
詳細はこちらの表が詳しい
参考：HTTP リクエストスマグリング
HTTPリクエストスマグリングは、現在の RFC で定義されている以下2つのヘッダが同時に存在する場合の解釈の優先順位を正しく実装していない脆弱性のあるサーバーがプロキシなどに存在する際に起きる脆弱性
-
Content-Length：HTTP のボディの長さを指定する（固定長）ヘッダ -
Transfer-Encoding：レスポンスをリアルタイムに生成するなどで HTTP のボディの長さが不明な場合にこの値をchunckedとして可変長として送信するためのヘッダ
Transfer-Encoding : chunckedがある場合、本来連続で送られるリクエストなどを待たなければならず、Content-Lengthより優先される
が、脆弱性のあるサーバーではContetn-Lengthを優先した結果、バックエンドに対して本来可変長のリクエストを固定長の完了したリクエストとしてバックエンドに送信し、一連のHTTP通信を一旦完了する
バックエンド側が正常な実装をしている場合、Transfer-Encoding : chunckedを正しく解釈するので、レスポンスを返した後に次のパケットを持つ
ここで、別のHTTPパケットが届きプロキシがバックエンドへ送信すると、バックエンドはこのパケットを前の続きと解釈してしまう、といった問題が起こる💥
dns_record_client_routing_policy
特に要件がなければデフォルトで良い、いまいち情報が少なめ
大半がクロスゾーン負荷分散をONにする気もするので触ることが少なさそう（クロスゾーン負荷分散との併用は不可）
設定値としては、Route 53 Resolver を利用した名前解決を行うクライアントに対して、NLB の AZ へのルーティングのポリシーを制御するもの
- 全て同じ AZ にルーティング（100％）
- 85% 同じ AZ にルーティングし残りは分散
- 全てランダムにルーティング
The possible values are availability_zone_affinity with 100 percent zonal affinity, partial_availability_zone_affinity with 85 percent zonal affinity, and any_availability_zone with 0 percent zonal affinity.
enable_cross_zone_load_balancing
NLB ではデフォルト OFF、ALB はデフォルト ON
AWS の LoadBalancer は、AZ 単位でノードが存在しており、本来 AZ をまたがってトラフィックを分散しないが、クロスゾーン孵化分散を ON にすると AZ を跨いで分散してくれる
それぞれのノードは NIC で静的 IP アドレスを持つ
ロードバランサー用のアベイラビリティーゾーンを有効にすると、Elastic Load Balancing はアベイラビリティーゾーンにロードバランサーノードを作成します。デフォルトでは、各ロードバランサーノードは、アベイラビリティーゾーン内の登録済みターゲット間でのみトラフィックを分散します。クロスゾーン負荷分散を有効にすると、各ロードバランサーノードは、有効なすべてのアベイラビリティーゾーンの登録済みターゲットにトラフィックを分散します。
https://docs.aws.amazon.com/elasticloadbalancing/latest/network/introduction.html
以下の記述の通り、冗長性の確保のために基本的には有効化推奨だが、
NLB の場合、クロスゾーン負荷分散の結果発生した AZ をまたぐ通信については GB 単位での課金が発生するので料金が気になる人は注意が必要💰
アプリケーションの耐障害性を向上させる目的で、複数のアベイラビリティーゾーンをロードバランサーに対して有効にすることができます。各ターゲットグループで、有効にした各アベイラビリティーゾーンに 1 つ以上のターゲットがあることを確認してください。たとえば、1 つ以上のターゲットグループで 1 つのアベイラビリティーゾーン内に正常なターゲットがない場合、DNS から該当するサブネットの IP アドレスを削除しますが、他のアベイラビリティーゾーンのロードバランサーノードは、引き続きトラフィックをルーティングできます。
NLB の場合、クロスゾーンで GB 単位の料金が発生するが、
ALB の場合はクロスゾーン負荷分散が常時有効であるため、課金が発生しないらしい
（これが ALB はデフォルト有効、NLB はデフォルト無効な理由か）
Application Load Balancer でクロスゾーンロードバランシングを有効にすると、リージョンの AWS データ転送について料金が発生しますか?
いいえ。クロスゾーン負荷分散は Application Load Balancer では常に有効であるため、この種類のリージョンデータ転送には料金はかかりません。
Network Load Balancer でクロスゾーン負荷分散を有効にすると、リージョンの AWS データ転送に対して料金が発生しますか?
はい、クロスゾーン負荷分散を有効にすると、Network Load Balancer でのアベイラビリティーゾーン間のリージョンデータ転送には料金が発生します。料金は、Amazon EC2 オンデマンド料金表のページのデータ転送セクションを参照してください。
参考：フローハッシュアルゴリズム
NLB はラウンドロビンではなく、フローハッシュアルゴリズムに基づいてパケットを分散する
TCP, UDP ともに、送信元ポートや送信先アドレスなどの要素をベースに通信を1つの「フロー」とみなして、フローが変わらなければ同じ宛先へ振り分けを行う
（TCP はそもそもコネクションを保持するので、コネクションが切れないと常に同じ対象に保存するけれど）
この「フロー」はNW界隈の用語で、同じ送信元と送信先を共有するパケットのことを言うらしい📝
In networking terms, a flow represents a unidirectional sequence of packets sharing the same source and destination IP addresses, source and destination ports, and protocol type.
余談も余談だけれど、AWS が独自に作ったプロトコルらしい
NLB は UDP もフローをコネクションとして保持する
NLB が TCP コネクション を保持するのは特に違和感なく入ってくるが、
本来コネクションレスである UDP も上述のフローを一つのコネクションとして、120秒間コネクションを保持する
UDP はコネクションレスですが、ロードバランサーは送信元と宛先のIPアドレスとポートに基づいて UDP フロー状態を維持します。これにより、同じフローに属するパケットが一貫して同じターゲットに一貫して同じターゲットに送信されます。アイドルタイムアウト期間が経過した後、ロードバランサーは着信 UDP パケットを新しいフローとみなし、それを新しいターゲットにルーティングします。Elastic Load Balancing は、UDP フローのアイドルタイムアウト値を 120 秒に設定します。これは変更できません。
https://docs.aws.amazon.com/ja_jp/elasticloadbalancing/latest/network/network-load-balancers.html#connection-idle-timeout
enforce_security_group_inbound_rules_on_private_link_traffic
プライベートリンク経由できたパケットに対して、Security Group のインバウンドルールを適用するかどうか
これはお好みに応じて
余談
NLB の設定ではないが調べてしまったものがあり、もったいないのでそのまま載せておく
drop_invalid_header_fields
ALB のみの設定値
デフォルトはOFF（false）、AWS Config のルールの確認項目でもあるので、基本は ON（true）にしてしまってもいいはず
ELB では、正規表現[-A-Za-z0-9]+の準拠を推奨しているので、これに準拠しないHTTPヘッダをドロップしてくれる機能
Elastic Load Balancing では、登録されているすべてのメッセージヘッダー名が正規表現 [-A-Za-z0-9]+ に準拠している必要があります。
有効化することでセキュリティ的には向上が見込めるが、一方でアンダースコアを使ったヘッダ名がNGとなるので、既存システムなどでアンダースコアを用いたカスタムヘッダーなどを使用している場合は注意が必要（AWSがデフォルトでは無効としているのはこのためと思われる）
Discussion