Amazon ECS 完全ガイド 2026

初心者から実務者向けの包括的解説

Amazon ECS（Elastic Container Service） は、AWS ネイティブのフルマネージドコンテナオーケストレーションサービス です。Docker コンテナを EC2（セルフマネージド）または Fargate（サーバーレス）上で実行・スケーリング・管理します。Kubernetes（EKS）より学習コストが低く、AWS サービスとの統合が深いのが特徴です。本ドキュメントは、ECS の概念・アーキテクチャ・運用・最新動向を体系的に解説する包括的ガイドです。

ドキュメントの目的

本ガイドは以下を対象としています。

初心者向け： ECS とは何か、なぜ必要かを学びたい方
開発者向け： コンテナアプリをデプロイしたい方
SRE / インフラ向け： サービスディスカバリー・Auto Scaling・本番運用を構築したい方
意思決定者向け： ECS vs EKS vs Fargate vs Lambda の使い分け・投資判断

2026 年の ECS エコシステム

ECS Managed Instances：セルフマネージド EC2 の管理負担を軽減（2024-2025 GA）
Service Connect GA：ECS ネイティブのサービスメッシュ機能が一般提供
Fargate Spot 拡張：より多くのリージョンで利用可能、最大 70% 割引
AI ワークロード対応：Inferentia / Trainium チップ対応の拡大
Capacity Providers：EC2 / Spot / On-Demand の最適配分
Terraform / CDK / Pulumi：Infrastructure as Code による管理の標準化
Container Insights の深化：CloudWatch Logs の統合、ECS Exec による接続

定義

AWS 公式による定義：

“Amazon ECS is a fully managed container orchestration service that helps you easily run, scale, and secure Docker containers.”

複数の起動タイプ（EC2 / Fargate / ECS Anywhere）をサポートし、リアルタイムなスケーリング・ローリングアップデート・サービスディスカバリーを提供します。

概要
ECS が解決する課題
主な特徴
アーキテクチャ
起動タイプ（EC2 / Fargate / ECS Anywhere）
Fargate 詳細
主要ユースケース
Task Definition
ネットワーキング
サービス更新戦略
オートスケーリング
サービス検出
セキュリティ
モニタリング
ECS vs EKS vs Fargate vs Lambda
ECS Anywhere
他の類似ツールとの比較
クライアント・ツール・エコシステム
ベストプラクティス
トラブルシューティング
2025-2026 最新動向
学習リソース
実装例・活用シーン
導入ロードマップ
実装チェックリスト
まとめ
参考文献

概要

初心者向けメモ： ECS は「コンテナを実行する」サービスです。開発者が Docker イメージを ECR（Elastic Container Registry）にプッシュし、ECS はそのイメージをクラスターで実行・スケーリングします。「Kubernetes より簡単で、AWS ネイティブ統合が深い」のが最大の特徴です。

Amazon ECS は、Docker コンテナのオーケストレーション（スケジューリング・スケーリング・管理）を自動化するフルマネージドサービスです。公式ドキュメント（ECS Developer Guide）に基づくと、単なるコンテナ実行エンジンではなく、本番グレードの運用基盤 として機能します。

ECS の位置づけ

【図1】AWS コンテナサービスの階層：

graph TD
    App[アプリケーション]
    
    subgraph Abstraction["抽象化レベル"]
        Lambda["Lambda<br/>(最高抽象化<br/>コード実行のみ)"]
        AppRunner["App Runner<br/>(高抽象化<br/>Dockerfile指定)"]
        Fargate["Fargate<br/>(中抽象化<br/>タスク定義)"]
        ECS["ECS<br/>(低抽象化<br/>完全制御)"]
        EKS["EKS<br/>Kubernetes<br/>(最低抽象化<br/>フル拡張性)"]
    end
    
    App --> Lambda
    App --> AppRunner
    App --> Fargate
    App --> ECS
    App --> EKS

ECS が解決する課題

課題	ECS の解決方法
コンテナの手動デプロイ	タスク定義で自動スケジューリング、ローリングアップデート
インフラ管理の複雑さ	Fargate でサーバーレス化、EC2 の管理を最小化
サービス間通信	Service Connect（ネイティブメッシュ）、Cloud Map によるサービスディスカバリー
本番環境のスケーリング	Target Tracking Auto Scaling、Capacity Providers による自動最適化
デプロイメント中のダウンタイム	Blue/Green デプロイ、Deployment Circuit Breaker による自動ロールバック
コンテナログ管理	CloudWatch Logs への自動ロギング、Container Insights による可視化
セキュリティ管理	IAM Task Role、Secrets Manager 統合、ECR 脆弱性スキャン

主な特徴

特徴	説明
完全マネージド	クラスター管理・パッチ・スケーリングの自動化（Fargate は完全サーバーレス）
複数起動タイプ	EC2（セルフマネージド）/ Fargate（サーバーレス）/ ECS Anywhere（オンプレ対応）
AWS 深い統合	ALB / NLB ターゲットグループ、CloudWatch Insights、IAM タスクロール、Secrets Manager
ゼロダウンタイムデプロイ	Blue/Green デプロイ、ローリングアップデート、自動ロールバック
Auto Scaling	Service Auto Scaling、Cluster Auto Scaling、Capacity Providers による多次元スケーリング
サービスディスカバリー	Service Connect（メッシュ）、Cloud Map（DNS）による自動検出
コスト最適化	Fargate Spot（最大 70% 割引）、Capacity Providers による ON/Spot 混合
セキュリティ	Task IAM Role、Execution Role、Secrets 暗号化、ECR vulnerability scanning
モニタリング・ロギング	Container Insights、CloudWatch Logs、Application Signals（トレース）
拡張性	Terraform / CDK / Copilot CLI による IaC、REST API による自動化

アーキテクチャ

初心者向けメモ： ECS は「クラスター」「タスク定義」「タスク」「サービス」の 4 層で構成されます。Docker で例えるなら、クラスター = Docker ホスト群、タスク定義 = docker-compose.yml、タスク = docker run の実行インスタンスです。

【図2】ECS の 4 層アーキテクチャ：

graph TD
    subgraph Cluster["ECS クラスター（論理的なグループ）"]
        EC2Inst["EC2 インスタンス<br/>（Container Instance）"]
        FargateServ["Fargate<br/>（サーバーレス）"]
    end
    
    subgraph Definition["Task Definition<br/>（設定テンプレート）"]
        Container["コンテナ定義<br/>（イメージ / CPU / メモリ）"]
        Volume["ボリューム定義"]
        Logging["ロギング設定"]
    end
    
    subgraph Service["Service<br/>（常時稼働管理）"]
        ASG["Auto Scaling"]
        LB["Load Balancer統合"]
        Discover["Service Discovery"]
    end
    
    subgraph Task["Task<br/>（実行インスタンス）"]
        Running["実行中のコンテナ"]
    end
    
    Definition -->|instan tiate| Task
    Cluster -->|host| Task
    Service -->|manage| Task
    Service -->|update| Definition

コアコンポーネント

1. クラスター（Cluster）

クラスターは、タスクとサービスの論理的なグループ です。

Cluster:
  ├─ 名前: my-cluster
  ├─ リージョン: ap-northeast-1
  ├─ タスク: 100 個実行中
  ├─ サービス: 5 個
  └─ Container Insights: 有効

起動タイプ別の構成：

起動タイプ	ノード管理	クラスター例
EC2	インスタンスを手動 / Auto Scaling Group で管理	Cluster に EC2 インスタンスを登録
Fargate	AWS が管理（ユーザーは見えない）	クラスター作成のみ、インスタンス管理不要
ECS Anywhere	オンプレ / VPC 外のサーバーを登録	外部ホストをクラスター「メンバー」として扱う

Cluster Auto Scaling / Capacity Providers:

Cluster Auto Scaling:
  ├─ EC2 起動タイプで Auto Scaling Group のスケーリングを自動化
  ├─ Target Capacity: 80% を目標に EC2 インスタンスを追加 / 削除
  └─ Drain: 既存タスクを他のノードに移行してから削除

2. Task Definition（タスク定義）

タスク定義は、Docker Compose 相当の設定テンプレート で、コンテナを実行するための設定を JSON で記述します。

必須フィールド：

フィールド	説明
family	タスク定義の名前（バージョン管理有り、例：`my-app:1`, `:2`, …）
containerDefinitions	コンテナの詳細設定（イメージ、ポート、環境変数等）
requiresCompatibilities	対応する起動タイプ（`EC2`, `FARGATE`, `EXTERNAL`）
networkMode	ネットワークドライバー（`awsvpc`, `bridge`, `host`）
cpu / memory	Fargate で必須（`256`, `512`, `1024` 等）
executionRoleArn	ECS エージェントが ECR / CloudWatch Logs にアクセス時の権限
taskRoleArn	タスク内のコンテナが AWS API を実行するときの権限

コンテナ定義の主要設定：

{
  "name": "web",
  "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1.2.3",
  "essential": true,
  "portMappings": [
    {"containerPort": 8080, "hostPort": 8080, "protocol": "tcp"}
  ],
  "environment": [
    {"name": "NODE_ENV", "value": "production"}
  ],
  "secrets": [
    {
      "name": "DB_PASSWORD",
      "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:prod/db/password"
    }
  ],
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/my-app",
      "awslogs-region": "ap-northeast-1",
      "awslogs-stream-prefix": "ecs"
    }
  },
  "healthCheck": {
    "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
    "interval": 30,
    "timeout": 5,
    "retries": 3,
    "startPeriod": 60
  }
}

3. Task（タスク）

タスクは、タスク定義を実行した具体的なインスタンス です。

Task:
  ├─ Task ID: arn:aws:ecs:ap-northeast-1:123456789012:task/my-cluster/abc123
  ├─ Task Definition: my-app:5
  ├─ Launch Type: FARGATE
  ├─ Status: RUNNING
  ├─ IP: 10.0.1.50（Fargate / awsvpc の場合）
  ├─ Created: 2026-04-26T10:30:00Z
  └─ CPU / Memory: 512 vCPU / 1024 MB

タスクの種類：

種類	用途	特性
Service 内のタスク	Webサーバー等、常時稼働の役割	終了後は自動再起動
スタンドアロンタスク	バッチ処理、一度限りのジョブ	完了後は停止
Scheduled Task	定期実行（CloudWatch Events で起動）	定期的にスケジュール実行

4. Service（サービス）

サービスは、指定したタスク数（desired count）を常時維持 し、スケーリング・デプロイ・サービスディスカバリーを管理します。

Service:
  ├─ 名前: my-web-service
  ├─ タスク定義: my-app:5
  ├─ 起動タイプ: FARGATE
  ├─ Desired Count: 3（常に 3 タスクを稼働）
  ├─ Running Count: 3
  ├─ Pending Count: 0
  ├─ Load Balancer: ALB/TargetGroup を自動登録
  ├─ Auto Scaling: CPU 60% で最大 10 タスクまでスケールアウト
  ├─ Deployment Strategy: Rolling（minimumHealthyPercent: 100, maximumPercent: 200）
  └─ Service Discovery: Cloud Map / Service Connect で DNS 登録

起動タイプ

初心者向けメモ： 「どこでコンテナを実行するか」で 3 つの選択肢があります。新規は Fargate が推奨、コスト最適化が必要なら EC2、既存インフラなら ECS Anywhere です。

1. Fargate（サーバーレス）

AWS がインフラを完全管理し、ユーザーはタスク定義を指定するだけ。

特徴：

✅ インフラ管理不要（EC2 インスタンス管理不要）
✅ 秒単位の課金（実行時間のみ）
✅ セキュリティが強化（各タスクが独立した実行環境）
❌ カスタマイズが限定的（GPU なし、ボリュームタイプ限定）
❌ EC2 より割高（ただし小規模 / 変動ワークロードには割安）

推奨ユースケース：

新規アプリケーション
トラフィックが変動するアプリ（スパイク対応）
マイクロサービス個別スケーリング

料金（US East 1, 2026）：

CPU: $0.04048 / vCPU / 時
メモリ: $0.004445 / GB / 時
例: 0.5 vCPU + 1 GB × 24h = $0.968 / 日

2. EC2（セルフマネージド）

ユーザーが EC2 インスタンスをクラスターに登録し、ECS がタスクをスケジュールします。

特徴：

✅ コスト最適化（EC2 On-Demand / Spot 混合）
✅ 完全にカスタマイズ可能（GPU、大容量ストレージ）
✅ 大規模ワークロード向け
❌ インフラ管理の負担（AMI 更新、パッチ、キャパシティプランニング）
❌ 起動遅延（インスタンス起動 1-3 分）

推奨ユースケース：

大規模本番環境
GPU / 特殊ハードウェアが必要
コスト最適化が重要

料金：

EC2 インスタンス料金のみ（ECS のオーバーヘッドなし）
例: t3.medium × 3（常時稼働）≈ $70 / 月

3. ECS Anywhere（ハイブリッド）

オンプレミス / VPC 外のサーバーをクラスターに登録し、ECS で管理します。

特徴：

✅ 既存インフラの活用
✅ ハイブリッドクラウドに対応
❌ インフラ管理の負担（Anywhere エージェント管理）
❌ ネットワーク設定の複雑さ

推奨ユースケース：

オンプレミスからクラウドへの段階的移行
データセンター内の既存サーバーの再利用

Fargate 詳細

Fargate の動作モデル

【図3】Fargate の実行フロー：

graph LR
    User["ユーザー<br/>(タスク定義指定)"]
    Queue["キュー<br/>(リクエスト受け取り)"]
    Scheduler["ECS スケジューラ"]
    Placement["リソース配置<br/>(自動選択)"]
    Launch["Fargate ENI<br/>(起動)"]
    Running["タスク実行"]
    Monitor["CloudWatch<br/>(監視)"]
    
    User -->|タスク定義| Queue
    Queue -->|スケジュール| Scheduler
    Scheduler -->|最適ホスト| Placement
    Placement -->|起動| Launch
    Launch -->|実行| Running
    Running -->|メトリクス| Monitor

コンテナレベル課金

Fargate は コンテナが実際に稼働した時間のみ課金 されます。

利点: スケーリングイン時に不要なコンテナを削除 → 即座に課金停止

【表】Fargate リソース仕様と料金（US East 1, 2026）：

vCPU	メモリ（GB）	月額（$）*	用途
0.25	0.5 / 1 / 2	~17	低負荷、開発・テスト
0.5	1 / 2 / 3 / 4	~35	小規模 Web / API
1	2 / 3 / 4 / 5 / 6 / 7 / 8	~68	標準的な Web アプリ
2	4 / 5 / 6 / 7 / 8 / … / 30	~137	中規模アプリ
4	8 / 9 / … / 30	~274	高スループット

*概算値（CPU 0.04048/h + Memory 0.004445/h）

Fargate Spot

Fargate Spot は、未利用の Fargate キャパシティを 最大 70% 割引 で利用できます。

特徴：

✅ コスト削減（最大 70%）
✅ Spot インスタンスより安定（ユーザー数が少ない時間帯でも利用可）
❌ 中断リスク（AWS がキャパシティを要求した場合に中断）

推奨ユースケース：

バッチ処理
キャッシュ / 一時的なデータ処理
成功 / 失敗を許容できるワークロード

組み合わせ戦略：

Service: Desired Count = 10
  ├─ Fargate ON-Demand: 5 タスク（ベースロード、安定）
  └─ Fargate Spot: 5 タスク（ピーク対応、コスト削減）
  
結果: 月額 ~$340（Spot なし $510 vs Spot あり $340 = 33% 削減）

Graviton（ARM ベース CPU）

AWS Graviton プロセッサ（ARM ベース）で実行し、さらに 20% コスト削減 が可能。

特徴：

✅ コスト最適化（20-30% 削減）
✅ 高性能（同じ vCPU でも x86 より高速な場合あり）
❌ アプリが ARM に対応している必要がある

Graviton 対応確認：

# イメージが ARM 対応か確認
docker pull myrepo/myimage:latest
docker inspect myrepo/myimage:latest | grep -i 'arm64\|amd64'

# Dockerfile で ARM マルチアーキ対応
FROM --platform=$BUILDPLATFORM golang:1.21 AS builder
WORKDIR /app
COPY . .
RUN GOOS=linux GOARCH=$TARGETARCH go build -o app .

FROM --platform=$TARGETPLATFORM alpine:latest
COPY --from=builder /app/app /
CMD ["/app"]

主要ユースケース

1. Web / API サーバー

トポロジー:
  ALB → Target Group → ECS Service (Fargate, Desired=3, Auto Scaling)
  
特徴:
  - ALB がヘルスチェック、トラフィック分散
  - Service が Auto Scaling で負荷対応
  - ローリングアップデートで無停止デプロイ

2. マイクロサービスアーキテクチャ

サービス A (ECS)
  ├─ Service Connect → Cloud Map DNS
  ├─ Task IAM Role → Service B API 呼び出し
  └─ CloudWatch Logs → 集約ログ

Service B (ECS)
  ├─ Service Connect DNS: serviceb.local
  └─ 自動スケーリング

Service C (ECS)
  └─ 非同期処理（SQS → Lambda / ECS）

3. バッチ処理

CloudWatch Events → ECS RunTask → 処理実行 → 終了
  ├─ スケジュール: cron(0 2 * * ?)
  ├─ コスト: 実行時間のみ課金
  └─ 例: 日次 ETL、データクリーニング

4. 機械学習推論

ECS Service (GPU 対応 EC2) → SageMaker Endpoint の代替
  ├─ 低レイテンシ推論
  ├─ リアルタイムスケーリング
  └─ カスタムモデル運用

5. Daemonset パターン

Cluster の全ノードで 1 つずつ実行:
  ├─ ログコレクター（Fluentd / LogStash）
  ├─ モニタリングエージェント（DataDog / NewRelic）
  ├─ セキュリティエージェント（Wazuh）
  └─ ECS Placement Strategy: spread

6. CI/CD エージェント

GitLab Runner / GitHub Actions self-hosted を ECS で実行:
  ├─ ECS タスク = CI ジョブ実行環境
  ├─ Auto Scaling で同時実行数を制御
  └─ 実行後にタスク削除（費用削減）

7. ゲームバックエンドサーバー

Game Client → ALB → ECS Game Server
  ├─ WebSocket / gRPC サポート
  ├─ リアルタイムスケーリング（プレイヤー数に応じて）
  ├─ Blue/Green デプロイで無停止アップデート
  └─ Regional デプロイ（複数リージョン）で低レイテンシ

8. ストリーム処理

Kinesis / Kafka → ECS Consumer
  ├─ リアルタイムデータ処理
  ├─ スケーリング: スキップ数に応じて Auto Scaling
  └─ Fargate で効率的（変動負荷対応）

9. ETL パイプライン

S3 / RDS / API → ECS Data Pipeline → Data Warehouse
  ├─ スケジュール / イベントドリブン実行
  ├─ 失敗時の自動リトライ
  └─ Spot インスタンスで コスト最適化

10. 音声 / ビデオ処理

ECS + GPU (EC2 g4dn) → FFmpeg / TensorFlow
  ├─ リアルタイム変換
  ├─ バッチ処理
  └─ コスト: GPU 料金 + ECS (Spot)

11. Web スクレイピング

CloudWatch Events → ECS Task
  ├─ 定期実行スクレイピング
  ├─ IP rotation（複数タスク）
  └─ データベース保存

12. チャットボット / AI エージェント

API Gateway → ALB → ECS LLM Service
  ├─ LLM API（OpenAI / Claude / Anthropic）統合
  ├─ リアルタイムスケーリング
  └─ メモリ最適化（Graviton）

Task Definition

基本構造

{
  "family": "my-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRoleDefault",
  "taskRoleArn": "arn:aws:iam::123456789012:role/myAppTaskRole",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:latest",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 8080,
          "hostPort": 8080,
          "protocol": "tcp"
        }
      ],
      "environment": [
        {"name": "NODE_ENV", "value": "production"},
        {"name": "LOG_LEVEL", "value": "info"}
      ],
      "secrets": [
        {
          "name": "DATABASE_URL",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:prod/database/url"
        },
        {
          "name": "API_KEY",
          "valueFrom": "arn:aws:ssm:ap-northeast-1:123456789012:parameter/prod/api/key"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "ecs",
          "awslogs-datetime-format": "%Y-%m-%d %H:%M:%S"
        }
      },
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 60
      },
      "mountPoints": [
        {"sourceVolume": "efs-storage", "containerPath": "/data", "readOnly": false}
      ],
      "dependsOn": [
        {"containerName": "sidecar", "condition": "START"}
      ]
    },
    {
      "name": "sidecar",
      "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/sidecar:latest",
      "essential": false,
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-app",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "sidecar"
        }
      }
    }
  ],
  "volumes": [
    {
      "name": "efs-storage",
      "efsVolumeConfiguration": {
        "fileSystemId": "fs-12345678",
        "transitEncryption": "ENABLED"
      }
    }
  ]
}

Execution Role vs Task Role

【表】権限の役割分担：

ロール	用途	例
Execution Role	ECS エージェントが ECR / CloudWatch / Secrets にアクセス	`AmazonEC2ContainerServiceTaskExecutionRolePolicy`
Task Role	コンテナ内のアプリが AWS API を呼び出す	S3 GetObject、DynamoDB Query

// Execution Role ポリシー
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/ecs/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "ssm:GetParameters"
      ],
      "Resource": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:prod/*"
    }
  ]
}

// Task Role ポリシー（アプリケーション権限）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject"
      ],
      "Resource": "arn:aws:s3:::my-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": ["dynamodb:Query", "dynamodb:Scan"],
      "Resource": "arn:aws:dynamodb:ap-northeast-1:123456789012:table/my-table"
    }
  ]
}

ネットワーキング

ネットワークモード

初心者向けメモ： 「ネットワークモード」で、コンテナ同士・外部との通信方法が決まります。Fargate は awsvpc 固定、EC2 は複数選択肢があります。

モード	説明	用途	Fargate / EC2
awsvpc	各タスク独立した ENI（Elastic Network Interface）	マイクロサービス、セキュリティグループ単位制御	✅ Fargate（必須）
bridge	ホストのポート + コンテナポートをマッピング	EC2 従来型（ポート競合に注意）	❌ Fargate ✅ EC2
host	ホストのネットワークスタックを共有	ハイパフォーマンス（ポート専有）	❌ Fargate ✅ EC2
none	ネットワークなし（ログ出力等に使用）	バッチジョブ（ネットワーク不要）	✅ Fargate / EC2

awsvpc（推奨）

Fargate Task:
  ├─ ENI: eni-12345678（VPC 内のサブネット）
  ├─ Private IP: 10.0.1.50
  ├─ Security Group: sg-web（Port 8080 許可）
  └─ Public IP: eip-xxxxx（オプション）

利点:
  ✅ タスク単位で Security Group 制御
  ✅ Service Discovery で IP 自動登録
  ✅ マイクロサービス間通信が簡単

Service Connect（ネイティブメッシュ）

ECS ネイティブのサービスメッシュで、DNS ベースのサービスディスカバリー + ロードバランシングを提供します。

Service A → Service Connect → Cloud Map DNS
  ├─ 名前: serviceb.ecs.local
  ├─ ポート: 8080
  └─ 自動ロードバランシング

設定:
{
  "name": "my-service",
  "serviceRegistries": [
    {
      "registryArn": "arn:aws:servicediscovery:ap-northeast-1:123456789012:service/...",
      "containerName": "web",
      "containerPort": 8080
    }
  ],
  "serviceConnectConfiguration": {
    "enabled": true,
    "namespace": "ecs",
    "services": [
      {
        "portName": "http",
        "discoveryName": "serviceb.ecs.local",
        "clientAliases": [
          {"port": 8080, "dnsName": "serviceb.ecs.local"}
        ]
      }
    ]
  }
}

App Mesh（高度なメッシュ機能）

AWS App Mesh は、Envoy ベースの高度なサービスメッシュを提供します。

利点:
  ✅ Circuit breaker、Retry ポリシー
  ✅ トラフィックシェイピング（Canary デプロイ）
  ✅ mTLS 自動化
  ❌ 複雑（管理コスト増加）
  
利用時期: Service Connect では不足する場合

サービス更新戦略

1. ローリングアップデート（Rolling Deployment）

特徴：

古いタスク / 新しいタスクが一時的に共存
ダウンタイムなし（ヘルスチェック前提）

1. 新しいタスク起動
   ├─ ヘルスチェック成功待つ
   ├─ Load Balancer に登録
   └─ トラフィック流入

2. 古いタスク停止
   ├─ Connection drain（既存接続完了待つ）
   └─ 削除

設定:
{
  "deploymentConfiguration": {
    "minimumHealthyPercent": 100,  // 常に 100% 健全
    "maximumPercent": 200           // 最大 200%（2倍のタスク）
  }
}

2. Blue/Green デプロイ（CodeDeploy 統合）

完全なトラフィック切り替え戦略で、ロールバックが容易です。

【フロー】
Before: ALB → Target Group A (Blue, v1.0)

1. Green 環境を起動
   ├─ Target Group B (v2.0)
   └─ テストリスナー (Port 8080) で検証

2. トラフィック切り替え戦略
   ├─ Canary: 5% → 10% → 50% → 100%（時間かけて）
   ├─ Linear: 10% ずつ増加（10分間隔）
   └─ All at once: 即座に 100% 切り替え

3. 本番トラフィック切り替え
   ├─ 成功: Green (v2.0) を本運用化
   └─ 失敗: Blue (v1.0) に自動ロールバック

CloudWatch Alarm で監視:
  ├─ HttpCode_Target_5XX > 10
  ├─ TargetResponseTime > 5000 ms
  └─ 自動ロールバック実行

3. ECS Deployment Circuit Breaker

デプロイ失敗時に自動ロールバック。

{
  "deploymentConfiguration": {
    "deploymentCircuitBreaker": {
      "enable": true,
      "rollback": true
    },
    "minimumHealthyPercent": 100,
    "maximumPercent": 200
  }
}

動作：

デプロイ開始 → ヘルスチェック失敗（継続） → 閾値超過
→ 自動ロールバック → 前バージョンに戻す
リスク低減: 失敗デプロイが本番を壊さない

オートスケーリング

1. Service Auto Scaling

ターゲットメトリクスに基づいて、タスク数を自動調整。

# ターゲット登録
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/my-cluster/my-service \
  --min-capacity 2 \
  --max-capacity 20

# CPU 60% でスケール
aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/my-cluster/my-service \
  --policy-name cpu-scaling \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 60.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "ScaleInCooldown": 300,
    "ScaleOutCooldown": 60
  }'

# メモリ 70% でスケール
aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id service/my-cluster/my-service \
  --policy-name memory-scaling \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageMemoryUtilization"
    }
  }'

2. Cluster Auto Scaling（EC2 起動タイプ）

EC2 インスタンス数を自動調整。

Capacity Provider が Auto Scaling Group の EC2 を自動追加 / 削除。

前提:
  ├─ Cluster に Capacity Provider を関連付け
  ├─ Capacity Provider が Auto Scaling Group を参照
  └─ Target Capacity を設定（例: 80%）

効果:
  新しいタスクを配置できない
  → EC2 インスタンスを自動追加
  → 使用率が低下 → インスタンス削除（Drain）

3. Capacity Providers

EC2 / Spot / On-Demand を自動混合管理。

Capacity Providers:
  ├─ ON_DEMAND: Auto Scaling Group (on-demand instances)
  ├─ SPOT: Auto Scaling Group (spot instances)
  └─ FARGATE

Service Placement Strategy:
{
  "capacityProviderStrategy": [
    {
      "capacityProvider": "FARGATE",
      "weight": 1,
      "base": 1  // 最低 1 タスクは Fargate
    },
    {
      "capacityProvider": "SPOT",
      "weight": 4  // 4 倍のウェイト（コスト削減重視）
    },
    {
      "capacityProvider": "ON_DEMAND",
      "weight": 2
    }
  ]
}

効果:
  → 新しいタスク: SPOT (4) → ON_DEMAND (2) → FARGATE (1) の優先順
  → コスト最適化 + 安定性確保

サービス検出

1. Cloud Map（DNS ベース）

ECS Service を DNS 名で登録 / 検出。

登録:
  Service Name: serviceb.my-namespace.local
  健全なタスク IP を自動登録

クライアント側:
  curl http://serviceb.my-namespace.local:8080/api
  → Cloud Map が IP に解決
  → Route53 で返却
  
利点:
  ✅ 従来的な DNS アプローチ
  ✅ クライアント側の実装不要

2. Service Connect（推奨）

Envoy サイドカー + mTLS を自動注入。

設定:
{
  "serviceConnectConfiguration": {
    "enabled": true,
    "namespace": "ecs-prod",
    "services": [
      {
        "portName": "http",
        "discoveryName": "service-b",
        "clientAliases": [
          {"port": 8080, "dnsName": "service-b.local"}
        ]
      }
    ]
  }
}

クライアント側:
  curl http://service-b:8080/api

自動機能:
  ✅ Envoy プロキシ自動注入
  ✅ サーキットブレーカー
  ✅ タイムアウト制御
  ✅ リトライ政策
  ✅ mTLS（相互認証）

セキュリティ

1. IAM ロール

// Task Execution Role（ECS エージェント権限）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ecr:GetAuthorizationToken",
        "ecr:BatchGetImage",
        "ecr:GetDownloadUrlForLayer"
      ],
      "Resource": "*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "logs:CreateLogStream",
        "logs:PutLogEvents"
      ],
      "Resource": "arn:aws:logs:*:*:log-group:/ecs/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue",
        "ssm:GetParameters"
      ],
      "Resource": [
        "arn:aws:secretsmanager:*:*:secret:prod/*",
        "arn:aws:ssm:*:*:parameter/prod/*"
      ]
    }
  ]
}

// Task Role（アプリケーション権限）
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket/*"
    }
  ]
}

2. Secrets Manager 統合

{
  "secrets": [
    {
      "name": "DATABASE_PASSWORD",
      "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:prod/db/password"
    },
    {
      "name": "API_KEY",
      "valueFrom": "arn:aws:ssm:ap-northeast-1:123456789012:parameter/prod/api/key"
    }
  ]
}

3. ECR 脆弱性スキャン

# ECR スキャンを有効化
aws ecr put-image-scanning-configuration \
  --repository-name my-app \
  --image-scanning-configuration scanOnPush=true

# スキャン結果確認
aws ecr describe-image-scan-findings \
  --repository-name my-app \
  --image-id imageTag=latest

4. Task IAM Role 用途

✅ S3 バケットへのアクセス
✅ DynamoDB クエリ
✅ Secrets Manager からシークレット取得
✅ SNS / SQS メッセージ送信
✅ CloudWatch Logs 出力（明示的）
❌ 過度な権限（最小権限の原則）

モニタリング

1. CloudWatch Container Insights

ECS クラスター / サービス / タスク単位でメトリクスを収集。

有効化:
{
  "clusterSettings": [
    {
      "name": "containerInsights",
      "value": "enabled"
    }
  ]
}

メトリクス:
  ├─ Cluster: CPUUtilization, MemoryUtilization, TaskCount
  ├─ Service: DesiredCount, RunningCount, PendingCount, CPUUtilization
  └─ Task: CPUUtilization, MemoryUtilization, NetworkIn/Out, StorageRead/Write

2. CloudWatch Logs

{
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/my-app",
      "awslogs-region": "ap-northeast-1",
      "awslogs-stream-prefix": "ecs",
      "awslogs-datetime-format": "%Y-%m-%d %H:%M:%S"
    }
  }
}

3. Application Signals（トレース）

X-Ray 統合でエンドツーエンドのトレース。

# トレース有効化
aws xray create-group \
  --group-name ECS-Service \
  --filter-expression 'service("ecs-service")'

ECS vs EKS vs Fargate vs Lambda

【表】コンテナサービス比較：

観点	ECS	EKS	Fargate	Lambda
学習コスト	低（AWS API）	高（Kubernetes）	低	最低（コード記述）
管理負担	中（デプロイ管理）	高（クラスター管理）	低（サーバーレス）	最低（フルマネージド）
ポータビリティ	AWS 専用	マルチクラウド	AWS 専用	AWS 専用
実行単位	コンテナ（タスク）	コンテナ（Pod）	コンテナ	関数
起動時間	秒（Fargate）分（EC2）	分	秒	ミリ秒
デプロイ方式	自動スケジューリング	Helm / YAML	ネイティブ統合	コード更新
AWS 統合	深い（IAM / ALB / SSM）	アドオン必要	最深（ネイティブ）	最深
コスト	On-Demand > Spot	$0.10/h + EC2	従量課金	従量課金
推奨用途	本番マイクロサービス	Kubernetes 標準が必要	サーバーレス / 開発	短時間処理

ECS Anywhere

オンプレミス / 外部インフラのサーバーを ECS クラスターに登録。

セットアップ:
  1. 外部ホストに SSM エージェント + ECS エージェント インストール
  2. CloudWatch Agent でメトリクス収集
  3. ECS に「External」起動タイプで登録

トポロジー:
  VPC 内の ECS
  ↔ (VPN / Direct Connect)
  ↔ オンプレミスの ECS Anywhere

利点:
  ✅ 段階的なクラウド移行
  ✅ 既存インフラの活用
  ❌ 管理複雑（ネットワーク設定）
  ❌ 高レイテンシ

他の類似ツールとの比較

ツール	特性	向いている場面
Kubernetes (EKS)	高度な拡張性、マルチクラウド	複雑なマイクロサービス、ポータビリティ重視
Docker Swarm	シンプル（非推奨）	小規模環境 / 学習用
HashiCorp Nomad	マルチプラットフォーム	ハイブリッドクラウド / 複合ワークロード
Google Cloud Run	完全サーバーレス	イベント駆動型、HTTP リクエスト処理
Azure Container Instances	Azure ネイティブ	Azure エコシステム
Fly.io	グローバルエッジデプロイ	地理的分散、低レイテンシ

クライアント・ツール・エコシステム

1. AWS CLI

# クラスター作成
aws ecs create-cluster --cluster-name my-cluster

# サービス作成
aws ecs create-service \
  --cluster my-cluster \
  --service-name my-service \
  --task-definition my-app:5 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-xxx"],
      "securityGroups": ["sg-xxx"]
    }
  }'

# タスク実行
aws ecs run-task \
  --cluster my-cluster \
  --task-definition my-app:5 \
  --launch-type FARGATE

2. ECS CLI（サポート終了、非推奨）

古い ECS 専用 CLI。Copilot CLI に統合。

3. AWS Copilot CLI（推奨）

モダンな ECS / App Runner デプロイツール。

# アプリケーション初期化
copilot app init my-app

# サービス作成
copilot svc init --name api --svc-type "Load Balanced Web Service"

# 環境作成（VPC / クラスター）
copilot env init --name prod

# デプロイ
copilot svc deploy --name api --env prod

# ログ確認
copilot svc logs --name api --env prod --follow

4. Terraform + ECS

resource "aws_ecs_cluster" "main" {
  name = "my-cluster"

  setting {
    name  = "containerInsights"
    value = "ENABLED"
  }
}

resource "aws_ecs_task_definition" "main" {
  family                   = "my-app"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]
  cpu                      = 512
  memory                   = 1024
  execution_role_arn       = aws_iam_role.ecsTaskExecutionRole.arn
  task_role_arn            = aws_iam_role.myTaskRole.arn

  container_definitions = jsonencode([{
    name      = "web"
    image     = "${data.aws_caller_identity.current.account_id}.dkr.ecr.${var.region}.amazonaws.com/my-app:latest"
    essential = true
    portMappings = [{
      containerPort = 8080
      hostPort      = 8080
      protocol      = "tcp"
    }]
    logConfiguration = {
      logDriver = "awslogs"
      options = {
        "awslogs-group"         = aws_cloudwatch_log_group.ecs.name
        "awslogs-region"        = var.region
        "awslogs-stream-prefix" = "ecs"
      }
    }
  }])
}

resource "aws_ecs_service" "main" {
  name            = "my-service"
  cluster         = aws_ecs_cluster.main.id
  task_definition = aws_ecs_task_definition.main.arn
  desired_count   = 3
  launch_type     = "FARGATE"

  network_configuration {
    subnets          = var.private_subnet_ids
    security_groups  = [aws_security_group.alb.id]
    assign_public_ip = false
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.app.arn
    container_name   = "web"
    container_port   = 8080
  }

  deployment_configuration {
    maximum_percent         = 200
    minimum_healthy_percent = 100
    deployment_circuit_breaker {
      enable   = true
      rollback = true
    }
  }
}

5. AWS CDK (Python)

from aws_cdk import (
    aws_ecs as ecs,
    aws_ec2 as ec2,
    aws_ecs_patterns as ecs_patterns,
    core
)

class EcsStack(core.Stack):
    def __init__(self, scope: core.Construct, id: str, **kwargs) -> None:
        super().__init__(scope, id, **kwargs)

        vpc = ec2.Vpc(self, "VPC", max_azs=3)
        cluster = ecs.Cluster(self, "Cluster", vpc=vpc)

        # Fargate Service
        ecs_patterns.ApplicationLoadBalancedFargateService(
            self, "Service",
            cluster=cluster,
            memory_limit_mib=1024,
            cpu=512,
            desired_count=3,
            image=ecs.ContainerImage.from_registry(
                f"{core.Stack.of(self).account}.dkr.ecr.{core.Stack.of(self).region}.amazonaws.com/my-app:latest"
            ),
            public_load_balancer=True
        )

6. Compose-X

Docker Compose で ECS / Fargate デプロイ。

# Docker Compose を ECS に変換
compose-x render -f docker-compose.yml -o generated.yml

# AWS デプロイ
compose-x create -f docker-compose.yml

7. Pulumi

import pulumi
import pulumi_aws as aws

# クラスター
cluster = aws.ecs.Cluster("main", {
    "settings": [{
        "name": "containerInsights",
        "value": "ENABLED"
    }]
})

# タスク定義
task_definition = aws.ecs.TaskDefinition("app", {
    "family": "my-app",
    "networkMode": "awsvpc",
    "requiresCompatibilities": ["FARGATE"],
    "cpu": "512",
    "memory": "1024",
    "executionRoleArn": execution_role.arn,
    "containerDefinitions": pulumi.Output.concat(...)
})

# サービス
service = aws.ecs.Service("web", {
    "cluster": cluster.arn,
    "taskDefinition": task_definition.arn,
    "desiredCount": 3,
    "launchType": "FARGATE"
})

ベストプラクティス

1. デプロイ安全性

✅ Deployment Circuit Breaker を有効化

{
  "deploymentConfiguration": {
    "deploymentCircuitBreaker": {
      "enable": true,
      "rollback": true
    }
  }
}

✅ ヘルスチェック実装

{
  "healthCheck": {
    "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
    "interval": 30,
    "timeout": 5,
    "retries": 3,
    "startPeriod": 60
  }
}

✅ Blue/Green デプロイで検証

# CodeDeploy + ALB で完全なトラフィック切り替え

2. セキュリティ

✅ Secrets Manager / SSM Parameter Store 利用

{
  "secrets": [
    {
      "name": "DB_PASSWORD",
      "valueFrom": "arn:aws:secretsmanager:..."
    }
  ]
}

❌ 環境変数に直書き禁止

✅ IAM Task Role で最小権限

{
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::my-bucket/data/*"
    }
  ]
}

✅ ECR 脆弱性スキャン有効化

aws ecr put-image-scanning-configuration \
  --repository-name my-app \
  --image-scanning-configuration scanOnPush=true

3. スケーリング

✅ Auto Scaling 有効化

aws application-autoscaling put-scaling-policy \
  --policy-type TargetTrackingScaling \
  --target-value 70.0

✅ Capacity Providers で ON/Spot 混合

{
  "capacityProviderStrategy": [
    {"capacityProvider": "ON_DEMAND", "weight": 1},
    {"capacityProvider": "SPOT", "weight": 4}
  ]
}

4. ロギング・モニタリング

✅ CloudWatch Logs 設定

{
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/my-app",
      "awslogs-stream-prefix": "ecs"
    }
  }
}

✅ Container Insights 有効化

aws ecs put-cluster-setting \
  --cluster my-cluster \
  --name containerInsights \
  --value ENABLED

5. ネットワーク設計

✅ awsvpc ネットワークモード使用

{
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"]
}

✅ Service Connect で自動サービスディスカバリー

{
  "serviceConnectConfiguration": {
    "enabled": true,
    "namespace": "ecs-prod"
  }
}

6. コスト最適化

✅ Fargate Spot で 70% 削減

{
  "capacityProviderStrategy": [
    {"capacityProvider": "FARGATE_SPOT", "weight": 3},
    {"capacityProvider": "FARGATE", "weight": 1, "base": 1}
  ]
}

✅ Graviton で 20% 削減

# Task Definition で ARM サポート確認
docker inspect my-image | grep 'arm64'

✅ 不要なタスク削除

aws ecs stop-task \
  --cluster my-cluster \
  --task <task-arn> \
  --reason "Not needed"

トラブルシューティング

1. タスクが起動しない

症状: Task Status = PROVISIONING → PENDING で止まる

原因と対策:
  ❌ Fargate リソース不足
    ✅ 別リージョンを試す、Capacity Providers を確認
  
  ❌ ECR イメージが見つからない
    ✅ ECR リポジトリ / タグを確認
    ✅ Execution Role が ecr:BatchGetImage 権限を持つか確認
  
  ❌ セキュリティグループが制限的
    ✅ アウトバウンド許可（0.0.0.0/0 確認）、ECR エンドポイント確認
  
  ❌ VPC エンドポイント設定不足
    ✅ S3 / ECR / CloudWatch Logs エンドポイント作成

2. タスクがすぐ終了する

症状: Task Status = RUNNING → STOPPED（数秒以内）

原因と対策:
  ❌ ヘルスチェック失敗
    ✅ curl コマンド実行確認: docker run ... /bin/sh -c "curl ..."
    ✅ startPeriod を長くする
  
  ❌ アプリケーションクラッシュ
    ✅ CloudWatch Logs 確認: /aws/ecs/my-app
    ✅ docker run でローカルテスト
  
  ❌ メモリ不足（OOM Kill）
    ✅ Task Definition の memory 増加
    ✅ アプリのメモリリーク確認

3. デプロイが失敗する

症状: Deployment Status = PRIMARY (Rollback)

原因と対策:
  ❌ 新タスク起動失敗
    ✅ CloudWatch Logs で詳細確認
    ✅ ECR イメージ確認
  
  ❌ ヘルスチェック失敗
    ✅ minimumHealthyPercent = 100 を下げて試す
    ✅ health check timeout / retries を調整
  
  ❌ AutoScaling 衝突
    ✅ Desired Count 確認、Scaling Policy 一時無効化

4. Auto Scaling が動作しない

症状: CPU 高騰してもタスク数が増えない

原因と対策:
  ❌ Scaling Policy 登録なし
    ✅ aws application-autoscaling put-scaling-policy で登録
  
  ❌ Max Capacity に達している
    ✅ --max-capacity を増加
  
  ❌ CloudWatch メトリクス取得失敗
    ✅ Container Insights 有効か確認
    ✅ IAM 権限確認

5. Service Discovery が動作しない

症状: Service Connect DNS が解決しない

原因と対策:
  ❌ Service Connect 未設定
    ✅ serviceConnectConfiguration.enabled = true に設定
  
  ❌ Cloud Map に登録されていない
    ✅ serviceRegistries 確認
  
  ❌ ネットワークモード awsvpc でない
    ✅ awsvpc に変更

2025-2026 最新動向

1. ECS Express Mode（2025年11月GA）

シンプルな Web / API サービス向けワンクリックデプロイ

従来：Cluster → Task Definition → Service の複数ステップ
Express Mode：Docker Compose + ワンステップで本番デプロイ

特徴：
  ✅ VPC・ロードバランサー自動作成
  ✅ CloudFormation 不要
  ✅ Copilot CLI でシンプル管理
  ✅ 開発環境から本番への段階的移行

後続：Service Connect で マイクロサービス統合

2. Service Connect GA（2025年完全サポート）

ECS ネイティブのサービスメッシュが完全一般提供。

機能：
  ✅ Envoy サイドカー自動注入
  ✅ mTLS 自動化（証明書管理不要）
  ✅ Circuit Breaker / Timeout / Retry ポリシー
  ✅ トラフィックシェイピング（Canary 対応）
  ✅ ロギング・メトリクス統合
  
料金：
  ✅ 追加費用なし（Service Discovery のみ）

3. ECS Managed Instances

EC2 インスタンス管理を AWS が一部サポート（2024-2025）。

機能：
✅ OS パッチ管理自動化
✅ キャパシティプランニング支援
✅ コスト最適化提案

4. Fargate Spot 拡張

より多くのリージョン / AZ で利用可能（2026 年拡大予定）。

割引：最大 70%
用途：バッチ処理・開発環境・一時的なワークロード

5. AI / ML ワークロード加速

Inferentia2 / Trainium チップ対応 EC2 インスタンス。

用途：
✅ 機械学習推論（低遅延・コスト最適）
✅ 大規模言語モデル訓練
✅ Hugging Face Model Hub 統合

6. Container Insights 深化

トレース・プロファイリング統合（2026）。

機能：
✅ Application Signals（X-Ray 統合）
✅ CloudWatch ServiceLens で依存関係可視化
✅ 自動的なパフォーマンス異常検知

7. ECS Anywhere での Hybrid 運用

オンプレミス・エッジサーバーを ECS で統合管理。

学習リソース

公式ドキュメント

学習パス

初級: ECS 基本概念（Cluster / Task / Service）
中級: Fargate デプロイ、Auto Scaling、ロードバランシング
上級: Service Connect、Blue/Green デプロイ、Capacity Providers
エキスパート: ECS Anywhere、Kubernetes 統合、高度なセキュリティ

実装例・活用シーン

シーン 1: 新規 Web API（推奨構成）

ALB → ECS Service (Fargate, Desired=3)
  ├─ Auto Scaling: CPU 70%
  ├─ Blue/Green デプロイ (CodeDeploy)
  ├─ CloudWatch Logs
  └─ IAM Task Role: S3 / DynamoDB アクセス

月額: ~$240（Fargate 0.5 vCPU / 1 GB × 3 + ALB）

シーン 2: マイクロサービス

Service A → Service Connect (servicea.local)
Service B → Service Connect (serviceb.local)
Service C → Service Connect (servicec.local)
  ├─ 各サービス独立スケーリング
  ├─ 自動サービスディスカバリー
  └─ Capacity Provider で ON/Spot 混合

月額: ~$500（3 サービス × $240 - 割引）

シーン 3: バッチ処理

CloudWatch Events (cron)
  → ECS RunTask (Fargate Spot)
  → S3 データ処理
  → RDS / DynamoDB 更新

月額: 実行時間のみ（例: 1h/日 × $0.04 ≈ $1.2）

導入ロードマップ

フェーズ 1: 評価（1-2 週間）

[ ] ECS / Fargate コンセプト理解
[ ] 既存アプリを Docker 化
[ ] ECR にイメージプッシュ

フェーズ 2: POC（2-4 週間）

[ ] ECS クラスター作成（Copilot / Terraform）
[ ] Fargate 上でアプリ実行
[ ] CloudWatch Logs 確認

フェーズ 3: 本番化（4-8 週間）

[ ] ALB / NLB 統合
[ ] Auto Scaling 設定
[ ] Blue/Green デプロイ設定
[ ] セキュリティ（IAM / Secrets）

フェーズ 4: 最適化（継続）

[ ] Capacity Providers（ON/Spot）
[ ] Service Connect 導入
[ ] コスト削減（Fargate Spot / Graviton）

実装チェックリスト

デプロイ前チェック：

✅ Docker イメージは ECR にプッシュ済みか
✅ タスク定義は環境変数 / シークレットで分離されているか
✅ ヘルスチェック (HTTP / TCP / CMD-SHELL) が設定されているか
✅ Execution Role は ecr:BatchGetImage / logs:PutLogEvents 権限を持つか
✅ Task Role は必要最小限の権限か
✅ ロギングは CloudWatch Logs 設定済みか
✅ Fargate の場合、ネットワークモードは awsvpc か
✅ Auto Scaling ポリシーは設定済みか（CPU / メモリ）
✅ ALB ターゲットグループ健全性チェック設定済みか
✅ Deployment Circuit Breaker は有効か
✅ CloudWatch Container Insights は有効か

デプロイ後チェック：

✅ タスクは RUNNING ステータスか
✅ ALB でエンドポイント応答するか（200 OK）
✅ CloudWatch Logs にログが流れているか
✅ Auto Scaling アラーム設定済みか
✅ バックアップ / ディザスタリカバリー計画はあるか

まとめ

Amazon ECS は、AWS ネイティブのフルマネージドコンテナオーケストレーションサービス です。

要点

簡単: Kubernetes より学習コスト低い、AWS 統合深い
柔軟: EC2 / Fargate / ECS Anywhere で複数起動タイプ対応
安全: Blue/Green デプロイ、自動ロールバック、IAM Task Role
スケーラブル: Auto Scaling、Capacity Providers で多次元最適化
コスト効率: Fargate Spot（70% 割引）、Graviton（20% 削減）

いつ ECS を選ぶか

✅ AWS 専業の本番環境 ✅ 新規コンテナアプリ ✅ Kubernetes の学習コストが許容できない ✅ AWS ネイティブ統合が重要

❌ マルチクラウド / ポータビリティ重視 → EKS ❌ イベント駆動 / 短時間処理 → Lambda ❌ より高い抽象化が必要 → App Runner

次のステップ

Copilot CLI / Terraform で実装
小規模 POC 実施（テストアプリ）
Production 環境への段階的移行
Service Connect / Capacity Providers による最適化

参考文献

公式ドキュメント・ガイド

AWS ECS Documentation - 最新仕様・API リファレンス
ECS Best Practices
ECS Service Connect Guide - サービスディスカバリー
AWS ECS Workshop - ハンズオン実習
ECS Pricing - 料金詳細・コスト計算

デプロイツール・CLI

AWS Copilot CLI - モダンコンテナデプロイツール
AWS Copilot Documentation
ECS Container Agent - GitHub オープンソース

Infrastructure as Code

Terraform AWS ECS
AWS CDK ECS Module
Pulumi ECS
Docker Compose X - Docker Compose → CloudFormation

ブログ・リソース

AWS Containers Blog - 最新ニュース・ベストプラクティス
「ECS の基本からベストプラクティスまで」AWS Black Belt 動画
「Fargate vs EC2: 使い分けガイド」AWS ブログ
「マイクロサービスと ECS」クラウドネイティブの実装パターン

最終更新：2026-04-26 バージョン：v2.3（Express Mode・Service Connect GA 対応） 対象: ECS 2026 年最新仕様、Express Mode、Fargate Spot、Service Connect GA、Managed Instances、AI/ML ワークロード加速 著者：Claude (Anthropic) — i のメモ拡充プロジェクト

目次

Amazon ECS 完全ガイド 2026

初心者から実務者向けの包括的解説

ドキュメントの目的

2026 年の ECS エコシステム

定義

目次

概要

ECS の位置づけ

ECS が解決する課題

主な特徴

アーキテクチャ

コアコンポーネント

1. クラスター（Cluster）

2. Task Definition（タスク定義）

3. Task（タスク）

4. Service（サービス）

起動タイプ

1. Fargate（サーバーレス）

2. EC2（セルフマネージド）

3. ECS Anywhere（ハイブリッド）

Fargate 詳細

Fargate の動作モデル

コンテナレベル課金

Fargate Spot

Graviton（ARM ベース CPU）

主要ユースケース

1. Web / API サーバー

2. マイクロサービスアーキテクチャ

3. バッチ処理

4. 機械学習推論

5. Daemonset パターン

6. CI/CD エージェント

7. ゲーム バックエンドサーバー

8. ストリーム処理

9. ETL パイプライン

10. 音声 / ビデオ処理

11. Web スクレイピング

12. チャットボット / AI エージェント

Task Definition

基本構造

Execution Role vs Task Role

ネットワーキング

ネットワークモード

awsvpc（推奨）

Service Connect（ネイティブメッシュ）

App Mesh（高度なメッシュ機能）

サービス更新戦略

1. ローリングアップデート（Rolling Deployment）

2. Blue/Green デプロイ（CodeDeploy 統合）

3. ECS Deployment Circuit Breaker

オートスケーリング

1. Service Auto Scaling

2. Cluster Auto Scaling（EC2 起動タイプ）

3. Capacity Providers

サービス検出

1. Cloud Map（DNS ベース）

2. Service Connect（推奨）

セキュリティ

1. IAM ロール

2. Secrets Manager 統合

3. ECR 脆弱性スキャン

4. Task IAM Role 用途

モニタリング

1. CloudWatch Container Insights

2. CloudWatch Logs

3. Application Signals（トレース）

ECS vs EKS vs Fargate vs Lambda

ECS Anywhere

他の類似ツールとの比較

クライアント・ツール・エコシステム

1. AWS CLI

2. ECS CLI（サポート終了、非推奨）

3. AWS Copilot CLI（推奨）

4. Terraform + ECS

5. AWS CDK (Python)

6. Compose-X

7. Pulumi

ベストプラクティス

1. デプロイ安全性

7. ゲームバックエンドサーバー