How can a developer implement the required time measurement and notification with the LEAST operational overhead?
Create an Amazon CloudWatch custom metric. Each time a photo is processed, publish the processing time as a metric value. Create a CloudWatch alarm that is based on a static threshold of 5 seconds. Notify the development team by using an Amazon Simple Notification Service (Amazon SNS) topic.
Create an Amazon Simple Queue Service (Amazon SQS) queue. Each time a photo is processed, publish the processing time to the queue. Create an application to consume from the queue and to determine whether any values are more than 5 seconds. Notify the development team by using an Amazon Simple Notification Service (Amazon SNS) topic.
Create an Amazon CloudWatch custom metric. Each time a photo is processed, publish the processing time as a metric value. Create a CloudWatch alarm that enters ALARM state if the average of values is greater than 5 seconds. Notify the development team by sending an Amazon Simple Email Service (Amazon SES) message.
Create an Amazon Kinesis data stream. Each time a photo is processed, publish the processing time to the data stream. Create an Amazon CloudWatch alarm that enters ALARM state if any values are more than 5 seconds. Notify the development team by using an Amazon Simple Notification Service (Amazon SNS) topic.
Explanations:
Using CloudWatch custom metrics allows for minimal operational overhead. By publishing the processing time as a metric and setting a CloudWatch alarm with a threshold of 5 seconds, the development team can be notified via SNS when the threshold is breached. This solution is simple, scalable, and has low overhead.
Using SQS and a custom application to monitor processing times introduces unnecessary complexity. It requires managing a queue, building an application to check the queue, and manually handling notifications, which adds significant operational overhead.
A CloudWatch alarm based on the average processing time is not ideal since the requirement specifies notifying when any single processing time exceeds 5 seconds, not an average. This could lead to delayed notifications if the alarm only triggers based on the average.
Using Kinesis introduces unnecessary complexity for the given requirement. Kinesis is typically used for real-time data streaming and large-scale analytics, which is more complex than needed for this simple task of measuring processing times and sending notifications.
I weigh that the answer is:
Create an Amazon CloudWatch custom metric. Each time a photo is processed, publish the processing time as a metric value. Create a CloudWatch alarm that is based on a static threshold of 5 seconds. Notify the development team by using an Amazon Simple Notification Service (Amazon SNS) topic.