Build IoT Core topic rule configurations with SQL queries, multi-action routing, and error handling.
Build IoT Core topic rule configurations with SQL queries, multi-action routing, and error handling.
Required Fields
RuleNameSqlActionsOutput will appear here...Build an AWS IoT Core topic rule combining an IoT SQL query (a SQL-like syntax over MQTT message payloads and topic segments, not standard ANSI SQL) with multiple parallel Actions routing matched messages to different destinations simultaneously (Timestream, Lambda, S3 in the example), plus a separate ErrorAction specifically for delivery failures. A rule's SQL WHERE clause filters which incoming messages trigger the actions at all, but a failure in one Action (say, the S3 write) doesn't roll back or block the other Actions from executing, IoT Core fires all matched actions independently, so partial success/failure across multiple destinations is a real operational scenario to design around, not an edge case.
No, each action listed in a topic rule executes independently, a failure in one action doesn't block or roll back the others. This means a single incoming message can succeed in reaching Timestream and Lambda while failing to reach S3 (due to a permissions issue, say), and without ErrorAction configured, that partial failure has no visible signal at all.
No, it's IoT SQL, a SQL-like syntax specific to IoT Core with its own functions (topic(), timestamp(), parse_time(), newuuid(), as seen in the example) for working with MQTT topic structure and message context, not a general-purpose database query language. Some familiar SQL constructs work, but IoT-specific functions and topic-path extraction are unique to this rules engine.
Before, the WHERE clause (part of the Sql field) is evaluated first, and only messages matching the condition proceed to trigger any of the rule's Actions at all. A message that doesn't match the WHERE clause is simply not processed by this rule, it's a pre-filter on which messages the rule's actions even see, not a post-processing filter on their outputs.
The builder validates that RuleName, Sql, and Actions all resolve before accepting the JSON as a valid CreateTopicRule request, the fields IoT Core needs to know the rule's name, its filtering query, and what to do with matching messages; it can't validate the IoT SQL syntax itself for correctness, or that the referenced IAM roles in each action actually have permission to write to their target destinations, those are checked only against the live account and at message-processing time.
Always configure ErrorAction for any rule with multiple actions or any action with real failure modes (Lambda throttling, S3 permission issues), without it, a partial delivery failure across a fan-out rule is completely invisible until someone notices missing data downstream.
IoT SQL's topic() function for extracting path segments is a genuinely useful pattern for avoiding payload bloat (not requiring every device to redundantly embed its own ID in every message), but it's brittle to topic structure changes, changing your MQTT topic hierarchy later breaks every rule relying on positional topic() extraction.
A WHERE clause filter that's too narrow (only catching genuinely rare anomalies) means most of your telemetry silently never reaches any of the rule's actions, verify the filter actually matches your intended monitoring scope, especially after initial testing with synthetic data that may not reflect real device behavior.
Was this tool helpful?
Disclaimer: This tool runs entirely in your browser. No data is sent to our servers. Always verify outputs before using them in production. AWS, Azure, and GCP are trademarks of their respective owners.