A high-throughput Lambda function must record per-request custom metrics such as latency and a success flag, broken down by customer tier, while still keeping the full structured log line for later querying. The team wants CloudWatch to extract the metrics asynchronously from the logs rather than making a separate synchronous metrics API call on every invocation. Which approach meets this requirement?
- ACall the CloudWatch PutMetricData API once per request with the latency value and a dimension for the customer tier, and write the structured log line separately.
- BWrite the structured log line to CloudWatch Logs and create a metric filter for each metric, so CloudWatch turns matching log values into metrics over time.
- CSend the metrics directly to a CloudWatch dashboard widget from the function code, so the dashboard stores the latency and success values for each customer tier.
- DEmit the log line using the CloudWatch embedded metric format, declaring the metrics and dimensions in the metadata so CloudWatch extracts metrics from the log asynchronously. Correct
Why A is wrong: PutMetricData adds a synchronous API call and latency on every invocation, which is exactly the per-request metrics call the team wants to avoid in a high-throughput function.
Why B is wrong: Metric filters can extract numeric values from logs, but maintaining a separate filter per metric and dimension combination is rigid and does not scale to per-request high-cardinality breakdowns.
Why C is wrong: A dashboard only visualises metrics that already exist and cannot ingest or store raw values from function code, so it is not a mechanism for emitting custom metrics.
Why D is correct: The embedded metric format lets the function write one structured log line carrying both the raw fields and metric metadata, and CloudWatch extracts the metrics from the logs without a separate synchronous API call.