Docker でイメージを作れるようになり、次は AWS で動かしたい。ところが ECS の資料を開くと、クラスター・タスク定義・タスク・サービスと、似た言葉が一度に出てきます。Fargate は ECS の一部なのか別のサービスなのか、ロールがなぜ2つあるのかも、読むほど混ざっていきます。この記事では、ECS を4つの部品の関係として並べ直し、イメージを取り出してリクエストを受けるまでの流れと、2つのロールの使い分けを、構成図を読める形に整理します。
この記事の結論
- Amazon ECS は、コンテナをいつ・どこで・何個動かすかを管理するフルマネージドのコンテナオーケストレーションサービスです。
- ECS の部品は、動かす場所のまとまりのクラスター、設計図のタスク定義、実行中のタスク、数を保つサービスの4つです。
- AWS Fargate はサーバーを自分で管理せずにタスクを動かす土台で、EC2 を土台にするとインスタンスの管理を自分で持ちます。
- ECS はイメージを Amazon ECR などから取り出して起動し、サービスが ALB のターゲットグループにタスクを登録してリクエストを受けます。
- タスクロールはアプリが AWS を呼ぶための権限、タスク実行ロールは ECS がイメージの取り出しやログの送信をするための権限です。
Amazon ECS とは？何を任せるサービスか
Amazon ECS（Amazon Elastic Container Service）は、コンテナ化したアプリの配置・管理・台数の調整を任せられる、フルマネージドのコンテナオーケストレーションサービスです。Docker の記事で見たとおり、イメージはアプリと依存物を固めた「箱」でした。ECS はその箱を「どのサーバーに置くか」「いくつ動かすか」「止まったらどうするか」を引き受けます。
手で docker run を打つだけなら、ECS は要りません。必要になるのは、次のような問いが出てきたときです。
- コンテナが落ちたら、誰が起動し直すのか
- 利用が増えたら、誰がコンテナを増やすのか
- 新しい版を出すとき、古いコンテナと入れ替える順番を誰が守るのか
- ロードバランサーにどのコンテナを登録するのか
ECS はこれらを、宣言した状態（このイメージを、この設定で、この数だけ）に合わせて保ち続ける形で解きます。
READ ALSO — 学習中向け・段2 構成
Docker（コンテナ）とは｜イメージ・コンテナ・Dockerfile と仮想マシンとの違い
クラスター・タスク定義・タスク・サービスはどう関係するのか
ECS を読むときの最初の壁は、4つの部品の区別です。1枚で並べます。
FOUR PARTS OF ECS4つの部品の役割
ECS は場所・設計図・実行中・数を保つ係の4つでできている
-
場所
クラスター — タスクとサービスを動かすまとまり
土台は Fargate・EC2 などから選ぶ
-
設計図
タスク定義 — イメージ・CPU・メモリ・ロールを書く
書き換えると版が上がる（web:3 → web:4）
-
実行中
タスク — 設計図から起動したコンテナの組
1回で終わる処理は単発で起動
-
数を保つ
サービス — 決めた数のタスクを保ち、入れ替える
不健全なタスクを代わりと入れ替える
| 部品 | 何か | Docker の言葉でいうと | 例 |
|---|---|---|---|
| クラスター | タスクやサービスを動かす場所の論理的なまとまり | コンテナを載せる土台の集まり | prod-cluster |
| タスク定義 | コンテナの動かし方を書いた設計図（JSON） | docker run に渡す設定一式 |
イメージ・CPU・メモリ・ポート・環境変数・ロール |
| タスク | タスク定義から起動した実行中の単位（1つ以上のコンテナ） | 起動したコンテナ | Web アプリのコンテナ1組 |
| サービス | 決めた数のタスクを保ち、入れ替える仕組み | 「落ちたら起動し直す」係 | 常に3つのタスクを動かす |
タスク定義は版を重ねる設計図
タスク定義には、使うイメージ、CPU とメモリの量、開けるポート、環境変数、ログの送り先、使う IAM ロール、ネットワークモードなどを書きます。書き換えると新しい版（リビジョン）ができ、web:3 → web:4 のように番号が上がります。どの版で動かしているかが残るので、戻すときも版を指定できます。Docker の記事で「イメージの外に残る」と書いた設定値の多くは、ここに書かれます。
タスクは実行中の単位、サービスは数を保つ係
タスクは、タスク定義から起動した実行中の実体です。1つのタスクに複数のコンテナを入れることもできます（アプリ本体とログ収集のコンテナを組にする、など）。
サービスは、決めた数（desired count）のタスクを保ち続ける仕組みです。公式ドキュメントによると、コンテナのヘルスチェックやロードバランサーのヘルスチェックに失敗して不健全と判定されたタスクは、サービスのスケジューラーが入れ替えます。新しい版のタスク定義を指定すれば、古いタスクを順に新しいタスクに置き換えるデプロイもサービスが受け持ちます。
一方、夜間の集計のように「1回動いて終われば良い」処理は、サービスを作らずにタスクを単発で起動します。EventBridge Scheduler などから、決まった時刻にタスクを起動することもできます。
常に動いていてほしいものはサービス、終われば良いものは単発のタスク、と分けると迷いにくくなります。
CHECK 1ここまでの確認
ECS で「このイメージを、この CPU とメモリで、この環境変数で動かす」を書いておく部品はどれ?
答えと解説
答え: 2. タスク定義
タスク定義はコンテナの動かし方の設計図です。クラスターは動かす場所のまとまり、サービスは決めた数のタスクを動かし続ける仕組みです。「4つの部品はどう関係するのか」の章を読み直してください。
CHECK 2ここまでの確認
ECS のサービスが担う役割として正しいのはどれ?
答えと解説
答え: 2. 決めた数のタスクを保ち、止まったり不健全になったりしたタスクを入れ替える
サービスは「望む数（desired count）」を保つ仕組みです。タスクが止まったり、ヘルスチェックに失敗したりすると、代わりのタスクを起動します。イメージの保存は ECR の役割です。
起動タイプ（Fargate と EC2）は何が違うのか
タスクは、どこかの計算資源の上で動きます。その土台の選び方が起動タイプ（と、それを発展させた容量プロバイダー）です。公式ドキュメントは、起動タイプとして Fargate・EC2・External（オンプレミスのサーバーや VM）を挙げ、容量の決め方としては容量プロバイダーを推奨しています。容量プロバイダーには、Fargate と Fargate Spot、自分で管理する EC2 の Auto Scaling グループ、EC2 の管理を AWS に任せる Amazon ECS Managed Instances があります。
学び始めに押さえるのは、Fargate と EC2 の2つの違いです。
| 観点 | AWS Fargate | EC2（自分で管理するインスタンス） |
|---|---|---|
| サーバーの管理 | AWS が持つ。インスタンスは見えない | 自分で持つ。台数・OS の更新・エージェントの更新 |
| 何を決めるか | タスクごとの vCPU とメモリ | インスタンスの種類と台数、タスクの詰め方 |
| 料金のかかり方 | タスクが求めた vCPU・メモリ・ストレージに対して | 起動しているインスタンスと EBS などに対して |
| 向いている場面 | サーバーを持たずに始めたい、台数の上下が大きい | GPU など特定のインスタンスが要る、細かく調整したい |
| 中断してよい処理 | Fargate Spot を選べる | EC2 のスポットインスタンスを選べる |
AWS Fargate は、サーバーやクラスターの容量を自分で用意しなくてもコンテナを動かせる、サーバーレスの計算エンジンです。ECS と EKS の両方から使えます。つまり Fargate は ECS の「代わり」ではなく、ECS が動かすタスクの「土台」の1つです。
ECS は「何をいくつ動かすか」、Fargate や EC2 は「どこで動かすか」を受け持つ、と役割で分けると、構成図に両方が並んでいる理由が読めます。
READ ALSO — 未経験向け・段1 入口
EC2 とは何か｜インスタンス・AMI・EBS・セキュリティグループを「借りた1台」で理解する
イメージを取り出してリクエストを受けるまでの流れ
ここからは、Web アプリを ECS のサービスとして Fargate で動かし、ALB でリクエストを受ける場合の流れを追います。
FROM IMAGE TO REQUESTリクエストを受けるまで
サービスが起動し、ECR から取り出して ALB につなぐ
-
タスク定義
版を登録する
-
サービス
起動を指示する
-
ECR から pull
実行ロールで取り出す
-
ENI を得る
awsvpc で IP を持つ
-
ALB に登録
ターゲットの種類は ip
1. 実行ロールで ECR からイメージを取り出す
タスクを起動するとき、ECS（Fargate では Fargate のエージェント、EC2 ではコンテナエージェント）が、タスク定義に書かれたイメージをレジストリから取り出します。イメージが Amazon ECR のプライベートリポジトリにあるなら、その取り出しに使うのがタスク実行ロールの権限です。取り出せないとタスクは起動に失敗し、停止の理由にイメージを取り出せなかった旨が出ます。
2. タスクがネットワークインターフェースを得る
Fargate のタスクは awsvpc というネットワークモードで動き、タスクごとに VPC のサブネットの中でネットワークインターフェース（ENI）とプライベート IP アドレスを持ちます。EC2 のインスタンスと同じように、タスクにセキュリティグループを付けられるのはこのためです。
3. サービスが ALB のターゲットに登録する
サービスにロードバランサーの設定があると、起動したタスクがターゲットグループに登録され、ヘルスチェックに通ったものにリクエストが届きます。awsvpc のタスクはインスタンスではなくネットワークインターフェースに結び付くので、ターゲットグループのターゲットの種類は ip にします（instance では登録できません）。公式ドキュメントは、Fargate のタスクを使うサービスがつなげるのは Application Load Balancer と Network Load Balancer だと説明しています。
4. 新しい版は入れ替えで出す
新しいイメージを出すときは、タスク定義の新しい版を作り、サービスにその版を指定します。サービスは新しいタスクを起動してヘルスチェックに通ったら古いタスクを止める、という入れ替えを進めます。入れ替え方にはローリング更新やブルー/グリーンといった型があり、選び方は運用の記事で扱います。
READ ALSO — 学習中向け・段2 構成
Elastic Load Balancing とは何か｜ALB・NLB・GWLB の違いとヘルスチェック、複数 AZ
CHECK 3ここまでの確認
Fargate で動くタスクを ALB につなぐとき、ターゲットグループのターゲットの種類はどれにする?
答えと解説
答え: 2. ip
Fargate のタスクは awsvpc というネットワークモードで動き、タスクごとにネットワークインターフェースを持ちます。インスタンスではなくタスクの IP アドレスを登録するので、ターゲットの種類は ip です。「リクエストを受けるまでの流れ」の章を読み直してください。
タスクロールと実行ロールはどう違うのか
ECS でいちばん混ざりやすいのが、2つの IAM ロールです。どちらもタスク定義に書きますが、誰が使う権限かが違います。
WHO USES THE ROLE2つのロール
実行ロールはECS が準備に、タスクロールはアプリが仕事に使う
タスク実行ロール
使うのは ECS のエージェント
- ECR からイメージを取り出す
- CloudWatch Logs にログを送る
- 秘密情報を取り出してコンテナに渡す
タスクロール
使うのはコンテナの中のアプリ
- S3 のオブジェクトを読む
- DynamoDB に書き込む
- SQS にメッセージを送る
| 観点 | タスク実行ロール | タスクロール |
|---|---|---|
| 使うのは誰か | ECS のコンテナエージェントと Fargate のエージェント | コンテナの中で動くアプリのコード |
| いつ使うか | タスクを起動する前後（準備と後片付け） | アプリが動いている間 |
| 典型的な権限 | ECR からイメージを取り出す、CloudWatch Logs にログを送る、秘密情報を取り出してコンテナに渡す | S3 のオブジェクトを読む、DynamoDB に書く、SQS にメッセージを送る |
| コンテナから見えるか | 見えない（エージェントだけが使う） | 見える（アプリが一時的な認証情報として受け取る） |
公式ドキュメントは、タスク実行ロールの権限はエージェントに渡されコンテナからは直接使えないこと、タスクロールの権限はタスクの中のコンテナに渡されエージェントは使わないことを、それぞれ説明しています。ECR からイメージを取り出すだけなら、その権限はタスクロールではなく実行ロールに付けます。
1つにまとめない理由
2つを1つのロールにまとめると、アプリが本来要らない権限（ほかのイメージの取り出しや、ログの設定）まで持つことになります。アプリのコードに脆弱性があったとき、使える権限が広いほど被害も広がります。アプリに渡す権限は、アプリが呼ぶ API の分だけにする、という最小権限の考え方を ECS に当てはめた形が、この2つの分け方です。
READ ALSO — 未経験向け・段1 入口
IAM ポリシーの評価の仕組み｜許可と拒否はどの順で決まるか
CHECK 4ここまでの確認
コンテナの中のアプリが S3 のオブジェクトを読むための権限は、どちらのロールに付ける?
答えと解説
答え: 1. タスクロール
アプリ自身が AWS の API を呼ぶ権限はタスクロールに付けます。タスク実行ロールは、ECS のエージェントが ECR からイメージを取り出したり、ログを CloudWatch Logs に送ったりするための権限です。
まとめ
- ECS は、コンテナを「何を・いくつ・どう入れ替えるか」を宣言した状態に保つサービスです。
- 部品は、クラスター（場所）・タスク定義（設計図）・タスク（実行中の単位）・サービス（数を保つ係）の4つです。
- Fargate と EC2 は「どこで動かすか」の選択肢で、ECS の代わりではありません。サーバーの管理を誰が持つかで分かれます。
- ECR からの取り出しとログの送信は実行ロール、アプリが AWS を呼ぶ権限はタスクロールに付けます。
- Fargate のタスクを ALB につなぐときは、ターゲットの種類を ip にします。
次は、同じコンテナを動かすもう1つの選択肢の EKS と比べて、どちらを選ぶかを考えます。
参照ソース
- What is Amazon Elastic Container Service?（Amazon ECS デベロッパーガイド） — ECS の定義と、クラスター・タスク・サービスの位置づけ（2026年9月時点の記載）
- Amazon ECS task definitions（Amazon ECS デベロッパーガイド） — タスク定義に書く項目とリビジョン（2026年9月時点の記載）
- Amazon ECS services（Amazon ECS デベロッパーガイド） — desired count の維持と、不健全なタスクの入れ替え（2026年9月時点の記載）
- Amazon ECS launch types and capacity providers（Amazon ECS デベロッパーガイド） — 起動タイプ（Fargate・EC2・External）と容量プロバイダー、ECS Managed Instances（2026年9月時点の記載）
- AWS Fargate for Amazon ECS（Amazon ECS デベロッパーガイド） — Fargate がサーバーの管理なしにコンテナを動かす土台であること（2026年9月時点の記載）
- Use an Application Load Balancer for Amazon ECS（Amazon ECS デベロッパーガイド） — awsvpc のタスクでターゲットの種類を ip にすること（2026年9月時点の記載）
- Allocate a network interface for an Amazon ECS task（Amazon ECS デベロッパーガイド） — awsvpc ネットワークモードでタスクごとに ENI を持つこと（2026年9月時点の記載）
- Amazon ECS task execution IAM role（Amazon ECS デベロッパーガイド） — 実行ロールの用途（ECR からの取り出し・CloudWatch Logs への送信）（2026年9月時点の記載）
- Amazon ECS task IAM role（Amazon ECS デベロッパーガイド） — タスクロールの権限がコンテナに渡されること（2026年9月時点の記載）
- Amazon ECS pricing（AWS） — Fargate・EC2 を土台にするとき ECS 自体に追加料金がないこと（2026年9月時点の記載。単価は公式ページで確認）
