ALBをHTTPSの入口として、安全にAPIへルーティングする
ALBは単なる転送役ではない。TLSを終端し、意図したホスト名だけをターゲットへ送り、異常なタスクを外す公開境界である。
TL;DR
- Listenerは受信するプロトコル・ポートとルールを持ち、Target Groupへ転送する。
- Target Groupは変動するECSタスクのIPをサービス経由で登録し、ヘルスチェックで配送先を選ぶ。
- デフォルトは403にし、許可したホスト名のルールだけをAPI Target Groupへ送ると意図しない直アクセスを減らせる。
01ListenerとTarget Groupで「受付」と「配送先」を分ける
ALBはどのリクエストを受け、どの集団へ送るかを分離する

ALBのListenerはHTTPSリクエストを受け、条件に合うルールのアクションを選ぶ。Target Groupは個々のECSタスクIPを束ねるため、ALBはタスクが置換されても同じグループへ転送すればよい。
FargateではTarget typeをIPにする。ECSサービスがタスクのIP登録・解除を担当するため、ここで手動登録しない。
- Listener: 受信ポート・プロトコル・ルール
- Target Group: 配送先とヘルス状態
- ECS service: タスクIPの登録・解除
02HTTPSとヘルスチェックを公開境界に置く
暗号化と到達可能性の確認を、アプリの前段で揃える

HTTPS ListenerにACM証明書を設定すると、クライアントとのTLSはALBで終端する。Target Groupではアプリのヘルスチェックパスを定期確認し、正常なタスクだけを転送対象にする。
ヘルスチェックのパス、成功コード、アプリのルーティングがずれると、タスクが起動していてもUnhealthyになる。
- ACM証明書はListenerへ設定する
- health checkはアプリ専用の軽い経路を使う
- Healthyになるまで利用者トラフィックへ送らない
03名前付きアクセスだけを許可するListenerルールを作る
Route 53のAliasとHost条件で、正規の入口を明確にする

Route 53のAliasでAPIサブドメインをALBへ向け、HTTPS ListenerにはそのHost名に一致するルールを作る。既定アクションを403にすれば、ALBのDNS名やIPを直接使うリクエストはAPIへ流れない。
ドメインでの200だけでなく、ALBのIP指定で403になることを確認すると、ルールの意図を検証できる。
- AliasはALBを名前で参照する
- Host条件がAPIへの正規経路を定義する
- default 403が想定外の到達を拒む
結論
- ALBはHTTPS受付、Target Groupは動的なECS配送先を担う。
- ヘルスチェックは正常なタスクだけを経路に残す。
- Route 53 AliasとHostルール、default 403で公開入口を限定する。