Skip to main content
In this lesson we’ll explore AWS X-Ray — Amazon’s managed distributed tracing service used to visualize, analyze, and debug requests as they travel through modern, distributed applications. X-Ray helps you find latency hotspots, identify failing components, and trace the root cause across microservices, databases, and third-party APIs. Why use X-Ray?
  • Modern applications are frequently built from many independent services (microservices, containers, functions). When a request fails or is slow, it can be hard to spot which component is responsible.
  • X-Ray instruments requests across services to provide an end-to-end view of latency, errors, and metadata so you can quickly locate performance bottlenecks or error sources.
  • X-Ray integrates with instrumented applications (via the X-Ray SDK or auto-instrumentation) and with many AWS services that natively emit traces.
What X-Ray provides
  • Distributed tracing: Collects timing and diagnostic metadata for requests as they flow through your system.
  • Full request context: For each traced request, X-Ray shows the sequence of calls, how long each component took, response codes (when available), and operation-level details (for example, database queries, downstream HTTP calls, and S3 operations).
  • Visualization: Service maps and timeline views help you see where time is spent and which components are failing or slow.
  • Sampling: X-Ray uses sampling to limit the volume of trace data; you can tune sampling rules to control how many requests are recorded.
X-Ray is ideal for troubleshooting latency in microservices, investigating intermittent errors, and understanding end-to-end request flows across AWS (Lambda, ECS, EC2, RDS, S3) and custom services.
Adjusting sampling to record more traces increases visibility but can also increase data ingestion and storage costs. Tune sampling rules thoughtfully and monitor costs when changing defaults.
How traces, segments, and subsegments work Taken together, traces → segments → subsegments let X-Ray reconstruct the full path of a request and show duration and success/failure at each step. The following graphic illustrates how X-Ray surfaces this information in a timeline view: each row represents a component or service, displaying response codes, status, duration, and endpoint/operation details.
A presentation slide titled "AWS X‑Ray Segments" showing a segment timeline table with columns for Group by Nodes, Segment Status, Response Code, Duration, and Endpoint. Rows list services like MyApp::AWS::ECS::Container, Myapp, RDS, and S3 with OK status, 200 response codes, durations (e.g., 118ms, 105ms, 88ms) and their endpoints.
Example interpretation
  1. A single request enters MyApp and is traced across multiple components.
  2. The timeline shows MyApp::AWS::ECS::Container handling the request for 118 ms and returning an HTTP 200.
  3. The trace then shows an RDS call where an INSERT into the users table took 105 ms and returned 200.
  4. Finally, the request performed an S3 PUT that took 88 ms and also returned 200. From this view you can quickly see where time is spent and whether any step returned errors or unexpected response codes.
Using X-Ray to diagnose issues
  • Filter and compare traces by error status, latency, annotations, or specific services to isolate the root cause (for example, a slow query or failing downstream API).
  • Use the service map to identify high-impact nodes (services with many long traces or errors).
  • Drill into slow traces to inspect subsegments and pinpoint which downstream call or operation caused the latency.
  • Annotate traces in your code to add searchable metadata (user IDs, order IDs, or feature flags) that help group and filter related traces.
  • Adjust sampling rules if you need more traces for debugging, but balance against potential cost increases.
Quick reference links

Watch Video