AWS X-Ray
Distributed tracing that follows one request across every service it touches and draws a service map from real traffic. Here's what X-Ray is, when it's worth the instrumentation, what it costs, how each service sends traces to it, and the tracing mistakes Design Beaver catches as you draw.
What X-Ray is
X-Ray records requests as they travel across the components of your application and stitches them into one end-to-end trace. Each instrumented component emits a segment — and finer subsegments for the downstream calls it makes — all tied together by a shared trace ID. From those, X-Ray builds a service map: a diagram of which component called which, with timing and error rates on each hop, generated from real traffic rather than hand-drawn.
Services don’t POST segments to X-Ray straight from your code. The X-Ray SDK (or an OpenTelemetry collector) hands segments to a local daemon that buffers them and relays them to the X-Ray API in batches. Who runs that daemon differs by service — managed for Lambda and App Runner, something you run yourself on EC2 and ECS.
Design Beaver models X-Ray as a passive telemetry sink and draws every connection to it as an attachment, so it validates as you draw which services can send it traces and what each of those edges needs to be correct.
When to use X-Ray (and when not to)
Reach for X-Ray when a request crosses several services and you want one trace showing the whole path and where the time is spent. It earns its keep on microservice and serverless call chains — an API Gateway request fanning out through Lambda, Step Functions, and the functions they invoke. It’s also the way to see downstream AWS SDK and HTTP call timing as subsegments, not just a function’s total duration, and to get a service map built from actual traffic.
Don’t reach for it when you only need metrics and logs — CloudWatch covers those with no instrumentation at all. A single component with no downstream fan-out gains little from a trace over a log line. And if you want vendor-neutral tracing you can also point at a non-AWS backend, instrument with OpenTelemetry instead. ADOT can still export to X-Ray, but the classic X-Ray SDKs are AWS-specific.
X-Ray pricing in plain English
You pay per trace — nothing upfront, no minimum — split between traces recorded and traces retrieved or scanned, with recorded traces kept 30 days for free. The number that actually moves your bill is the sampling rate, not the per-trace rate.
Pay per trace, with no upfront cost or minimum. You are billed for traces recorded (ingested), and separately for traces retrieved and scanned (queried/analyzed). Recorded traces are retained for 30 days at no extra storage charge. X-Ray Insights, if enabled, records additional traces that are billed at the recorded-trace rate.
| Option | Representative rate |
|---|---|
| recorded | $5.00 per 1 million traces recorded |
| retrieved-scanned | $0.50 per 1 million traces retrieved, and $0.50 per 1 million traces scanned |
Free tier
- First 100,000 traces recorded per month free; first 1,000,000 traces retrieved or scanned per month free.
Keeping the bill down
- Tune the sampling rules rather than tracing 100% of requests — the default samples the first request each second plus a small percentage of the rest, which is usually enough to spot problems at a fraction of the recorded-trace cost
- Be deliberate about enabling X-Ray Insights — it records extra traces that add to the recorded-trace bill
us-east-1 (rates vary by region). Rates as of 2026-07. Verify at https://aws.amazon.com/xray/pricing/ before using for real cost estimates — these figures are not kept in sync with AWS pricing changes, and cost depends heavily on your sampling rate.
How X-Ray connects to other services
X-Ray is a passive telemetry sink: instrumented services send trace data to it. That’s why Design Beaver draws every X-Ray connection as an attachment pointing inbound, not a data-flow edge — a trace segment is observability metadata about a call, not the call’s request or response payload. The real application data flows on the edges between your services; the X-Ray edge just says “this component reports its traces here,” so it’s excluded from data-flow validation the same way an IAM role or a Cognito authorizer attachment is.
That framing captures what usually gets lost on a canvas — how each service actually gets its traces to X-Ray, and where the write permission lives. It’s managed for Lambda, App Runner, API Gateway, and Step Functions; on EC2 and ECS you run the daemon yourself. Design Beaver models each of these edges and what it requires.
A Lambda function with Active Tracing enabled sends segments to X-Ray via the fully-managed X-Ray daemon Lambda runs for you — X-Ray shows the invocation's duration, cold starts, and (once the function is instrumented with the X-Ray SDK or ADOT) subsegments for its downstream AWS SDK/HTTP calls
An application on an EC2 instance, instrumented with the X-Ray SDK (or ADOT), sends segments over UDP port 2000 to an X-Ray daemon you run on the instance, which batches and relays them to the X-Ray API
- ECS
A containerized app on ECS/Fargate sends segments to an X-Ray daemon (or ADOT Collector) run as a sidecar container in the same task definition, which relays them to X-Ray — the container equivalent of the EC2 daemon setup
- App Runner
An App Runner service with X-Ray tracing enabled sends traces to X-Ray through the built-in AWS Distro for OpenTelemetry (ADOT) integration — App Runner manages the collector, you instrument the app with an ADOT SDK
An API Gateway REST API stage with active tracing enabled samples incoming requests and emits its own X-Ray segment, so the API appears as the entry node on the service map and its latency is traced end-to-end into the backend it integrates with
A Step Functions state machine with X-Ray tracing enabled traces each execution, showing the workflow's states and the downstream services each state calls as one connected trace
The IAM point is the one people miss: for the compute services, the X-Ray write permission belongs on that service’s own role — the Lambda execution role, the EC2 instance profile, the ECS task role, the Step Functions execution role — not on X-Ray. X-Ray is the receiver; it doesn’t assume a role to pull traces in.
What X-Ray can’t connect to
Some X-Ray edges look reasonable on a canvas but don’t exist in AWS. Design Beaver flags them instead of letting you draw a service map that AWS will never actually produce.
An Application Load Balancer does NOT send data to X-Ray and does not appear as a node on the service map. It only adds or updates the X-Amzn-Trace-Id header on requests it forwards, so downstream instrumented targets can correlate their own segments — there is no ALB-to-X-Ray edge, just a trace header the ALB propagates.
X-Ray does not connect to DynamoDB (or other data stores) as an architectural edge. A DynamoDB call shows up in X-Ray as a subsegment of whatever instrumented service made the call (e.g. a Lambda's SDK client), captured on that service's segment — not as a direct X-Ray-to-DynamoDB connection.
X-Ray has no relationship with Route 53 — it is a tracing/telemetry service, not something DNS resolves to or that participates in name resolution.
Anti-patterns Design Beaver catches
These are the tracing mistakes that pass a diagram review but leave you with an empty or misleading service map — the ones the validation engine flags as you draw.
Enabling Active Tracing on a Lambda function and expecting to see the DynamoDB/S3 calls it makes, without instrumenting the code
Why it breaksActive Tracing alone traces the invocation envelope (duration, cold start), not the function's own downstream calls — those subsegments only appear once the handler is wrapped with the X-Ray SDK or ADOT
Do this insteadTurn on Active Tracing AND instrument the handler with the X-Ray SDK / ADOT so downstream AWS SDK and HTTP calls are captured as subsegments
Running the X-Ray daemon on EC2/ECS in a private subnet with no route to the X-Ray API and no write permissions on the role
Why it breaksSegments buffer at the daemon and are silently dropped — traces never reach X-Ray. Two independent failure modes: no network path to the X-Ray endpoint, or a role missing xray:PutTraceSegments/PutTelemetryRecords
Do this insteadGrant the instance/task role the AWSXRayDaemonWriteAccess actions and give the daemon a path to the X-Ray endpoint (NAT gateway, or an interface VPC endpoint for X-Ray in a fully private subnet)
Expecting an ALB or CloudFront to show up as a traced node in the X-Ray service map
Why it breaksLoad balancers propagate the trace header but do not emit X-Ray segments, so they never appear as nodes — the map starts at the first component that actually sends segments (API Gateway with active tracing, or your instrumented compute)
Do this insteadTrace at the first instrumented hop (API Gateway active tracing, or the Lambda/EC2/ECS behind the load balancer) and rely on the propagated X-Amzn-Trace-Id to stitch the request together
Gotchas that bite in production
- A load balancer never appears on the service map. An ALB (or CloudFront) only adds and propagates the
X-Amzn-Trace-Idheader — it does not send segments to X-Ray. The map starts at the first component that actually emits segments: API Gateway with active tracing, or your instrumented compute behind the load balancer. - Active Tracing on Lambda is not tracing your downstream calls. Ticking Active Tracing traces the invocation envelope — duration, cold start. To see the DynamoDB, S3, or HTTP calls the function makes, you also have to instrument the handler with the X-Ray SDK or ADOT. Without that, the subsegments simply aren’t there.
- A private-subnet daemon with no route silently drops traces. On EC2 or ECS in a private subnet, the daemon still needs a network path to the X-Ray endpoint — a NAT gateway, or an interface VPC endpoint for X-Ray. Miss that, or miss the write permission on the role, and segments buffer locally and never arrive, with no obvious error.
- X-Ray doesn’t connect to DynamoDB or S3 as an edge. A call to DynamoDB shows up as a subsegment of the calling service’s segment, captured by that service’s SDK instrumentation — not as a direct X-Ray-to-DynamoDB connection.
Further reading
Frequently asked questions
When should you use AWS X-Ray?
Query inside a Lambda) as subsegments. Skip it when you only need metrics and logs (CloudWatch covers those with no instrumentation), when a component has no downstream fan-out, or when you want vendor-neutral tracing you can point at a non-AWS backend — instrument with OpenTelemetry instead.How much does AWS X-Ray cost?
Does enabling Active Tracing on a Lambda function trace its DynamoDB calls?
Does an Application Load Balancer show up in the X-Ray service map?
X-Amzn-Trace-Id header so downstream instrumented targets can correlate their own segments — it never sends segments to X-Ray, so it never appears as a node. The map starts at the first component that actually emits segments, like API Gateway with active tracing or your instrumented compute. Design Beaver models ALB as a "cannot connect" for X-Ray for exactly this reason.Validate your X-Ray architecture as you draw
Design Beaver checks your AWS design in real time — missing queues, invalid connections, and security anti-patterns, caught before you ship. It’s live in beta, free, and runs in your browser with no account.
Open the app →Prefer email? Get new features in your inbox: