How to find the source of increased response time in a Lambda function integrated with API Gateway?

A company recently deployed a new serverless user portal. Users have reported that part of the portal is slow. The initial analysis found a single Amazon API Gateway endpoint that is responsible for the performance issues. The endpoint integrates with an AWS Lambda function. However, the Lambda function interacts with other APIs and AWS services. How can a developer find the source of the increased response time by using operational best practices?

Update the Lambda function by adding logging statements with high-precision timestamps before and after each external request. Deploy the updated Lambda function. After accumulating enough usage data, examine the Amazon CloudWatch logs for the Lambda function to determine the likely sources for the increased response time.
Instrument the Lambda function with the AWS X-Ray SDK. Add HTTP and HTTPS interceptors and SDK client handlers. Deploy the updated Lambda function. Turn on X-Ray tracing. After accumulating enough usage data, use the X-Ray service map to examine the average response times to determine the likely sources. Source Reference Answer
Review the Lambda function's Amazon CloudWatch metrics by using the metrics explorer. Apply anomaly detection to the Duration metric and the Throttles metric. Review the anomalies to determine the likely sources.
Use Amazon CloudWatch Synthetics to create a new canary. Turn on AWS X-Ray tracing on the canary. Configure the canary to scan the user portal. After accumulating enough usage data, use the CloudWatch Synthetics canary dashboard to view the metrics from the canary.

Community Votes

83%

17%

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

Community Insight

The core concept is distributed tracing; the common trap is confusing proactive monitoring (CloudWatch Synthetics canaries) with reactive performance debugging (AWS X-Ray).

This question tests the use of AWS X-Ray to trace and identify performance bottlenecks in a serverless application where a Lambda function interacts with multiple external services. The community strongly agrees that instrumenting the Lambda function with the X-Ray SDK and analyzing the service map is the operational best practice for pinpointing increased response times.

Many candidates choose Option D (CloudWatch Synthetics canary) because it sounds like a modern monitoring solution, but canaries are designed for proactive availability and latency monitoring from the outside, not for deep-diving into the internal execution segments of a Lambda function to find which downstream call is slow.

Community Discussion (6 comments)

Saudis 👍 2 Selected: B

increased response => Tracing so B is the best choice

65703c1 👍 3 Selected: B

B is the correct answer.

DeaconStJohn 👍 3 Selected: B

I have to agree B for this one and not because chatGPT told me so. upon research the canary seems to be the best option to capture issues before your customer sees them. As we already have reports of performance issues here I think the more long winded canary option is less feasible. the canary checks for broken links and compares screenshots to baseline images, it also checks for heart beats and whether API's read/write functionality is working. I feel like Xray would be the better tool as the SDK with provide higher quality metrics and highlight latency, bottlenecks or other performance issues at any point in the service map. It is a single tool as opposed to option D's needing two tools and ultimately if option D requires X-ray to add granularity to canary results why not just start with X-ray.

Prastuti55 👍 1 Selected: B

X-Ray for investigating performance issues.

outrageous7 👍 1 Selected: B

gpt & makes sense

KarBiswa 👍 2 Selected: D

https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Synthetics_Canaries.html

Comments & Corrections

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

Expert Analysis

Understanding the Problem

The scenario describes a serverless user portal where a specific Amazon API Gateway endpoint is slow. This endpoint triggers an AWS Lambda function that, in turn, calls other APIs and AWS services. The developer's goal is to find the source of the increased response time using operational best practices. This is a classic distributed tracing problem.

Why Option B is Correct

AWS X-Ray is AWS's dedicated distributed tracing service. It is specifically designed to help developers analyze and debug production, distributed applications, such as those built using a microservices or serverless architecture. By instrumenting the Lambda function with the AWS X-Ray SDK and adding interceptors for HTTP/HTTPS calls and SDK client handlers, X-Ray can trace the entire request path.

When you turn on X-Ray tracing and analyze the X-Ray service map, you can visually see the entire workflow and the average response times for each downstream call (the other APIs and AWS services). This allows you to instantly pinpoint which specific external dependency is causing the latency. As community member Saudis noted, "increased response => Tracing so B is the best choice."

Why the Other Options are Incorrect

Option A (Custom Logging): While adding custom logs with high-precision timestamps in Amazon CloudWatch Logs can technically help calculate durations, it is a manual, error-prone, and inefficient process. It is not considered an "operational best practice" for distributed systems when a purpose-built tool like X-Ray exists. You would have to manually correlate log entries across multiple requests to find the bottleneck.

Option C (CloudWatch Metrics & Anomaly Detection): CloudWatch metrics for Lambda (like Duration and Throttles) provide an aggregate view of the function's performance. While anomaly detection is a great feature for alerting you that the duration has increased, it will not tell you why it increased or which* downstream call is responsible. It lacks the granular, segment-level detail required for this task. Option D (CloudWatch Synthetics): This is the most common trap. Amazon CloudWatch Synthetics uses canaries to proactively monitor the availability and latency of your endpoints from the outside. While it can tell you that the portal is slow, it does not provide the internal, segment-by-segment breakdown of the Lambda function's execution. As community member DeaconStJohn* correctly pointed out, canaries are better for capturing issues before customers see them, not for debugging the internal cause of an already reported performance issue.

Key Takeaway

When the question asks to find the source of latency in a distributed application (like a Lambda function calling multiple services), the answer is almost always AWS X-Ray. It provides the necessary service map and trace details to see exactly where the time is being spent.

Official Reference

Exam Strategy

When an AWS exam question asks to 'find the source' of a problem in a distributed or serverless application, look for the distributed tracing service (AWS X-Ray). Distinguish between tools that alert you to a problem (CloudWatch Alarms, Synthetics) and tools that help you debug the root cause internally (X-Ray).

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