Question

A company runs a critical order-processing service on Amazon ECS with Fargate. During a recent deployment, tasks began stopping repeatedly with the stopped reason 'Essential container in task exited' and exit code 1, creating a crash loop that generated hundreds of task state change events. The operations team wants an automated response that captures diagnostic details (task ARN, stopped reason, and the failing container's exit code) and posts them to an incident channel, but only when a task stops for a NON-deployment reason — routine scale-in and successful deployment stops should be ignored. Which approach BEST meets these requirements?

Accepted Answer

Create an EventBridge rule matching the 'ECS Task State Change' event with an event pattern that filters on lastStatus 'STOPPED' and a stoppedReason that is anything-but the scale-in and deployment reasons, targeting a Lambda function that parses the detail and posts to the incident channel.

Answer

Configure a CloudWatch alarm on the ECS RunningTaskCount metric with a threshold of the desired count, and use an alarm action to invoke an SNS topic that notifies the incident channel whenever the count drops.

Answer

Enable ECS Container Insights and create a Contributor Insights rule on stopped task logs, then schedule an EventBridge rule every five minutes to invoke a Lambda that queries the rule and posts summaries to the incident channel.

Answer

Create an EventBridge rule matching all 'ECS Task State Change' events and target a Lambda function that inspects every event, calls DescribeTasks to determine the exit code, and decides in code whether the stop was deployment-related before notifying.