IoT Core

Connect and manage billions of IoT devices using MQTT, HTTPS, and WebSocket

AWS IoT Core is a fully managed cloud service that lets you connect billions of IoT devices to AWS without provisioning or managing servers. It supports MQTT, HTTPS, and WebSocket protocols and provides a rules engine to route device data to over 20 AWS services. For cloud engineers, IoT Core is the entry point for any IoT architecture and understanding its message broker, security model, and rules engine is essential.

How IoT Core Works: Message Broker and Device Shadow

IoT Core has three main components: the message broker, the rules engine, and the device shadow service. Devices connect via MQTT or HTTPS, authenticate with X.509 certificates, and publish/subscribe to topics. The rules engine evaluates SQL-like rules on incoming messages and routes them to downstream services.

Component	Purpose	Key Detail
Message Broker	Pub/sub backbone for device-to-cloud and cloud-to-device messaging	Supports MQTT 3.1.1, MQTT 5, HTTPS, WebSocket
Rules Engine	Routes and transforms messages to AWS services	Uses SQL syntax, supports 20+ actions including Lambda, S3, DynamoDB, Kinesis
Device Shadow	Persistent JSON document representing device state	Supports desired, reported, and delta states; survives device disconnects
Registry	Catalog of all registered IoT things	Stores metadata, attributes, and certificates for each device
Jobs	Remote operations pushed to devices	Used for firmware updates, config changes; supports rollout rates and abort criteria

💡

Device Shadow is one of the most commonly tested IoT Core topics. Know the difference between desired (cloud wants), reported (device says), and delta (mismatch between the two).

Protocols: MQTT vs HTTPS vs WebSocket

Choosing the right protocol depends on device capabilities, power constraints, and connection persistence requirements.

Protocol	Port	Best For	Limitations
MQTT	8883 (TLS)	Persistent connections, low-bandwidth devices, QoS delivery	Requires persistent TCP connection
MQTT over WebSocket	443	Browser clients, environments that block 8883	Higher overhead than native MQTT
HTTPS	443	Simple publish-only from devices or serverless functions	No subscribe support, higher latency per request

MQTT QoS Level	Guarantee	Use Case
QoS 0	At most once - fire and forget, no acknowledgment	Telemetry where occasional loss is acceptable
QoS 1	At least once - acknowledged, may be delivered multiple times	Commands and state updates that must arrive
QoS 2	Exactly once - not supported by IoT Core	N/A - use application-level deduplication instead

⚠️

IoT Core does not support MQTT QoS 2. If your application requires exactly-once delivery, you must implement deduplication at the application layer using message sequence numbers or timestamps.

Security: Certificates, Policies, and IAM

IoT Core uses a layered security model. Devices authenticate with X.509 certificates (not IAM users). IoT policies (similar to IAM policies) control what MQTT topics a device can publish or subscribe to. These are separate from IAM policies used to control AWS API access.

bash

# Create a certificate and attach a policy
aws iot create-keys-and-certificate \
  --set-as-active \
  --certificate-pem-outfile cert.pem \
  --public-key-outfile public.key \
  --private-key-outfile private.key

# Create an IoT policy
aws iot create-policy \
  --policy-name "DevicePublishPolicy" \
  --policy-document '{
    "Version": "2012-10-17",
    "Statement": [{
      "Effect": "Allow",
      "Action": ["iot:Publish"],
      "Resource": "arn:aws:iot:us-east-1:123456789:topic/devices/${iot:ClientId}/telemetry"
    }]
  }'

# Attach policy to certificate
aws iot attach-policy \
  --policy-name "DevicePublishPolicy" \
  --target <certificate-arn>

💡

Use policy variables like ${iot:ClientId} and ${iot:Connection.Thing.ThingName} to scope device permissions to their own topics without creating one policy per device.

Rules Engine: Routing and Transforming Device Data

The rules engine listens to MQTT topics and evaluates SQL queries against message payloads. A single rule can have multiple actions. Rules are evaluated in real time as messages arrive.

bash

# Example rule that routes high-temperature readings to an SNS alert
# Rule SQL:
SELECT deviceId, temperature, timestamp
FROM 'sensors/+/temperature'
WHERE temperature > 80

# Create rule via CLI
aws iot create-topic-rule \
  --rule-name "HighTempAlert" \
  --topic-rule-payload '{
    "sql": "SELECT deviceId, temperature FROM 'sensors/+/temperature' WHERE temperature > 80",
    "actions": [{
      "sns": {
        "targetArn": "arn:aws:sns:us-east-1:123456789:alerts",
        "roleArn": "arn:aws:iam::123456789:role/iot-rules-role",
        "messageFormat": "JSON"
      }
    }],
    "errorAction": {
      "cloudwatchLogs": {
        "logGroupName": "/iot/rule-errors",
        "roleArn": "arn:aws:iam::123456789:role/iot-rules-role"
      }
    }
  }'

Rule Action	Use Case
Lambda	Custom processing, enrichment, complex routing logic
DynamoDB	Store individual readings directly to a table
DynamoDBv2	Store full message as an item, multiple columns from JSON
Kinesis Data Streams	High-volume telemetry fan-out to analytics pipelines
S3	Archive raw messages, batch processing
SNS	Fan-out alerts and notifications
SQS	Decoupled processing queues
IoT Events	Feed event detectors for state machine logic
Timestream	Time-series storage for device metrics

⚠️

Always configure an errorAction on every rule. Without it, failed rule evaluations are silently dropped. The errorAction should write to CloudWatch Logs or SQS so you can debug routing failures.

Pricing Model and Cost Optimization

IoT Core pricing has several dimensions. Understanding each dimension is key for cost estimation in architecture interviews.

Pricing Dimension	Unit	Approximate Cost
Connectivity	Per million minutes of device connection	$0.042 per million minutes
Messaging	Per million messages (payload up to 5 KB)	$1.00 per million messages (first billion)
Rules Engine	Per million rules triggered	$0.15 per million rule triggers
Rules Engine actions	Per million actions executed	$0.15 per million actions
Device Shadow operations	Per million operations	$1.25 per million operations
Device Shadow storage	Per GB per month	$0.10 per GB-month
Registry operations	Per million API calls	$1.25 per million calls

💡

Cost optimization tip: batch multiple sensor readings into a single MQTT message rather than publishing one message per reading. A single 5 KB message costs the same as a 1-byte message. This can reduce messaging costs by 10-50x for high-frequency sensors.

🎯

Interview Focus Points

1Explain the difference between desired, reported, and delta states in Device Shadow.
2A device publishes sensor data every second. How would you reduce IoT Core messaging costs?
3How do IoT policies differ from IAM policies, and can a device use both?
4What happens to MQTT messages published while a device is offline - how does QoS 1 help?
5Walk me through how you would design a rule to alert when 10 devices in the same fleet all report temperature above a threshold within 5 minutes.
6How would you handle firmware updates for 100,000 devices with IoT Core Jobs and what abort criteria would you set?
7Explain the two-way communication pattern using Device Shadow for a thermostat that may be offline.
8What is the difference between a Thing Type and a Thing Group in the IoT registry?