An EC2-hosted photo-processing app must process each photo in under 5 seconds; if processing exceeds 5 seconds the development team must be notified. What approach provides the time measurement and alerting with the least operational overhead?

Publishing a custom CloudWatch metric for each photo's processing time directly addresses the requirement to measure individual processing times. A CloudWatch alarm with a static 5-second threshold can then directly monitor these individual metrics and trigger an Amazon SNS notification when the threshold is breached, providing a fully managed and low-overhead solution for both measurement and alerting. Sending times to an SQS queue requires building and managing a consumer application, increasing operational overhead. Using an average in a CloudWatch alarm might miss individual photo processing exceeding 5 seconds if other photos are processed quickly, and Amazon SES is an email service, not a pub/sub notification service like SNS, which is better for alerting. Streaming to Kinesis Data Streams introduces unnecessary complexity and cost for this specific use case, and while a CloudWatch alarm can monitor Kinesis, the initial data ingestion and processing overhead is higher than directly publishing custom metrics.