AWS IoT Core

What IoT Core is

IoT Core is the front door for connecting physical devices to AWS. A device gateway holds long-lived, secure connections to your fleet — devices connect over MQTT (or MQTT-over-WebSocket, or plain HTTPS) and keep a bidirectional session open so messages flow either way at any time. A pub/sub message broker moves those messages between devices and applications by topic, and a Rules Engine matches inbound messages against SQL-like rules and forwards them to other AWS services.

The fourth piece is the Device Shadow — a persistent JSON document per device holding its last reported state and its desired state, so your apps can read and set a device’s state through an API even while the device is offline. Design Beaver models IoT Core as a regional connectivity broker and Rules Engine router, and validates as you draw which services a rule can forward to and the IAM each of those actions needs.

When to use IoT Core (and when not to)

Reach for IoT Core when you have real devices that need a secure, authenticated, long-lived connection to the cloud — especially over MQTT, which is built for bandwidth- and power-constrained hardware. It’s the right tool when device messages have to fan out to several AWS services with per-message filtering, without each device knowing the downstream targets, and when devices are intermittently connected and you need a durable per-device state that apps can read and write regardless.

Don’t reach for it for service-to-service messaging inside AWS with no devices involved — the connectivity and shadow machinery is pure overhead, and SNS, SQS, or EventBridge do that job more simply. A plain HTTP API for a web or mobile app is API Gateway, not a device gateway. And high-throughput ordered stream analytics is Kinesis — route IoT data into it rather than treating the broker as a stream processor.

Variants: how devices connect and hold state

The real choices are how a device talks to IoT Core and whether you use a shadow. Most fleets sit on the long-lived MQTT session; HTTPS suits devices that only occasionally publish; Device Shadow is the state layer for hardware that isn’t always online.

IoT Core pricing

The thing that surprises people isn’t the per-component split — it’s that almost everything meters in size increments. Messaging, rules, and actions bill in 5 KB chunks and shadow operations in 1 KB, so a slightly-oversized payload quietly rounds up to the next unit on every single message.

How IoT Core connects to other services

The device gateway and broker are only half the picture — the connections that matter on a diagram are the Rules Engine actions, where a topic rule forwards matched device messages into the rest of your architecture. Almost every one is an IAM edge: IoT Core runs each action under a role the rule assumes, and that role has to grant the action on the target — dynamodb:PutItem, s3:PutObject, lambda:InvokeFunction, and so on. Design Beaver models each of these edges, so it knows what a rule can route to and what makes that route correct.

• →Lambdasecurity

  A topic rule's Lambda action invokes a function with the matched device message as input — the general-purpose way to run custom logic on incoming device data

  IAM:lambda:InvokeFunction

• →DynamoDBsecurity

  A topic rule's DynamoDB action writes the (optionally transformed) device message straight into a table — e.g. persisting each sensor reading as an item, keyed by device ID and timestamp

  IAM:dynamodb:PutItem

• →S3security

  A topic rule's S3 action saves the message payload as an object — e.g. archiving raw device data to a bucket for later batch processing or as a data lake landing zone

  IAM:s3:PutObject

• →SNSsecurity

  A topic rule's SNS action publishes to a topic to fan a device event out to multiple subscribers or send a push/SMS notification — e.g. alerting when a sensor crosses a threshold

  IAM:sns:Publish

• →SQSsecurity

  A topic rule's SQS action sends the message to a queue, giving a downstream consumer a durable buffer to process device data at its own pace

  IAM:sqs:SendMessage

• →Step Functionssecurity

  A topic rule's Step Functions action starts a state machine execution from a device message — kicking off a multi-step workflow (e.g. an over-the-air update or an incident-response flow) in response to a device event

  IAM:states:StartExecution

What IoT Core can’t connect to

Some edges look reasonable on a canvas but have no rule action behind them — the Rules Engine can’t put an event on a bus, run a SQL insert, or call software on an instance directly. Design Beaver flags them instead of letting you draw a diagram that can’t be built.

• ✕EventBridge

  The IoT Rules Engine has no EventBridge action — a topic rule can't put an event on an event bus directly. (AWS IoT device lifecycle/registry events reach EventBridge through a separate managed integration, not a rule action you configure on message data.) To land device messages on a bus, target a Lambda rule action that calls PutEvents.

• ✕RDS

  There is no Rules Engine action for RDS — a topic rule can't run a SQL insert against a relational database. Route the message through a Lambda action (or into a queue a worker drains) and write to RDS from there.

• ✕EC2

  IoT Core doesn't make network calls to software on an EC2 instance — there's no EC2 rule action. To hand device data to an app on EC2, use a rule action to a queue/topic the instance consumes, or an HTTP action to an endpoint it exposes.

• ✕CloudFront

  CloudFront is a CDN that serves content to end users from HTTP origins — it is neither a device-connectivity endpoint nor a Rules Engine target. There is no IoT Core <-> CloudFront relationship to draw.

• ✕Route 53

  Route 53 is DNS. Devices reach IoT Core through its account-specific data endpoint, and the Rules Engine routes by topic, not DNS — there is no IoT Core <-> Route 53 edge.

Anti-patterns Design Beaver catches

These are the IoT Core mistakes that pass a diagram review but bite in production — the ones the validation engine flags as you draw.

Gotchas that bite in production

• Everything meters in size increments. Messaging, rules, and actions bill in 5 KB chunks; shadow and registry operations in 1 KB. A chatty fleet with slightly-oversized payloads pays for the next whole increment on every message.
• Rule actions are one-shot, with no logic. A DynamoDB, S3, SNS, or SQS action does exactly one thing per message. Anything with branching, validation, or multiple writes belongs in a Lambda action — or a Step Functions workflow — not a web of rules faking a pipeline.
• The rule’s IAM role is a separate thing to get right. IoT Core assumes a role you configure per rule to run its actions, and a missing permission fails the action at message time, not at setup. This is exactly the edge Design Beaver surfaces as you draw.
• Device Shadow is current-state, not history. It holds reported and desired state, is capped in practical size, and is priced per operation — it’s not a time-series store. Write historical telemetry to DynamoDB or S3 via rule actions instead.
• No devices? Wrong service. Using IoT Core as an in-cloud message bus between AWS services means paying connectivity and messaging metering to do what SNS, SQS, or EventBridge do more simply.

Further reading

• Official AWS documentation
• Why we built a validation engine