developersIO
Amazon ECSの新機能「Action Logs」でデプロイの状態遷移ログを確認してみた

Amazon ECSの新機能「Action Logs」でデプロイの状態遷移ログを確認してみた

Amazon ECSでAction Logsが利用可能になりました。デプロイ中にECSの実行する操作が構造化ログとしてCloudWatch Logsに記録されます。正常デプロイ・OOM失敗・イメージプル失敗の3パターンで出力されるイベントを確認しました。
Amazon ECSCloudWatch LogsAWS FargateログAWS
2026.07.22

はじめに

2026年7月21日、Amazon ECSでAction Logsが利用可能になりました。デプロイ中にECSの実行するオーケストレーション操作が、構造化ログとしてCloudWatch Logsに自動的に記録されるようになっています。

https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-ecs-action-logs/

Action Logsを有効化すると、デプロイ状態の追跡方法が次のように変わります。

観点 従来 Action Logs 有効化後
デプロイ状態の追跡 サービスイベント（describe-services）を都度確認 構造化ログとして CloudWatch Logs に自動記録
イメージダイジェストの特定 :latest タグの場合は特定困難 SERVICE_REVISION_STABLE で自動記録
サーキットブレーカー発動の検知 サービスイベントで確認 WARN レベルのログとして記録され、アラート連携が可能
障害原因の切り分け サービスイベント・タスクステータスを手動で相関 イベントパターン（SERVICE_REVISION_STABLE の有無）で分類可能
ログ検索・分析 非構造化テキストの目視確認 CloudWatch Logs Insights でクエリ可能

本記事ではAction LogsをCLIで有効化し、正常デプロイ・OOM失敗・イメージプル失敗の3パターンで出力されるイベントを確認しました。3パターンの結果サマリーは次のとおりです。

パターン SERVICE_REVISION_STABLE ロールバック観測 結果
正常デプロイ あり（ダイジェスト記録） — SERVICE_DEPLOYMENT_SUCCESSFUL
OOM失敗 あり（ダイジェスト記録） あり（約4分） SERVICE_DEPLOYMENT_ROLLBACK_SUCCESSFUL
イメージプル失敗 なし なし（18分以上未到達） SERVICE_DEPLOYMENT_IN_PROGRESS のみ

https://docs.aws.amazon.com/AmazonECS/latest/developerguide/action-logs.html

検証内容

検証環境

Fargate上のサービスを対象に、ap-northeast-1リージョンで検証しました。デプロイサーキットブレーカーは有効（rollback=true、しきい値50%）としています。

タスク定義 用途 イメージ CPU メモリ（タスク） メモリ（コンテナ hard limit）
action-logs-test-normal:1 正常デプロイ public.ecr.aws/nginx/nginx:latest 256 512 MiB —
action-logs-test-oom:1 OOM失敗 public.ecr.aws/docker/library/alpine:latest 256 512 MiB 6 MiB
action-logs-test-pull-fail:1 イメージプル失敗 public.ecr.aws/does-not-exist/fake-image:v9999 256 512 MiB —

Action Logs 有効化（CLI）

Action LogsはCloudWatch LogsのVended Logs配信の仕組みを利用します。ロググループ作成→リソースポリシー→配信元（Delivery Source）→配信先（Delivery Destination）→配信（Delivery）の5ステップで有効化します。配信元のlog-typeにはACTION_LOGSを指定します。

必要なIAM権限：

  • logs:CreateLogGroup
  • logs:PutRetentionPolicy
  • logs:PutResourcePolicy
  • logs:PutDeliverySource
  • logs:PutDeliveryDestination
  • logs:CreateDelivery
  • logs:GetDelivery
  • ecs:AllowVendedLogDeliveryForResource

各ステップのCLIコマンド：

# 1. ロググループ作成
aws logs create-log-group \
  --log-group-name /aws/vendedlogs/ecs/action-logs/<cluster-name> \
  --region ap-northeast-1

aws logs put-retention-policy \
  --log-group-name /aws/vendedlogs/ecs/action-logs/<cluster-name> \
  --retention-in-days 7 \
  --region ap-northeast-1

# 2. リソースポリシー（delivery.logs.amazonaws.com に書き込み許可）
aws logs put-resource-policy \
  --policy-name ecs-action-logs-delivery-policy \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Sid": "AllowECSActionLogsDelivery",
      "Effect": "Allow",
      "Principal": {"Service": "delivery.logs.amazonaws.com"},
      "Action": ["logs:CreateLogStream", "logs:PutLogEvents"],
      "Resource": "arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/ecs/action-logs/<cluster-name>:log-stream:*",
      "Condition": {
        "StringEquals": {"aws:SourceAccount": "123456789012"},
        "ArnLike": {"aws:SourceArn": "arn:aws:ecs:ap-northeast-1:123456789012:*"}
      }
    }]
  }' \
  --region ap-northeast-1

# 3. 配信元 (Delivery Source)
aws logs put-delivery-source \
  --name <source-name> \
  --resource-arn arn:aws:ecs:ap-northeast-1:123456789012:cluster/<cluster-name> \
  --log-type ACTION_LOGS \
  --region ap-northeast-1

# 4. 配信先 (Delivery Destination)
aws logs put-delivery-destination \
  --name <destination-name> \
  --output-format json \
  --delivery-destination-configuration '{"destinationResourceArn":"arn:aws:logs:ap-northeast-1:123456789012:log-group:/aws/vendedlogs/ecs/action-logs/<cluster-name>"}' \
  --region ap-northeast-1

# 5. 配信作成 (Delivery)
aws logs create-delivery \
  --delivery-source-name <source-name> \
  --delivery-destination-arn arn:aws:logs:ap-northeast-1:123456789012:delivery-destination:<destination-name> \
  --region ap-northeast-1

Action Logsのスキーマ

今回の検証で取得したイベントは次の構造でした（公式ドキュメントのスキーマ定義とフィールド配置が異なる場合があります）。

{
  "resourceArn": "arn:aws:ecs:<region>:<account>:cluster/<cluster-name>",
  "actionSourceId": "service/<cluster-name>/<service-name>",
  "logLevel": "INFO | WARN | ERROR",
  "eventTimestamp": 1784663292399,
  "detail": {
    "eventName": "<event-name>",
    "status": "IN_PROGRESS | SUCCEEDED",
    "statusReason": "<human-readable reason>",
    "serviceDeploymentArn": "arn:aws:ecs:...:service-deployment/...",
    "serviceRevisionArn": "arn:aws:ecs:...:service-revision/..."
  }
}
フィールド 意味
resourceArn 対象クラスターの ARN
actionSourceId イベント発生元（service/<cluster-name>/<service-name> 形式。ログストリーム名としても使用される）
logLevel ログレベル（INFO / WARN / ERROR）
eventTimestamp イベント発生時刻（エポックミリ秒）
detail.eventName イベント種別
detail.statusReason 人間可読の状態理由

ログストリームは service/<cluster-name>/<service-name> の命名規則で作成されるため、サービス単位でのフィルタリングが容易です。

今回の検証で確認できた eventName は次のとおりです。

eventName logLevel 意味
SERVICE_DEPLOYMENT_IN_PROGRESS INFO デプロイ開始
SERVICE_REVISION_STABLE INFO サービスリビジョン安定、イメージダイジェストにロック
SERVICE_DEPLOYMENT_SUCCESSFUL INFO デプロイ正常完了
SERVICE_DEPLOYMENT_ROLLBACK WARN サーキットブレーカー発動、ロールバック進行中
SERVICE_DEPLOYMENT_ROLLBACK_SUCCESSFUL INFO ロールバック完了

正常デプロイ時のログ確認

nginxイメージ（action-logs-test-normal:1）でサービスを作成し、正常デプロイ時に出力されるイベントを確認しました。

経過 eventName logLevel
0秒 SERVICE_DEPLOYMENT_IN_PROGRESS INFO
+34秒 SERVICE_REVISION_STABLE INFO
+約3分 SERVICE_DEPLOYMENT_SUCCESSFUL INFO

各イベントの全体構造：

{
  "resourceArn": "arn:aws:ecs:ap-northeast-1:123456789012:cluster/action-logs-test-cluster",
  "actionSourceId": "service/action-logs-test-cluster/action-logs-test-service",
  "logLevel": "INFO",
  "eventTimestamp": 1784663292399,
  "detail": {
    "statusReason": "Service deployment in progress.",
    "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:123456789012:service-deployment/action-logs-test-cluster/action-logs-test-service/xQiDJv98PtZRdF7HNahyb",
    "status": "IN_PROGRESS",
    "eventName": "SERVICE_DEPLOYMENT_IN_PROGRESS"
  }
}

{
  "resourceArn": "arn:aws:ecs:ap-northeast-1:123456789012:cluster/action-logs-test-cluster",
  "actionSourceId": "service/action-logs-test-cluster/action-logs-test-service",
  "logLevel": "INFO",
  "eventTimestamp": 1784663326125,
  "detail": {
    "statusReason": "Service revision marked stable. Locked to container image(s): public.ecr.aws/nginx/nginx:latest@sha256:709204fab25be0425d55090c79f3e84161cf99f50278543d7f6bf372e326ad1f.",
    "serviceRevisionArn": "arn:aws:ecs:ap-northeast-1:123456789012:service-revision/action-logs-test-cluster/action-logs-test-service/7911470091089632318",
    "status": "SUCCEEDED",
    "eventName": "SERVICE_REVISION_STABLE"
  }
}

{
  "resourceArn": "arn:aws:ecs:ap-northeast-1:123456789012:cluster/action-logs-test-cluster",
  "actionSourceId": "service/action-logs-test-cluster/action-logs-test-service",
  "logLevel": "INFO",
  "eventTimestamp": 1784663469912,
  "detail": {
    "statusReason": "Service deployment completed successfully.",
    "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:123456789012:service-deployment/action-logs-test-cluster/action-logs-test-service/xQiDJv98PtZRdF7HNahyb",
    "status": "SUCCEEDED",
    "eventName": "SERVICE_DEPLOYMENT_SUCCESSFUL"
  }
}

注目したいのはSERVICE_REVISION_STABLEイベントです。statusReasonにイメージダイジェスト付きでLocked to container image(s): ...@sha256:709204...と記録されています。:latestタグでデプロイした場合でも、実際に稼働したイメージのダイジェストを後から特定できます。

デプロイ失敗時のログ確認（OOM → サーキットブレーカー）

次に、意図的にOOMを発生させてサーキットブレーカーが発動する場合のログを確認しました。alpineイメージのコンテナメモリ上限を6 MiBに絞り、dd if=/dev/zeroでメモリを消費させることで、起動直後にOOMが発生する構成としています。

経過 eventName logLevel
0秒 SERVICE_DEPLOYMENT_IN_PROGRESS INFO
+53秒 SERVICE_REVISION_STABLE INFO
+約3分45秒 SERVICE_DEPLOYMENT_ROLLBACK WARN
+約4分 SERVICE_DEPLOYMENT_ROLLBACK_SUCCESSFUL INFO

各イベントの全体構造：

{
  "logLevel": "INFO",
  "eventTimestamp": 1784663519017,
  "detail": {
    "statusReason": "Service deployment in progress.",
    "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:123456789012:service-deployment/action-logs-test-cluster/action-logs-test-service/Z6HSP7lksB3wTV0bOxmpF",
    "status": "IN_PROGRESS",
    "eventName": "SERVICE_DEPLOYMENT_IN_PROGRESS"
  }
}

{
  "logLevel": "INFO",
  "eventTimestamp": 1784663571619,
  "detail": {
    "statusReason": "Service revision marked stable. Locked to container image(s): public.ecr.aws/docker/library/alpine:latest@sha256:28bd5fe8b56d1bd048e5babf5b10710ebe0bae67db86916198a6eec434943f8b.",
    "serviceRevisionArn": "arn:aws:ecs:ap-northeast-1:123456789012:service-revision/action-logs-test-cluster/action-logs-test-service/2005995910462199077",
    "status": "SUCCEEDED",
    "eventName": "SERVICE_REVISION_STABLE"
  }
}

{
  "logLevel": "WARN",
  "eventTimestamp": 1784663746287,
  "detail": {
    "statusReason": "Service deployment rolled back because the circuit breaker threshold was exceeded.",
    "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:123456789012:service-deployment/action-logs-test-cluster/action-logs-test-service/Z6HSP7lksB3wTV0bOxmpF",
    "status": "IN_PROGRESS",
    "eventName": "SERVICE_DEPLOYMENT_ROLLBACK"
  }
}

{
  "logLevel": "INFO",
  "eventTimestamp": 1784663762604,
  "detail": {
    "statusReason": "Service deployment rolled back because the circuit breaker threshold was exceeded.",
    "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:123456789012:service-deployment/action-logs-test-cluster/action-logs-test-service/Z6HSP7lksB3wTV0bOxmpF",
    "status": "SUCCEEDED",
    "eventName": "SERVICE_DEPLOYMENT_ROLLBACK_SUCCESSFUL"
  }
}

このパターンでは、イメージ自体は解決できるためSERVICE_REVISION_STABLEが出力されました。その後タスクがOOMで起動に失敗し続けた結果、SERVICE_DEPLOYMENT_ROLLBACKがWARNレベルで記録されています。statusReasonにしきい値超過の理由が明記されるため、CloudWatch Alarmsとの連携でロールバックの検知に使えます。

イメージプル失敗時のログ確認

最後に、存在しないイメージ public.ecr.aws/does-not-exist/fake-image:v9999 にサービスを更新しました。

Action Logsに出力されたのは、デプロイ開始を示すイベントのみでした（検証時間内に観測できた範囲）。

{
  "logLevel": "INFO",
  "eventTimestamp": 1784663869100,
  "detail": {
    "statusReason": "Service deployment in progress.",
    "serviceDeploymentArn": "arn:aws:ecs:ap-northeast-1:123456789012:service-deployment/action-logs-test-cluster/action-logs-test-service/IB_8BjTwukTyDzQ4uW4Ca",
    "status": "IN_PROGRESS",
    "eventName": "SERVICE_DEPLOYMENT_IN_PROGRESS"
  }
}

SERVICE_REVISION_STABLE は出力されませんでした。イメージを解決できず、ダイジェストへのロックが行えなかったためです。つまり SERVICE_REVISION_STABLE の有無によって、イメージ解決の段階で失敗したのか、イメージは解決できたがランタイムで失敗したのかを切り分けられます。

従来のサービスイベントには、コンテナ単位の失敗理由が記録されていました。

CannotPullContainerError: pull image manifest has been retried 7 time(s):
failed to resolve ref public.ecr.aws/does-not-exist/fake-image:v9999:
public.ecr.aws/does-not-exist/fake-image:v9999: not found.

Action Logsはデプロイ全体の状態遷移レベルで記録されるため、コンテナ単位の詳細を持つ従来のサービスイベントと補完的に使えます。

なお、サーキットブレーカーの発動までにかかった時間は、OOMのケースが約4分でした。イメージプル失敗のケースでは18分以上経過してもサーキットブレーカーが発動しなかったため、SERVICE_DEPLOYMENT_ROLLBACKのログは取得できていません。

CloudWatch Logs Insights クエリ例

運用で使えるクエリ例です。

-- WARN/ERROR イベントの抽出（デプロイ障害調査用）
fields @timestamp, detail.eventName, logLevel, detail.statusReason
| filter logLevel in ["WARN", "ERROR"]
| sort @timestamp asc
| limit 50

-- 全イベント時系列（サービスレベル）
fields @timestamp, detail.eventName, logLevel, detail.status, detail.statusReason
| filter @logStream like /^service\//
| sort @timestamp asc
| limit 50

-- 特定デプロイの追跡
fields @timestamp, detail.eventName, logLevel, detail.statusReason
| filter detail.serviceDeploymentArn like /<deployment-id>/
| sort @timestamp asc

-- サーキットブレーカー発動の検出
fields @timestamp, detail.eventName, detail.statusReason
| filter detail.eventName = "SERVICE_DEPLOYMENT_ROLLBACK"
| sort @timestamp desc
| limit 20

まとめ

ECS Action Logsにより、デプロイの進行・完了・ロールバックをCloudWatch Logs上で追跡できました。今回の検証では、SERVICE_REVISION_STABLEの出力有無と後続イベントを組み合わせることで、イメージ解決前後の失敗を調査しやすくなりました。ロールバック開始イベントは、デプロイ失敗を検知するアラート条件としても利用できます。

参考リンク

この記事をシェアする

AWSのお困り事はクラスメソッドへ

関連記事

[アップデート] Amazon ECS で Amazon CloudWatch Logs の Live Tail 分析をサポートしました
たかくに
2025.08.22
Amazon ECSコンソールの新しいリアルタイムデプロイ可視化機能を試してみた
suzuki.ryo
2026.07.03
Amazon Quick のチャットログやフィードバックログを CloudWatch Logs Analytics で、利用状況とエージェント改善のヒントを分析してみた
石川覚
2026.07.13
[アップデート] Amazon Managed Service for Prometheus でマネージドコレクターのログを CloudWatch ログに出力できるようになりました
枡川 健太郎
2025.10.23