AWS IoT Core

Internet of Things

Managed message broker that securely connects devices to AWS and routes their data to other services.

Verified against AWS documentation · 2026-09-09

Key facts

  1. 01Devices publish and subscribe to MQTT topics; the broker fans each message out to every subscriber — devices never talk to each other directly
  2. 02Rules Engine filters messages with SQL-like syntax and routes them to 20+ AWS services (Lambda, S3, DynamoDB, SNS, Kinesis) — no servers, no polling
  3. 03Device Shadow is a JSON doc holding last-reported and desired state, so an app can read or command a device that's currently offline
  4. 04Every device authenticates with its own X.509 certificate over mutual TLS; an IoT policy controls which topics it may touch
  5. 05Limits: 128 KB max message payload, 8 KB Device Shadow doc; protocols are MQTT, MQTT over WSS, HTTPS, LoRaWAN

Exam triggers

Phrases and scenarios that point here.

  • "Millions of sensors", "connected devices", "telemetry", "device fleet" → IoT Core
  • Constrained device on a flaky, low-bandwidth network → MQTT, which IoT Core speaks natively
  • Send a command to a device that's intermittently offline → Device Shadow, not a direct call
  • Sensor data must land in S3 / DynamoDB / Lambda with nothing in between → Rules Engine

Not this service

  • Compute must run on the device itself, offline → AWS IoT Greengrass
  • App-to-app messaging with no physical devices → SNS, SQS, or EventBridge

Use cases

  1. 01Cold-chain trucks publishing freezer temperature every 30 seconds — a rule writes every reading to DynamoDB and fires SNS the moment one crosses the threshold
  2. 02City-wide smart electricity meters reporting usage on a schedule, with one managed broker instead of a fleet of servers holding connections open
  3. 03Consumer appliance control: the phone app writes "desired: on" to the Device Shadow, and the air-con picks it up the next time it's on Wi-Fi
  4. 04Factory vibration sensors streaming to one topic, where a rule tees the same data into S3 for history and Lambda for anomaly alerts
  5. 05Delivery-bike GPS trackers publishing position, with the rule filtering to only the ones outside their zone before anything is stored

How it's charged

  1. 01Four separate meters — connectivity, messaging, Device Shadow/registry, and rules engine — so the bill can grow from any one of them independently
  2. 02Connectivity is per minute per connected device, so an always-on device costs the same whether it's chatty or silent; keep-alive pings are free
  3. 03Messaging is metered in 5 KB blocks, and delivery counts too — one 8 KB publish to five subscribers is two metered messages in and ten out
  4. 04Shadow and registry operations are metered in 1 KB blocks of record size, so a 1.5 KB shadow update is charged as two operations
  5. 05Rules are metered per rule triggered plus per action executed, minimum one action; Basic Ingest (publish straight to a rule, skipping the broker) carries no messaging charge

Commonly confused with

Amazon SNSApplication IntegrationAmazon Kinesis Data StreamsAnalytics

References