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

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アプリケーションの実用構成を図にすると以下のようになる。

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

基盤層のリソース

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オプションを使う。

json

"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:

json

"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レコードを作成

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

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ロールが必要

追加で必要なリソース:

リソース	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でキューの深さに応じてタスク数を調整

追加で必要なリソース:

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

リソース間の依存関係

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

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

チェックリスト

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

基盤層

コンテナ層

トラフィック層（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の構成が本番向け

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