ECS の仕組みは読んだのに、いざタスク定義を書こうとすると手が止まる。コンテナを何個入れるのか、CPU とメモリはいくつか、ロールがなぜ2つあるのか、パスワードはどこに置くのか。この記事は、タスク定義の各項目を「設計の判断」として整理します。部品の定義そのものは 
READ ALSO — 学習中向け・段2 構成
Amazon ECS の仕組み｜クラスター・タスク定義・サービスと Fargate の関係
で扱っているので、ここでは決め方に絞ります。
この記事の結論
- 1つのタスクには「一緒に起動し、一緒に止まってよいもの」だけを入れます。独立して増減させたいものは別のタスク定義・別のサービスにします。
- 必須（essential）のコンテナが止まるとタスクごと止まります。本体と補助のコンテナを区別して指定します。
- Fargate ではタスク単位の CPU とメモリを、許可された組み合わせから選びます。小さく始め、メトリクスを見て直します。
- ロールは2つです。実行ロールは ECS 側が使い、タスクロールはアプリのコードが使います。
- 設定は環境変数、秘密は Secrets Manager などから注入し、イメージやタスク定義に直書きしません。
- タスク定義は変更のたびに新しいリビジョンになります。サービスをその版に更新して入れ替えます。
1つのタスクに何を入れるか｜コンテナを分ける・同居させる判断
タスク定義は、コンテナの設計図です（練習問題でも「イメージ・CPU/メモリ・環境変数などを定義する設計図」として問われる定義です）。1つのタスク定義には、複数のコンテナを書けます。ただし、複数書けることと、書くべきことは別の話です。
判断の軸は1つ、一緒に起動し、一緒に止まってよいかです。同じタスクに入れたコンテナは同じ単位で起動・停止し、台数を増やすときも丸ごと増えます。
- 同居させてよい例: アプリ本体と、そのログを転送するだけの補助コンテナ。本体が動く間だけ必要で、台数も常に1対1です。
- 分けるべき例: Web のフロントと、重い非同期処理のワーカー。負荷のかかり方が違うので、同居させるとスケールの単位が揃ってしまいます。
各コンテナには essential（必須）かどうかを指定します。必須のコンテナが止まるとタスク全体が止まります。本体は必須、使い捨ての初期化処理や補助は必須にしない、というように、止まったときの影響で決めます。
TASK DEFINITIONタスク定義の構成
タスク定義はロール・コンテナ・設定・ログの4段で決める
-
全体
タスクのロールとサイズ
実行ロール・タスクロール・CPU・メモリ
-
コンテナ
何を同居させるか
イメージ・essential の指定
-
設定
環境変数とシークレット
秘密は参照だけを書く
-
ログ
logConfiguration
標準出力の出力先を決める
CHECK 1ここまでの確認
負荷に合わせて別々に台数を増やしたい2つの処理は、どう置く?
答えと解説
答え: 2. 別のタスク定義にして、別のサービスで動かす
タスクは「一緒に起動し、一緒に止まる」単位で、台数を増やすときも丸ごと増えます。「1つのタスクに何を入れるか」の章を読み直してください。
CPU とメモリはどう決めるか｜タスクサイズと「超えたらどうなるか」
Fargate では、タスク全体の CPU とメモリを指定します。値は自由な数字ではなく、許可された組み合わせから選ぶ形です。具体的な組み合わせと料金は改定されるため、ここには書かず、Fargate のタスク定義パラメータ と公式の料金ページで確認してください。
設計の考え方は次の3点です。
- 取った分が課金の単位になる。 大きく取れば安心、ではありません。
- 最初は小さめに置く。 実際の使用量が分からないうちに大きく決めても、根拠がありません。
- メトリクスを見て直す。 クラスターで Container Insights を有効にすると、タスク単位・サービス単位の CPU とメモリの使用量を追加の開発なしに見られます。見た結果を次のリビジョンのサイズに反映します。
コンテナごとにもメモリの上限を書けます。タスク全体の枠の中を、コンテナ同士でどう分け合うかの指定です。メモリは CPU と違い、上限を超えると処理が遅くなるのではなくコンテナが止められる性質があります。必須のコンテナが止まればタスクも止まるので、「超えたらどうなるか」まで含めて余裕を決めます。
ロールが2つあるのはなぜか｜タスクロールと実行ロールの分担
タスク定義には IAM ロールを2つ指定できます。名前が似ていて混ざりやすいところです。
TWO ROLES2つのロール
実行ロールはECS が使い、タスクロールはアプリが使う
実行ロール
ECS 側が起動までに使う
- イメージの取得
- ログの出力
- シークレットの取得
タスクロール
アプリのコードが動作中に使う
- S3 の読み書き
- DynamoDB の呼び出し
- 他の AWS サービスの利用
| 実行ロール | タスクロール | |
|---|---|---|
| 使うのは誰か | ECS（Fargate エージェント）側 | コンテナの中のアプリのコード |
| 何のためか | イメージの取得、ログの出力、シークレットの取得 | S3 や DynamoDB など、他の AWS サービスの呼び出し |
| 判断の問い | コンテナを「起動するまで」に要る権限か | コンテナが「動いている間」にコードが要る権限か |
公式ドキュメントでも、タスクロールは「アプリのコードが他の AWS サービスを使うため」のもので、ECS エージェントや Fargate エージェントが使う権限とは別、と整理されています（タスクの IAM ロール）。
分ける理由は、権限の範囲を小さく保つためです。1つにまとめると、アプリのコードにイメージ取得やシークレット取得の権限まで渡すことになります。逆に、実行ロールにアプリ用の権限を足すと、起動のための権限が広がります。迷ったら「この権限を使うのは ECS か、自分のコードか」と問います。
ロールで起きやすい3つの取り違え
- アプリが S3 を読めないのに、実行ロールへ S3 の権限を足す（足すのはタスクロール）
- イメージが取得できない、ログが出ないのに、タスクロールを直す（直すのは実行ロール）
- 手間を省くため、1つのロールに両方の権限をまとめる
CHECK 2ここまでの確認
アプリのコードが S3 のデータを読むために必要な権限は、どちらのロールに付ける?
答えと解説
答え: 2. タスクロール
アプリのコードが呼ぶ権限はタスクロール、ECS 側がイメージの取得やログ出力に使う権限は実行ロールです。「ロールが2つあるのはなぜか」の章を読み直してください。
設定と秘密をどう渡すか｜環境変数・シークレット・イメージに入れないもの
アプリに渡す値は、性質で置き場を分けます。
- 変えても困らない設定（実行モード、接続先のホスト名など）: タスク定義の環境変数として渡します。
- 秘密（DB のパスワード、API キー）: Secrets Manager や Systems Manager Parameter Store に置き、タスク定義からはその参照だけを書いて、起動時に環境変数として注入します。この取得は ECS 側が行うので、必要な権限は実行ロールに付けます。
- イメージに入れない。 イメージは ECR などに保存され、複数の環境で使い回されます。値を埋めると、見える範囲が広がり、値を変えるたびにイメージの作り直しが要ります。
同じイメージを開発・本番で使い回し、違いは環境変数と注入するシークレットだけにするのが基本形です。タスク定義にも秘密の値そのものは書きません。定義はコードと一緒に管理され、人の目に触れるためです。
CHECK 3ここまでの確認
DB のパスワードをアプリに渡す置き場として、適切なのはどれ?
答えと解説
答え: 3. Secrets Manager などに置き、実行時に注入する
イメージやタスク定義に書くと見える範囲が広がり、変えるたびに作り直しが要ります。「設定と秘密をどう渡すか」の章を読み直してください。
ログはどこへ出すか｜標準出力と logConfiguration
コンテナのログは、アプリがファイルに書くのではなく、標準出力・標準エラーに出す形が基本です。タスク定義の logConfiguration でログドライバーを指定すると、その出力が CloudWatch Logs などへ送られます。
設計で決めるのは次の2点です。
- どのログ出力先・ロググループに出すか。サービスごとにまとめると探しやすくなります。
- ログ出力に必要な権限を実行ロールに付けたか。ログが出ないときは、タスクロールではなく実行ロールを疑います。
ログの保存期間や分析の設計は別の題材なので、ここでは「タスク定義の中で出力先を決めておく」までにとどめます。
タスク定義を変えるとき何が起きるか｜リビジョンとサービスの更新
タスク定義は、family（名前）に対して登録のたびにリビジョンが増えます。既存の版を書き換えるのではなく、新しい版を足す仕組みです。古い版は残るので、どの版で動かしていたかを後から追えます。
設定を変えるときの流れは次のとおりです。
REVISION変更の入り方
変更は新しいリビジョンの登録から入る
-
新リビジョン登録
既存の版は書き換えない
-
サービス更新
新しい版を指定する
-
新タスク起動
新しい版で動く
-
旧タスク停止
古い版は役目を終える
- 変更を入れた新しいリビジョンを登録する。
- サービスを更新して、新しいリビジョンを使うように指定する。
- サービスが新しいタスクを起動し、あとで古いタスクを停止する。
新しい版に不具合があると、タスクが起動と停止を繰り返すことがあります。デプロイの失敗検知やロールバックの設計、ブルー/グリーンなどの方式は別の題材として扱います。ここでは、「変更は新しい版の登録とサービスの更新で入る」ことを押さえてください。
CHECK 4ここまでの確認
動いているサービスの設定を変えたいとき、既存のタスク定義はどうなる?
答えと解説
答え: 2. 新しいリビジョンを登録し、サービスがその版を使うよう更新する
タスク定義は版（リビジョン）として積み上がります。「タスク定義を変えるとき何が起きるか」の章を読み直してください。
設計の確認表（読者が自分のサービスに当てる問い）
自分のサービスのタスク定義に、次の問いを当ててみてください。
| 問い | 見るところ |
|---|---|
| 同居させたコンテナは、一緒に増減してよいか | コンテナの分け方 |
| 止まったら困るコンテナだけを必須にしているか | essential |
| サイズの根拠はメトリクスか、勘か | CPU・メモリ |
| 実行ロールとタスクロールを分け、権限は最小か | 2つのロール |
| 秘密がイメージやタスク定義に直書きされていないか | シークレットの注入 |
| ログの出力先と、それに必要な権限が決まっているか | logConfiguration と実行ロール |
| 変更時は新しいリビジョンとして登録しているか | リビジョン |
Fargate はサーバーを自分で管理せずにコンテナを動かせる基盤で、ECS と組み合わせれば Kubernetes の知見も要りません。その分、サーバーの設計が消えるぶん、タスク定義の設計が運用の中心になります。基盤を ECS にするか EKS にするかは 
READ ALSO — 実務向け・段3 基盤
ECS か EKS か、それとも EC2 か Lambda か｜コンテナ基盤の判断を「何を自分で持ちたいか」で決める
で扱います。
タスク定義は、コンテナを「何と一緒に動かすか」「どの大きさで」「誰の権限で」「何を渡して」動かすかを決める設計図です。1つのタスクに持たせるものを「一緒に起動・停止してよいか」で絞ると、サイズ・ロール・設定の判断が自然に決まります。
参照ソース
- Amazon ECS タスク定義のパラメータ（Fargate） — family・タスクロール・コンテナ定義・CPU/メモリ・ログ設定の項目を確認する根拠に使った
- Amazon ECS のタスクの IAM ロール — タスクロールがアプリのコードのための権限であり、ECS・Fargate エージェントの権限とは別であることの根拠に使った
