In your company, AWS ECS is being used to manage Docker containers for a Java application.
Recently, to meet the market need, several important features are under development and the team is under pressure to deliver new releases.
Your manager asks you to notify the team in both Slack channel and email whenever the ECS task enters into the Stopped status so that relevant personnel can take action immediately.
What is the best way for you to implement that?
Click on the arrows to vote for the correct answer
A. B. C. D.Correct Answer - A.
CloudWatch Events can integrate with Amazon ECS to provide immediate notifications.
When there is a state change in ECS, CloudWatch Events can capture the event and notify the target.
Refer to.
https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_cwet2.htmlOption A is CORRECT: Using this CloudWatch Events rule, when the ECS task enters into the “STOPPED” state, the rule can immediately trigger the targets (Lambda and SNS).
Option B is incorrect: The issue of CloudWatch Logs is that there would be some delay for the agents to send the logs so that notifications are not as timely as option A.
Besides, the alarm cannot trigger a Lambda directly.
It has to send a notification to an SNS topic first.
Option C is incorrect: Because "ECS Container Instance State Change" is incorrect as the question asks for the state change of the ECS task instead of the instance.
Option D is incorrect: Because /var/log/docker/ may not be able to capture problems of ECS task.
Also, CloudWatch Logs cannot provide in-time notifications.
The best answer to the given question is Option A: Create the following CloudWatch Event rule. Add a target of Lambda function to send a notification in Slack and another target of SNS to send the email.
Option A proposes the most efficient and straightforward approach to notify the team in both Slack channel and email when the ECS task enters into the Stopped status. The CloudWatch Event rule is designed to listen to the ECS Task State Change events and triggers when the lastStatus attribute of the ECS task changes to STOPPED. This approach also provides flexibility as it allows multiple targets to be added to the rule, enabling notifications to be sent through different channels. In this case, the rule is configured to send notifications to both Slack and email using Lambda and SNS as targets, respectively.
Option B is incorrect because it suggests sending notifications based on log files generated by ECS instances. This approach is not the most efficient way to monitor ECS tasks' status changes and notify the relevant personnel, as it requires additional configuration and processing resources.
Option C is incorrect because the CloudWatch Event rule is listening to the ECS Container Instance State Change events, which may not accurately reflect the ECS task status changes. This approach can lead to false-positive or false-negative notifications, leading to delays or unnecessary actions by the team.
Option D is incorrect because it suggests monitoring log files generated by Docker instances, which may not be as accurate as monitoring ECS events. Additionally, the proposed approach is more complicated than Option A, as it requires creating a metric filter, setting up an alarm, subscribing to an SNS topic, and executing a Lambda function. This approach may also lead to additional costs and delays in sending notifications.
Overall, Option A provides the most efficient and accurate approach to monitor ECS tasks' status changes and notify the relevant personnel through Slack and email.