miruky

Posted on Sep 3

Trace a Lambda Invocation with AWS X-Ray

#lambda #aws #observability #xray

Introduction

Hi, I'm miruky.

AWS Lambda can emit service-level AWS X-Ray segments without application instrumentation. Active tracing records the Lambda service's work and the function execution as separate segments, which gives a small but useful trace map for a synchronous invocation.

This Console run creates a Python function with a fixed response, enables Lambda service traces, invokes the same empty private event three times, and inspects one sampled trace in CloudWatch. The article does not open raw trace data or publish trace IDs, request IDs, ARNs, account details, environment variables, annotations, or metadata.

X-Ray sampling and trace storage have current pricing terms, as do Lambda invocations and CloudWatch Logs. Review the linked pricing pages before enabling tracing on production traffic.

1. Create a tracing-capable execution role

The validation stays in us-east-1.

The header confirms United States (N. Virginia) while the Lambda Console is in English. This fixes the Region shared by the function and its trace data.

Open IAM, choose Roles, and create a role for the Lambda service. Enter miruky-eftzwycpzwhjwahl and attach AWSLambdaBasicExecutionRole plus AWSXRayDaemonWriteAccess.

The review shows miruky-eftzwycpzwhjwahl, AWSLambdaBasicExecutionRole, and AWSXRayDaemonWriteAccess together. The policies cover Lambda log delivery, trace upload, and the sampling-rule reads needed by X-Ray; they do not grant X-Ray configuration writes.

Open the role and verify its Lambda trust relationship and the two attached policies. The X-Ray policy grants xray:PutTraceSegments and xray:PutTelemetryRecords; the basic policy covers CloudWatch Logs writes.

The stacked crops show the final permissions review and the saved trust relationship. The role has exactly the two intended managed policies, and lambda.amazonaws.com can assume it. AWSXRayDaemonWriteAccess permits segment and telemetry uploads plus the three sampling read operations documented by its current policy version.

2. Create a function with deterministic output

Open Lambda and search for the exact name miruky-cokynoojzfivdjpl. The result should be empty before this validation creates the function.

The exact filter for miruky-cokynoojzfivdjpl returns no function. That empty result establishes the resource boundary before creation.

Choose Create function and Author from scratch. Enter miruky-cokynoojzfivdjpl, select Python 3.14 and x86_64, then choose the existing role miruky-eftzwycpzwhjwahl.

The form shows miruky-cokynoojzfivdjpl, Python 3.14, x86_64, and miruky-eftzwycpzwhjwahl together. These visible values fix the runtime and execution role before creation.

Replace the sample code with the fixed handler below and choose Deploy. It reads no event field and returns no runtime, request, environment, or identity value.

def lambda_handler(event, context):
    # Return a fixed value so tracing adds no application-data variability.
    return {"status": "traced"}

The deployed editor contains only the deterministic handler and its fixed traced value. The trace experiment therefore adds no application instrumentation or dynamic response data.

3. Enable Lambda service traces

Before changing the function, open Configuration, choose Monitoring and operations tools, and edit Additional monitoring tools. Inspect the Lambda service traces control before selecting it.

The Lambda service traces control is unchecked. The handler can still run in this state, but Lambda will not emit the two service-level X-Ray segments that this exercise needs to inspect.

Under CloudWatch Application Signals and AWS X-Ray, enable Lambda service traces and save.

The editor shows Lambda service traces enabled under the X-Ray controls. Saving that choice changes the function from pass-through behavior to active tracing.

Return to the monitoring configuration and confirm that tracing is active. Lambda now creates service-level segments automatically; this step does not add custom application subsegments, annotations, or metadata.

The saved configuration continues to show Lambda service traces enabled. The setting is persisted before any validation invocation is run.

AWS places the legacy X-Ray SDKs in maintenance mode and recommends OpenTelemetry for new custom instrumentation. This article uses only Lambda's built-in service tracing, so no X-Ray SDK dependency is bundled with the function.

4. Invoke a private event and find the sampled trace

Open the Test tab and create a private event named miruky-rnsdepoalbavxzhr with the JSON body {}. Save it and run the same event three times, leaving at least one second between invocations.

The event editor shows miruky-rnsdepoalbavxzhr, Private, and the empty object {}. Repeating this fixed event avoids adding attributes that could appear in trace details.

Each Console test should return {"status": "traced"}. X-Ray samples requests rather than recording every invocation; Lambda's documented sampling uses one request per second plus 5 percent of additional requests, and that sampling rate cannot be configured for Lambda functions.

The cropped result shows a successful invocation and {"status": "traced"}. Execution logs and request identifiers remain outside the image.

Open CloudWatch, choose X-Ray traces, and then choose Traces. Under Query refiners, keep Node selected. The generated function appears twice: once as Lambda Context and once as Lambda Function. Select Lambda Function, add it to the query, and run the query.

The refiners show miruky-cokynoojzfivdjpl as both node types, and the query returns three traces from the validation window. The generated query includes an account.id condition, so that query text and every trace identifier stay outside the retained image.

Open one row from the trace table without copying its trace ID.

The trace map should contain two Lambda nodes. The current map labels them Lambda Context and Lambda Function. In the segment timeline, those nodes correspond to AWS::Lambda for service work such as preparing the execution environment and AWS::Lambda::Function for work performed by the function.

The map visibly separates Lambda Context from Lambda Function. Both nodes belong to the selected invocation, but they represent different portions of its execution.

Open the segment timeline and inspect the status and duration columns. I kept the raw segment JSON closed because it contains unique IDs, timestamps, resource references, and other details that this article does not need.

The timeline shows AWS::Lambda and AWS::Lambda::Function with OK status and visible durations. The Logs section remains outside the image, and trace, segment, resource, and request identifiers are not retained.

Wrap-up

One synchronous test produced a trace with two different operational views: Lambda's service-side preparation and the function's own execution. The separation helps distinguish platform work from handler work before custom instrumentation is added.

For a new distributed application, use ADOT and OpenTelemetry when you need custom spans or multiple observability backends. Keep indexed attributes low-cardinality, avoid putting personal or secret data into trace attributes, and tune sampling against diagnostic value and cost.

X-Ray retains trace data for 30 days. Removing the function stops new traces, but an already recorded validation trace follows that service-controlled retention period.

Thanks for reading this far.

See you in the next one.

Disclosure: This article was written with AI assistance and independently verified against the linked primary sources and observed results.

DEV Community