All Services

Developer Tools

AWS X-Ray

AWS X-Ray collects distributed-trace segments and telemetry for service maps, request timing, errors, and dependencies; the X-Ray SDKs and daemon entered maintenance mode on February 25, 2026, so new instrumentation should use OpenTelemetry and an OpenTelemetry-compatible collector.

Explore pricing models, common use cases, infrastructure support, and the AWS services that commonly work with AWS X-Ray.

AWS X-Ray pricing and cost programs

Pricing model: Trace recording and retrieval usage

On-Demand
Available
Reserved Instances or reserved capacity
Not applicable
Savings Plans
Not applicable
Spot
Not applicable

Billing dimensions: Traces recorded · Traces scanned or retrieved · Insights

Programs and modes: Trace recording · Trace retrieval and scan · X-Ray Insights

Recorded and retrieved or scanned traces use separate dimensions.

Free Tier: Available — verify current offers

Pricing reviewed 2026-07-25. Reviewed against the linked official AWS pricing page. Recheck regional rates and program terms before purchase.

Official AWS pricing

Official AWS sources reviewed 2026-07-21.

Why implement AWS X-Ray?

  • Correlates distributed request paths, latency, errors, annotations, and downstream dependencies across supported services and custom applications.
  • Provides trace search, service-map views, sampling, groups, analytics, and integration with CloudWatch application observability.
  • Accepts OpenTelemetry telemetry through supported collectors, avoiding lock-in to the maintenance-mode X-Ray SDK and daemon.

How to implement AWS X-Ray

  1. Define service naming, propagation, attributes, redaction, sampling, latency, error, and retention objectives before adding instrumentation.
  2. Instrument applications with supported OpenTelemetry libraries, propagate context across async boundaries, deploy an OpenTelemetry-compatible collector with bounded queues and least-privilege export permissions, and enable relevant AWS service tracing.
  3. Validate complete traces under normal and failure conditions, correlate traces with logs and metrics, create focused groups and alarms, monitor dropped telemetry and cost, and migrate remaining X-Ray SDK or daemon workloads.

AWS X-Ray best practices

  • Do not start new integrations on the X-Ray SDK or daemon; use OpenTelemetry and follow the AWS migration guidance because the legacy components are in maintenance mode.
  • Never attach secrets, full payloads, tokens, or sensitive identifiers to trace attributes; define an allowlist and enforce consistent redaction before export.
  • Use representative sampling with deliberate rules for errors and high-value paths, bound collector memory and retries, and alert when telemetry drops so observability cannot silently fail.

AWS X-Ray use cases and server impact

  • Microservice latency and dependency analysis
  • Serverless request-path debugging
  • Correlating errors across APIs, containers, and databases

Replaces custom trace storage, indexing, and visualization for supported telemetry, while application instrumentation, propagation, sampling, sensitive-data controls, collector reliability, and diagnosis remain yours.

Official implementation resources

Commonly paired AWS services