Amazon ECS (Fargate) でマイクロサービスを運用している企業の DevOps チームは、ECS タスクが非正常終了（exit code 非ゼロ：プロセス終了コード。0が正常終了、それ以外が異常終了を示す）で停止した際に Lambda 関数を起動してインシデント対応を自動化したいと考えています。ポーリング（定期的な問い合わせ）を使わずにリアルタイムで ECS タスクの障害を検出する最も適切な方法はどれですか？
正解： Amazon EventBridge ルールを作成し、ソース `aws.ecs`・detail-type `ECS Task State Change`・`detail.lastStatus` が `STOPPED` かつ `detail.containers[0].exitCode` が 0 以外の条件でフィルタリングし、Lambda 関数をターゲットに設定する。 Amazon ECS はタスクの状態変化（Pending→Running→Stopped 等）をリアルタイムで EventBridge に自動発行します。`ECS Task State Change` イベントと `lastStatus: STOPPED`・exitCode フィルターを組み合わせることで、タスク障害のみを精度高く捕捉できるイベント駆動型アーキテクチャが実現します。 Aは誤りです。RunningTaskCount の減少はスケールイン（正常な縮小）や正常なタスク完了でも発生するため障害のみを識別できません。また CloudWatch アラームには評価期間があり即時性に欠けます。 Cは誤りです。CloudTrail は ECS のコントロールプレーン API（CreateService・StopTask などの管理操作）を記録します。タスク内のコンテナプロセスが自律的に終了して停止した場合は `StopTask` API は呼び出されないため、CloudTrail では検出できません。 Dは誤りです。EventBridge Scheduler で定期的に Lambda を起動して ECS API でタスク状態を確認する手法は、ポーリング（定期問い合わせ）型のアーキテクチャであり、タスク障害発生の瞬間をリアルタイムで検知する要件を満たしません。また1分ごとの Lambda 実行は不要なコストを発生させます。