🌟
✅ AWS Step Functionsをマスターする方法

2025/04/02に公開
 ✅ AWS Step Functionsをマスターする方法
 1. 基本を学ぶAWS Step Functionsは、複数の処理（ステップ）をつなげて自動化するためのサービス。

主に「状態（State）」と「タスク（Task）」で構成される「状態マシン」を設計していく。

 スタート地点：AWS公式のGetting Startedガイド
Datacampなどの初心者向けチュートリアル

 前提スキル：AWSアカウント
基本的なAWSサービス（IAM、Lambdaなど）の知識
JSONの読解力
Pythonの基礎

 2. シンプルなワークフローを構築Step Functionsのビジュアルエディタを使って、簡単なワークフローを作成する。

 例：記事ステータスに基づく処理
First関数で記事の状態を受け取る

Choice状態でステータス（pending/review）を判定
該当するLambda関数に処理を振り分け（MoveToPublish/AddToReviewなど）
// 例：First関数のコード（Lambda）
export const handler = async (event) => {
  const { status, name } = event;
  return { name, status };
};
IAMロールを設定し、状態マシンに割り当て。すべて完了したら「Create」でデプロイ。

 3. テストと最適化
 テスト：成功ケースと失敗ケースを用意（例：3歳の子は登録OK、5歳はNG）
実行し、Graph Viewで状態の流れを確認

 最適化ポイント：状態遷移を最小限に（コスト削減）
Lambdaのタイムアウトや失敗時のRetry/Catch設定を使う
エラーが起きた場合でも処理が落ちないようにする

 4. コストと制限への対応
 コスト：無料枠：月4,000回の状態遷移
それ以降：1,000回あたり$0.025
例：10遷移×10万画像処理 + リトライ込み＝約$25.25

 実行制限：1実行あたり25,000状態遷移
リクエストサイズ上限：1MB
タグ数制限：最大50個
制限はAWSサポート経由で引き上げ申請可。

 5. ワークフローの種類比較（Standard vs Express）

種類
実行モデル
最大時間
適用例
特徴


Standard
Exactly-once
1年
複雑な長期処理
実行履歴をStep Functions内で確認可能

Express
At-least-once
5分
高頻度・短時間処理
CloudWatchでログ確認、コストは回数＋時間課金


 6. サービス統合パターン（抜粋）

サービス
Request Response
Run a Job (.sync)
Wait for Callback


Lambda
○
×
○

ECS/Fargate
○
○
○

AWS Batch
○
○
×

Athena
○
○
×


 7. 高度な使い方
 Amazon States Language（ASL）を理解するJSONで状態マシンを定義できる
公式ドキュメントを読みながら実例を試すとよい

 よくある使い方データ処理パイプライン（ETL）
マイクロサービスの連携制御
GDPRに対応した削除フローの自動化

 代替案：シンプルな定時実行ならEventBridge + Lambdaの方が安く済むことも

 🔚 結論AWS Step Functionsをマスターするには：
基本から手を動かして学ぶ
実践的なワークフローを作る
テストと最適化を繰り返す
コストと制限も考慮する
最終的には、**「見える化」「堅牢性」「スケーラビリティ」**を意識して設計・運用できるようになることが目標です。
以下に、AWS Step Functions で使用される Amazon States Language (ASL) の定義例を示します。

 ✅ ASL 定義例：シンプルな状態マシンこの例は、「記事のステータス」に応じて処理を振り分けるワークフローです。
{
  "Comment": "記事のステータスによって処理を分岐する状態マシン",
  "StartAt": "First",
  "States": {
    "First": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:FirstFunction",
      "Next": "CheckStatus"
    },
    "CheckStatus": {
      "Type": "Choice",
      "Choices": [
        {
          "Variable": "$.status",
          "StringEquals": "pending",
          "Next": "AddToReview"
        },
        {
          "Variable": "$.status",
          "StringEquals": "review",
          "Next": "MoveToPublish"
        }
      ],
      "Default": "ShowArticle"
    },
    "AddToReview": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:AddToReview",
      "Next": "ShowArticle"
    },
    "MoveToPublish": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:MoveToPublish",
      "Next": "ShowArticle"
    },
    "ShowArticle": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:ShowArticle",
      "End": true
    }
  }
}

 🔍 補足ポイント
"StartAt": ワークフローの開始状態名

"Type":

"Task" → Lambda などの実行

"Choice" → 条件分岐

"End": true → 終了


"Resource": 実行する Lambda 関数の ARN

"Variable": 条件で使う JSON パス（例：$.status）

 🎯 入力例（実行時）{
  "name": "article1",
  "status": "pending"
}
この例では "AddToReview" が実行され、その後 "ShowArticle" に進みます。
Retry・Catchによるエラーハンドリングと、.waitForTaskTokenを使った非同期実行パターンの両方を、実用的でシンプルなASLコード付きで紹介する。

 ✅ ① Retry・Catch 付きエラーハンドリングのASL例
 状況：Lambda関数が一時的に失敗する可能性がある（例：ネットワークやDB接続エラーなど）
{
  "StartAt": "RiskyTask",
  "States": {
    "RiskyTask": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:RiskyFunction",
      "Retry": [
        {
          "ErrorEquals": ["States.ALL"],
          "IntervalSeconds": 3,
          "MaxAttempts": 2,
          "BackoffRate": 2.0
        }
      ],
      "Catch": [
        {
          "ErrorEquals": ["States.ALL"],
          "Next": "HandleError"
        }
      ],
      "Next": "SuccessState"
    },
    "HandleError": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789012:function:ErrorHandler",
      "End": true
    },
    "SuccessState": {
      "Type": "Pass",
      "Result": "正常完了",
      "End": true
    }
  }
}

 補足：
Retry: 最大2回リトライ（3秒→6秒）して、それでも失敗したら Catch へ

Catch: すべてのエラーを HandleError に流す

States.ALL: すべてのエラーに対応（細かい制御も可能）

 ✅ ② .waitForTaskToken を使った非同期呼び出しのASL例
 状況：Step Functionsから何か処理（例：人間の承認や外部APIの非同期通知）を呼び出して、完了通知を待ちたいとき。
{
  "StartAt": "AsyncInvoke",
  "States": {
    "AsyncInvoke": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
      "Parameters": {
        "FunctionName": "arn:aws:lambda:ap-northeast-1:123456789012:function:AsyncHandler",
        "Payload": {
          "token.$": "$$.Task.Token",
          "input.$": "$"
        }
      },
      "Next": "AfterCallback"
    },
    "AfterCallback": {
      "Type": "Pass",
      "Result": "コールバック完了",
      "End": true
    }
  }
}

 補足：
invoke.waitForTaskToken を使うと、Step Functions が Lambda からのコールバックを待つ
Lambda 側は以下のように SendTaskSuccess を呼び出す必要あり：
const AWS = require('aws-sdk');
const stepfunctions = new AWS.StepFunctions();

exports.handler = async (event) => {
  const token = event.token;
  // 非同期処理や人の承認がここで行われる

  await stepfunctions.sendTaskSuccess({
    taskToken: token,
    output: JSON.stringify({ message: "完了！" })
  }).promise();

  return;
};

 🔚 結論：Step Functionsを本気で活用するなら…
Retry と Catch は 信頼性の基本装備

.waitForTaskToken は 人間の介入や非同期システムとの橋渡し
実務でよく使う「バッチ処理の完了待ち（.sync）」パターンと、CloudWatchログへの連携の具体例を紹介する。これを押さえれば、AWS Step Functionsを使ったジョブ監視やトラブル解析もレベルアップする。

 ✅ ① .sync を使ったバッチ処理待ち（例：AWS Batch）
 状況：非同期ジョブ（例：データ変換・バッチ処理など）の完了まで自動で待ちたいとき。
{
  "StartAt": "RunBatchJob",
  "States": {
    "RunBatchJob": {
      "Type": "Task",
      "Resource": "arn:aws:states:::batch:submitJob.sync",
      "Parameters": {
        "JobDefinition": "my-batch-job-def",
        "JobName": "example-job",
        "JobQueue": "my-job-queue",
        "ContainerOverrides": {
          "Command": ["python", "batch_task.py"]
        }
      },
      "Next": "JobCompleted"
    },
    "JobCompleted": {
      "Type": "Pass",
      "Result": "ジョブ完了",
      "End": true
    }
  }
}

 補足：
.sync がついていると、ジョブ完了までStep Functionsが自動で待つ
Jobが失敗した場合は、Retry/Catchで対応できる
LambdaやECSの .sync 版もある（arn:aws:states:::lambda:invoke.sync, ecs:runTask.sync）

 ✅ ② CloudWatch Logs 連携の例（Express ワークフロー専用）
 状況：Step Functionsの実行ログをCloudWatch Logsに自動出力して、監視・トラブル対応に活用したい。
{
  "type": "EXPRESS",
  "loggingConfiguration": {
    "level": "ALL",
    "includeExecutionData": true,
    "destinations": [
      {
        "cloudWatchLogsLogGroup": {
          "logGroupArn": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/stepfunctions/my-express-logs:*"
        }
      }
    ]
  },
  "definition": {
    // ASL定義がここに入る
  }
}

 補足：
Expressタイプのみログ設定可（Standardは視覚ログが標準装備）

level：ERROR, FATAL, ALLなど

includeExecutionData: true で入出力も含めて保存できる

CloudWatch Logs Insightsでクエリ分析も可能（例：どの状態が一番失敗してる？など）

 ✅ まとめ：この2つが必要な理由

パターン
現場での用途


.sync
ジョブの完了を確実に待って次に進む


CloudWatch連携

障害分析・実行トレースができる

ECS/Fargate .syncでのジョブ完了待ちパターンと、EventBridgeでジョブ完了を非同期通知してStep Functionsを続行するパターンを紹介する。

 ✅ ① ECS/Fargate .sync パターン：完全同期型ワークフロー
 状況：ECS Fargateで重い処理を実行し、それが完了するまでワークフローを止めておきたい。
{
  "StartAt": "RunFargateTask",
  "States": {
    "RunFargateTask": {
      "Type": "Task",
      "Resource": "arn:aws:states:::ecs:runTask.sync",
      "Parameters": {
        "LaunchType": "FARGATE",
        "Cluster": "my-ecs-cluster",
        "TaskDefinition": "my-task-def:1",
        "NetworkConfiguration": {
          "awsvpcConfiguration": {
            "Subnets": ["subnet-xxxxxx"],
            "AssignPublicIp": "ENABLED"
          }
        },
        "Overrides": {
          "ContainerOverrides": [
            {
              "Name": "main-container",
              "Command": ["python", "process.py"]
            }
          ]
        }
      },
      "Next": "Done"
    },
    "Done": {
      "Type": "Pass",
      "End": true
    }
  }
}

 補足：
ecs:runTask.sync → ジョブ完了まで自動で待機
結果が返ってきたら Next に進む
ネットワークは awsvpc モード必須（Fargate利用時）

 ✅ ② 完全非同期：EventBridge + Task Tokenで外部ジョブの終了通知
 状況：処理が長い・外部システムが関わるため、Step Functionsから起動 → 完了通知を後から受け取る構成にしたい。

 🔧 流れ概要：Step Functionsが Lambda に Task Token を渡して実行
Lambdaがジョブを外部に投げる（ECSでもバッチでもOK）
外部ジョブが完了 → EventBridge でイベント発火
EventBridge → Lambda → SendTaskSuccess でStep Functionsが再開

 Step Functions側（.waitForTaskToken）{
  "StartAt": "AsyncJobStart",
  "States": {
    "AsyncJobStart": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
      "Parameters": {
        "FunctionName": "arn:aws:lambda:ap-northeast-1:123456789012:function:TriggerJob",
        "Payload": {
          "token.$": "$$.Task.Token",
          "input.$": "$"
        }
      },
      "Next": "Complete"
    },
    "Complete": {
      "Type": "Pass",
      "End": true
    }
  }
}

 Lambda（TriggerJob）でECS/Fargate起動 & Task Token保存exports.handler = async (event) => {
  const taskToken = event.token;
  const input = event.input;

  // DynamoDBなどにtaskTokenとジョブIDを保存

  // ECS起動 or 外部API呼び出しなど非同期ジョブ実行

  return;
};

 外部ジョブ完了 → EventBridge → Lambda → Step Functions再開// Lambda(EventBridgeターゲット)で完了検知後
const AWS = require('aws-sdk');
const stepfunctions = new AWS.StepFunctions();

exports.handler = async (event) => {
  const token = event.taskToken; // DynamoDB等から取得

  await stepfunctions.sendTaskSuccess({
    taskToken: token,
    output: JSON.stringify({ message: "Job completed" })
  }).promise();
};

 🧠 まとめ

方法
向いているケース
特徴



.sync (ECS/Fargate)
処理完了を同期で待ちたい
シンプル・短時間処理向け


.waitForTaskToken + EventBridge
外部処理・人の作業・長時間バッチ
柔軟でスケーラブル・やや実装複雑

「Step Functions × ECS Fargate × 非同期処理（EventBridge）」構成の全体像を、図とTerraformテンプレートでガッツリまとめる。

 ✅ 1. 全体構成図（非同期型ワークフロー）┌────────────┐
│ StepFunctions│
│  (waitForTaskToken)│
└──────┬─────┘
       │ Token付きPayload
       ▼
┌────────────┐
│ Lambda (TriggerJob)│
└──────┬─────┘
       │ ジョブ起動 + Token保存
       ▼
┌────────────┐
│ ECS Fargate Job │────┐
└────────────┘        │
                      ▼
             ┌────────────┐
             │ EventBridge │ (ジョブ完了イベント)
             └──────┬─────┘
                    ▼
          ┌────────────────┐
          │ Lambda (Callback)│
          └──────┬─────────┘
                 │ sendTaskSuccess(token)
                 ▼
         StepFunctions 続行

 ✅ 2. Terraformテンプレート例以下の構成を簡略化して提示：
Step Functions定義
Lambda (TriggerJob / Callback)
ECSタスク定義
EventBridgeルール
必要なIAMロール

 main.tf（一部抜粋）provider "aws" {
  region = "ap-northeast-1"
}

resource "aws_iam_role" "step_function_role" {
  name = "StepFunctionExecutionRole"
  assume_role_policy = jsonencode({
    Version = "2012-10-17",
    Statement = [{
      Effect = "Allow",
      Principal = {
        Service = "states.amazonaws.com"
      },
      Action = "sts:AssumeRole"
    }]
  })
}

resource "aws_sfn_state_machine" "job_flow" {
  name     = "JobExecutionFlow"
  role_arn = aws_iam_role.step_function_role.arn

  definition = file("${path.module}/statemachine.json")
  type       = "STANDARD"
}

 statemachine.json（ASL定義）{
  "StartAt": "TriggerJob",
  "States": {
    "TriggerJob": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
      "Parameters": {
        "FunctionName": "arn:aws:lambda:ap-northeast-1:123456789012:function:TriggerJob",
        "Payload": {
          "token.$": "$$.Task.Token",
          "input.$": "$"
        }
      },
      "Next": "Done"
    },
    "Done": {
      "Type": "Pass",
      "End": true
    }
  }
}

 lambda.tf（TriggerJob Lambda）resource "aws_lambda_function" "trigger_job" {
  function_name = "TriggerJob"
  runtime       = "nodejs18.x"
  handler       = "index.handler"
  role          = aws_iam_role.lambda_exec.arn

  filename = "lambda_trigger.zip"
}
※lambda_trigger.zipには、ECS起動処理とToken保存のコードを含める（例：DynamoDB保存など）

 eventbridge.tf（ジョブ完了通知）resource "aws_cloudwatch_event_rule" "job_complete" {
  name        = "ecs-job-complete"
  event_pattern = jsonencode({
    "source": ["aws.ecs"],
    "detail-type": ["ECS Task State Change"],
    "detail": {
      "lastStatus": ["STOPPED"]
    }
  })
}

resource "aws_cloudwatch_event_target" "callback_lambda" {
  rule      = aws_cloudwatch_event_rule.job_complete.name
  target_id = "callbackLambda"
  arn       = aws_lambda_function.callback_job.arn
}

 callback_lambda.tf（sendTaskSuccess）resource "aws_lambda_function" "callback_job" {
  function_name = "CallbackJob"
  runtime       = "nodejs18.x"
  handler       = "index.handler"
  role          = aws_iam_role.lambda_exec.arn

  filename = "lambda_callback.zip"
}
このLambdaは、DynamoDBなどからtaskTokenを取得して、sendTaskSuccess()を呼び出す。

 ✅ 必要に応じて追加するもの
DynamoDB：TokenとジョブIDの保存用

IAM Role: Lambdaに対する states:SendTaskSuccess, ECSの起動権限など

SecurityGroup/Subnet: Fargate実行のため

 🎯 まとめこの構成は、
ジョブ完了までワークフローを止める
ジョブ完了を「外部」から通知して再開する
スケーラブルで耐障害性も高い
という、**“現場でガチ使いされるStep Functions設計”**です。
# 🚀 Step Functions × ECS × EventBridge Async Pattern

このテンプレートは、**非同期ECSジョブ実行と完了通知をStep Functionsで自動制御する構成**です。  
長時間処理や外部バッチと連携したいケースで活躍します。

---

## 📦 構成要素

- **Step Functions**（`.waitForTaskToken` を使用）
- **Lambda (Trigger)**：ECSジョブ起動＋Task Token保存
- **ECS Fargate**：非同期バッチ処理（任意）
- **EventBridge**：ジョブ終了イベント検知
- **Lambda (Callback)**：Tokenを使って `sendTaskSuccess()`
- **DynamoDB**：Job IDとTask Tokenの紐づけ

---

## 🗂️ ディレクトリ構成

stepfunctions-ecs-template/

├── main.tf

├── statemachine.json

├── lambda_trigger/

│   └── index.js

├── lambda_callback/

│   └── index.js

├── eventbridge.tf

├── lambda.tf

├── callback_lambda.tf

├── variables.tf

├── outputs.tf

└── README.md

---

## 🚀 デプロイ手順

### 1. Terraform 初期化 & 実行

```bash
terraform init
terraform apply
必要に応じて variables.tf を編集してください。

 2. Lambda ZIP 作成 & アップロードそれぞれの Lambda フォルダで以下を実行：
# Trigger Lambda
cd lambda_trigger
zip -r lambda_trigger.zip .
# AWS Lambda コンソール or CLI でアップロード

# Callback Lambda
cd ../lambda_callback
zip -r lambda_callback.zip .
# 同様にアップロード

 3. Step Functions の実行Step Functions コンソールから以下のような入力で実行：
{
  "jobId": "sample-job-001"
}
> `jobId` は DynamoDB に保存されるキーで、ジョブ完了時の照合に使われます。

---

## 📚 補足事項

- Lambda は `TaskToken` を DynamoDB テーブル `TaskTokens` に保存します。
- ECS タスクが終了すると EventBridge 経由で Callback Lambda がトリガーされ、`sendTaskSuccess()` を呼び出して Step Functions が再開します。
- `TaskTokens` テーブルは Terraform または手動で事前に作成が必要です（テンプレート追加予定）。

---

## 🔧 今後の拡張アイデア

- ECS タスクの `exitCode` による成否判定
- `sendTaskFailure` を使った失敗ハンドリング
- S3 や CloudWatch Logs との連携
- CloudWatch Logs Insights での実行分析

---

ここでは、以下の4項目をすべて **実務に使える具体コード付き** で解説します：

---

## ✅ 1. ECSタスクの `exitCode` による成否判定

**目的**：ECSのタスクが正常終了したかを検出し、Step Functions側で成功/失敗を切り替える。

### Lambda（Callback側）修正例：

```js
const AWS = require("aws-sdk");
const stepfunctions = new AWS.StepFunctions();
const dynamodb = new AWS.DynamoDB.DocumentClient();

exports.handler = async (event) => {
  const taskArn = event.detail.taskArn;
  const jobId = taskArn.split("/").pop();
  const exitCode = event.detail.containers?.[0]?.exitCode;

  // Token取得
  const data = await dynamodb.get({
    TableName: "TaskTokens",
    Key: { jobId }
  }).promise();

  const token = data.Item.token;

  if (exitCode === 0) {
    await stepfunctions.sendTaskSuccess({
      taskToken: token,
      output: JSON.stringify({ status: "Job succeeded" })
    }).promise();
  } else {
    await stepfunctions.sendTaskFailure({
      taskToken: token,
      error: "ECSJobFailed",
      cause: `Job exited with code ${exitCode}`
    }).promise();
  }
};

 ✅ 2. sendTaskFailure を使った失敗ハンドリングStep Functionsは sendTaskFailure() を受け取ると、そのタスクは「失敗」として次の Catch へ進みます。

 Step Functions ASL例（Catch付き）：{
  "StartAt": "TriggerJob",
  "States": {
    "TriggerJob": {
      "Type": "Task",
      "Resource": "arn:aws:states:::lambda:invoke.waitForTaskToken",
      "Parameters": {
        "FunctionName": "arn:aws:lambda:ap-northeast-1:123456789012:function:TriggerJob",
        "Payload": {
          "token.$": "$$.Task.Token",
          "input.$": "$"
        }
      },
      "Catch": [
        {
          "ErrorEquals": ["ECSJobFailed"],
          "Next": "HandleFailure"
        }
      ],
      "Next": "Done"
    },
    "HandleFailure": {
      "Type": "Pass",
      "Result": "ジョブ失敗を検知しました",
      "End": true
    },
    "Done": {
      "Type": "Pass",
      "End": true
    }
  }
}

 ✅ 3. S3やCloudWatch Logsへの連携ECSタスクの標準出力は、タスク定義に以下を指定すれば CloudWatch Logsへ自動出力されます。

 ECSタスク定義（抜粋）："logConfiguration": {
  "logDriver": "awslogs",
  "options": {
    "awslogs-group": "/ecs/your-job",
    "awslogs-region": "ap-northeast-1",
    "awslogs-stream-prefix": "ecs"
  }
}
💡 awslogs-group を固定すれば、CloudWatch Logsで一括分析できる。
S3に出力したい場合は、タスク内で明示的に aws-sdk を使って S3.putObject() する必要あり（ログや結果を出力）。

 ✅ 4. CloudWatch Logs Insights による実行分析目的：ECSログから「失敗の多いジョブ」や「処理時間」などを簡単にクエリする。

 例1：失敗ログのみ抽出fields @timestamp, @message
| filter @message like /ERROR/ or @message like /exitCode/
| sort @timestamp desc
| limit 20

 例2：exitCodeごとのカウントfields @timestamp, @message
| parse @message /exitCode: (?<exitCode>\d+)/
| stats count(*) by exitCode

 例3：ジョブIDごとの実行回数fields @message
| parse @message /jobId: (?<jobId>[^ ]+)/
| stats count(*) by jobId
CloudWatch Logs Insights は 速くて安価 なので、Step Functions＋ECSのトラブルシュートや傾向分析にかなり有効。

 🔚 まとめ

項目
内容


✅ exitCode 成否判定
Callback Lambda内で exitCode を見て Success/Failure 分岐

✅ sendTaskFailure
失敗時の Catch ルートに分岐可能

✅ CloudWatch Logs出力

awslogs ドライバーで ECSログを保存

✅ Logs Insights 分析
ジョブの傾向・失敗率分析に最適

以下をTerraform化する

 ✅ 目的：Terraformで以下を自動作成する

CloudWatch Logsグループ（ECSタスク用ログ保存先）
Insightsクエリ定義（Saved Query）
（任意）ダッシュボード連携

 ✅ 1. CloudWatch Logsグループ作成resource "aws_cloudwatch_log_group" "ecs_logs" {
  name              = "/ecs/your-job"
  retention_in_days = 14
}
ECSタスク定義の logConfiguration と連携するロググループ。

 ✅ 2. Insightsクエリの保存（例：exitCodeごとの件数集計）Terraform では直接 Insights の「Saved query」はサポートされていないが、CloudWatch Dashboard のウィジェット経由でクエリを持たせられる。以下は workaround だ。

 ✅ 3. CloudWatch Dashboard にInsightsクエリを埋め込むresource "aws_cloudwatch_dashboard" "ecs_dashboard" {
  dashboard_name = "ecs-job-insights"

  dashboard_body = jsonencode({
    widgets = [
      {
        type = "log",
        x    = 0,
        y    = 0,
        width = 24,
        height = 6,
        properties = {
          query = "fields @timestamp, @message | parse @message /exitCode: (?<exitCode>\\d+)/ | stats count(*) by exitCode",
          region = "ap-northeast-1",
          title = "ECSジョブのexitCode集計",
          logGroupNames = [
            aws_cloudwatch_log_group.ecs_logs.name
          ]
        }
      }
    ]
  })
}
ダッシュボードで exitCode 集計が可視化され、CloudWatch Insights相当の効果をGUIで得られる。

 ✅ オプション：ログ出力に合わせたECSタスク定義の変更例（参考）"logConfiguration": {
  "logDriver": "awslogs",
  "options": {
    "awslogs-group": "/ecs/your-job",
    "awslogs-region": "ap-northeast-1",
    "awslogs-stream-prefix": "ecs"
  }
}

 ✅ まとめ：TerraformでCloudWatch Logs + クエリ可視化

リソース
機能


aws_cloudwatch_log_group
ECS/Fargateのログ保存先を定義

aws_cloudwatch_dashboard
Insightsクエリを埋め込んでGUIで可視化

logDriver設定（ECS側）
ECSタスクの標準出力をログとして保存
種類	実行モデル	最大時間	適用例	特徴
Standard	Exactly-once	1年	複雑な長期処理	実行履歴をStep Functions内で確認可能
Express	At-least-once	5分	高頻度・短時間処理	CloudWatchでログ確認、コストは回数＋時間課金
サービス	Request Response	Run a Job (.sync)	Wait for Callback
Lambda	○	×	○
ECS/Fargate	○	○	○
AWS Batch	○	○	×
Athena	○	○	×
パターン	現場での用途
`.sync`	ジョブの完了を確実に待って次に進む
CloudWatch連携	障害分析・実行トレースができる
方法	向いているケース	特徴
`.sync` (ECS/Fargate)	処理完了を同期で待ちたい	シンプル・短時間処理向け
`.waitForTaskToken` + EventBridge	外部処理・人の作業・長時間バッチ	柔軟でスケーラブル・やや実装複雑
項目	内容
✅ exitCode 成否判定	Callback Lambda内で `exitCode` を見て `Success/Failure` 分岐
✅ sendTaskFailure	失敗時の `Catch` ルートに分岐可能
✅ CloudWatch Logs出力	`awslogs` ドライバーで ECSログを保存
✅ Logs Insights 分析	ジョブの傾向・失敗率分析に最適
リソース	機能
`aws_cloudwatch_log_group`	ECS/Fargateのログ保存先を定義
`aws_cloudwatch_dashboard`	Insightsクエリを埋め込んでGUIで可視化
logDriver設定（ECS側）	ECSタスクの標準出力をログとして保存
Discussion

ログインするとコメントできます