AWS IoT Basic Ingest: Explain Why a Telemetry Rule Works but MQTT Subscribers See Nothing

A telemetry rule can receive an AWS IoT Basic Ingest message while an MQTT observer receives nothing. That is consistent with the selected route: Basic Ingest removes the publish/subscribe broker from the ingestion path. A functioning rule therefore does not establish that a broker publication exists for subscribers to receive.

Before investigating an observer’s wildcard, compare the actual published topic with the route the application intended. This article uses harmless synthetic telemetry and official AWS IoT Core documentation read on 19 October 2026. No device, rule, subscription or policy was changed.

Read the reserved prefix as a routing decision

The Basic Ingest guide identifies the prefix $aws/rules/rule_name. The named rule is the ingestion destination. Devices and rules cannot subscribe to these reserved Basic Ingest topics.

For an invented gateway, use the rule name LineTelemetry and this publication topic:

$aws/rules/LineTelemetry/lab/gateway17/temperature

The application suffix is lab/gateway17/temperature. It does not mean that an additional broker publication is automatically made on that suffix. An observer subscribed to lab/+/temperature is listening for ordinary broker traffic, not a mirror of every Basic Ingest message.

Similarly, subscribing to the whole reserved topic is not a repair. The absence of subscriber delivery is part of this route’s documented design. Changing a wildcard cannot reinsert a broker that the path intentionally bypasses.

Keep rule-relative topic levels explicit

The Basic Ingest prefix has three topic levels: $aws, rules, and the rule name. AWS documents that these levels are excluded from the rule’s topic() function interpretation.

For the synthetic topic, the rule-relative values are:

topic(1) -> lab
topic(2) -> gateway17
topic(3) -> temperature

A rule action that expects topic(2) to identify the gateway should therefore reason about the application suffix. Counting from $aws in a handwritten diagram would select the wrong field. Preserve the full published topic and the rule-relative interpretation together in the review record.

This is a routing and indexing example, not a complete rule definition. It does not supply account identities, credentials, destination resources or a publish policy to apply to a real system.

Choose the route according to the consumers

If the requirement is to deliver one publication to both an ordinary MQTT observer and the rules engine, the documented broker path uses a topic outside the Basic Ingest namespace. In the example, that could be lab/gateway17/temperature, with an appropriate rule subscription and observer subscription for that conventional topic.

Prepare the two intended paths on paper before changing anything:

• Basic Ingest topic: gateway to the named rule, without broker subscriber fanout.
• Conventional topic: gateway to the broker, with eligible subscriptions supplying the rule and observer paths.

The existence of both options does not authorize duplicating every production publication onto both. Such a change can double application effects if both routes reach the same destination. Decide which consumers actually need the record and keep its application identity visible during any isolated comparison.

Do not describe a silent MQTT observer as proof that a rule action failed. Conversely, rule invocation is not the same observation as successful downstream storage. Check the specific boundary required by the test instead of using one consumer as a proxy for another.

Build a route-discriminating fixture

Use an isolated rule and a harmless payload carrying a unique test-record ID. Record the publisher’s exact topic, intended rule, selected action destination, and observer’s subscription. First exercise the Basic Ingest path and inspect its rule/action evidence. The observer is not expected to receive a broker copy from that publication.

Then, if the reviewed design calls for broker distribution, exercise the conventional topic with explicitly configured subscriptions. Compare the record IDs at the rule destination and observer. This second case needs its own authorization and configuration checks; success on Basic Ingest does not prove that those subscriptions or permissions exist.

A useful negative check keeps the payload identical and changes only the route. That makes it possible to distinguish “no broker publication on this path” from a payload parser error. Preserve the expected recipient set for each case rather than calling every absent copy lost data.

These checks are proposed, not executed. The outcome should explain where the publication was routed and which consumers were meant to receive it. Once that is clear, a successful rule alongside a quiet MQTT observer stops being a contradictory result.