How to measure custom Lambda throughput excluding initialization in CloudWatch?

A company's application has an AWS Lambda function that processes messages from IoT devices. The company wants to monitor the Lambda function to ensure that the Lambda function is meeting its required service level agreement (SLA). A developer must implement a solution to determine the application's throughput in near real time. The throughput must be based on the number of messages that the Lambda function receives and processes in a given time period. The Lambda function performs initialization and post-processing steps that must not factor into the throughput measurement. 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. Source Reference Answer
Use the Lambda function's Invocations metric and Duration metric to calculate the throughput in Amazon CloudWatch.

Community Votes

100%

100% of anonymous learners picked answer C. Votes are pick records left by other test-takers — they are not the verified answer.

Community Insight

This question tests the ability to define and measure custom business-level throughput in Lambda by emitting CloudWatch metrics at specific code points, avoiding reliance on default metrics that include all execution phases.

To measure AWS Lambda throughput excluding initialization and post-processing time, developers must publish custom Amazon CloudWatch metrics at the exact points messages are received and processed. Community consensus strongly supports custom metrics for precise, near real-time SLA monitoring.

Candidates often choose option D, using the built-in Invocations and Duration metrics, mistakenly believing they can derive throughput from them. However, Duration includes initialization and post-processing time, which the requirement explicitly excludes.

Community Discussion (7 comments)

Alagong 👍 5 Selected: C

Use the metrics to calculate the throughput. This is because custom metrics can provide a more accurate measure of throughput, as they can be configured to only increment when a message is received and processed by the Lambda function. This would exclude the time spent on initialization and post-processing, which are not part of the throughput measurement.

examuserss 👍 1 Selected: C

Correct Answer: C. 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. This solution allows the developer to focus on the specific parts of the Lambda function that are responsible for processing messages, providing the most accurate and real-time measurement of throughput. By publishing custom metrics, the developer can ensure the throughput is tracked exactly as required, excluding any irrelevant steps.

albert_kuo 👍 1 Selected: C

import boto3 import time cloudwatch = boto3.client('cloudwatch') def lambda_handler(event, context): # Process the IoT message process_message(event) # Publish custom CloudWatch metric for throughput cloudwatch.put_metric_data( Namespace='IoTMessageProcessing', MetricData=[ { 'MetricName': 'MessagesProcessed', 'Timestamp': time.time(), 'Value': 1, 'Unit': 'Count' }, ] )

65703c1 👍 1 Selected: C

C is the correct answer.

trungtd 👍 2 Selected: C

Because this requirement provides its own definition of how throughput is measured, you must use custom metrics.

seetpt 👍 2 Selected: C

I think C

KarBiswa 👍 2 Selected: A

https://aws.amazon.com/blogs/compute/understanding-aws-lambda-scaling-and-throughput/

Comments & Corrections

No comments yet — spotted an error or have a note? Share it below.

Expert Analysis

Understanding the Requirement

The scenario requires measuring throughput defined strictly as the number of messages received and processed by a Lambda function within a time period, explicitly excluding initialization and post-processing steps. This is a custom business metric, not a standard AWS operational metric.

Why Option C is Correct

Option C instructs the developer to modify the Lambda function code to publish custom Amazon CloudWatch metrics using the AWS SDK (e.g., boto3 put_metric_data) precisely when a message is received and again when it is successfully processed. This approach:

Provides near real-time visibility because CloudWatch custom metrics can be emitted with a resolution of 1 second (high-resolution metrics) or 1 minute.
Allows the developer to isolate the exact processing window by placing metric emission calls immediately before and after the core processing logic, completely bypassing initialization and post-processing phases.
Enables throughput calculation as the delta between received and processed counts over a defined time window.

Community comment [1] correctly notes that custom metrics can be configured to increment only when a message is actually received and processed, satisfying the exclusion requirement. Comment [3] provides a practical Python code snippet demonstrating how to emit a MessagesProcessed custom metric inside the handler.

Why the Other Options Are Incorrect

Option A (ConcurrentExecutions metric): This metric indicates how many instances of the function are running concurrently. It reflects scaling behavior, not message throughput, and cannot distinguish between initialization, processing, or post-processing phases.

Option B (CloudWatch Logs + EventBridge + separate Lambda): While technically feasible, this introduces unnecessary latency and complexity. Parsing logs on a schedule does not meet the near real-time requirement and adds operational overhead compared to direct custom metric emission.

Option D (Invocations and Duration metrics): The built-in Invocations metric counts total invocations, and Duration measures total execution time from start to finish, including initialization (cold starts) and post-processing. Since the requirement explicitly excludes these phases, these default metrics cannot accurately reflect the desired throughput definition. Community comment [5] emphasizes that because the question provides its own definition of throughput, custom metrics are mandatory.

Key Takeaway

Whenever an exam question defines a custom business metric that does not align 1:1 with AWS default metrics—especially when specific execution phases must be included or excluded—the correct approach is almost always to publish custom CloudWatch metrics from within the application code.

Official Reference

Exam Strategy

When a question defines its own metric or measurement criteria that differs from AWS default metrics, immediately look for the option involving custom metrics or application-level instrumentation. Default CloudWatch metrics rarely satisfy custom business SLA definitions.

Related Analysis

Practice All DVA-C02 Questions

Access 100 questions with complete answers and detailed explanations.

View Full DVA-C02 Practice Test →

← Back to DVA-C02 Study Guide