X-Ray accounts recording traces at an uncapped rate above 10%
What does ZopNight detect here?
X-Ray charges $5 per million traces recorded, and a fixed sampling rate above 10% with no reservoir records far more than debugging needs. ZopNight computes the delta from reducing to the 5% AWS default against the account's measured monthly trace volume. Both inputs are required, or it abstains.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1519 |
| Category | rightsizing |
| Severity | low |
| Metric | none — pure configuration read |
| Source | xray_sampling.go |
Where it applies
Observability priced by the trace
Tracing feels free until volume arrives: at $5.00 per million recorded traces, a high-throughput account sampling every third request records tens of millions of traces monthly for a bill nobody scrutinises. Sampling exists precisely because a representative fraction answers the same questions (latency distributions, dependency maps, error localisation) that exhaustive recording answers, at a twentieth of the cost.
The delta model, with both variables measured
The recommendation quantifies one move: reducing the configured fixed rate to 5%, AWS’s own default sampling rate. Reduced volume scales proportionally (target rate over current rate), and the saving is the trace-count difference times the per-million price. Both variables must be real: the configured rate comes from the account’s discovered sampling configuration, and the monthly volume from the trace-count series measured over at least 30 days; X-Ray publishes that series only when group-level metrics are enabled. Missing rate, missing volume, or thin coverage each abstain; the only fixed input is X-Ray’s published price, which is a rate card, not an estimate.
Account-scoped on purpose
X-Ray sampling rules match by service and host patterns, frequently a bare wildcard, so a high rate is not a property of any one instance or function; it applies account-and-region wide. The finding is therefore raised at the account grain, one per affected region, rather than scattered across every workload the rule happens to touch.
Read your sampling configuration
aws xray get-sampling-rules \ --query 'SamplingRuleRecords[].SamplingRule.[RuleName,FixedRate,ReservoirSize,Priority]' \ --output tableA FixedRate above 0.10 with no meaningful reservoir is the shape this rule prices.
Reduce without losing the traces that matter
Drop the fixed rate to about 5% and add a small reservoir of 1 request per second, so low-traffic services keep a floor of representative traces. Then protect the exception: keep a separate higher-priority rule sampling error and fault responses at 100%, because failure investigations want every bad trace and the bad traces are, by definition, rare. Watch recorded volume for a day and tune from measurement, which is the same standard the rule holds itself to.