ECS Fargateで必要なリソースの全体像

#aws #ecs #fargate #container #infrastructure

ECS Fargateを使ってアプリケーションを構築する際、「これで設定足りてるのかな」という不安を感じることがある。関連するリソースが多く、何が必須で何がオプショナルなのか分かりにくいからだ。

この記事では、ECS Fargateで必要なリソースを網羅的に整理し、全体像を把握できるようにする。ゴールは「自信を持って0から構築できる」状態になること。

3層構造で捉える

ECS Fargateのリソースは、大きく3つの層に分けて考えると理解しやすい。

┌─────────────────────────────────────────┐
│  トラフィック層                           │
│  Route53 → ALB → TargetGroup            │
├─────────────────────────────────────────┤
│  コンテナ層                              │
│  Cluster → Service → Task → Container   │
├─────────────────────────────────────────┤
│  基盤層                                  │
│  VPC, Subnet, SG, IAM, ECR, Logs        │
└─────────────────────────────────────────┘

基盤層: ネットワーク、権限、イメージ保管など、コンテナが動くための土台
コンテナ層: ECS固有のリソース。タスクの定義と実行を担う
トラフィック層: 外部からのリクエストをコンテナに届ける経路

下から順に構築していくイメージだ。CloudFormationで書く場合も、この順序で依存関係を意識すると整理しやすい。

全体アーキテクチャ図

Webアプリケーションの実用構成を図にすると以下のようになる。

flowchart TB
    subgraph Internet
        User[ユーザー]
    end

    subgraph AWS Cloud
        subgraph VPC
            subgraph Public Subnet
                ALB[Application Load Balancer]
                NAT[NAT Gateway]
            end

            subgraph Private Subnet
                subgraph ECS Cluster
                    Service[ECS Service]
                    Task1[Task]
                    Task2[Task]
                end
            end
        end

        Route53[Route53]
        ACM[ACM Certificate]
        ECR[ECR Repository]
        CWLogs[CloudWatch Logs]

        subgraph IAM
            ExecRole[Task Execution Role]
            TaskRole[Task Role]
        end
    end

    User --> Route53
    Route53 --> ALB
    ACM -.-> ALB
    ALB --> Service
    Service --> Task1
    Service --> Task2
    Task1 & Task2 --> NAT
    NAT --> Internet
    ECR -.-> Task1 & Task2
    Task1 & Task2 -.-> CWLogs
    ExecRole -.-> Task1 & Task2
    TaskRole -.-> Task1 & Task2

実線は通信の流れ、点線はリソースの参照関係を示している。

基盤層のリソース

VPC / Subnet / Internet Gateway / NAT Gateway

ネットワークの土台となるリソース群。

リソース	ARN形式	役割
VPC	`arn:aws:ec2:{region}:{account}:vpc/{vpc-id}`	仮想ネットワークの境界
Subnet	`arn:aws:ec2:{region}:{account}:subnet/{subnet-id}`	VPC内のネットワークセグメント
Internet Gateway	`arn:aws:ec2:{region}:{account}:internet-gateway/{igw-id}`	VPCとインターネットの接続点
NAT Gateway	`arn:aws:ec2:{region}:{account}:natgateway/{nat-id}`	プライベートサブネットからの外向き通信

構成のポイント:

Public Subnet: ALB、NAT Gatewayを配置。Internet Gatewayへのルートを持つ
Private Subnet: ECSタスクを配置。NAT Gateway経由で外部通信

なぜプライベートサブネットにタスクを置くのか？セキュリティのためだ。タスクに直接パブリックIPを付与する構成も可能だが、本番環境ではALB経由でのみアクセスを許可するのが一般的。

マルチAZ構成: 可用性のため、最低2つのAZにサブネットを配置する。ALBの要件でもある。

Security Group

リソース	ARN形式	役割
Security Group	`arn:aws:ec2:{region}:{account}:security-group/{sg-id}`	インバウンド/アウトバウンドのトラフィック制御

必要なセキュリティグループ:

ALB用SG:
- インバウンド: 0.0.0.0/0 からの 80/443
- アウトバウンド: ECSタスク用SGへの通信
ECSタスク用SG:
- インバウンド: ALB用SGからのコンテナポート（例: 8080）
- アウトバウンド: 0.0.0.0/0（外部API呼び出し、ECRからのイメージ取得など）

セキュリティグループ間の参照（SGのIDを指定）を使うことで、IPアドレスに依存しない柔軟な設定ができる。

IAM Role

ECSでは2種類のIAMロールを使い分ける。これが混乱しやすいポイント。

ロール	ARN形式	用途
Task Execution Role	`arn:aws:iam::{account}:role/{role-name}`	ECSエージェントが使用。ECRからのイメージ取得、CloudWatch Logsへの書き込み
Task Role	`arn:aws:iam::{account}:role/{role-name}`	コンテナ内のアプリケーションが使用。S3アクセス、DynamoDB操作など

┌─────────────────────────────────────────────────┐
│  ECS Agent（AWS管理）                            │
│  └─ Task Execution Role を使用                   │
│     ・ECRからイメージをpull                       │
│     ・CloudWatch Logsにログを送信                 │
│     ・Secrets Managerから秘密情報を取得           │
├─────────────────────────────────────────────────┤
│  コンテナ（アプリケーション）                      │
│  └─ Task Role を使用                             │
│     ・S3バケットへのアクセス                      │
│     ・DynamoDBの読み書き                         │
│     ・SQSへのメッセージ送信                       │
└─────────────────────────────────────────────────┘

Task Execution Roleに必要なポリシー:

AmazonECSTaskExecutionRolePolicy（AWS管理ポリシー）
Secrets Manager使用時: secretsmanager:GetSecretValue
Systems Manager Parameter Store使用時: ssm:GetParameters

Task Roleに必要なポリシー:

アプリケーションが必要とするAWSリソースへのアクセス権限
最小権限の原則に従って設計する

ECR (Elastic Container Registry)

リソース	ARN形式	役割
ECR Repository	`arn:aws:ecr:{region}:{account}:repository/{repo-name}`	コンテナイメージの保管・配信

タスク定義でイメージを指定する際のURI形式:

{account}.dkr.ecr.{region}.amazonaws.com/{repo-name}:{tag}

ECRはタスク定義から直接参照され、Task Execution Roleの権限でpullされる。

CloudWatch Logs

リソース	ARN形式	役割
Log Group	`arn:aws:logs:{region}:{account}:log-group:{log-group-name}`	コンテナログの集約・保存

タスク定義内のlogConfigurationで指定する。ロググループは事前に作成しておくか、autoCreateGroupオプションを使う。

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

コンテナ層のリソース

ECS Cluster

リソース	ARN形式	役割
Cluster	`arn:aws:ecs:{region}:{account}:cluster/{cluster-name}`	タスクとサービスを論理的にグループ化

クラスターは「箱」のようなもので、それ自体には大きな設定項目はない。Fargateの場合、キャパシティプロバイダーとしてFARGATEとFARGATE_SPOTが自動的に利用可能になる。

Container Insights: 有効にするとメトリクスとログが強化されるが、追加コストがかかる。

Task Definition

リソース	ARN形式	役割
Task Definition	`arn:aws:ecs:{region}:{account}:task-definition/{family}:{revision}`	コンテナの設計図

タスク定義はECSの中核となるリソース。設定項目が多いので主要なものを整理する。

タスクレベルの設定:

項目	説明
`family`	タスク定義のファミリー名。リビジョン管理の単位
`requiresCompatibilities`	`["FARGATE"]` を指定
`networkMode`	Fargateでは `awsvpc` 固定
`cpu`	タスク全体のCPU（256, 512, 1024, 2048, 4096）
`memory`	タスク全体のメモリ（cpuとの組み合わせに制約あり）
`executionRoleArn`	Task Execution RoleのARN
`taskRoleArn`	Task RoleのARN（アプリがAWSリソースを使う場合）

コンテナ定義の設定:

項目	説明
`name`	コンテナ名
`image`	ECRイメージURI
`portMappings`	公開するポート
`environment`	環境変数
`secrets`	Secrets Manager/Parameter Storeからの値
`logConfiguration`	ログ設定
`healthCheck`	コンテナレベルのヘルスチェック
`essential`	trueの場合、このコンテナが停止するとタスク全体が停止

CPU/メモリの組み合わせ制約:

Fargateでは有効な組み合わせが決まっている。例えば:

256 CPU: 512, 1024, 2048 MB
512 CPU: 1024〜4096 MB
1024 CPU: 2048〜8192 MB
以降、段階的に増加

Service

リソース	ARN形式	役割
Service	`arn:aws:ecs:{region}:{account}:service/{cluster-name}/{service-name}`	タスクの実行・維持・スケーリング

サービスは「タスクを指定した数だけ実行し続ける」責務を持つ。主要な設定項目:

項目	説明
`taskDefinition`	使用するタスク定義のARN
`desiredCount`	起動するタスク数
`launchType`	`FARGATE` を指定
`networkConfiguration`	サブネット、セキュリティグループ、パブリックIP割り当て
`loadBalancers`	ターゲットグループとの関連付け
`deploymentConfiguration`	ローリングアップデートの設定
`enableExecuteCommand`	ECS Execを有効にするか

networkConfiguration:

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

プライベートサブネットに配置する場合はassignPublicIp: DISABLEDにする。

トラフィック層のリソース

Application Load Balancer

リソース	ARN形式	役割
Load Balancer	`arn:aws:elasticloadbalancing:{region}:{account}:loadbalancer/app/{name}/{id}`	トラフィックの受け口、SSL終端
Listener	`arn:aws:elasticloadbalancing:{region}:{account}:listener/app/{lb-name}/{lb-id}/{listener-id}`	ポートごとのリクエスト受付
Listener Rule	`arn:aws:elasticloadbalancing:{region}:{account}:listener-rule/app/{lb-name}/{lb-id}/{listener-id}/{rule-id}`	パスやホストに基づくルーティング
Target Group	`arn:aws:elasticloadbalancing:{region}:{account}:targetgroup/{name}/{id}`	ヘルスチェック、ターゲット管理

構成の関係:

ALB
 └─ Listener (443)
     └─ Listener Rule (パス: /api/*)
         └─ Target Group
             └─ ECS Tasks (動的に登録)

Target Groupの設定ポイント:

項目	説明
`targetType`	Fargateでは `ip` を指定（`instance`ではない）
`protocol`	HTTP or HTTPS
`port`	コンテナのポート
`healthCheckPath`	ヘルスチェック用のパス
`deregistrationDelay`	ターゲット登録解除時の待機時間（デプロイ速度に影響）

ECSサービスがTarget Groupを参照し、タスクのIPアドレスを自動的に登録・解除する。

Route53 / ACM

リソース	ARN形式	役割
Hosted Zone	`arn:aws:route53:::hostedzone/{zone-id}`	DNS管理
Certificate	`arn:aws:acm:{region}:{account}:certificate/{cert-id}`	SSL/TLS証明書

HTTPS対応には:

ACMで証明書を発行（DNS検証が楽）
ALBのHTTPSリスナーに証明書を関連付け
Route53でALBへのAliasレコードを作成

リソース間の依存関係

CloudFormationで構築する際、リソースの作成順序を意識する必要がある。以下は主要な依存関係を示した図。

flowchart TD
    subgraph "作成順序: 1"
        VPC[VPC]
        IGW[Internet Gateway]
        ECR[ECR Repository]
        CWLogs[CloudWatch Log Group]
        ExecRole[Task Execution Role]
        TaskRole[Task Role]
    end

    subgraph "作成順序: 2"
        Subnet[Subnets]
        SG[Security Groups]
    end

    subgraph "作成順序: 3"
        NAT[NAT Gateway]
        ALB[ALB]
        TG[Target Group]
    end

    subgraph "作成順序: 4"
        TaskDef[Task Definition]
        Listener[Listener]
    end

    subgraph "作成順序: 5"
        Cluster[ECS Cluster]
    end

    subgraph "作成順序: 6"
        Service[ECS Service]
    end

    VPC --> Subnet
    VPC --> SG
    VPC --> IGW
    Subnet --> NAT
    Subnet --> ALB
    SG --> ALB
    SG --> Service
    ALB --> Listener
    ALB --> TG
    ECR --> TaskDef
    CWLogs --> TaskDef
    ExecRole --> TaskDef
    TaskRole --> TaskDef
    TaskDef --> Service
    Cluster --> Service
    TG --> Service
    Subnet --> Service

依存関係の読み方: 矢印の根本にあるリソースが、矢印の先のリソースから参照される。つまり、矢印の根本のリソースを先に作成する必要がある。

主要な参照関係まとめ:

リソース	参照するリソース
Subnet	VPC ID
Security Group	VPC ID
NAT Gateway	Subnet ID, Elastic IP
ALB	Subnet IDs, Security Group IDs
Target Group	VPC ID
Listener	ALB ARN, Target Group ARN, Certificate ARN
Task Definition	Execution Role ARN, Task Role ARN, ECR Image URI, Log Group Name
ECS Service	Cluster ARN, Task Definition ARN, Subnet IDs, Security Group IDs, Target Group ARN

ユースケース別の構成バリエーション

Webアプリケーション（メイン）

これまで説明してきた構成。ALB経由でHTTPリクエストを受けるパターン。

Internet → Route53 → ALB → ECS Service → Tasks

必須リソース: VPC一式、ALB一式、ECS一式、IAM、ECR、CloudWatch Logs

バッチ処理（スケジュール実行）

EventBridge（旧CloudWatch Events）でスケジュール実行するパターン。

EventBridge Rule → ECS RunTask → Task（実行後に終了）

Webアプリとの差分:

ALB、Target Groupは不要
ECS Serviceではなく、EventBridgeから直接RunTaskを呼び出す
EventBridge RuleにECSタスクを実行するIAMロールが必要

flowchart LR
    EB[EventBridge Rule] --> |RunTask| Task[ECS Task]
    Task --> |終了| Done[完了]

追加で必要なリソース:

リソース	ARN形式	役割
EventBridge Rule	`arn:aws:events:{region}:{account}:rule/{rule-name}`	スケジュール定義
EventBridge Target Role	`arn:aws:iam::{account}:role/{role-name}`	RunTaskを実行する権限

内部API（Service Connect / Cloud Map）

他のECSサービスからのみアクセスされる内部APIパターン。

ECS Service A → Service Connect → ECS Service B（内部API）

Webアプリとの差分:

ALBは不要（またはInternal ALBを使用）
Service ConnectまたはCloud Map（Service Discovery）を使用
同一VPC内での通信

Service Connect:
ECS Service Connect（2022年導入）を使うと、サービス間通信が簡潔に設定できる。サービス名でアクセス可能になる。

追加で必要なリソース:

リソース	ARN形式	役割
Service Connect Namespace	`arn:aws:servicediscovery:{region}:{account}:namespace/{namespace-id}`	サービス名前空間

ワーカー（SQS連携）

SQSからメッセージを取得して処理するパターン。

SQS Queue → ECS Task（ポーリング） → 処理

Webアプリとの差分:

ALBは不要
Task RoleにSQSへのアクセス権限が必要
アプリケーション側でSQSをポーリングするロジックが必要
Auto Scalingでキューの深さに応じてタスク数を調整

flowchart LR
    Producer[Producer] --> SQS[SQS Queue]
    SQS --> |ポーリング| Task1[Task]
    SQS --> |ポーリング| Task2[Task]
    Task1 & Task2 --> Process[処理実行]

追加で必要なリソース:

リソース	ARN形式	役割
SQS Queue	`arn:aws:sqs:{region}:{account}:{queue-name}`	メッセージキュー
Application Auto Scaling	-	タスク数のスケーリング

チェックリスト

「これで足りてる？」を確認するためのチェックリスト。

基盤層

コンテナ層

トラフィック層（Webアプリの場合）

ALBを作成したか
Target Group（targetType: ip）を作成したか
Listenerを作成したか
HTTPS対応する場合:
- ACM証明書を発行したか
- HTTPSリスナーに証明書を関連付けたか
Route53レコードを作成したか（カスタムドメインの場合）

まとめ

ECS Fargateでアプリケーションを構築する際のリソースを3層構造で整理した。

基盤層: VPC、Subnet、Security Group、IAM Role、ECR、CloudWatch Logs
コンテナ層: Cluster、Task Definition、Service
トラフィック層: ALB、Target Group、Listener、Route53、ACM

特に混乱しやすいポイント:

2つのIAMロール: Task Execution Role（ECSエージェント用）とTask Role（アプリ用）の区別
Target Groupのタイプ: Fargateではipタイプを使用
ネットワーク構成: プライベートサブネット + NAT Gatewayの構成が本番向け

チェックリストを活用して、必要なリソースが揃っているか確認しながら構築を進めてほしい。

抽出された概念

ECS Fargate - サーバーレスコンテナ実行環境の概念と3層構造
IAMロールの責務分離 - Task Execution RoleとTask Roleを分ける設計パターン
インフラの層構造 - インフラリソースを依存関係の方向で層に分けて捉えるアーキテクチャパターン

3層構造で捉える

全体アーキテクチャ図

基盤層のリソース

VPC / Subnet / Internet Gateway / NAT Gateway

Security Group

IAM Role

ECR (Elastic Container Registry)

CloudWatch Logs

コンテナ層のリソース

ECS Cluster

Task Definition

Service

トラフィック層のリソース

Application Load Balancer

Route53 / ACM

リソース間の依存関係

ユースケース別の構成バリエーション

Webアプリケーション（メイン）

バッチ処理（スケジュール実行）

内部API（Service Connect / Cloud Map）

ワーカー（SQS連携）

チェックリスト

基盤層

コンテナ層

トラフィック層（Webアプリの場合）

まとめ

関連ノート

抽出された概念