---
title: "AWS ECSとは？Dockerコンテナを動かす手順と起動タイプ・料金・EKSとの違い【2026年10月】"
url: "https://www.issoh.co.jp/tech/details/3870/"
published: 2024-10-17
updated: 2026-10-28
categories: ["AWS"]
publisher: "株式会社一創"
---
# AWS ECSとは？Dockerコンテナを動かす手順と起動タイプ・料金・EKSとの違い【2026年10月】
AWS ECS（Amazon Elastic Container Service、読み方はイーシーエス）は、Dockerコンテナの配置・起動・監視・スケーリングをAWSが肩代わりするフルマネージドのコンテナオーケストレーションサービスです。2017年11月21日までは「Amazon EC2 Container Service」という名前で、古い資料にあるEC2 Container Serviceは同じサービスを指します。手元で `docker run` していたコンテナを本番で動かすには、イメージをAmazon ECRへpushし、起動条件をタスク定義に書き、サービスとして常駐させる3段階を踏みます。本記事ではこの流れをCLIで通したうえで、4つの起動タイプと使えるOS、東京リージョンの料金、ALB連携・オートスケール・デプロイといった運用の設定、EKSやLambdaとの違いを2026年10月時点の公式情報で扱います。Fargate単体の料金やEC2起動タイプとの損益分岐は[AWS Fargateとは？ECSのEC2起動タイプとの違い・料金・運用をわかりやすく解説](/tech/details/3304/)に分けています。
## まとめ：ECSでDockerコンテナを動かす要点と2026年10月時点の構成
- ECSはAWS純正のコンテナオーケストレーション。クラスター・タスク定義・タスク・サービスの4要素で、コンテナの台数維持・自動復旧・入れ替えを宣言的に任せられる。旧称はEC2 Container Service。
- Dockerイメージを動かす流れは「docker build → ECRへpush → タスク定義を登録 → サービスを作成」。Fargateならサーバーを1台も用意せずに動く。
- 起動タイプは4つ：Fargate／EC2／Managed Instances（2025年9月30日提供開始）／ECS Anywhere。EC2で使うAMIはAmazon Linux 2023版が推奨で、Amazon Linux 2版は2026年6月30日にサポートが終わった。
- ECS自体の利用料は無料。東京のFargate（Linux・x86）は0.5vCPU・1GBの常時稼働で月約22.5ドル、ARM（Graviton）なら約18.0ドル。ALBとNATゲートウェイを常設すると、小さなタスクでは本体より周辺の方が高くつくことがある。
- 本番運用ではALBのターゲットタイプを `ip` にし、ターゲット追跡のオートスケールとデプロイサーキットブレーカー（失敗時の自動ロールバック）を最初から有効にしておく。
- EKSとの最大の違いはKubernetesを使うか。EKSは制御プレーンに0.10ドル毎時（約73ドル毎月・1クラスター）かかり、ECSは無料。App Runnerの受け皿はECS Express Modeに移った。
## AWS ECSとは：Dockerコンテナを本番で束ねるフルマネージドの仕組み
ECSは、AWS上でコンテナ化したアプリケーションを本番運用するための土台です。開発者はコンテナイメージと「どう動かすか」の定義だけを渡し、実際の配置・ヘルスチェック・入れ替え・スケールはECSが担います。AWS純正なので、IAM・VPC・ロードバランサー・CloudWatchとの連携に追加の部品が要りません。公式の位置づけは開発者ガイドの[What is Amazon Elastic Container Service?](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/Welcome.html)にまとまっています。
### コンテナオーケストレーションでECSが自動化する範囲と人が残す作業
コンテナオーケストレーションとは、多数のコンテナを「どのホストに」「何個」「落ちたら再起動」「負荷が上がったら増やす」を自動で調整する仕組みです。ECSはこのうち、タスクの配置決定、異常タスクの自動置き換え、希望タスク数の維持、オートスケーリング、ローリング更新を引き受けます。
人の手に残るのは、イメージのビルドと脆弱性対応、タスク定義の更新、IAMロールとネットワークの設計です。前提となるコンテナ技術そのものは[Dockerとは｜仮想マシンとの違い・必要スペック・Desktop/Engineの違いとインストール手順](/tech/details/6857/)で扱う領域で、ECSはそのDockerコンテナを本番で束ねる層にあたります。
### ECSを構成する4要素：クラスター・タスク定義・タスク・サービスの関係
| 要素 | 役割 | Dockerでいえば |
| ----- | ----------------------- | --------------- |
| クラスター | タスクを動かす論理的な入れ物 | Dockerホストの集まり |
| タスク定義 | イメージ・CPU/メモリ・ポート・ログの設計図 | docker runの引数一式 |
| タスク | タスク定義から起動した実行単位 | 起動中のコンテナ群 |
| サービス | 指定数のタスクを常時維持しLBと紐づける | restart＋台数管理 |
バッチのように一度きり動かすならタスクを単発で実行し、Web APIのように常時稼働させるならサービスを使います。1つのタスクに複数のコンテナを入れられますが、台数の増減はタスク単位で、コンテナごとに個別にはスケールできません。
タスク定義は上書きされず、登録するたびに `myapp:1`、`myapp:2` とリビジョン番号が増えます。サービスがどのリビジョンを指しているかで本番の中身が決まるため、障害時は前のリビジョンを指定し直せば戻せます。ただし、そのリビジョンが指すイメージをECRに残してあることと、DBスキーマなど外部の状態が旧版と互換であることが前提です。クラスターは環境（本番・検証）ごとに分けるのが基本で、同じ環境内のサービスまで細かく分ける必要はありません。
### docker runの引数とタスク定義パラメータの対応
手元の `docker run` コマンドがあれば、タスク定義はほぼ機械的に書き起こせます。各パラメータの正式な仕様は公式の[Amazon ECS task definition parameters](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task%5Fdefinition%5Fparameters.html)に一覧があります。
| docker runの指定 | タスク定義の項目 | Fargateでの注意 |
| ------------- | -------------------------- | --------------- |
| イメージ名 | image | ECRのURIを書く |
| \-p 8080:80 | portMappings.containerPort | hostPortは省略か同じ値 |
| \-e KEY=VALUE | environment | 機密値はsecretsへ分ける |
| –cpus・–memory | cpu・memory | 決められた組み合わせのみ |
| \-v（ボリューム） | volumes・mountPoints | 永続化はEFSを使う |
| –restart | restartPolicy | 台数の維持はサービスが担う |
| –log-driver | logConfiguration | awslogsが標準 |
Fargateではネットワークモードが `awsvpc` に固定され、タスクごとにENI（IPアドレス）が割り当たります。そのため `-p 8080:80` のようなホスト側ポートの付け替えはできず、コンテナが待ち受けるポートをそのまま公開する設計が前提です。ポートを変えたいなら、アプリ側の待ち受けポートを変えるか、前段のALBで受け口を変えます。
## DockerイメージをECSで動かす手順：ビルドからECR push・サービス作成まで
ここからは、手元のDockerイメージをFargate上で常駐させるまでをAWS CLIで通します。前提はAWS CLI v2とDockerが入っていること、デフォルトVPCがある東京リージョン（ap-northeast-1）を使うことです。アカウントIDやサブネットIDは自分の環境の値に置き換えてください。
### 手順1 Dockerfileの作成とlinux/amd64向けビルド
例として、nginxで静的ページを返すだけの最小イメージを作ります。作業用ディレクトリに、配信するindex.htmlとDockerfileを置きます。
```
mkdir myapp && cd myapp
echo 'Hello ECS
' > index.html
```
```
# Dockerfile
FROM nginx:1.30-alpine
COPY index.html /usr/share/nginx/html/index.html
EXPOSE 80
```
Apple Silicon（M系チップ）のMacでそのまま `docker build` すると、arm64向けのイメージができます。タスク定義の既定はx86\_64なので、このまま動かすとタスクが `exec format error` で停止します。ビルド時にプラットフォームを明示するのが確実です。
```
docker build --platform linux/amd64 -t myapp:1.0.0 .
docker run --rm -p 8080:80 myapp:1.0.0 # 手元で http://localhost:8080 を確認
```
`--platform` による別アーキテクチャ向けビルドの仕組みはDocker公式の[Multi-platform builds](https://docs.docker.com/build/building/multi-platform/)に解説があります。arm64のまま使いたい場合は、タスク定義の `runtimePlatform` で `cpuArchitecture` を `ARM64` にすればGraviton上で動き、後述のとおりFargate単価も約2割下がります。
### 手順2 ECRリポジトリの作成・docker login・イメージのpush
ECSが取りに行くイメージの置き場として、Amazon ECRにプライベートリポジトリを作ります。認証からpushまでの流れはAWS公式の[Pushing a Docker image to an Amazon ECR private repository](https://docs.aws.amazon.com/AmazonECR/latest/userguide/docker-push-ecr-image.html)と同じです。
```
export AWS_DEFAULT_REGION=ap-northeast-1 # 以降のAWS CLIの既定リージョン
ACCOUNT_ID=123456789012
REGION=$AWS_DEFAULT_REGION
REPO=myapp
aws ecr create-repository --repository-name $REPO --region $REGION
aws ecr get-login-password --region $REGION \
| docker login --username AWS --password-stdin $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com
docker tag myapp:1.0.0 $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/$REPO:1.0.0
docker push $ACCOUNT_ID.dkr.ecr.$REGION.amazonaws.com/$REPO:1.0.0
```
手順3以降と運用の章のコマンドも、この `AWS_DEFAULT_REGION` を設定した同じシェルで続けて実行する前提です。`get-login-password` で得られる認証トークンの有効期限は12時間です。CIから毎回pushする場合は、ジョブの冒頭でログインし直します。タグには `latest` を使わず版番号やコミットハッシュを付けておくと、タスク定義がどのイメージを指しているかを後から追えます。ECRの料金やライフサイクルポリシーは[Amazon ECR（AWS ECR）とは？料金・ECSとの違いとDockerイメージのpush手順](/tech/details/2667/)で解説しています。
### 手順3 タスク実行ロールの準備とタスク定義のCLI登録
FargateでECRのイメージを取得し、CloudWatch Logsへログを送るには、タスク実行ロール（ecsTaskExecutionRole）が必要です。このロールには管理ポリシー `AmazonECSTaskExecutionRolePolicy` を付けます。作成手順は公式の[Amazon ECS task execution IAM role](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task%5Fexecution%5FIAM%5Frole.html)にあります。ロールを用意したら、次のJSONを `taskdef.json` として保存します。
```
{
"family": "myapp",
"requiresCompatibilities": ["FARGATE"],
"networkMode": "awsvpc",
"cpu": "512",
"memory": "1024",
"executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
"runtimePlatform": { "cpuArchitecture": "X86_64", "operatingSystemFamily": "LINUX" },
"containerDefinitions": [
{
"name": "web",
"image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:1.0.0",
"essential": true,
"portMappings": [{ "containerPort": 80, "protocol": "tcp" }],
"logConfiguration": {
"logDriver": "awslogs",
"options": {
"awslogs-group": "/ecs/myapp",
"awslogs-region": "ap-northeast-1",
"awslogs-stream-prefix": "web"
}
}
}
]
}
```
```
aws logs create-log-group --log-group-name /ecs/myapp --region ap-northeast-1
aws ecs register-task-definition --cli-input-json file://taskdef.json --region ap-northeast-1
```
FargateではnetworkModeに `awsvpc` が必須で、cpu・memoryは文字列で指定します。cpuが512（0.5vCPU）ならmemoryは1〜4GBというように、指定できる組み合わせは[Amazon ECS task definition differences for Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-tasks-services.html)の表で決まっています。ロググループは事前に作るか、`awslogs-create-group` を有効にして実行ロールに作成権限を足します。awslogsドライバーの各オプションは公式の[Send Amazon ECS logs to CloudWatch](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/using%5Fawslogs.html)で確認できます。
### 手順4 クラスター・サービスの作成とタスクの起動確認
最後にクラスターを作り、タスク定義を指定してサービスを起動します。検証用としてパブリックIPを付け、セキュリティグループで80番を開けた状態を想定しています。
```
aws ecs create-cluster --cluster-name demo --region ap-northeast-1
aws ecs create-service \
--cluster demo \
--service-name myapp \
--task-definition myapp \
--desired-count 1 \
--launch-type FARGATE \
--network-configuration "awsvpcConfiguration={subnets=[subnet-0abc1234],securityGroups=[sg-0abc1234],assignPublicIp=ENABLED}" \
--region ap-northeast-1
# 起動状態と停止理由の確認（起動直後に落ちたタスクは STOPPED で絞る）
aws ecs list-tasks --cluster demo --service-name myapp --region ap-northeast-1
aws ecs list-tasks --cluster demo --service-name myapp --desired-status STOPPED --region ap-northeast-1
aws ecs describe-tasks --cluster demo --tasks <タスクARN> \
--query "tasks[0].{status:lastStatus,reason:stoppedReason}" --region ap-northeast-1
```
`lastStatus` が RUNNING になれば、タスクに付いたパブリックIPへブラウザでアクセスしてページが返ることを確かめられます。オプションの全体像はAWS CLIリファレンスの[create-service](https://docs.aws.amazon.com/cli/latest/reference/ecs/create-service.html)にあります。本番ではパブリックIPを付けず、プライベートサブネットに置いたタスクの前段にALBを立てます（設定は後述の運用の章）。検証が終わったら、課金を止めるために `desired-count` を0にしてからサービスとクラスターを削除します。
### docker composeからECSへ移すときの現行の選択肢と移行の注意
かつてはDocker Desktopの「ECSコンテキスト」で `docker compose up` を実行するだけでECSへデプロイできましたが、この統合はすでに退役しています。Docker公式の[Deprecated and retired Docker products and features](https://docs.docker.com/retired/)でも、ECSとAzure Container Instancesとの統合は非推奨となり、クラウド側のネイティブツールかサードパーティ製品を使うよう案内されています。古いブログの手順をなぞっても再現できないのはこのためです。
2026年10月時点で現実的な移し方は次の3つです。
- **compose.yamlを読み替えてタスク定義を手書きする**：1サービス1タスク定義を基本に、servicesの各コンテナをcontainerDefinitionsへ移す。同じタスクに残すコンテナ間のdepends\_onは `dependsOn` に移せるが、別タスク・別サービスの起動順は制御できないため接続のリトライで吸収する。DB等の同居コンテナはRDSなどのマネージドサービスへ切り出す。
- **ECS Express Modeで最短に動かす**：イメージとロール2つを渡すと、ALB・HTTPS・オートスケールまで自動で組まれる。詳細は[ECS Express Modeとは？使い方・料金・CloudFormation対応とApp Runner移行先を解説](/tech/details/9958/)を参照。
- **デプロイツールでタスク定義をコード管理する**：タスク定義とサービス定義をJSON/YAMLで持ち、差分デプロイする。[ecspressoとは｜ECSデプロイをコードで管理する仕組みと導入手順](/tech/details/13182/)がこの型にあたる。
composeで同じネットワークに並べていた複数コンテナを、そのまま1タスクへ詰め込むのは避けてください。WebとDBを同じタスクに入れると、Webを増やすたびにDBも増えてしまいます。
### ECSでDockerコンテナが起動しないときに多い原因と確認箇所
タスクがPENDINGからSTOPPEDへすぐ落ちる場合、`describe-tasks` の `stoppedReason` とコンテナの `reason` を見ると、原因はおおむね次のどれかに絞れます。
1. **CannotPullContainerError**：タスク実行ロールが無い、またはプライベートサブネットからECRへの経路（NATゲートウェイかVPCエンドポイント）が無い。パブリックサブネットなら `assignPublicIp=ENABLED` の付け忘れも疑う。
2. **exec format error**：arm64でビルドしたイメージをx86\_64のタスクで動かしている。手順1の `--platform` を付けて作り直すか、`runtimePlatform` をARM64に揃える。
3. **ResourceInitializationError（ログ関連）**：`awslogs-group` のロググループが存在しない。事前作成するか自動作成オプションを使う。
4. **Essential container exited**：アプリ自体が終了している。CloudWatch Logsでアプリのエラーを確認し、手元の `docker run` で同じ環境変数を渡して再現させる。
手元の `docker run` で動くのにECSだけで落ちるなら、まず1と3の設定（実行ロール・ECRへの経路・ロググループ）を疑います。1はイメージURIやタグの書き間違い、ECRにそのタグが無い場合にも出るため、`aws ecr describe-images --repository-name myapp` でタグの実在も確かめます。
## ECSの起動タイプとOS：4つの実行基盤の管理責任と選べるOS
ECSは「コンテナをどの計算資源の上で動かすか」を起動タイプ（キャパシティ）で選びます。オーケストレーション（ECS）は共通で、下回りの管理責任と選べるOSが変わります。
### Fargate・EC2・Managed Instances・ECS Anywhereの管理責任と課金対象
| 起動タイプ | インフラ管理 | 課金対象 | 向くケース |
| ----------------- | ------------ | ------------- | -------------- |
| Fargate | 不要（サーバーレス） | vCPU・メモリ（秒単位） | 運用を軽くしたい・変動負荷 |
| EC2 | 自分でインスタンス管理 | EC2インスタンス料金 | GPU・特殊構成・常時高負荷 |
| Managed Instances | AWSが選定・パッチ適用 | EC2料金＋型別の管理料 | EC2の柔軟性を管理レスで |
| ECS Anywhere | 自社サーバー（オンプレ） | 登録インスタンスの時間料金 | データを外に出せない処理 |
新規構成の第一候補はFargateです。サーバーやOSを意識せずに済み、タスクは最大32vCPU・244GB（Linux）まで取れます。EC2はインスタンス群を自分で用意する代わりに、インスタンスタイプやGPUを自由に選べます。
Managed Instancesは[2025年9月30日に提供が始まった](https://aws.amazon.com/about-aws/whats-new/2025/09/amazon-ecs-managed-instances/)中間案で、EC2の柔軟性を保ちながらインスタンスの選定・プロビジョニング・定期的なセキュリティパッチをAWSに任せます。EC2料金に加えて、インスタンスタイプごとに異なる管理料が秒単位でかかります。
### ECSで使えるOS：ECS最適化AMIとFargateの対応OS
EC2起動タイプでは、ECSエージェント入りのECS最適化AMIからインスタンスを起動します。公式の[Amazon ECS-optimized Linux AMIs](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-optimized%5FAMI.html)が推奨するのはAmazon Linux 2023版で、x86・arm64（Graviton）・GPU・Neuron（Inferentia/Trainium）の派生があります。Amazon Linux 2版は上流のAmazon Linux 2と同じ2026年6月30日にサポートが終わっており、まだ使っているクラスターは移行の対象です。
ほかにパッケージマネージャーを持たずコンテナ実行に絞った[Bottlerocket](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs-bottlerocket.html)版と、Windows Server版のAMIがあります。Fargateで選べるのはLinux（x86\_64・ARM64）と、Windows Server 2019・2022のFull／Core（x86\_64のみ・1vCPU以上）です。Linuxコンテナはホストのカーネルだけを使うので、イメージの中身はUbuntuでもDebianでも動きます。
## ECSとEC2の違い：コンテナ管理サービスと仮想マシンというレイヤー差
「ECSとEC2の違い」は同じ土俵の比較ではありません。EC2は仮想マシン（計算資源）そのもの、ECSはコンテナを束ねる管理サービスで、レイヤーが異なります。ECSのEC2起動タイプでは「ECSが管理するコンテナ」を「自分で用意したEC2インスタンスの上」で動かすため、両者を同時に使うことになります。この構成でもOSのパッチ適用は利用者の担当で、Fargateを選べばEC2インスタンスは表に出てきません。
EC2に直接Dockerを入れて `docker run` で動かす構成と比べると、ECSを挟む利点は「落ちたコンテナの自動復旧」「台数の維持」「ローリング更新」を自前のスクリプトなしで得られる点です。1台のサーバーで1コンテナを動かすだけなら素のEC2でも足りますが、2台以上に分散させる時点でECSを使った方が運用は軽くなります。
## ECSとEKSの違い：Kubernetes資産・移植性・制御プレーン料金での判断
ECSとEKS（Elastic Kubernetes Service）は、どちらもAWSのコンテナオーケストレーションですが、EKSはKubernetesをそのまま動かすマネージドサービス、ECSはAWS独自方式という根本差があります。EKSはKubernetesの標準API・マニフェスト・Helmなどのエコシステムをそのまま使えるため、オンプレや他クラウドと運用を揃えやすくなります。
| 観点 | ECS | EKS |
| ---------- | ----------- | ------------------------ |
| 方式 | AWS独自 | Kubernetes準拠 |
| 制御プレーン料金 | 無料 | 0.10ドル毎時（延長サポート中は0.60ドル） |
| 定義ファイル | タスク定義（JSON） | マニフェスト（YAML） |
| 制御プレーンの版上げ | 不要 | Kubernetesの版を定期的に上げる |
| 移植性 | AWS前提 | マルチクラウド向き |
[Amazon EKS pricing](https://aws.amazon.com/eks/pricing/)によると、EKSはクラスターを立てるだけで制御プレーンに0.10ドル毎時（月約73ドル）がかかり、Kubernetesの版が14か月の標準サポートを過ぎると延長サポート料0.50ドルが加わって0.60ドル毎時になります。ECSの制御プレーンにはKubernetesのような版が無いため、この固定費と版上げの作業がどちらもかかりません。
判断はシンプルで、チームにKubernetesの資産・知見があり将来マルチクラウドを見据えるならEKS、AWSで完結し運用を軽く保ちたいならECSです。Dockerイメージ自体はどちらでも同じものを使えるので、ECSで始めてKubernetesが必要になった段階でEKSへ移すこともできます。EKSのノード形態と料金は[Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説](/tech/details/15437/)で詳しく扱っています。
## ECSの料金：制御プレーンは無料、課金は起動タイプと周辺リソース次第
ECSというサービスの管理機能自体には追加料金がかかりません（[Amazon ECS pricing](https://aws.amazon.com/ecs/pricing/)）。支払うのは、選んだ起動タイプが消費する実リソース分です。
### 東京リージョンのFargate単価と0.5vCPU・1GBの月額試算
FargateはリクエストしたvCPUとメモリの量に対し、イメージのpull開始からタスク終了まで秒単位で課金され、最低課金時間はLinuxが1分、Windowsが5分です。AWSのPrice List API（2026年10月19日版）で取得した東京リージョンの単価は次のとおりです。
| OS・CPU | vCPU毎時 | メモリGB毎時 | 0.5vCPU・1GBの月額（730時間） |
| --------- | --------------------- | ----------- | --------------------- |
| Linux・x86 | 0.05056ドル | 0.00553ドル | 約22.5ドル |
| Linux・ARM | 0.04045ドル | 0.00442ドル | 約18.0ドル |
| Windows | 0.058144ドル＋OS料0.046ドル | 0.0063595ドル | 1vCPU以上のため対象外 |
この金額はタスク1つを常時稼働させた場合で、冗長化のために2タスク並べれば倍になります。実際の請求にはALB（1時間あたりの固定料金＋LCU課金）、NATゲートウェイ、CloudWatch Logsの取り込み、ECRのストレージが加わり、小規模なWeb APIではFargate本体よりALBとNATの方が高くつくことも珍しくありません。表の単価は[Price List APIの東京リージョンのJSON](https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonECS/current/ap-northeast-1/index.json)から取り、最低課金時間などの条件は[AWS Fargate pricing](https://aws.amazon.com/fargate/pricing/)で確認できます。
### EC2・Managed Instances・ECS Anywhereの課金とFargate Spot
EC2起動タイプならEC2インスタンスやEBS・パブリックIPv4の通常料金だけです。Managed InstancesはEC2料金に管理料が乗り、同じPrice ListのJSONでは東京の m7i.large が0.015624ドル毎時、m7g.large が0.012648ドル毎時です（`ECS-Managed-Instances:<型>-management-hours` の項目）。ECS Anywhereは登録したオンプレのインスタンス1台あたり0.01025ドル毎時かかります。
コストを抑えるなら、中断されても困らないステートレスな処理で[Fargate Spot](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-capacity-providers.html)（オンデマンド比で最大70%割引）を使います。Fargate SpotはAWSの余剰キャパシティを使うため、回収時は2分前の通知のあとタスクが停止します。Webのように落とせない処理は、通常のFargateとSpotをキャパシティプロバイダー戦略で混ぜて、最低台数をオンデマンド側に置きます。
## ECSの運用：ALB連携・オートスケール・デプロイ・監視の設定
手順4のサービスは、パブリックIPに直接アクセスする検証用の形です。本番で常駐させるには、前段のロードバランサー、負荷に応じた台数調整、失敗したデプロイの自動ロールバック、監視の4つを足します。ALB・証明書・ターゲットグループの作成をECSに任せ、1台のALBを複数サービスで共有する方法は[Amazon ECS Gatewayとは：共有ALBでECSサービスを公開する手順とCLI例](https://www.issoh.co.jp/tech/details/19025/)で手順を解説しています。
### ALB（ELB）との連携：ターゲットタイプipとヘルスチェックの調整
Fargateのように `awsvpc` ネットワークモードで動くタスクは、EC2インスタンスではなくENIに紐づきます。そのため公式の[Use an Application Load Balancer for Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/alb.html)のとおり、ターゲットグループは `instance` ではなく `ip` タイプで作る必要があります。ターゲットグループはサービスごとに1つ用意し、複数サービスで共有しないでください。
```
aws ecs create-service \
--cluster demo --service-name myapp --task-definition myapp \
--desired-count 2 --launch-type FARGATE \
--load-balancers "targetGroupArn=<ターゲットグループARN>,containerName=web,containerPort=80" \
--health-check-grace-period-seconds 60 \
--network-configuration "awsvpcConfiguration={subnets=[subnet-0abc1234,subnet-0def5678],securityGroups=[sg-0abc1234],assignPublicIp=DISABLED}"
```
ALBのヘルスチェックは既定で30秒間隔、回復の判定に5回連続の成功が要るため、一度不健全になったタスクが復帰と判定されるまで150秒かかります。起動が10秒以内に安定するアプリなら、[公式の最適化ガイド](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/load-balancer-healthcheck.html)どおり間隔5秒・閾値2回に縮めるとデプロイが速くなります。逆に起動の遅いJavaアプリなどは、`--health-check-grace-period-seconds` で起動直後のヘルスチェック失敗を無視させないと、立ち上がる前に停止と再起動を繰り返します。ヘルスチェックが失敗するときの理由コードの読み方は[ELBヘルスチェックの設定と失敗原因の調べ方｜ALB・NLBの既定値と理由コード](/tech/details/18067/)にまとめています。
### サービスオートスケーリング：CPU使用率のターゲット追跡設定
ECSのオートスケールは、Application Auto Scalingがサービスの希望タスク数を増減させる仕組みです。[公式](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/service-auto-scaling.html)が挙げる方式はターゲット追跡・ステップ・スケジュール・予測・SQSキューの滞留数の5つで、最初はCPU使用率を目標値に保つターゲット追跡で足ります。
```
aws application-autoscaling register-scalable-target \
--service-namespace ecs --scalable-dimension ecs:service:DesiredCount \
--resource-id service/demo/myapp --min-capacity 2 --max-capacity 10
aws application-autoscaling put-scaling-policy \
--service-namespace ecs --scalable-dimension ecs:service:DesiredCount \
--resource-id service/demo/myapp --policy-name cpu60 \
--policy-type TargetTrackingScaling \
--target-tracking-scaling-policy-configuration \
'{"TargetValue":60.0,"PredefinedMetricSpecification":{"PredefinedMetricType":"ECSServiceAverageCPUUtilization"}}'
```
注意点は3つあります。オートスケールを有効にすると、手で設定した希望タスク数も上書きされます。また、デプロイ中はスケールインだけが止まり、スケールアウトは続きます。夜間にタスクを0まで落とすなら最小値を0にできますが、タスクが0台になるとCPU使用率のメトリクスも出なくなるため、上のCPUターゲット追跡だけでは0台から戻れません。朝に台数を戻すスケジュールアクションか、SQSキューの滞留数のようにタスクの外で発生するメトリクスを併用します。
### デプロイ方式とサーキットブレーカー：失敗判定と自動ロールバックの設定
サービスの更新方式は、既定のローリング更新に加え、2025年7月にECSネイティブのBlue/Green、同年10月にリニアとカナリアが加わりました（[開発者ガイドの更新履歴](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/document%5Fhistory.html)）。いずれもCodeDeployを使わずECSだけで切り替えられます。
ローリング更新では、デプロイサーキットブレーカーを必ず有効にします。新しいタスクがRUNNINGにならない、またはヘルスチェックに落ち続けると失敗と判定し、直近の完了済みデプロイへ自動で戻します。[公式](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/deployment-circuit-breaker.html)の既定の閾値は希望タスク数の50%で、最小3・最大200に丸められます。
```
aws ecs update-service --cluster demo --service myapp \
--deployment-configuration "deploymentCircuitBreaker={enable=true,rollback=true},minimumHealthyPercent=100,maximumPercent=200"
```
`minimumHealthyPercent=100`・`maximumPercent=200` にすると、新しいタスクを先に立ててから古いタスクを止めるため、台数が減る時間がありません。ローリング更新の設定値の考え方は[ローリングアップデートとは？仕組みとKubernetes・ECSの設定値・採用判断を解説](/tech/details/16189/)、本番トラフィックを一気に切り替えたい場合は[ECSネイティブBlue/Greenデプロイの設定手順](/tech/details/7858/)を参照してください。
### 監視とログ：Container InsightsとCloudWatch Logs
ECSは1分間隔でサービスのCPU・メモリ使用率をCloudWatchへ送ります。タスクやコンテナ単位の値まで見たいなら、クラスターでContainer Insightsの拡張オブザーバビリティを有効にします。[公式](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cloudwatch-container-insights.html)によると、2026年10月1日から `RunningTaskCount` メトリクスは課金されなくなりましたが、それ以外はカスタムメトリクスとして課金されます。
```
aws ecs update-cluster-settings --cluster demo \
--settings name=containerInsights,value=enhanced
```
アプリのログは手順3のawslogsでCloudWatch Logsへ送り、デプロイの失敗はEventBridgeの `SERVICE_DEPLOYMENT_FAILED` イベントで通知を受けると気づき漏れがありません。稼働中のコンテナに入って調べる場合はECS Execを使います。Fargateでの有効化手順や停止前の待機時間などは[AWS Fargateとは？ECSのEC2起動タイプとの違い・料金・運用をわかりやすく解説](/tech/details/3304/)の運用の章で扱っています。
## Lambda・Express Modeとの選び分けとECSを採用しない場面
AWSでサーバーレスにコンテナを動かす標準解はECS×Fargateです。Express ModeはそのECS×Fargate構成を自動で組む入口で、関数単位で動かすならLambdaが候補になります。要件から逆引きすると次のとおりです。
| 要件・状況 | 第一候補 |
| ------------------------ | -------------------------- |
| AWS完結・省運用・標準的なDockerコンテナ | ECS（Fargate） |
| 単一のWebアプリ・APIを最短で公開したい | ECS Express Mode |
| GPU・特殊インスタンス・常時高負荷の費用削減 | ECS（EC2・Managed Instances） |
| Kubernetes資産あり・マルチクラウド前提 | EKS |
| イベント駆動・短時間処理・ゼロスケール重視 | Lambda |
Lambdaはイベント駆動の関数実行に特化し、通常のオンデマンド実行ならリクエストのない間は課金されません（Provisioned Concurrencyを設定した分は待機中も課金されます）。ただし標準の関数は1回の実行が最大900秒（15分）で、この上限は公式の[Configure Lambda function timeout](https://docs.aws.amazon.com/lambda/latest/dg/configuration-timeout.html)に明記されています。仕組みと料金は[AWS Lambdaとは？仕組み・料金体系とコールドスタート対策・採用判断を実装者目線で解説](/tech/details/15407/)を参照してください。
App Runnerは公式の[AWS App Runner availability change](https://docs.aws.amazon.com/apprunner/latest/dg/apprunner-availability-change.html)のとおり2026年4月30日から新規顧客の受付を停止し、推奨の移行先はECS Express Modeです。Express Modeはコンテナイメージ・タスク実行ロール・インフラストラクチャロールを渡すだけで、Fargate上のサービス、HTTPS付きのALB、オートスケールまでを組みます。[公式](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/express-service-overview.html)によると機能自体に追加料金はなく、作られたFargate・ALB・CloudWatchの分だけを支払います。
ECSを選ぶべきでない場面もはっきりしています。既存のKubernetesマニフェストやHelmチャートを流用したい、他クラウドと運用を統一したいならEKSが妥当です。1日数回・数秒で終わる処理のためだけに常駐サービスを立てるのは割高で、Lambdaで足ります。社内の数人が使う小さなツールのように0.25〜0.5vCPUのタスク1つで足りる用途では、ALBとNATゲートウェイの固定費がFargate本体を上回りやすいため、タスクサイズと周辺構成を見積もってから決めます。ECS・EKS・Fargate・Lambdaを並べた詳しい比較は[AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順](/tech/details/17869/)にあります。
VPC・ALB・IAMロールの設計から、Dockerイメージのビルドパイプライン、ECSへの自動デプロイまでを一式で組みたい場合は、一創の[インフラ構築（AWS・Google Cloud・Azure）](/service/system/aws/)でご相談いただけます。既存のEC2上のDocker運用をECSへ移す設計も対象です。
## よくある質問：ECSとDockerの関係・料金・EKSとの選び方
### ECSを使うのにDockerの知識は必要ですか？
必要です。ECSが動かすのはOCI形式のコンテナイメージで、実務ではDockerfileを書いて `docker build` で作るのが一般的です。ECSは「できたイメージをどこで何個動かすか」を管理する層なので、イメージの作り方やポート・環境変数の渡し方はDockerの知識がそのまま要ります。
### ECSとFargateの違いは何ですか？
ECSはコンテナを束ねて管理するオーケストレーション本体、Fargateはそのコンテナを動かす起動タイプ（サーバーレスな計算資源）です。対立する別物ではなく、ECSの中でFargateを選ぶという包含関係です。FargateはEKSからも使えるため、Fargate＝ECS専用ではありません。
### ECSの料金はいくらかかりますか？
ECSの管理機能自体は無料です。課金されるのは起動タイプの実リソースで、東京のFargate（Linux・x86）はvCPUが0.05056ドル毎時、メモリが0.00553ドル毎GB時です。0.5vCPU・1GBのタスクを1つ常時動かすと月約22.5ドルで、これにALBやNATゲートウェイ、ログの料金が加わります。
### ECSとEKSはどちらを選ぶべきですか？
AWSで完結し運用を軽く保ちたいならECS、Kubernetesの資産・知見があり将来マルチクラウドを見据えるならEKSです。EKSは制御プレーンに0.10ドル毎時（約73ドル毎月・1クラスターあたり）の固定費がかかり、延長サポート期間の版では0.60ドル毎時に上がります。
### docker-compose.ymlはそのままECSで使えますか？
そのままは使えません。Docker DesktopのECS統合（`docker compose up` でECSへデプロイする機能）は退役しており、composeファイルの内容をタスク定義へ読み替える必要があります。servicesの各コンテナをcontainerDefinitionsに移し、ポートはportMappings、環境変数はenvironment、DBなどの状態を持つコンテナはRDS等へ切り出すのが基本です。
## 関連記事
- [AWS Fargateとは？ECSのEC2起動タイプとの違い・料金・運用をわかりやすく解説【2026年版】](/tech/details/3304/)
- [Amazon ECR（AWS ECR）とは？料金・ECSとの違いとDockerイメージのpush手順【2026年10月】](/tech/details/2667/)
- [AWSのコンテナサービス比較｜ECS・EKS・Fargate・Lambdaの選び方とExpress Modeで動かす手順](/tech/details/17869/)
- [ECSネイティブBlue/Greenデプロイの設定手順｜ライフサイクルフック・ロールバック・CodeDeploy移行【2026年版】](/tech/details/7858/)
- [ECS Express Modeとは？使い方・料金・CloudFormation対応とApp Runner移行先を解説【2026年版】](/tech/details/9958/)
---
出典: [AWS ECSとは？Dockerコンテナを動かす手順と起動タイプ・料金・EKSとの違い【2026年10月】]()（株式会社一創）