Which solution will meet these requirements?
Create an Amazon EventBridge rule to capture task state changes. Send the event to Amazon CloudWatch Logs. Use CloudWatch Logs Insights to investigate stopped tasks.
Configure tasks to write log data in the embedded metric format. Store the logs in Amazon CloudWatch Logs. Monitor the ContainerInstanceCount metric for changes.
Configure the EC2 instances to store logs in Amazon CloudWatch Logs. Create a CloudWatch Contributor Insights rule that uses the EC2 instance log data. Use the Contributor Insights rule to investigate stopped tasks.
Configure an EC2 Auto Scaling lifecycle hook for the EC2_INSTANCE_TERMINATING scale-in event. Write the SystemEventLog file to Amazon S3. Use Amazon Athena to query the log file for errors.
Explanations:
Creating an Amazon EventBridge rule to capture task state changes and sending the event to Amazon CloudWatch Logs is the most suitable solution for logging and reviewing stopped tasks. CloudWatch Logs Insights can then be used to analyze and investigate the events for errors.
Writing log data in the embedded metric format does not specifically address logging stopped tasks. Additionally, monitoring the ContainerInstanceCount metric is unrelated to logging and reviewing stopped task errors.
EC2 instance logs and CloudWatch Contributor Insights focus on EC2 instances’ resource usage or performance, not specifically on ECS task states or errors. This option is not tailored for reviewing stopped tasks.
Using EC2 Auto Scaling lifecycle hooks to monitor EC2 instance termination events and querying the SystemEventLog file is not relevant to ECS tasks. This method only applies to EC2 instance lifecycle, not the logging of stopped ECS tasks.
If memory serves me right, the answer is:
Create an Amazon EventBridge rule to capture task state changes. Send the event to Amazon CloudWatch Logs. Use CloudWatch Logs Insights to investigate stopped tasks.