Amazon ECS が AWS マネジメントコンソールでのワンクリックイベントキャプチャとイベント履歴クエリに対応

はじめに

2025 年 10 月 2 日、AWS は Amazon Elastic Container Service（ECS）向けの新機能を発表しました。
ECS コンソール上でワンクリックでイベントキャプチャを有効化し、イベント履歴を直感的にクエリできる機能です。
この機能は全 AWS 商用リージョンおよび AWS GovCloud (US) リージョンで即座に利用可能となっています。
本記事では、新機能の詳細、従来との違い、実際の使い方、コストや制限事項についてまとめています。

新機能の概要

今回発表された新機能により、ECS のライフサイクルイベントを簡単に記録・分析できるようになりました。

主な特徴

主な特徴としては以下の 3 つです。

• ワンクリックセットアップ
• イベント履歴の長期保持
• 直感的なクエリインターフェース

ワンクリックセットアップ

ECS コンソールの設定タブから「イベントキャプチャをオンにする」ボタンをクリックするだけで有効化できます。
EventBridge ルールと CloudWatch Logs ログループが自動作成されます。

イベント履歴の長期保持

停止した ECS タスクの情報や過去のイベント履歴を、デフォルトで 7 日間（設定により 1 日～ 10 年）保持できます。

直感的なクエリインターフェース

クラスターまたはサービスの詳細ページのイベント履歴タブから、イベント履歴を検索・分析できます。
イベントタイプを選択し、フィルタ条件を指定することで必要な情報を素早く見つけることができます。

イベントタイプ

• タスク状態変更イベント：タスクやコンテナが起動・実行停止に失敗する理由を特定するのに役立つ
• サービスアクションイベント：プロビジョニングやリソース割り当ての問題を特定するのに役立つ

フィルタ条件

以下の条件を組み合わせて、イベントを絞り込むことができます。

• デプロイ ID（サービスの詳細ページでのみ使用可能）
• 開始時間/終了時刻
• サービス名
• タスク ID
• タスクの最終ステータス
• タスク定義ファミリー
• タスク定義のリビジョン

キャプチャされるイベント

イベントキャプチャは、ECS によって生成されるすべてのイベントを以下のカテゴリに保存します。

• タスク状態変更イベント
• サービスアクション
• サービスデプロイのステータス変化
• コンテナインスタンスのステータス変化

タスク状態変更イベント

コンテナの停止やその他の終了イベントを含むタスクのライフサイクルの遷移を追跡するイベントです。
トラブルシューティングやタスクのライフサイクルのタイムラインを監視するために使用できます。

サービスアクション

定常状態への到達、タスク配置の失敗、リソース制約などのイベントを含むサービス運用に関連するイベントです。
プロビジョニングやリソース割り当ての問題を特定するのに役立ちます。

サービスデプロイのステータス変化

進行中、完了、失敗といったデプロイの進行状況を追跡するイベントです。
サーキットブレーカーやロールバック設定によってトリガーされ、デプロイのステータスを監視するのに役立ちます。

コンテナインスタンスのステータス変化

EC2 および Amazon ECS マネージドインスタンス上のワークロードについて、接続状態と切断状態を示すイベントです。

仕組み

イベントキャプチャは、EventBridge を使用して ECS が生成するすべてのイベントを事前定義された CloudWatch Logs のログループに保存します。

Amazon CloudWatch Logs ロググループ

以下の形式でAmazon CloudWatch Logs ロググループが自動生成される。

ロググループ名

/aws/events/ecs/containerinsights/${clusterName}/performance

ロググループの保持期間はデフォルトで 7 日間、最大 10 年まで設定可能です。

EventBridge ルール

aws.ecs ソースからのすべてのイベントを取り込み、ロググループに転送する EventBridge ルールが自動生成される。

何が変わったのか

今回発表された新機能により、ECS のイベント管理が大きく変わりました。
イベント管理における従来の課題と新機能による変化を見ていきましょう。

従来の課題

主な課題としては以下の 4 つがありました。

• 停止タスク情報の表示期間
• 限定的なイベント履歴へのアクセス
• 煩雑なイベント保存設定
• 複数コンソール間の移動

停止タスク情報の表示期間

停止した ECS タスクの情報は 1 時間しか表示されませんでした。
深夜に発生した障害を翌朝調査しようとしても、すでに情報が消えているという状況が頻繁に発生していました。

限定的なイベント履歴へのアクセス

ECS コンソールでは最新 100 件のイベントしか表示されず、フィルタリング機能もありませんでした。
特定のタスクやデプロイ状況を追跡するには、大量のイベントから手動で探す必要がありました。

煩雑なイベント保存設定

イベントを長期保存する場合、以下の手順が必要でした。

1. EventBridge コンソールで手動でルールを作成
2. CloudWatch Logs でロググループを作成
3. 適切な IAM ロールとターゲット設定を構成
4. クエリ実行時は CloudWatch Logs Insights に移動してクエリ言語を記述

手動での設定が必要であり、設定ミスのリスクもありました。

複数コンソール間の移動

トラブルシューティングのたびに、ECS コンソール → CloudWatch Logs Insights と複数コンソール間の移動が発生していました。

新機能による変化

新機能により、従来の課題がすべて解決されました。

イベント履歴の長期保持

項目	従来	新機能
停止タスク表示	1 時間のみ	デフォルト 7 日間（最大 10 年）
イベント履歴	最新 100 件	全イベント保存
フィルタリング	なし	複数条件で絞り込み可能

ワンクリックセットアップ

「イベントキャプチャをオンにする」ボタンをクリックするだけで完了。 EventBridge ルールと CloudWatch Logs ログループが自動作成されるため、手動設定は不要です。

自動管理

作成されたリソースは AWS が自動で管理するため、設定ミスのリスクがなく無効化も簡単です。

ECS コンソール内で完結

イベント履歴タブから直感的にクエリでき、CloudWatch Logs Insights のクエリ言語を学ぶ必要がありません。
複数のコンソール間を移動することなく、すべての操作が単一のコンソール内で完結します。

使い方

新機能の使い方をイベントキャプチャの有効化から、実際のクエリ方法までを説明します。

イベントキャプチャの有効化

1. ECS コンソールでクラスター詳細ページを開く
2. 「設定」タブを選択
3. 「イベントキャプチャをオンにする」ボタンをクリック
4. 保持期間を設定

動作確認用サンプル

新機能を実際に試すためにシンプルなタスク定義を用意します。
以下は意図的にコンテナを異常終了させるタスク定義の例です。

タスク定義

{
  "family": "event-capture-demo",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [
    {
      "name": "failing-container",
      "image": "busybox:latest",
      "essential": true,
      "command": ["sh", "-c", "echo 'Starting container'; sleep 5; exit 1"]
    }
  ]
}

このタスク定義では、コンテナが起動後5秒待機してから exit code 1 で異常終了します。
essential: true が設定されているため、このコンテナが終了するとタスク全体が停止します。
この失敗イベントを Event History で追跡することで、新機能の動作を確認できます。

サービスの作成

1. 上記のタスク定義を登録
2. サービスを作成してデプロイ
3. タスクが繰り返し起動・停止することを確認

イベント履歴のクエリ

イベントキャプチャを有効化すると、クラスター詳細ページまたはサービス詳細ページの「イベント履歴」タブからクエリが実行できるようになります。
実際の使用例として、タスクが起動失敗した場合の調査手順を見ていきましょう。

イベントタイプの選択

「イベント履歴」タブを開き、「タスク状態変更イベント」を選択します。

フィルタ条件を指定

デプロイ ID を指定して、該当するデプロイに関連するイベントのみを抽出します。

クエリ実行結果の確認

「クエリを実行」ボタンをクリックすると、該当するイベントが一覧表示されます。

イベント詳細を確認すると、以下の情報が表示されます。

• 停止コード：EssentialContainerExited
• 停止理由：Essential container in task exited
• コンテナ終了コード：1

新機能のメリット

従来は CloudWatch Logs Insights でクエリ言語を書いて調査する必要がありましたが、新機能では ECS コンソール内でフィルタを選択し、数クリックで根本原因を特定できます。
また、デプロイから数時間後でも情報が保持されているため深夜のデプロイを翌朝調査することが可能になりました。

コストと制限事項

新機能を利用する前に知っておくべきコストと制限事項について説明します。

料金体系

イベントキャプチャを有効化すると、以下のリソースコストが発生します。

• EventBridge
• CloudWatch Logs

EventBridge

• AWS管理イベント（aws.ecs ソース）は無料
• イベント取り込みに課金は発生しない

CloudWatch Logs

• 取り込み：$ 0.50 / GB（無料枠：月 5 GB）
• 保存：$ 0.03 / GB / 月
• クエリ実行：$ 0.005 / GB スキャン

コスト例

東京リージョンにおける環境規模ごとの月額概算は以下のようになります。

環境規模	ログ量 / 日	保持期間	月額概算
小規模	100 MB	7 日	$ 1 ~ 2
中規模	1 GB	30 日	$ 13 ~ 15
大規模	10 GB	30 日	$ 150 ~

コスト最適化のポイント

• 保持期間を適切に設定（本番環境 30 日、開発環境 7 日など）
• まずは非本番環境でログ量を測定
• 必要に応じて保持期間を調整

制限事項

機能面の制限

• イベントキャプチャは全イベントを保存、特定イベントのみの選択的保存は不可
• ECS コンソールは事前定義されたクエリパラメータのみ対応
• 高度なクエリには CloudWatch Logs Insights の直接使用が必要
• ライブテール機能は ECS コンソールでは利用不可

運用上の注意点

• イベントキャプチャを無効化すると、EventBridge ルールは自動削除
• イベントキャプチャ無効化後、既存ログデータの保持期間中は残る
• クラスタ単位での有効化となり、サービス単位では設定不可

まとめ

今回発表された新機能は既存の EventBridge と CloudWatch Logs の組み合わせを、ワンクリックで利用できるようにした実用的な改善です。
設定の煩雑さがなくなり、トラブルシューティングが ECS コンソール内で完結するようになりました。
小規模環境であれば月額 $ 1 ~ 2 程度から始められるため、まずは非本番環境で実際に試してみることをお勧めします。

参考リンク