ECS 上の Nginx プロキシを ALB のホスト書き換えで置き換える検討メモ

背景

• 現状は ALB → ECS(Fargate) 上の Nginx → 外部の連携サービス各種、という 2 段プロキシ構成で Host ヘッダーを書き換えて転送しています。
• もともとはApp Meshを利用想定でしたが、サービス終了に伴いECS service connectを採用する背景でECSを用意する形となりました。
• 2025 年 10 月のアップデートで Application Load Balancer がリクエストヘッダー（Host を含む）の書き換えに対応したため、Nginx を ALB に置き換えられないかを検討します。
  ※本記事は、検討段階であり変更計画について記したものとなります。

現状の構成と課題

• Nginx の主な役割は Host ヘッダー書き換えと簡易的なパス振り分けで、CPU/メモリをほとんど消費していません。
• OS/ミドルウェアのパッチやイメージ更新、監視設定がコンテナ側にも必要で、運用対象が増えています。
• 設定変更時はコンテナの再デプロイが必要で、ルール変更の反映速度も ALB より遅くなりがちです。

ALB のホスト書き換え機能のポイント

• リスナールールのアクションに「HTTP ヘッダーを挿入/上書き」が追加され、Host を任意値に書き換えたうえでターゲットグループへフォワードできます。
• 条件付き書き換え（Host/Path/HTTP ヘッダー条件に一致したときのみ）に対応しており、複数ドメインを 1 ALB に集約しつつ内部 Host を振り分けられます。
• 送信元 IP は従来どおり X-Forwarded-For で渡されるため、クライアントトレースは維持できます。
• Nginx で付けていた追加ヘッダーは、ALB のヘッダー挿入アクションで再現できます。

置き換えを判断する観点

• Host 書き換え以外の役割：TLS 終端、圧縮、キャッシュ、レート制限などを Nginx で担っている場合は ALB だけでは不足する可能性があります。
• バックエンドが期待する Host：アプリ内のバーチャルホストや認可ロジックが書き換え後の Host でも動くかを確認します。
• 証明書と SNI：ALB で TLS 終端する場合は問題ありませんが、エンドツーエンド TLS を維持する場合はバックエンド証明書が書き換え後の Host に対応しているかを確認します。デフォルトではターゲットへの SNI は元リクエストの Host が送られますが、ターゲットグループのバックエンド接続オプションで SNI 名を指定することもできます（mTLS は非対応）。
• ヘッダーの大文字小文字・順序：ALB ではヘッダーの順序が変わることがあります。レガシーアプリで厳密に見ている場合は事前検証が必要です。

置き換えの進め方

1. PoC 用ターゲットグループを用意する：既存バックエンドをぶら下げた新規ターゲットグループを作成し、Nginx を経由しない疎通を確認します。
2. リスナールールで Host 書き換えを設定する：
   • 条件例: Host が proxy.example.com に一致。
   • アクション 1: HTTP ヘッダーを挿入/上書き → Host: backend.internal.example.
   • アクション 2: 対応するターゲットグループへフォワード。
     コンソールでは「リスナー > ルール > アクションを追加 > HTTP ヘッダーを挿入/上書き」で設定できます。
3. 検証する：
   • cURL で -H 'Host: proxy.example.com' を指定し、バックエンドログや ALB アクセスログで Host ヘッダーの書き換えを確認します。
   • ヘルスチェック結果、証明書検証（SNI は元 Host のまま送られる点に注意）を確認します。
4. 段階的カットオーバーを行う：
   • 一部トラフィックのみ新ルールに流し、問題なければ Nginx タスク数を徐々に 0 へスケールダウンします。
   • 安定後にタスク定義、不要なセキュリティグループ/ターゲットグループを整理します。

Terraform でのイメージ

listener_rule {
  listener_arn = aws_lb_listener.http.arn
  priority     = 10

  condition {
    host_header {
      values = ["proxy.example.com"]
    }
  }

  action {
    type = "insert_header"
    insert_header {
      header = "host"
      value  = "backend.internal.example"
    }
  }

  action {
    type = "forward"
    target_group_arn = aws_lb_target_group.backend.arn
  }
}

※ モジュールやプロバイダーのバージョンによって insert_header（または override_header）ブロックの名前やパラメーターが異なる場合があります。利用中の AWS Provider バージョンに合わせ、コンソールでの動作を確認してから IaC 化すると安全です。

移行時のチェックリスト

• バックエンドが参照する Host 文字列（アプリ内バーチャルホスト、認可ロジック）が書き換え後の値で動作するか。
• TLS をエンドツーエンドで張る場合、バックエンド証明書の CN/SAN が書き換え後の Host に対応しているか（難しければ ALB で TLS 終端し内部を HTTP にする）。デフォルトでは SNI が元 Host のまま送られるため、必要ならターゲットグループのバックエンド接続オプションで SNI 名を指定する。
• ALB のヘッダー順序/大文字小文字が変わっても問題ないか（レガシー依存がないかを確認）。
• Nginx で付与していた独自ヘッダー（例: X-Request-ID, X-Env）を ALB のヘッダー挿入で再現できているか。
• レート制限や WAF の適用を ALB/WAFv2 へ移せるか、どのスコープ（ALB 全体 / ルール単位）で適用するかを整理する。レートリミットは WAF の rate-based rule で代替できる。
• 監視/アラートの移行（ALB ヘルスチェック、5xx、ターゲット応答時間、アクセスログ出力先）を済ませる。

既知の制約・注意点

• ALB からターゲットへの SNI はデフォルトで元リクエストの Host を送りますが、ターゲットグループのバックエンド接続オプションで SNI 名を指定できます。mTLS は非対応なので、必要なら ALB で TLS 終端し内部を HTTP に落とすか、バックエンド証明書を合わせます。
• HTTP/2 はフロントエンドのみ対応で、ターゲットとの通信は HTTP/1.1 固定です（公式仕様）。バックエンドが HTTP/2 を前提にしている場合は Nginx/Envoy など別レイヤを検討します。
• ALB のルール適用は即時ですが、Terraform 反映時は一時的に優先度衝突が起きる場合があります。並行適用を避け、priority の一意性を計画的に管理します。

コストと運用メリット

• ECS で常時起動していた Nginx タスク分のリソースコストを削減できます（Fargate の最小タスク×台数分がそのまま浮きます）。
• ミドルウェアのライフサイクル管理が不要になり、設定変更は ALB のルール変更だけで完結します。
• ログ集約が ALB アクセスログに一本化され、CloudWatch Logs や Firehose への送信設計が単純になります。
• ルール変更の反映が速く、デプロイ待ち時間を減らせます。

ALB 置き換えで失われる（実現しにくい）機能

• サーキットブレーカー：一定失敗で自動的に経路を開放する動作は非対応（ヘルスチェックによる切り離しのみ）。
• 接続プーリングや同一コネクション多重化：Nginx の upstream keepalive／HTTP/2 アップストリームは ALB にはありません（ターゲット側は HTTP/1.1 固定）。
• 細かなリトライ制御：上流／下流単位でのリトライ回数・バックオフ調整は不可（ALB にはリトライ機構なし）。
• レートリミット／スロットリング：Nginx の limit_req/limit_conn 相当は非対応（WAF で代替検討が必要）。
• レスポンスキャッシュ：Nginx の proxy_cache 等は非対応。
• 圧縮の細かな制御：Nginx の gzip/zstd での微調整や条件付き圧縮は不可（ALB には圧縮機能なし）。
• きめ細かなヘッダー・ボディ改変：Lua/JS フィルタや正規表現ベースのレスポンス書き換えはできません（ALB は限定的なヘッダー書き換えのみ）。
• TCP/UDP レイヤの柔軟なプロキシ：ストリームモジュール相当は ALB では非対応（ALB は HTTP/HTTPS/HTTP2 のみ、TCP/UDP は NLB 領域）。
• 高度なルーティングロジック：Lua/Javascript での動的判定や複雑な条件分岐は不可（ALB は定義済み条件のみ）。
• mTLS の終端：Nginx の相互 TLS 終端は ALB ではできません（現状 ALB はクライアント証明書検証非対応）。
• 独自のリクエスト/レスポンスロギング：Nginx の log_format での細かなログ項目カスタムは不可（ALB は固定フォーマット）

まとめ

ALB が Host を含むヘッダー書き換えに対応したことで、ホスト書き換え専用の Nginx プロキシは不要になるかもしれません。
一方サーキットブレーカーなど実現できないことが要件に含まれている場合などは、慎重に進める必要がありそうです。

参考

• Introducing URL and Host Header Rewrite with AWS Application Load Balancers（AWS Networking & Content Delivery Blog）
• ルールの変換
• Application Load Balancer リスナーのルールとアクション
• ALB のリスナーアクション種類とヘッダー挿入/上書きの説明