The Problem: What Do You Do With All This Data?
Once devices are publishing MQTT messages to IoT Core, you have a firehose of data. A fleet of 10,000 temperature sensors publishing every 30 seconds generates 20,000 messages per minute. You need to store it, analyze it, trigger alerts, and feed it into other systems — without writing a custom message consumer for each destination.
The Solution: Rules Engine
The IoT Rules Engine lets you define SQL-like rules that evaluate incoming MQTT messages and route them to AWS services automatically. It runs inside IoT Core — no servers to manage.
Rule anatomy:
SELECT temperature, deviceId, timestamp()
FROM 'factory/+/sensors/temperature'
WHERE temperature > 85
This rule:
- Listens to all topics matching factory/+/sensors/temperature
- Filters for messages where temperature exceeds 85°C
- Extracts three fields from the message payload
Actions you can attach to a rule:
| Action | Use Case |
|---|---|
| DynamoDB | Store each message as a row for device-level queries |
| S3 | Archive raw payloads for long-term storage or batch analysis |
| Kinesis Data Streams | Fan out to real-time analytics pipelines |
| Lambda | Run arbitrary code — call an API, send a notification, apply complex logic |
| SNS | Send SMS/email alerts when a threshold is crossed |
| SQS | Queue messages for downstream workers to process |
| IoT Analytics | Clean, enrich, and store time-series IoT data for visualization |
| Republish | Forward to another MQTT topic (useful for fan-out or normalization) |
Error handling: Every rule can have an error action — a secondary destination for messages that fail the primary action (e.g., Lambda throws an exception). Without an error action, failed messages are silently dropped.
A complete rule example — alert on high temperature: a rule combines the SQL query with one or more actions plus an optional error action. A high-temperature alert rule, for instance, would attach two actions to fire off the same matched message: an SNS publish to notify on-call staff and a DynamoDB write that logs the alert keyed by device ID and timestamp. Each action carries the ARN of the IAM role the Rules Engine assumes to perform it. The error action — commonly an SQS dead-letter queue — catches messages that fail every primary action, since without one, failed messages are silently dropped.
The Rules Engine evaluates rules in parallel — a single message can match multiple rules and trigger multiple actions simultaneously.