What should the developer do to meet these requirements?
Use the Lambda function’s ConcurrentExecutions metric in Amazon CloudWatch to measure the throughput.
Modify the application to log the calculated throughput to Amazon CloudWatch Logs. Use Amazon EventBridge to invoke a separate Lambda function to process the logs on a schedule.
Modify the application to publish custom Amazon CloudWatch metrics when the Lambda function receives and processes each message. Use the metrics to calculate the throughput.
Use the Lambda function’s Invocations metric and Duration metric to calculate the throughput in Amazon CloudWatch.
Explanations:
The ConcurrentExecutions metric indicates the number of concurrent executions of the Lambda function but does not provide a measure of the throughput based on the number of messages processed. It does not account for the initialization and post-processing steps either.
Logging calculated throughput to CloudWatch Logs and using EventBridge to invoke another Lambda function adds complexity and does not provide near real-time throughput monitoring. This approach also involves additional latency and does not directly measure the throughput of messages processed.
Publishing custom CloudWatch metrics when the Lambda function receives and processes each message allows for precise measurement of throughput. This method can focus specifically on message processing, excluding initialization and post-processing, thus providing accurate near real-time throughput monitoring.
The Invocations metric counts the number of times the Lambda function is invoked, and the Duration metric measures the execution time. However, they do not provide a direct calculation of throughput specific to the message processing, and they do not differentiate between processing time and initialization/post-processing time.
I assess that the answer is:
Modify the application to publish custom Amazon CloudWatch metrics when the Lambda function receives and processes each message. Use the metrics to calculate the throughput.