Compare
Ivy vs AWS X-Ray
AWS X-Ray is the tracing service built into AWS, now instrumented through OpenTelemetry and shown in CloudWatch. Ivy records more per Lambda invocation (the event, the response and every AWS SDK and HTTP body), traces every invocation instead of a sample, and makes it all readable by coding agents. X-Ray stays inside AWS and traces across many AWS services natively.
Feature comparison
As of November 2026, from AWS's public documentation and pricing.
| Feature | Ivy | AWS X-Ray (with CloudWatch) |
|---|---|---|
| Where it runs | ivytrace.dev or self-hosted | Inside your AWS account |
| Lambda setup | Opt-in auto-trace attaches a layer; no code changes | Active tracing toggle; OpenTelemetry (ADOT) for detailed spans |
| What each invocation records | Event, response, logs, errors, every AWS SDK and HTTP call with bodies | Segments and subsegments with timings; payloads only if you add them as metadata |
| Sampling | Every invocation | Sampling rules (by default, the first request each second and 5% of the rest) |
| Failures outside the handler | Init errors, out of memory, crashes, timeouts with log tails; throttles | Lambda metrics and CloudWatch Logs |
| Cross-service traces | Within one invocation | Across API Gateway, SQS, SNS, Step Functions and other AWS services |
| Agents | MCP server, MCP Apps views, HTTP API | AWS APIs and AWS's own tooling |
| Open source | Yes (MIT) | No (OpenTelemetry instrumentation is) |
Where X-Ray is stronger: no third party, no data leaving AWS, IAM-native access control, and traces that follow a request across AWS services. CloudWatch Application Signals adds service maps and SLOs on top.
Where Ivy is stronger: much more detail per Lambda invocation without writing instrumentation, every invocation kept rather than a sample, failures outside the handler as traces with their last log lines, a dashboard built only for Lambda, and an MCP server for your coding agent.
X-Ray SDK maintenance
AWS put the X-Ray SDKs and daemon into maintenance mode on February 25, 2026, with end of support on February 25, 2027, and recommends OpenTelemetry instead (AWS announcement, support timeline). If you are rewriting X-Ray SDK instrumentation anyway, that is a good moment to choose where the traces go. Ivy accepts OpenTelemetry over OTLP, so an OpenTelemetry SDK can send to Ivy instead of, or as well as, X-Ray.
Pricing
| Pricing | Ivy | AWS X-Ray |
|---|---|---|
| Free each month | 100,000 traces | 100,000 traces recorded; 1,000,000 traces retrieved or scanned |
| Beyond that | €5 per million traces | $5.00 per million traces recorded; $0.50 per million retrieved or scanned |
| What a trace is | One Lambda invocation, all spans included | One request's trace, as sampled |
The list prices per million traces are similar ($5.00 and €5). X-Ray's sampling means you record fewer traces, with less detail in each; Ivy keeps every invocation with its payloads.
Using both
Ivy's layer does not use X-Ray, so you can keep X-Ray active tracing on for cross-service maps and use Ivy for invocation detail. Ivy does not read or forward X-Ray trace headers yet, so the two show separate traces.
Sources
Checked in November 2026:
- Amazon CloudWatch pricing (X-Ray tracing)
- X-Ray SDKs and daemon end of support
- X-Ray SDK and daemon support timeline
- Migrating from X-Ray instrumentation to OpenTelemetry
AWS, AWS Lambda and AWS X-Ray are trademarks of Amazon.com, Inc. or its affiliates. Ivy is not affiliated with AWS.