Amazon ECS入門 Dockerコンテナをクラウドで動かすための設計パターンとオンプレ移行ガイド

オンプレでDockerを使い始めたはいいものの、「本番環境にどう載せればいいのか」で詰まったことはないでしょうか。
コンテナそのものの技術は理解できても、運用・スケーリング・監視まで含めた設計になると途端に壁が高くなります。

この記事では、Amazon ECS（Elastic Container Service）について、オンプレのDockerコンテナ運用を経験したエンジニアにもわかりやすく解説します。
ECSの基本概念から起動タイプの選び方、料金感、実務でよく使うパターンまで、現場目線で丁寧に説明します。

なぜオンプレのDockerをそのまま本番に使わないのか

オンプレでDockerを動かしていると、だいたいこんな悩みが出てきます。

・スケーリングが手動: アクセスが増えたらコンテナを手で増やす必要がある
・サーバーが死んだら終わり: ホストが落ちるとコンテナごと消える
・デプロイが煩雑: SSHでログインしてdocker pullしてrestartして…と手順が長い
・監視が自前: ヘルスチェックやログ収集を自分で組む必要がある

Amazon ECSはこれらをすべてAWSのマネージドサービスとして引き受けてくれるオーケストレーターです。
Kubernetesほど複雑ではなく、AWSとの統合が深いため、クラウド移行の最初のコンテナ基盤として非常に選ばれやすいサービスです。

ECSの基本構造を理解する

ECSには3つの主要概念があります。最初にここを押さえておくと全体像がすっきりします。

1. クラスター（Cluster）

コンテナを動かす「場所」の論理的な単位です。
オンプレで言えば「Dockerが動くサーバー群」に相当します。
Fargateを使う場合はサーバーを意識しなくてよいため、クラスターは「名前空間」程度の感覚になります。

2. タスク定義（Task Definition）

コンテナの「設計書」です。
使うDockerイメージ・CPUとメモリのサイズ・環境変数・ログ設定などをJSONで定義します。
オンプレの docker-compose.yml に近い概念ですが、バージョン管理が可能で、デプロイのロールバックも容易です。

# タスク定義の主要フィールド（JSON概略）
{
  "family": "myapp",
  "cpu": "256",
  "memory": "512",
  "networkMode": "awsvpc",
  "containerDefinitions": [
    {
      "name": "myapp-container",
      "image": "123456789.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest",
      "portMappings": [{"containerPort": 8080}],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/myapp",
          "awslogs-region": "ap-northeast-1"
        }
      }
    }
  ]
}

3. サービス（Service）

「タスクを常に指定した数だけ動かし続ける」仕組みです。
オンプレでsystemdやsupervisordでデーモンを管理するイメージに近いですが、自動スケーリング・ヘルスチェック失敗時の自動再起動・ロードバランサーへの自動登録まで面倒を見てくれます。

FargateとEC2起動タイプの使い分け

ECSには2つの起動タイプがあります。ここの選択が最も重要なので、しっかり比較します。

まず迷ったらFargateを選ぶのが現場での正解です。
EC2インスタンスのパッチ管理・スケールアウト時のキャパシティ管理・ECSエージェントの更新など、EC2起動タイプは運用コストが跳ね上がります。
よほどのコスト最適化が必要なケースや、GPUワークロードでなければFargate一択です。

料金の仕組み（コスト感覚を把握する）

Fargateの料金は vCPU時間 + メモリ時間の合計 で計算されます（2026年4月時点、東京リージョン ap-northeast-1）。

・vCPU: 約$0.04048 / vCPU / 時間
・メモリ: 約$0.004445 / GB / 時間

例として、0.25 vCPU・0.5GBのタスクを1か月（720時間）動かし続けた場合：

# 月額コスト概算（Fargate、東京リージョン、2026年4月時点）
vCPU費用  : 0.25 vCPU x $0.04048 x 720h = $7.29
メモリ費用: 0.5 GB  x $0.004445 x 720h = $1.60
月額合計  : 約 $8.89（約1,300円）

小規模なWebアプリなら月1,000〜3,000円程度から始められます。
ただし、ロードバランサー（ALB）やNAT Gatewayを組み合わせると、そちらのコストがかさむ点に注意が必要です。
ALBは起動しているだけで月約$20前後かかるため、開発環境では停止するか、複数サービスで共有する設計が鉄則です。

応用・実務Tips

【重要】ECRとの組み合わせ

コンテナイメージはAWSのプライベートレジストリ「Amazon ECR（Elastic Container Registry）」に置くのが基本です。
Docker Hubと違いIAMで認証管理でき、イメージのスキャン機能でセキュリティ管理も一元化できます。

# AWS CLIでECRにDockerイメージをプッシュする手順
# 1. ECRにログイン（東京リージョンの場合）
aws ecr get-login-password --region ap-northeast-1 |   docker login --username AWS   --password-stdin 123456789.dkr.ecr.ap-northeast-1.amazonaws.com

# 2. イメージにタグ付け
docker tag myapp:latest   123456789.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest

# 3. ECRにプッシュ
docker push 123456789.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest

ALBとサービスの連携で自動ロードバランシング

ECSサービスにALB（Application Load Balancer）を紐付けると、新しいタスクが起動した瞬間に自動でターゲットグループに登録されます。
オンプレでnginxやHAProxyのコンフィグを手動で書き換えていた作業がゼロになります。

CloudWatch Logsへのログ転送

タスク定義に awslogs ドライバーを設定するだけで、コンテナの標準出力がAmazon CloudWatch Logsに自動転送されます。
サーバーにSSHしてログファイルを追いかける運用から解放されます。

Secrets Managerで環境変数を安全に管理

DBのパスワードやAPIキーなどの機密情報は、タスク定義にそのまま書くのではなく、AWS Secrets ManagerまたはAWS Systems Manager Parameter Storeから動的に注入するパターンが推奨されます。

クラウド上でのLinuxサーバー構築やDockerの基礎については、姉妹サイトLinuxMaster.JPでも詳しく解説しています。

よくあるトラブルと対処法

タスクが起動してすぐ落ちる（EXIT CODE 1）

最も多いのは、環境変数の設定ミスやDockerイメージの不具合です。
CloudWatch Logsで標準エラー出力を確認するのが最短ルートです。
ECSコンソール → クラスター → タスク → ログタブで確認できます。

タスクのIPへの疎通が取れない

ECSのFargateタスクは awsvpc ネットワークモードを使います。
タスクのセキュリティグループでALBからのインバウンドを許可しているか確認してください。
ALBのセキュリティグループIDをソースに指定するのが正解です。直接IPレンジを指定すると管理が崩れます。

デプロイが終わらない（ローリングアップデートが止まる）

新しいタスクが起動してもALBのヘルスチェックを通過しない場合、デプロイが止まります。
・ヘルスチェックのパス（例: /health）がアプリに実装されているか
・ヘルスチェックのタイムアウト・猶予期間の設定が短すぎないか（デフォルト30秒は短い場合が多い）
の2点を確認するのが鉄板の手順です。

本記事のまとめ

Amazon ECSは、オンプレのDocker運用の「手作業の多さ」を解消するために設計されたサービスです。
Fargateを選べばサーバー管理から解放され、ALBとの連携でスケーリングも自動化できます。
まずはFargate＋CloudWatch Logs＋ECRの3点セットで始めてみてください。最初の一歩としては十分すぎる構成です。