クラウドキャリアフリーランス
技術記事 2026/8/11

ECSのサービスデプロイに監査ログが付いた — Action Logsをどこに何日残すか

Amazon ECS Action Logs(2026年7月21日発表)は、デプロイ中にECSが裏側で実行した操作をタイムスタンプ付きで記録します。記録内容と有効化手順を整理し、配信先3択とデフォルト7日保持の設計判断を解説します。

  • #Amazon ECS
  • #オブザーバビリティ
  • #CloudWatch Logs
  • #監査ログ
  • #SRE

Amazon ECSでサービスをデプロイして失敗したとき、調査の手がかりが乏しいという課題があります。サービスイベントには結果が短く出るだけで、ECSが裏側でどこまで進んで何につまずいたのかは見えません。2026年7月21日、AWSはこの区間を可視化する Amazon ECS Action Logs を発表しました。本記事は、Action Logsが何を記録するのか、どう有効化するのかを公式仕様に沿って整理したうえで、実務上の判断が必要になる「配信先をどれにするか」「デフォルトの保持期間7日のままでよいか」という設計論点を解説します。対象読者は、ECS/Fargateの運用設計やSREを担い、デプロイ障害調査の可観測性と監査証跡の設計に関心があるAWSエンジニアです。

何が変わったか — 状態遷移の「あいだ」が記録されるようになった

これまでECSの利用者が観測できたのは、リソースの開始状態と終了状態が中心でした。デプロイが失敗しても、その間にECSがどこまで進んでいたのかは外から見えず、原因の切り分けにAWSサポートへの問い合わせが必要になる場面がありました。

Action Logsは、この「あいだ」を埋めます。公式ドキュメントによれば、クラスタ内でECSが利用者に代わって実行するリソース操作・状態遷移・サービス起点のAPI呼び出しを、タイムスタンプ付きで記録します。従来見えなかった操作の例として、コンテナイメージのダウンロード、ロードバランサへの登録、セキュリティグループの設定が公式に挙げられています。記録対象は、サービスデプロイ(状態遷移・ロールバック・ライフサイクルフック実行)とManaged Daemonのライフサイクル(作成・更新・削除、インスタンスのドレイン)の2つです。

各ログエントリはJSON形式で、次のフィールドを持ちます。

フィールド内容
timestampイベント発生時刻(Unixミリ秒)
logLevelINFO / WARN / ERROR
resourceArnopt-inのスコープを表すクラスタARN
actionSourceIdサブリソース識別子(サービスARN・デーモンARNなど)
eventNameアクション識別子(例: DAEMON_DEPLOYMENT_IN_PROGRESS
detailイベント固有の追加情報を持つJSONペイロード
account / regionAWSアカウントID/発生リージョン

実務上見逃せない副次効果として、公式ドキュメントは「失敗したタスクのメタデータを、標準の1時間の保持期間を超えて保持できる」と記載しています。ECSでは失敗タスクの詳細情報が短時間で参照できなくなるため、夜間の失敗を翌朝調べようとしても情報が残っていない状況が起こり得ました。Action Logsを有効にしておけば、その情報が配信先に残ります。またログの発行は fire-and-forget 方式で、ECSのリソース操作をブロックせず、一時的な配信失敗が起きてもワークロードの処理は継続すると明記されています。

有効化はクラスタ単位のopt-inで、ECSコンソールまたはCloudWatch Logsのvended log delivery APIから設定します。APIの場合は PutDeliverySource(ログ種別 EcsActionLogs でクラスタARNを登録)、PutDeliveryDestination(配信先を指定)、CreateDelivery(両者を接続)の3ステップです。操作するIAMアイデンティティには logs:PutDeliverySourcelogs:PutDeliveryDestinationlogs:CreateDeliverylogs:GetDelivery に加え ecs:AllowVendedLogDeliveryForResource が必要で、配信先がCloudWatch Logsなら対象ロググループのリソースポリシーで delivery.logs.amazonaws.comlogs:CreateLogStreamlogs:PutLogEvents を許可しておきます。提供範囲は2026年7月時点で全AWSリージョンおよびAWS GovCloud (US) リージョンです。

設計判断①:配信先3択をどう選ぶか

配信先はCloudWatch Logs・Amazon S3・Amazon Data Firehoseの3択で、「調査用途か、監査証跡か、既存ログ基盤への集約か」で選び分けます。

ECS Action Logsの配信先3択を比較する図。CloudWatch Logsはデフォルト保持7日で即時調査向き、Amazon S3は5分ウィンドウでパーティションされgzip圧縮され長期保管向き、Amazon Data FirehoseはNDJSONをニアリアルタイム配信し既存SIEMへの集約向きと整理している
図1: 配信先3択の比較。デフォルト設定・向く用途・設計上の論点

CloudWatch Logs を選ぶと、/aws/vendedlogs/ecs/action-logs/{cluster-name} にログが集まり、サブリソースごとに {actionSourceId} を名前とするログストリームが分かれます。「どのサービスのデプロイか」で追いやすく、Logs Insightsでの横断検索もそのまま使え、デプロイ失敗を即座に調べる用途に最も素直な選択肢です。

Amazon S3 はアカウント・リージョン・5分単位の時間ウィンドウでパーティションされgzip圧縮されます。ストレージ単価が低くライフサイクルルールで長期保管階層へ移行できるため監査での数年単位の履歴証拠向きですが、即時の検索性は低くAthena等を別途要します。Amazon Data Firehose はNDJSONでニアリアルタイム配信するため、既にSIEMや外部ログ基盤へ集約済みの組織向けです。ただし配信先の運用が別途必要で、3択の中で最も構成が重くなります。

Action Logsは有料機能で、標準のCloudWatch vended logs料金(取り込み量・保存量に応じた課金)が適用されます。固有の別建て料金は無く、無料でもありません。デプロイ頻度が高い大規模クラスタでは有効化を本番環境に絞る判断もあります。実際の料金は各サービスの最新の料金表で確認してください。

設計判断②:デフォルト保持7日のままでよいか

配信先の選定と同じく重要なのが保持期間です。ECSコンソールからCloudWatch Logsを配信先として有効化すると、公式ドキュメントによればデフォルトの保持期間は7日で、7日を過ぎたログは消えます。

7日で足りるかは用途次第です。

  • デプロイ失敗の一次調査なら、失敗はデプロイ直後に検知されるため7日はおおむね実用的です。
  • 監査の履歴証拠なら不足します。監査は四半期・年単位で「いつ何が変更・適用されたか」を求めるため、保持期間を延ばすか長期保管向きの配信先を選ぶ必要があります。

保持期間は配信先側で構成します。CloudWatch Logsならロググループの保持期間を監査要件に合わせて延長し、コストが見合わなければS3へ配信して低コストな長期保管に寄せます。調査のしやすさと長期保管の両方が要るなら両方を配信先にすることも可能です。注意したいのは、この既定値がコンソールでの有効化に紐づく点です。CLIやIaCで PutDeliveryDestination にロググループを指定する場合、保持期間はそのロググループの設定に従います。CloudWatch Logsのロググループは公式ドキュメントによれば既定で無期限保存のため、IaCで新規作成時に保持期間の指定を省くと意図せず保存料金が積み上がります。7日と無期限のどちらに倒れるかが有効化の経路で変わるため、保持期間は既定任せにせず明示的に指定するのが安全です。

Action Logs / CloudTrail / ECS Exec の役割分担

Action Logsは既存の可観測性機能を置き換えるものではありません。デプロイ調査で使う3つの機能は、それぞれ見ている層が異なります。

ECS Action Logs・AWS CloudTrail・ECS Execの役割分担を示す図。Action LogsはECSのオペレーション層で「ECSが裏で何をしたか」、CloudTrailはAPI層で「誰がどのAPIを呼んだか」、ECS Execは実行環境層で「コンテナの中はどうなっているか」を担い、3つは代替ではなく補完関係にあると整理している
図2: 3つの機能は見ている層が異なり、代替ではなく補完関係にある

CloudTrail はAPI呼び出しを記録します。UpdateService を誰がいつどのパラメータで呼んだかという「変更の指示」の証跡は残りますが、ECSが内部でどう動いたかは記録しません。Action Logs が埋めるのはまさにその区間で、逆に誰が指示したかはAction Logsの守備範囲外です。ECS Exec は実行中コンテナへの対話的アクセス手段で、状態はその場で確認できますが事後参照できる証跡ではありません。

したがってデプロイ失敗の調査は「CloudTrailで変更の指示を特定し、Action Logsで進行と失敗地点を特定し、必要ならECS Execでコンテナ内部を確認する」流れになります。監査の観点でも、CloudTrailの「誰が変更したか」とAction Logsの「どう適用されたか」は別の証跡で、片方だけでは説明が閉じません。両方を保持対象として設計します。

なお、Action Logsを有効化すると、AWSマネジメントコンソールのAmazon Qがこのログを参照し、デプロイ失敗やデーモンの問題のデバッグをコンソール上で支援します。

まとめ

Amazon ECS Action Logs(2026年7月21日発表)は、サービスデプロイとManaged Daemon更新時にECSが実行する操作を、タイムスタンプ付き構造化ログとして記録する機能です。これまで開始・終了状態しか見えなかった区間の中間ステップが記録され、失敗タスクのメタデータを標準の1時間保持期間を超えて残せるようになりました。設計判断は2つで、配信先は即時調査ならCloudWatch Logs、長期の監査証跡ならS3、既存ログ基盤への集約ならData Firehoseという選び分けと、コンソール有効化時のCloudWatch Logs保持期間が既定7日であり監査要件があれば既定値のままにしないことです。Action LogsはCloudTrail・ECS Execの代替ではなく、見る層が異なる補完的な機能として組み合わせます。

出典

For Freelancers

AWSフリーランス案件、お探しですか?

案件探しから単価交渉・契約手続き・参画後のフォローまで、専任コンサルタントが伴走します。 お名前とメールだけで、まずは無料でご相談いただけます。

案件を探す