Achieving Distributed Tracing with AWS X-Ray - Performance Analysis for Microservices
The full path of microservice requests is visualized with the service map, and problem traces are narrowed down with filter expressions. Integration patterns with OpenTelemetry are also introduced.
X-Ray Overview
X-Ray is a service that traces requests in distributed applications and identifies performance bottlenecks. In a service chain such as API Gateway → Lambda → DynamoDB, it visualizes the time taken and the errors at each step. With the service map, you can visually understand the dependencies between microservices and immediately identify services with high latency or high error rates.
Traces and Sampling
When you incorporate an instrumentation library into your application, HTTP requests, AWS SDK calls, SQL queries, and so on are traced automatically. For a new implementation, the first choice is instrumentation with AWS Distro for OpenTelemetry (ADOT). The legacy X-Ray SDK and X-Ray daemon moved to maintenance mode on February 25, 2026, and no new features are added to them, so they are not chosen for applications built from now on. Simply by enabling active tracing for Lambda and enabling tracing in the stage settings of the REST API for API Gateway, tracing starts without instrumentation. You control the trace collection rate with sampling rules. By default, 1 request per second + 5% of additional requests are sampled. For high-traffic services, you lower the sampling rate to keep costs down, and for low-traffic services, you trace all requests with 100% sampling.
Service Maps and Performance Analysis
The X-Ray service map is generated automatically from trace data and visually displays the dependencies between microservices, the latency of each service, and error rates. Because node colors change according to latency and error rates, you can identify problematic services at a glance. When you click a specific node, the response time distribution (histogram) of that service is displayed, and you can check the P50, P95, and P99 latencies. By using filter expressions to narrow down to specific conditions (traces in which an error occurred, traces with latency of more than 3 seconds, and so on), you can efficiently investigate the root cause of a problem. The Insights feature monitors the fault rate of a service with a statistical model, detects fluctuations beyond the expected range as anomalies, and then presents sample traces of the affected requests. It does not take effect across the whole system automatically, and you need to enable Insights for each group of traces.
OpenTelemetry Integration and Implementation Patterns
X-Ray supports integration with OpenTelemetry (OTel), and with AWS Distro for OpenTelemetry (ADOT), you can send traces from applications instrumented with the OTel SDK to X-Ray. Because the OTel SDK provides a vendor-neutral instrumentation API, no changes to application code are needed even if you change the backend to Jaeger or Zipkin in the future. For Lambda functions, simply enabling X-Ray active tracing instruments them automatically, and no additional libraries need to be incorporated. On ECS and EKS, you deploy the ADOT Collector as a sidecar container (a DaemonSet on EKS), and it receives the trace data sent by application containers and forwards it to X-Ray. The X-Ray daemon, which formerly played this role, has entered maintenance mode as described above, so new configurations use the ADOT Collector. You can also create custom subsegments to measure the individual latency of external API calls and database queries. If you also handle X-Ray traces in Datadog, the AWS X-Ray integration converts them into Datadog APM traces and displays them on the detail screen of the Lambda function. You can also send data from applications instrumented with the OTel SDK to Datadog, and as of October 2026, the method that uses the DDOT Collector included in the Datadog Agent is recommended. In Datadog APM, you can view traces linked with logs and metrics, and Datadog's own instrumentation is also provided for the uses that X-Ray was needed for. The procedure is in the official Datadog documentation for the AWS X-Ray integration.
X-Ray Pricing
X-Ray pricing consists of 3 parts: the number of traces recorded, the number of traces retrieved (scanned), and the number of traces processed by Insights. The following are unit prices as of August 2026 / in the Tokyo Region. Recording traces is free for the first 100,000 per month, and after that it costs $5.00 per million. Retrieving (scanning) traces is free for the first 1,000,000 per month, and after that it costs $0.50 per million. For groups with Insights enabled, $1.00 per million traces processed is charged separately from the recording charges. Because it is not a feature you can use at no additional charge, the basic approach is to enable it only for the groups you want to monitor. Adjusting the sampling rate to control trace volume is the most effective cost optimization measure. Differentiating by lowering the sampling rate to 1% for high-traffic services and setting it to 100% for low-traffic services is recommended. If you want to search a wide range of spans without thinning them out by sampling, there is also the option of enabling CloudWatch Transaction Search. In that case, however, the billing basis changes from the number of traces to the data volume (GB) of ingested spans and the number of indexed spans. Unit prices differ by Region, so check the official pricing page.
Identifying Bottlenecks and Root Cause Analysis
In microservices, a single request passes through many services, so it is difficult to understand where delays or failures are occurring. X-Ray visualizes the time taken by each service that a request passes through, and lets you identify which segment is slow. By dividing processing into fine segments and measuring them, you can narrow down to the points that are bottlenecks, such as database queries and external API calls. When an error occurs, you can also use the traces to track down which process in which service it occurred in. Visualizing distributed processing as one continuous flow makes rapid identification of the root cause possible.
Making Use of X-Ray in Operations
X-Ray is useful not only for incident response but also for continuous monitoring during normal times. By looking at the service map, which shows the dependencies between services, you can understand the configuration and health of the whole system at a glance. You follow trends in latency and error rates and monitor whether performance is gradually degrading. If you combine X-Ray with metrics and logs, you can proceed with an investigation in a flow where, when you detect an anomaly in the numbers, you dig into the specific cause with traces. You can also set performance targets and check how well they are being achieved with trace data. Making use of visualized traces on a daily basis supports stable service operations.
Summary
X-Ray is a distributed tracing service that visualizes the full path of requests in a microservices architecture. Its main features are understanding dependencies with the service map, narrowing down problem traces with filter expressions, and vendor-neutral instrumentation through integration with OpenTelemetry. You can choose an instrumentation method that suits the deployment model, such as Lambda active tracing or the ADOT sidecar.
References (Official AWS Resources)
The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.
- AWS X-Ray official page
- AWS Lambda official page
- Amazon API Gateway official page
- AWS Documentation (official)
If this page and the official documentation disagree, treat the official documentation as authoritative.