iot

What this skill does

Specialist guidance for AWS IoT. Covers IoT Core (MQTT, shadows, rules engine), Greengrass v2 edge compute, fleet provisioning, security, data storage patterns, and fleet management.

## Process

1. Identify the IoT workload characteristics: device count, message frequency, payload size, connectivity (always-on vs intermittent), edge processing needs
2. Use the `awsknowledge` MCP tools (`mcp__plugin_aws-dev-toolkit_awsknowledge__aws___search_documentation`, `mcp__plugin_aws-dev-toolkit_awsknowledge__aws___read_documentation`, `mcp__plugin_aws-dev-toolkit_awsknowledge__aws___recommend`) to verify current IoT Core limits, Greengrass component versions, and service quotas
3. Select the appropriate IoT services using the decision matrix below
4. Design the communication and data ingestion topology (protocols, topics, rules)
5. Configure security (X.509 certificates, IoT policies, fleet provisioning method)
6. Design data storage and analytics pipeline
7. Plan fleet management (jobs, indexing, Device Defender)
8. Recommend operational best practices (monitoring, OTA updates, edge deployments)

## IoT Service Selection Decision Matrix

| Requirement | Recommendation | Why |
|---|---|---|
| Devices sending telemetry to cloud | IoT Core (MQTT) | Persistent connections, sub-second latency, bidirectional, scales to millions of concurrent connections |
| Request/response from constrained devices | IoT Core (HTTPS) | Stateless, no persistent connection needed, but higher latency and no server-to-device push |
| Browser or mobile app to IoT backend | IoT Core (MQTT over WebSocket) | Works through firewalls/proxies, uses IAM or Cognito auth instead of X.509 certificates |
| Edge preprocessing before cloud upload | Greengrass v2 | Reduces bandwidth cost and cloud ingestion volume by filtering/aggregating at the edge |
| Local device control when internet is down | Greengrass v2 | Local MQTT broker keeps device-to-device communication working during cloud disconnection |
| Industrial OPC-UA data collection | IoT SiteWise | Purpose-built for industrial protocols, asset modeling, and time-series with SiteWise Edge gateway |
| State machine on device events | IoT Events | Detector models react to patterns across multiple devices without custom Lambda logic |
| Time-series telemetry storage | Timestream | Purpose-built for time-series with automatic tiering (memory to magnetic), built-in interpolation and aggregation functions |
| Device metadata and state lookups | DynamoDB | Single-digit ms latency for key-value access to device config, state, and registry data |
| Bulk telemetry archival | S3 | Cheapest storage for raw telemetry; query with Athena when needed |
| Telemetry search and dashboards | OpenSearch | Full-text search and Kibana/OpenSearch Dashboards for operational visibility |

## Protocol Selection

### MQTT (Default Choice)

Use MQTT for device-to-cloud communication unless there is a specific reason not to. MQTT uses persistent TCP connections with minimal overhead (2-byte header minimum), supports QoS 0 (at most once) and QoS 1 (at least once), and enables server-initiated push to devices via subscriptions.

- **QoS 0**: Use for high-frequency telemetry where occasional message loss is acceptable (sensor readings every second). Lower overhead because no acknowledgment round-trip.
- **QoS 1**: Use for commands, configuration changes, and alerts where delivery must be confirmed. The broker retries until PUBACK is received.
- **QoS 2 is not supported** by AWS IoT Core. If exactly-once semantics are required, implement idempotency in the application layer.

### MQTT v5 Features (Prefer When Devices Support It)

- **Shared subscriptions**: Distribute messages across multiple subscribers for load balancing backend processors, avoiding hot-partition on a single consumer
- **Topic aliases**: Replace long topic strings with short integer aliases after first publish, reducing per-message overhead for bandwidth-constrained devices
- **Message expiry**: Set TTL on messages so stale commands are discarded rather than delivered to a device that reconnects hours later
- **Session expiry**: Control how long the broker holds session state after disconnect, preventing unbounded memory growth from abandoned devices

### HTTPS

Use HTTPS only for devices that wake up, send a single reading, and sleep (battery-powered sensors with cellular connectivity). HTTPS does not support subscriptions, so the device cannot receive commands without polling. Every request incurs TLS handshake overhead.

### MQTT over WebSocket

Use for browser-based dashboards and mobile apps that need real-time device data. Authenticates with IAM credentials or Cognito identity pools instead of X.509 certificates. Works through corporate proxies and firewalls that block raw TCP on port 8883.

## Topic Design

Design topics as a hierarchy with device identity and data type segments. This enables fine-grained IoT policy access control and targeted rules engine subscriptions.

### Recommended Structure

```
{org}/{environment}/{device-type}/{device-id}/{data-category}
```

Examples:
```
acme/prod/temperature-sensor/sensor-001/telemetry
acme/prod/temperature-sensor/sensor-001/alerts
acme/prod/temperature-sensor/sensor-001/commands
acme/prod/temperature-sensor/+/telemetry        # Rule subscribes to all sensors
```

### Topic Design Rules

- Include the device ID in the topic so IoT policies can use `${iot:Connection.Thing.ThingName}` to restrict each device to its own topics
- Separate telemetry, commands, and alerts into distinct subtopics so rules can target specific data types without parsing payloads
- Use `+` (single-level) and `#` (multi-level) wildcards in rules and subscriptions, never in publish topics
- Keep topics under 7 levels deep to stay within IoT Core limits and maintain readability

### Basic Ingest

For high-volume telemetry that goes directly to rules engine actions without needing the message broker, use the `$aws/rules/<rule-name>` topic prefix. Basic Ingest skips the message broker publish cost ($1.00 per million messages), saving significant cost at scale. The tradeoff: messages sent via Basic Ingest cannot be received by other MQTT subscribers.

## Device Shadow

Device Shadow maintains a JSON document of desired and reported state for each device. Use shadows when cloud applications need to read or set device state regardless of whether the device is currently connected.

### Classic vs Named Shadows

- **Classic shadow**: One per thing. Use for the primary device state (power on/off, firmware version, connectivity status).
- **Named shadows**: Up to 10 per thing. Use to separate independent state concerns (e.g., one shadow for configuration, another for diagnostics, another for firmware). Named shadows avoid state conflicts when multiple applications update different aspects of the same device.

### Shadow Best Practices

- Keep shadow documents small (<8 KB). Large shadows increase MQTT message size and DynamoDB read/write costs on the shadow service backend.
- Use `reported` state from the device, `desired` state from the cloud application. The `delta` field tells the device what to change.
- Set version-based optimistic locking on updates to prevent stale writes from overwriting newer state.

## IoT Rules Engine

The rules engine evaluates SQL statements against incoming MQTT messages and routes matching data to AWS service actions. Every production deployment should have at least one rule for data ingestion and error handling.

### Rule SQL Basics

```sql
SELECT temperature, humidity, timestamp() as ts, topic(4) as device_id
FROM 'acme/prod/temperature-sensor/+/telemetry'
WHERE temperature > 0 AND temperature < 150
```

- `topic(n)` extracts the nth level from the topic string (1-indexed)
- `timestamp()` adds server-side UTC timestamp
- `WHERE` clause filters before action execution, reducing downstream processing cost
- Use `SELECT *` sparingly; extract only the fields ne