AWS 基礎コース / Chapter 16

ALBからECSサービスへつなぎ、Healthyと200で完結を確認する

構成図で線がつながっていても、通信は成立しない。ALBがタスクのIPをHealthyとして登録し、正規ドメインからAPIが200を返して初めて完成する。

TL;DR

  1. ECSサービスとTarget Groupを関連付けると、サービスが起動したタスクIPをTarget Groupへ登録する。
  2. ALBからECSタスクへの通信は、タスク側Security GroupがALBのSecurity Groupからのアプリポートを許可して成立する。
  3. Target GroupのHealthyとcurlの200を、同じ経路の二つの証拠として確認する。

01ECSサービスがタスクIPをTarget Groupへ追従させる

ECSのスケール・置換とALBの配送先を手作業で同期しない

ECSサービスがタスクIPをTarget Groupへ自動登録する図
サービス連携により、変わるタスクIPをTarget Groupへ追従させる。

ECSサービスにTarget Groupを関連付けると、タスク起動時にプライベートIPが登録され、停止時には解除される。ALBは個別IPの変化を直接管理せず、Target Groupを通して配送先を得る。

Target Groupが空のままなら、サービス連携、タスク起動、ネットワーク設定のいずれかを疑う。

02Security Groupは「ALBからだけ」をタスクへ通す

公開入口とアプリ層の通信許可を分け、必要な経路を限定する

ALBのSecurity GroupだけがECSタスクのアプリポートへ接続する図
ECSタスクのアプリポートは、ALBのSecurity Groupを送信元として許可する。

ALBはインターネットからHTTPSを受けるが、ECSタスクのアプリポートを全公開する必要はない。タスク側Security GroupにALBのSecurity Groupを送信元として指定し、経路を一段ずつ限定する。

IPレンジではなくSecurity Group参照で許可すると、ALBのIP変化を個別に追わずに経路を表現できる。

03Healthyとcurl 200で経路を二重に検証する

インフラ視点と利用者視点を一つの到達確認にする

Target Group Healthyとcurl 200でALB-ECS経路を確認する図
内部の配送先確認と外部からのHTTP確認を両方そろえる。

まずTarget GroupでECSタスクのプライベートIPがHealthyになったことを確認する。続けて正規ドメインのhealth APIをcurlし、200と期待するレスポンスを得れば、DNSからGo APIまでの経路が通ったと説明できる。

Unhealthyなら、ヘルスチェックのパス・成功コード、ALBからtask SGへの許可、アプリログ、余計なworkerコンテナの有無を順に見る。

結論

  1. ECSサービス連携が、変動するタスクIPをTarget Groupへ追従させる。
  2. Security GroupでALB→ECS→DBの経路を段階的に許可する。
  3. Target Group Healthyとcurl 200をそろえて、公開APIの完成を検証する。