はじめに
業務ではさまざまな AWS サービスを扱っていますが、その中で「AWS ECS」というサービスについて、いまひとつ用語と概念の理解ができていなかったため、本記事ではそのECSについて理解を深めるために整理・深掘りしてみました。
本記事が、ECS を理解する一助になれば幸いです。
ざっくりとAWS ECSとは
AWS ECS（Amazon Elastic Container Service） は、DockerコンテナなどをAWS上で実行・管理するためのフルマネージドなコンテナオーケストレーションサービスです。
公式ドキュメントでは、
コンテナ化されたアプリケーションを簡単にデプロイ、管理、スケールできる
と説明されています。
コンテナオーケストレーションサービスとは？
コンテナオーケストレーションサービスとは、
多数のコンテナを自動で配置・起動・停止・監視・スケールしてくれる管理サービス
のことです。
一言でいうと、
コンテナ運用を人間の手作業から解放する仕組み
です。
コンテナオーケストレーションがないと何が起きるか
コンテナが増えると発生する問題
開発環境では Docker を手動で起動して問題ありませんが、本番環境では次のような問題が一気に発生します。
- サーバーが落ちたら、どのコンテナをどこで再起動する？
- アクセスが急増したら、手動でコンテナを増やす？
- デプロイのたびに全サーバーで
docker run？ - CPUが逼迫したコンテナをどうやって移動する？
- 死んでいるコンテナをどう検知する？
→台数が増えた瞬間に人力運用は破綻します
コンテナオーケストレーションサービスがやってくれること
① コンテナの自動配置（スケジューリング）
- CPU / メモリ条件をもとに最適なサーバーへ配置
- 空きリソースを自動判断
② 自動復旧（セルフヒーリング）
- コンテナが停止したら自動再起動
- サーバー障害時は別サーバーで再配置
③ オートスケーリング
- アクセス増加 → コンテナ数を自動で増加
- アクセス減少 → コンテナ数を自動削減（コスト最適化）
④ ローリングデプロイ
- サービスを止めずに新バージョンをデプロイ
- 古いコンテナから新しいコンテナへ段階的に切り替え
⑤ ヘルスチェック・監視
- 異常なコンテナをロードバランサーから除外
- 正常なコンテナのみトラフィックを受ける
ECSでできること
ECSを使うと、上記であげたようなコンテナ運用をAWSに任せることができます。
- Dockerコンテナの起動・停止・再起動
- コンテナ数の自動スケーリング
- アプリのローリングデプロイ
- ALB / NLB との連携による負荷分散
- CloudWatchによるログ・メトリクス管理
- IAMによる権限制御
コンテナ運用の面倒な部分をAWSが管理してくれるのが最大の特徴です。
ECSの起動タイプ
EC2 起動タイプ
- EC2インスタンス上でコンテナを実行
- OS管理やスケーリングが必要
- 柔軟だが運用負荷は高め
Fargate 起動タイプ（推奨）
- サーバーレス
- EC2を意識せずCPU・メモリを指定するだけ
- インフラ管理をほぼAWSに任せられる
公式ドキュメントでも、
インフラ管理を最小化したい場合は Fargate が推奨
とされています。
ECSの基本構成要素
クラスター（Cluster）
AWS ECS を学び始めると、最初に出てくる用語が 「クラスター」 です。
ECSのクラスターとは、
コンテナ（タスク→後述）を動かすための「論理的な置き場所（管理単位）」
です。
重要ポイント
- クラスター自体は 何も実行しない
- EC2 や Fargate、タスク、サービスをまとめて管理する箱
- ECSを使うなら 必ず作る
クラスターの役割を一言で
「この中でコンテナを動かしますよ」という管理範囲を決めるもの
イメージとしては：
- クラスター = コンテナを動かすための 敷地
- タスク = 実際に動く アプリ
- EC2 / Fargate = アプリを動かす 実行環境
ECS クラスター
├─ EC2インスタンス（EC2起動モードの場合）
│ └─ タスク（コンテナ）
└─ Fargate（Fargate起動モードの場合）
└─ タスク（コンテナ）
クラスターがやっていること
- タスクを どこで動かすか管理
- サービスによる タスク数の維持
- オートスケーリングの管理単位
クラスターを分ける際の考え方
多くの現場では「環境（dev / stg / prod）」単位で分けることが多い
dev-cluster ⭕️
stg-cluster ⭕️
prod-cluster ⭕️
サービスは「クラスター内」で分けるのが良さそう
user-api-cluster ❌️
order-api-cluster ❌️
admin-api-cluster ❌️
例外：クラスターを分けた方がよいケース
以下の場合は、環境とは別軸で分ける価値があります。
ケース① 本番の性質が大きく異なる
prod-web-cluster
prod-batch-cluster
理由：
- Web：常時稼働・低レイテンシ
- Batch：夜間実行・一時的に高負荷
→ スケール・監視・障害対応を分離できる
(batchが「常駐ワーカー」なのか「定期実行ジョブ」なのかで最適解が変わる場合あり)
ケース② EC2起動モードとFargateを混在させたい
prod-fargate-cluster
prod-ec2-cluster
理由：
- EC2起動モードは クラスターにEC2を登録する必要がある
- Fargateと混ぜると管理がややこしい
ケース③ 強い権限制御・隔離が必要
- 社外向けAPI
- 個人情報・決済系
→ 論理的・運用的な境界としてクラスターを分ける
クラスターの分け方まとめ
- ECSクラスターは 環境単位で分けるのが基本
- サービス単位で分ける必要はほぼない
- 性質・責務が大きく異なる場合のみ追加分割
- 分けすぎは逆に運用を苦しめる
タスク（Task）
ECSのタスクとは、
タスク定義(=後述)をもとに起動される、コンテナ実行の最小単位
です。
- タスク = 実際に動いているコンテナ（または複数コンテナの集合）
- ECSで「アプリが動いている状態」そのもの
- サービス（=後述）がなくても 単体で起動可能
タスク・コンテナ・タスク定義の関係
タスク定義（設計図）
↓
タスク（実行単位）
↓
コンテナ（Dockerイメージ）
タスクは「1コンテナ」とは限らない
1つのタスクに複数コンテナを含めることもできます。
例：
タスク
├─ appコンテナ（API）
└─ sidecarコンテナ（ログ送信）
特徴：
- 同じネットワーク・ライフサイクルを共有
- 同時に起動・同時に終了
→ 「常に一緒に動くもの」は1タスクにまとめる
「タスクの起動方法は2種類」
① 単発タスク（Run Task）
- 手動 / バッチ / cron 的な用途
- 終わったら自動終了
例：
- バッチ処理
- CSVインポート
- 定期集計
② サービス配下のタスク
- 常に指定数を維持
- Web / API サーバー向け
例：
サービス
└─ タスク × N
→ 本番Webアプリはほぼこちら
「Fargate と EC2 での違い」
Fargate のタスク
- タスク単位で CPU / メモリを指定
- サーバー意識ゼロ
- 初心者向け
EC2 起動モードのタスク
- EC2上で実行
- EC2の空きリソースに依存
- 上級者向け
👉 タスクという概念自体は同じ
タスク定義（Task Definition）
ECSのタスク定義とは、
ECSでコンテナを動かすための「設計図（テンプレート）」
です。
タスク定義には、コンテナを動かすために必要な情報をすべて書く必要があります。
① コンテナ定義（最重要）
- 使用する Docker イメージ
- コンテナ名
- 起動コマンド
- ポート番号
例：
"image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/app:latest"
② CPU / メモリ設定
タスク全体の CPU / メモリ
コンテナごとの割り当て
Fargate では 指定必須。
例：
CPU: 256（0.25 vCPU）
Memory: 512 MB
③ ネットワーク設定
ネットワークモード（Fargate は awsvpc 固定）
ポートマッピング
例：
"containerPort": 3000,
"protocol": "tcp"
④ 環境変数
アプリケーション設定値
外部サービス設定
例：
"name": "NODE_ENV",
"value": "production"
※ 秘密情報は AWS Secrets Manager / SSM Parameter Store 推奨
⑤ IAM ロール
タスク定義には 2 種類のロールを指定します。
Execution Role
→ イメージ取得・ログ出力用
Task Role
→ アプリが AWS サービスにアクセスするための権限
アクセスキーを持たせずにAWS操作できるのがECSの強み
⑥ ログ設定
CloudWatch Logs への出力
ロググループ・ストリーム設定
→ コンテナログを一元管理できる
タスク定義はリビジョン管理される
タスク定義は、更新するたびに リビジョン番号 が増えます。
task-definition:1
task-definition:2
task-definition:3
なぜ必要？
・ロールバックが簡単
・過去の設定を追跡できる
・安全なデプロイが可能
タスク定義はどこで使われる？
① サービス
サービス
└─ タスク定義 → タスク × N
・Web / API サーバー
・常時稼働が必要な処理
② 単発タスク（Run Task）
・バッチ処理
・一時的なジョブ
→ 同じタスク定義を使い回せる
サービス（Service）
ECSのサービスとは、
指定した数のタスクを、常に起動状態で維持し続けるための仕組み
です。
サービスが存在する理由
もしサービスがなかった場合
- タスクが落ちた → そのまま停止
- EC2 が落ちた → 復旧されない
- コンテナが異常終了 → 人が気づくまで放置
サービスはこれを防ぐために存在します。
サービスがやっていること
① タスク数の維持
desiredCount = 3
と設定すると、
- タスクが1つ落ちた
→ 自動で新しいタスクを起動 - 常に 3つ稼働している状態 を保つ
→ これがサービス最大の役割
② 自動復旧（セルフヒーリング）
- コンテナ異常終了
- インスタンス障害（EC2起動モード）
これらが起きても、
別の場所でタスクを再起動します。
③ ローリングデプロイ
サービスは 無停止デプロイ を実現します。
- 古いタスクを徐々に停止
- 新しいタスクを段階的に起動
→ 本番で安心してデプロイできる理由
④ オートスケーリング
CloudWatch メトリクスと連携し、
- CPU使用率が高い → タスク数増加
- 負荷が下がる → タスク数削減
→ アクセス変動に自動対応
まとめ
- ECSは AWS公式のコンテナ実行基盤
- Docker前提でアプリを簡単にデプロイ・運用できる
- Fargateを使えばサーバーレス感覚で利用可能
- Webアプリからバッチまで幅広く対応
この記事を書いたことによって、今までなんとなくで扱っていたECSサービスに関する理解を深めることができました。
参考記事：
Amazon Elastic Container Service (Amazon ECS)
AWSのECSってなんやねん