Cloud Parts

AWS IoT Core

AWS’s managed MQTT broker for devices, with per-device certificates, a SQL rules engine that routes messages into AWS services, and cloud-side device state.

Type
Managed service on AWS
Made by
Amazon Web Services
License
Proprietary; the AWS IoT Device SDKs are open source (Apache 2.0; the Embedded C SDK is MIT)
Facts checked
6 October 2026

What it is

Each AWS account gets its own device endpoint. Devices connect to it over MQTT 3.1.1 or MQTT 5 on TLS (port 8883, or 443 with ALPN), MQTT over WebSockets, or HTTPS, which can only publish. Most devices prove who they are with an X.509 client certificate; apps can sign with AWS SigV4, and a Lambda function can act as a custom authorizer. An AWS IoT policy, a JSON document in IAM style attached to the certificate, decides which client IDs may connect and which topics they may publish, subscribe and receive on. Behind the endpoint is a real publish/subscribe broker: topics are free-form, devices and apps can subscribe to each other, and it keeps retained messages and offline sessions (an hour by default). It supports QoS 0 and 1, not QoS 2.

Three services sit next to the broker. The rules engine runs SQL such as SELECT temp FROM 'factory/+/telemetry' WHERE temp > 80 over incoming messages and hands matches to actions: Lambda, Kinesis, Firehose, DynamoDB, S3, SQS, SNS, Kafka, Step Functions, Timestream, an HTTPS endpoint and more. Basic Ingest lets a device publish straight to one rule on $aws/rules/<rule>/..., skipping the broker and its message charge. Device Shadow keeps a JSON document per device with the state apps want (desired) and the state the device last reported (reported), so apps can read and change it while the device is offline. You pay per use: in US East, $1.00 per million messages (counted in 5 KB steps) for the first billion each month, $0.08 per million connection minutes, $1.25 per million shadow or registry operations, and $0.15 per million rules run and per million actions.

Why teams pick it

  • A full MQTT 3.1.1 and 5 broker with free-form topics, retained messages, persistent sessions and shared subscriptions, not just a device-to-cloud pipe
  • The rules engine filters messages with SQL and delivers them to about twenty destinations, mostly AWS services, with no servers to run; Basic Ingest skips the messaging charge
  • Per-device X.509 identities with IAM-style policies, and policy variables such as the thing name to give each device only its own topics
  • Pure pay-per-use: an idle fleet costs little, at $0.08 per million connection minutes in US East

Watch out for

  • No QoS 2, no guaranteed ordering, and QoS 0 messages can arrive more than once; devices must handle duplicates and reconnects
  • Every delivery is billed, in 5 KB steps: one publish fanned out to many subscribers, or replayed to a reconnecting persistent session, is charged again
  • Hard limits to design around: 128 KB per message, 100 publishes per second per connection, 8 KB shadows, and 50 subscriptions per connection by default
  • Shadows, rules, policies and $aws/... topics are AWS-specific, so device firmware and pipelines don’t move to another cloud unchanged
  • AWS has been retiring services around it: IoT Analytics shut down in December 2025, IoT Events in May 2026, and Greengrass V1 support ends on 7 October 2026

Alternatives

What all iot device messaging have in common →

How it fits with other technologies

Register a device, route hot readings to Lambda, publish with mosquitto · bash

# 1. A thing, a certificate, and a policy that limits it to its own topics
aws iot create-thing --thing-name pump-17
CERT_ARN=$(aws iot create-keys-and-certificate --set-as-active \
  --certificate-pem-outfile pump-17.crt --private-key-outfile pump-17.key \
  --query certificateArn --output text)

cat > policy.json <<'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "iot:Connect",
      "Resource": "arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}" },
    { "Effect": "Allow", "Action": "iot:Publish",
      "Resource": "arn:aws:iot:us-east-1:123456789012:topic/factory/${iot:Connection.Thing.ThingName}/*" }
  ]
}
EOF
aws iot create-policy --policy-name pump-policy --policy-document file://policy.json
aws iot attach-policy --policy-name pump-policy --target "$CERT_ARN"
aws iot attach-thing-principal --thing-name pump-17 --principal "$CERT_ARN"

# 2. A rule: readings above 80 go to a Lambda function
cat > rule.json <<'EOF'
{
  "sql": "SELECT topic(2) AS device, temp FROM 'factory/+/telemetry' WHERE temp > 80",
  "awsIotSqlVersion": "2016-03-23",
  "actions": [{ "lambda": { "functionArn": "arn:aws:lambda:us-east-1:123456789012:function:alert-on-heat" } }]
}
EOF
aws iot create-topic-rule --rule-name hot_pumps --topic-rule-payload file://rule.json
# (the function also needs `aws lambda add-permission` for iot.amazonaws.com)

# 3. Publish as the device over MQTT with its certificate
ENDPOINT=$(aws iot describe-endpoint --endpoint-type iot:Data-ATS \
  --query endpointAddress --output text)
mosquitto_pub -h "$ENDPOINT" -p 8883 --cafile AmazonRootCA1.pem \
  --cert pump-17.crt --key pump-17.key -i pump-17 -q 1 \
  -t factory/pump-17/telemetry -m '{"temp": 84.2}'

# Same rule through Basic Ingest: no broker, no messaging charge
# (the policy must also allow iot:Publish on topic/$aws/rules/hot_pumps/*)
mosquitto_pub -h "$ENDPOINT" -p 8883 --cafile AmazonRootCA1.pem \
  --cert pump-17.crt --key pump-17.key -i pump-17 -q 1 \
  -t '$aws/rules/hot_pumps/factory/pump-17/telemetry' -m '{"temp": 84.2}'

What you pay for#

List prices in US East (N. Virginia), checked 6 October 2026. Each line is billed separately, so one reading can incur several charges: the inbound message, each outbound delivery, a rule run and its actions.

MeterPriceNotes
Connectivity$0.08 per million connection minutesA device online all month is about 43,800 minutes, or $0.0035
Messaging (MQTT and HTTPS)$1.00 per million for the first billion a month; $0.80 for the next 4 billion; $0.70 beyondMetered in 5 KB steps: an 8 KB message counts as two. Inbound publishes and each delivery to a subscriber count
Device Shadow and registry$1.25 per million operationsShadow gets, updates and deletes, and registry calls
Rules engine$0.15 per million rules triggered, plus $0.15 per million actionsThe target service (Lambda, DynamoDB, S3…) bills on top
Basic IngestNo messaging chargeRule and action charges still apply; nothing else can subscribe to these messages
Direct Messaging$1.80 per million for the first billion; $2.50 per million with delivery confirmationAn HTTPS call that sends to one connected client by its client ID
  • Prices from the AWS Price List API for AWSIoT in us-east-1 (published 3 October 2026) and the AWS IoT Core pricing page. Other Regions cost more; LoRaWAN, Sidewalk and Device Location are priced separately.

AWS IoT Core, Azure IoT Hub and the Event Grid MQTT broker#

Azure splits what AWS IoT Core does across two services: IoT Hub for device identity, twins and commands, and Event Grid’s MQTT broker for open publish/subscribe. Google had an equivalent, Cloud IoT Core, until it retired the service on 16 August 2023.

AWS IoT CoreAzure IoT HubAzure Event Grid MQTT broker
ModelPub/sub broker on any topic, plus a rules engineDevice-to-cloud gateway: each device uses fixed topics for its own messagesPub/sub broker on custom topics, device to device and broadcast
MQTT3.1.1 and 5; QoS 0 and 13.1.1 only, with limited features; QoS 0 and 13.1.1 and 5; QoS 0 and 1
Other protocolsHTTPS (publish only), MQTT over WebSocketsAMQP, HTTPS, MQTT and AMQP over WebSocketsMQTT over WebSockets, HTTP Publish
Largest message128 KB256 KB device to cloud; 64 KB cloud to device1 MB
Device stateDevice Shadow, 8 KB by defaultDevice twin: 32 KB desired, 32 KB reported, 8 KB tagsNone built in; retained messages hold the last value per topic
Commands to a deviceShadow desired state, MQTT topics, Direct MessagingCloud-to-device queue (50 pending per device), direct methods with a 5 to 300 s timeoutMQTT topics, MQTT 5 request-response
RoutingSQL rules to about twenty destinations, mostly AWS servicesRouting queries to Event Hubs, Service Bus, Storage, Cosmos DBRoutes to Event Grid topics, then Event Hubs, webhooks or Fabric
Pricing modelPer message (5 KB), per connection minute, per shadow operation, per ruleFixed price per unit per month with a daily message quota (4 KB)Throughput units per hour plus operations (64 KB)

AWS IoT services that are gone or going#

The broker, shadows and rules engine are still developed, but several services built around them have been retired. Check before you design on top of one.

AWS IoT Analytics

shut down Dec 2025

Closed to new customers on 24 July 2024 and ended on 15 December 2025, after which consoles and resources were no longer reachable. Its rule action is gone from the docs.

AWS IoT Events

shut down May 2026

Detector models for state machines over device data. Closed to new customers on 20 May 2025 and ended on 20 May 2026. AWS’s migration guide rebuilds detectors with Kinesis, Lambda and other services.

AWS IoT Greengrass V1

ends 7 Oct 2026

The first version of AWS’s edge runtime is in sunset; support ends on 7 October 2026. Greengrass V2 is the replacement.

IoT FleetWise, SiteWise Monitor, Device Defender Detect

maintenance

No new customers and no new features, per AWS’s lifecycle list (announced October 2025 and March 2026). Existing users can keep using them.

See it in a real stack

No architecture uses AWS IoT Core yet. Drop it into the playground and wire it up yourself.Open playground →
Where it came from2015–2026

In 2015 AWS argued that cheaper compute, near-universal IP connectivity and big-data analytics would turn factory floors, vehicles, health care systems and household appliances into connected “things” that need somewhere in the cloud to talk to. On 8 October 2015 Jeff Barr announced AWS IoT in beta: a message broker speaking MQTT and HTTP, a registry of things, “thing shadows” holding each device’s state in the cloud, a rules engine with SQL-like filters that fed other AWS services, X.509 certificates for devices, and device SDKs for C, JavaScript and Arduino Yún. It became generally available on 18 December 2015.

The service, now called AWS IoT Core, grew around that broker. In December 2020 AWS added a managed LoRaWAN network server for long-range, low-power radios, and in November 2022 it added MQTT 5 features such as user properties, topic aliases, request-response and message expiry, with MQTT 3.1.1 and 5 clients able to talk to each other.

The family around it shrank later. AWS stopped taking new IoT Analytics customers in July 2024 and shut it down in December 2025, and ended IoT Events in May 2026, pointing customers back to general services like Kinesis and Lambda fed by IoT Core rules.

Why it’s built this way

A shadow of every device kept in the cloud
Devices drop off networks and sleep to save power. A stored desired and reported state lets apps read and change a device at any time; the device catches up when it reconnects.
SQL rules instead of consumer code
Most messages just need filtering and delivery to a database, queue or function. A declarative rule removes the fleet of subscriber programs you would otherwise run.
Per-device X.509 certificates and IAM-style policies
Shared passwords can’t be revoked for one stolen device. Mutual TLS with a certificate per device, and policies scoped to it, limit the damage to that device.
Standard MQTT, minus QoS 2
MQTT was already the light protocol constrained devices used. Leaving out QoS 2’s four-step handshake kept the broker simpler and scalable; devices handle duplicates instead.

Timeline

  1. 2015

    AWS IoT announced in beta on 8 October; generally available 18 December

  2. 2020

    AWS IoT Core for LoRaWAN runs the LoRaWAN network server for you

  3. 2022

    MQTT 5 support generally available in November

  4. 2024

    AWS IoT Analytics stops accepting new customers in July

  5. 2025

    AWS IoT Analytics shut down on 15 December

  6. 2026

    AWS IoT Events ends 20 May; Greengrass V1 support ends 7 October

Sources21 · facts checked 6 October 2026

Improve this page on GitHub