Question #891
A company's application uses an AWS Lambda function to process image uploads from users. The company needs to monitor the Lambda function's processing rate in near real time to verify compliance with a service level agreement (SLA). The throughput measurement must exclude the Lambda function's initialization and cleanup phases, focusing only on the time spent actively processing images. What should the developer implement to meet these requirements?
Use the Lambda function's Concurrent Executions metric in Amazon CloudWatch to derive the processing rate.
Modify the application to log the processing rate to Amazon CloudWatch Logs. Configure an Amazon EventBridge scheduled rule to trigger a secondary Lambda function that aggregates the logs hourly.
Modify the application to emit custom Amazon CloudWatch metrics when each image is received and fully processed. Calculate throughput using these metrics.
Use the Lambda function's Invocations metric and Duration metric in Amazon CloudWatch to compute the processing rate.
Explanation
Answer C is correct because emitting custom CloudWatch metrics when processing starts and ends enables accurate calculation of active processing time, excluding Lambda's initialization and cleanup phases. This meets the SLA monitoring requirement for near-real-time throughput.
Why other options are incorrect:
- A: 'Concurrent Executions' measures parallelism, not processing rate or time.
- B: Hourly aggregation via EventBridge isn't near real-time.
- D: 'Duration' metric includes initialization/cleanup, violating the requirement.
Key Points:
1. Custom metrics provide granular control over what's measured.
2. Lambda's built-in metrics (Duration, Invocations) include all execution phases.
3. Near-real-time monitoring requires immediate metric availability, achievable via CloudWatch custom metrics.
Answer
The correct answer is: C