ECSタスク定義を、コンテナ実行の契約として読む
タスク定義はDockerイメージの指定だけではない。CPU・メモリ・ポート・ログ・権限を一つの版として束ね、ECSが起動できる形にする契約書である。
TL;DR
- クラスターは実行先の論理的な入れ物、タスク定義は起動するコンテナの設計図。
- 実行ロールはECSの起動準備、タスクロールはアプリ本体のAWSアクセスに使う。
- Fargateではネットワーク、セキュリティグループ、イメージ、ログを合わせて定義する。
01ECSの部品を「場所・設計図・実体」に分ける
クラスター、タスク定義、タスクの役割を混同しない

ECSクラスターはタスクを動かすための論理的な場所で、タスク定義は起動条件を記述した版、タスクはその実体だ。障害時は「どの版の、どのタスクか」で追跡する。
コンテナを変更しても、タスク定義の新しいリビジョンを使わなければ実行中の条件は変わらない。
- clusterは実行先の論理単位
- task definitionは起動条件の版
- taskは実際に動くコンテナ集合
02起動準備の権限とアプリ権限を分ける
どの処理が誰の権限でAWSへアクセスするかを明確にする

ECSがイメージを取得してログやシークレットを扱う処理と、コンテナのアプリがAWS APIを呼ぶ処理は主体が違う。二つのロールを分けると、権限を広げずに必要な操作を許可できる。
アプリがS3へ触れない問題を、実行ロールへ権限追加して解決しようとしない。まずタスクロールを確認する。
- execution roleは起動フェーズの権限
- task roleはコンテナ内アプリの権限
- 役割ごとに最小権限を割り当てる
03Fargate起動に必要な宣言を揃える
イメージだけでは起動しない。ネットワークと観測先まで決める

Fargateではコンテナイメージ、リソース量、ポート、ログ設定に加え、タスクに接続するサブネットとセキュリティグループを揃える。どれか一つでも不一致なら、起動または通信で失敗する。
タスク定義の設定値はアプリの性能・通信・観測性に直結する。本番用の値をローカル用の感覚で決めない。
- ECRイメージとタグを明示する
- CPU・メモリ不足は起動・実行失敗につながる
- ログ出力先とポートの整合を確認する
結論
- タスク定義はコンテナを起動するための版管理された契約。
- 実行ロールとタスクロールを目的別に分ける。
- Fargateではイメージ、リソース、ネットワーク、ログを一体で確認する。