AWS ECSの基本概念とタスク定義の実践ガイド

はじめに

AWSでコンテナワークロードを本格的に運用する場合、ECS（Elastic Container Service）の理解は避けて通れません。ECSはAWSネイティブのコンテナオーケストレーションサービスであり、Kubernetesほど複雑ではなく、AWSサービスとの親和性が高いという特徴があります。

しかし、ECSには「クラスター」「タスク定義」「タスク」「サービス」といった固有の概念があり、これらの関係性を正しく理解しないと、適切な設計や運用ができません。本記事では、ECSのアーキテクチャを体系的に解説し、タスク定義の作成からサービスの構築・管理までを実践的に紹介します。

この記事を読むことで、以下のことが理解できるようになります。

• ECSのコンポーネント（クラスター、タスク定義、タスク、サービス）の役割と関係性
• タスク定義の各パラメータの意味と設定方法
• ECSサービスの作成と運用に必要な設定項目
• 本番環境を見据えたベストプラクティス

ECSアーキテクチャの全体像

ECSの構成要素

ECSを理解するには、4つの主要コンポーネントとその関係を把握することが重要です。

flowchart TB
    subgraph ECS["Amazon ECS"]
        Cluster["クラスター<br/>論理的なコンテナ実行環境"]
        
        subgraph Services["サービス"]
            ServiceA["サービスA<br/>Desired Count: 2"]
            ServiceB["サービスB<br/>Desired Count: 3"]
        end
        
        subgraph Tasks["実行中のタスク"]
            Task1["タスク1"]
            Task2["タスク2"]
            Task3["タスク3"]
            Task4["タスク4"]
            Task5["タスク5"]
        end
        
        TaskDefA["タスク定義A<br/>（設計図）"]
        TaskDefB["タスク定義B<br/>（設計図）"]
    end
    
    Cluster --> Services
    ServiceA --> Task1
    ServiceA --> Task2
    ServiceB --> Task3
    ServiceB --> Task4
    ServiceB --> Task5
    
    TaskDefA -.->|参照| Task1
    TaskDefA -.->|参照| Task2
    TaskDefB -.->|参照| Task3
    TaskDefB -.->|参照| Task4
    TaskDefB -.->|参照| Task5

各コンポーネントの役割

クラスター

クラスターは、ECSにおける最上位の論理的なリソースグループです。タスクとサービスを束ねる役割を持ちます。

クラスターを分離する一般的なパターンは以下のとおりです。

• 環境別（開発、ステージング、本番）
• アプリケーション別（フロントエンド、バックエンド）
• チーム別（チームA、チームB）

クラスター自体には追加料金は発生しません。課金は、クラスター内で実行されるタスクのコンピューティングリソース（FargateまたはEC2）に対して行われます。

タスク定義

タスク定義は、コンテナをどのように実行するかを定義するJSON形式の設計図です。以下の要素を指定します。

• 使用するコンテナイメージ
• CPU・メモリの割り当て
• 環境変数やシークレット
• ネットワーク設定
• ログ出力設定
• IAMロール

タスク定義はバージョン管理され、リビジョン番号が自動的に付与されます。一度作成したタスク定義は変更できず、修正する場合は新しいリビジョンとして登録します。

タスク

タスクは、タスク定義に基づいて起動されたコンテナのインスタンスです。1つのタスクには1つ以上のコンテナを含めることができます。

タスクの起動方法は2種類あります。

サービス

サービスは、指定した数のタスクを常に維持し、ヘルスチェックや自動復旧を管理するコンポーネントです。以下の機能を提供します。

• 指定したタスク数（Desired Count）の維持
• 異常終了したタスクの自動再起動
• ローリングデプロイによる無停止更新
• ロードバランサーとの統合
• Auto Scalingによる自動スケーリング

起動タイプの選択

ECSでは、タスクを実行するインフラストラクチャとして「EC2起動タイプ」と「Fargate起動タイプ」を選択できます。

flowchart TB
    subgraph LaunchTypes["起動タイプの選択"]
        ECS["Amazon ECS"]
        
        subgraph EC2Type["EC2起動タイプ"]
            EC2Instance1["EC2インスタンス"]
            EC2Instance2["EC2インスタンス"]
            Container1["コンテナ"]
            Container2["コンテナ"]
            Container3["コンテナ"]
            EC2Instance1 --> Container1
            EC2Instance1 --> Container2
            EC2Instance2 --> Container3
        end
        
        subgraph FargateType["Fargate起動タイプ"]
            FargateTask1["Fargateタスク"]
            FargateTask2["Fargateタスク"]
            FargateContainer1["コンテナ"]
            FargateContainer2["コンテナ"]
            FargateTask1 --> FargateContainer1
            FargateTask2 --> FargateContainer2
        end
    end
    
    ECS --> EC2Type
    ECS --> FargateType

EC2起動タイプ

EC2起動タイプでは、ユーザーがプロビジョニングしたEC2インスタンス上でコンテナが実行されます。

メリット

• インスタンスタイプを自由に選択可能
• GPUインスタンスが利用可能
• リザーブドインスタンスやSavings Plansでコスト最適化
• ホストレベルのカスタマイズが可能

デメリット

• EC2インスタンスの管理（パッチ適用、スケーリング）が必要
• キャパシティプランニングの負担
• 初期設定の複雑さ

Fargate起動タイプ

Fargate起動タイプでは、AWSがインフラストラクチャを完全に管理し、タスクごとに独立した実行環境が提供されます。

メリット

• サーバー管理が一切不要
• タスクレベルでのセキュリティ分離
• 使用した分だけの従量課金
• 素早いプロビジョニング

デメリット

• GPUサポートなし
• 一部のインスタンス機能（特権コンテナなど）の制限
• EC2と比較してコスト単価が高い場合がある

選択の判断基準

本記事では、運用負荷が低く導入しやすいFargate起動タイプを中心に解説します。

タスク定義の作成

タスク定義の構造

タスク定義はJSON形式で記述され、大きく「タスクレベルの設定」と「コンテナ定義」に分かれます。

flowchart TB
    subgraph TaskDef["タスク定義"]
        subgraph TaskLevel["タスクレベル設定"]
            Family["family: タスク定義名"]
            Network["networkMode: ネットワークモード"]
            CPU["cpu: タスク全体のCPU"]
            Memory["memory: タスク全体のメモリ"]
            ExecutionRole["executionRoleArn: 実行ロール"]
            TaskRole["taskRoleArn: タスクロール"]
        end
        
        subgraph ContainerDefs["containerDefinitions"]
            Container1["コンテナ1の定義"]
            Container2["コンテナ2の定義"]
        end
    end
    
    TaskLevel --> ContainerDefs

基本的なタスク定義の例

以下は、Nginx Webサーバーを実行するシンプルなタスク定義の例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

{
  "family": "nginx-web",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "nginx",
      "image": "nginx:1.25",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 80,
          "protocol": "tcp"
        }
      ],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/nginx-web",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "nginx"
        }
      }
    }
  ]
}

タスクレベルのパラメータ

タスク定義の主要なパラメータを解説します。

family

タスク定義の名前です。同じfamilyで複数のリビジョンを管理できます。命名規則として、アプリケーション名やサービス名を使用することを推奨します。

1
2
3

{
  "family": "my-web-app"
}

networkMode

タスクのネットワークモードを指定します。Fargateではawsvpcのみサポートされます。

cpu / memory

タスク全体で使用するCPUとメモリを指定します。Fargateでは以下の組み合わせから選択します。

1
2
3
4

{
  "cpu": "512",
  "memory": "1024"
}

executionRoleArn

ECSエージェントがタスクを実行するために使用するIAMロールです。以下の操作権限が必要です。

• ECRからのイメージプル
• CloudWatch Logsへのログ送信
• Secrets Managerからのシークレット取得（使用する場合）

AWSマネージドポリシーAmazonECSTaskExecutionRolePolicyを使用するのが一般的です。

taskRoleArn

タスク内のコンテナがAWSサービスにアクセスするために使用するIAMロールです。例えば、S3バケットへのアクセスやDynamoDBへのクエリを行う場合に必要です。

flowchart LR
    subgraph ECSTask["ECSタスク"]
        Container["コンテナ"]
    end
    
    ExecutionRole["実行ロール<br/>executionRoleArn"]
    TaskRole["タスクロール<br/>taskRoleArn"]
    
    ECR["Amazon ECR"]
    CloudWatch["CloudWatch Logs"]
    S3["Amazon S3"]
    DynamoDB["DynamoDB"]
    
    ExecutionRole -->|イメージ取得| ECR
    ExecutionRole -->|ログ送信| CloudWatch
    Container -->|タスクロール経由| TaskRole
    TaskRole -->|アクセス| S3
    TaskRole -->|アクセス| DynamoDB

コンテナ定義のパラメータ

containerDefinitions配列内で各コンテナの設定を定義します。

基本設定

1
2
3
4
5

{
  "name": "web",
  "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1.0.0",
  "essential": true
}

portMappings

コンテナが公開するポートを定義します。Fargateのawsvpcモードでは、hostPortはcontainerPortと同じ値になります。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

{
  "portMappings": [
    {
      "containerPort": 8080,
      "protocol": "tcp",
      "name": "http",
      "appProtocol": "http"
    }
  ]
}

environment / secrets

環境変数の設定方法は2種類あります。

environment（プレーンテキスト）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

{
  "environment": [
    {
      "name": "NODE_ENV",
      "value": "production"
    },
    {
      "name": "LOG_LEVEL",
      "value": "info"
    }
  ]
}

secrets（Secrets Manager / Parameter Store連携）

機密情報はSecrets ManagerまたはSystems Manager Parameter Storeから取得します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

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

logConfiguration

コンテナのログ出力先を設定します。CloudWatch Logsを使用する場合の例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

{
  "logConfiguration": {
    "logDriver": "awslogs",
    "options": {
      "awslogs-group": "/ecs/my-app",
      "awslogs-region": "ap-northeast-1",
      "awslogs-stream-prefix": "web",
      "awslogs-create-group": "true"
    }
  }
}

ログドライバーはawslogs以外にもsplunk、fluentd、awsfirelensなどを選択できます。

healthCheck

コンテナのヘルスチェックを設定します。ECSはこの設定に基づいてコンテナの状態を監視します。

1
2
3
4
5
6
7
8
9

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

完全なタスク定義の例

実際の本番環境を想定した、より完全なタスク定義の例を示します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64

{
  "family": "my-web-app",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "512",
  "memory": "1024",
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "taskRoleArn": "arn:aws:iam::123456789012:role/myAppTaskRole",
  "containerDefinitions": [
    {
      "name": "app",
      "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/my-app:v1.2.0",
      "essential": true,
      "portMappings": [
        {
          "containerPort": 8080,
          "protocol": "tcp",
          "name": "http"
        }
      ],
      "environment": [
        {
          "name": "NODE_ENV",
          "value": "production"
        },
        {
          "name": "PORT",
          "value": "8080"
        }
      ],
      "secrets": [
        {
          "name": "DATABASE_URL",
          "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:my-app/database-url"
        }
      ],
      "healthCheck": {
        "command": ["CMD-SHELL", "curl -f http://localhost:8080/health || exit 1"],
        "interval": 30,
        "timeout": 5,
        "retries": 3,
        "startPeriod": 60
      },
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/my-web-app",
          "awslogs-region": "ap-northeast-1",
          "awslogs-stream-prefix": "app"
        }
      }
    }
  ],
  "tags": [
    {
      "key": "Environment",
      "value": "Production"
    },
    {
      "key": "Application",
      "value": "MyWebApp"
    }
  ]
}

AWS CLIでのタスク定義の登録

タスク定義をAWS CLIで登録する場合は、以下のコマンドを使用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# タスク定義の登録
aws ecs register-task-definition \
  --cli-input-json file://task-definition.json \
  --region ap-northeast-1

# 登録されたタスク定義の確認
aws ecs describe-task-definition \
  --task-definition my-web-app \
  --region ap-northeast-1

# タスク定義のリビジョン一覧
aws ecs list-task-definitions \
  --family-prefix my-web-app \
  --region ap-northeast-1

ECSサービスの作成と管理

サービスの役割

ECSサービスは、タスクのライフサイクルを管理し、以下の機能を提供します。

flowchart TB
    subgraph Service["ECSサービス"]
        DesiredCount["Desired Count: 3"]
        Scheduler["スケジューラー"]
        
        subgraph Tasks["実行中のタスク"]
            Task1["タスク1<br/>RUNNING"]
            Task2["タスク2<br/>RUNNING"]
            Task3["タスク3<br/>RUNNING"]
        end
    end
    
    ALB["Application<br/>Load Balancer"]
    AutoScaling["Auto Scaling"]
    
    Scheduler -->|維持| Tasks
    ALB -->|トラフィック分散| Tasks
    AutoScaling -->|スケール制御| DesiredCount

サービス作成の前提条件

ECSサービスを作成する前に、以下のリソースを準備します。

1. ECSクラスター - サービスを配置するクラスター
2. タスク定義 - サービスが使用するタスク定義
3. VPCとサブネット - タスクを実行するネットワーク環境
4. セキュリティグループ - タスクへのトラフィック制御
5. ロードバランサー（任意） - トラフィックの分散

サービス定義のパラメータ

主要なサービス設定パラメータを解説します。

基本設定

ネットワーク設定

FargateではnetworkConfigurationが必須です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

{
  "networkConfiguration": {
    "awsvpcConfiguration": {
      "subnets": [
        "subnet-xxxxxxxx",
        "subnet-yyyyyyyy"
      ],
      "securityGroups": [
        "sg-xxxxxxxx"
      ],
      "assignPublicIp": "DISABLED"
    }
  }
}

assignPublicIpの設定は、タスクがインターネットにアクセスする方法によって決まります。

ロードバランサー設定

ALBまたはNLBと統合する場合の設定です。

1
2
3
4
5
6
7
8
9

{
  "loadBalancers": [
    {
      "targetGroupArn": "arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-tg/xxxxxxxxxx",
      "containerName": "app",
      "containerPort": 8080
    }
  ]
}

デプロイメント設定

ローリングデプロイの動作を制御します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

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

maximumPercent: 200、minimumHealthyPercent: 100の場合、3タスクのサービスでは以下のように動作します。

1. 新しいタスクを3つ起動（最大6タスク）
2. 新タスクがヘルシーになったら古いタスクを停止
3. 常に最低3タスクが稼働

AWS CLIでのサービス作成

サービス定義をJSONファイルで準備し、AWS CLIで作成します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# サービスの作成
aws ecs create-service \
  --cluster my-cluster \
  --service-name my-web-service \
  --task-definition my-web-app:1 \
  --desired-count 2 \
  --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-xxxxxxxx,subnet-yyyyyyyy],securityGroups=[sg-xxxxxxxx],assignPublicIp=DISABLED}" \
  --load-balancers "targetGroupArn=arn:aws:elasticloadbalancing:ap-northeast-1:123456789012:targetgroup/my-tg/xxxxxxxxxx,containerName=app,containerPort=8080" \
  --region ap-northeast-1

# サービスの状態確認
aws ecs describe-services \
  --cluster my-cluster \
  --services my-web-service \
  --region ap-northeast-1

# サービスの一覧表示
aws ecs list-services \
  --cluster my-cluster \
  --region ap-northeast-1

サービスの更新

タスク定義を更新してデプロイする場合は、update-serviceコマンドを使用します。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

# 新しいタスク定義でサービスを更新
aws ecs update-service \
  --cluster my-cluster \
  --service my-web-service \
  --task-definition my-web-app:2 \
  --region ap-northeast-1

# タスク数の変更
aws ecs update-service \
  --cluster my-cluster \
  --service my-web-service \
  --desired-count 4 \
  --region ap-northeast-1

# 強制的に新しいデプロイを実行
aws ecs update-service \
  --cluster my-cluster \
  --service my-web-service \
  --force-new-deployment \
  --region ap-northeast-1

サービスのAuto Scaling

ECSサービスは、Application Auto Scalingと統合してタスク数を自動調整できます。

flowchart LR
    CloudWatch["CloudWatch<br/>メトリクス"] --> AutoScaling["Application<br/>Auto Scaling"]
    AutoScaling --> ECSService["ECSサービス<br/>Desired Count"]
    
    subgraph Metrics["監視メトリクス"]
        CPU["CPU使用率"]
        Memory["メモリ使用率"]
        Request["リクエスト数"]
    end
    
    Metrics --> CloudWatch

スケーラブルターゲットの登録

1
2
3
4
5
6
7
8

# スケーラブルターゲットの登録
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-web-service \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 \
  --max-capacity 10 \
  --region ap-northeast-1

ターゲット追跡スケーリングポリシー

CPU使用率に基づくスケーリングポリシーの例です。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# CPU使用率に基づくスケーリングポリシー
aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-web-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-target-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "TargetValue": 70.0,
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "ScaleOutCooldown": 300,
    "ScaleInCooldown": 300
  }' \
  --region ap-northeast-1

サイドカーパターンの実装

ECSでは、1つのタスクに複数のコンテナを含めるサイドカーパターンを実装できます。代表的なユースケースを紹介します。

ログ収集サイドカー

アプリケーションログをFluentBitで収集し、外部に転送するパターンです。

flowchart LR
    subgraph Task["ECSタスク"]
        App["アプリコンテナ"]
        FluentBit["FluentBit<br/>サイドカー"]
    end
    
    App -->|ログ出力| FluentBit
    FluentBit -->|転送| CloudWatch["CloudWatch Logs"]
    FluentBit -->|転送| S3["Amazon S3"]

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

{
  "containerDefinitions": [
    {
      "name": "app",
      "image": "my-app:latest",
      "essential": true,
      "logConfiguration": {
        "logDriver": "awsfirelens"
      }
    },
    {
      "name": "log-router",
      "image": "amazon/aws-for-fluent-bit:stable",
      "essential": true,
      "firelensConfiguration": {
        "type": "fluentbit",
        "options": {
          "enable-ecs-log-metadata": "true"
        }
      }
    }
  ]
}

プロキシサイドカー

Envoyなどのプロキシをサイドカーとして配置し、サービスメッシュを構築するパターンです。AWS App Meshと組み合わせて使用します。

ベストプラクティス

タスク定義のベストプラクティス

1. イメージタグの固定

   • latestタグは避け、具体的なバージョンタグを使用する
   • ECRのイメージタグイミュータビリティを有効化する

2. リソース設定の最適化

   • 本番環境の負荷を計測してから適切なCPU・メモリを設定する
   • 過剰なリソース割り当てはコスト増加につながる

3. シークレット管理

   • 環境変数に機密情報を直接記載しない
   • Secrets ManagerまたはParameter Storeを使用する

4. ログ設定

   • 必ずログ出力を設定し、トラブルシューティングに備える
   • ログの保持期間とコストを考慮してロググループを設計する

サービス運用のベストプラクティス

1. デプロイメントサーキットブレーカーの有効化

   • デプロイ失敗時の自動ロールバックで可用性を確保する

2. ヘルスチェックの適切な設定

   • アプリケーションの起動時間を考慮してstartPeriodを設定する
   • ヘルスチェックエンドポイントは軽量な処理にする

3. マルチAZ配置

   • 複数のアベイラビリティゾーンにタスクを分散する
   • サブネットは少なくとも2つのAZに配置する

4. Auto Scalingの設定

   • 最小タスク数は可用性要件に基づいて設定する
   • スケールイン・アウトのクールダウン期間を適切に設定する

まとめ

本記事では、Amazon ECSのアーキテクチャからタスク定義の作成、サービスの管理までを解説しました。主要なポイントは以下のとおりです。

• ECSの4つのコンポーネント（クラスター、タスク定義、タスク、サービス）の関係性を理解することが重要
• タスク定義はコンテナの設計図であり、イメージ、リソース、環境変数、ログ設定などを定義する
• ECSサービスはタスクのライフサイクルを管理し、ロードバランサー統合やAuto Scalingを提供する
• Fargate起動タイプを選択することで、インフラ管理の負担を大幅に軽減できる

ECSは学習コストが比較的低く、AWSサービスとの統合も容易なため、コンテナワークロードの第一歩として適しています。まずはシンプルなタスク定義から始め、徐々にサイドカーパターンやAuto Scalingなどの高度な機能を取り入れていくことを推奨します。

参考リンク

• Amazon ECS ドキュメント
• タスク定義パラメータ
• AWS Fargate ドキュメント
• Amazon ECS サービス
• Application Auto Scaling
• Amazon ECS ベストプラクティスガイド