AWS IoT Core

What is AWS IoT Core?

AWS IoT Core is a fully managed cloud service from Amazon Web Services that acts as a managed MQTT broker and IoT connectivity platform. It allows devices - including RFID readers, sensors, and gateways - to connect securely to the cloud and communicate with each other and with AWS backend services, without requiring customers to provision or manage broker infrastructure.

Unlike self-hosted brokers such as Eclipse Mosquitto or HiveMQ , AWS IoT Core scales automatically to handle billions of messages and millions of concurrent device connections. Capacity is managed entirely by AWS. There are no servers to patch, no clusters to size, and no broker software to operate. You pay per message published and per minute of connection time.

AWS IoT Core is part of a broader family of AWS IoT services that includes IoT Greengrass (edge compute), IoT Device Management, IoT Analytics, and IoT Events. At the core of the platform is a standards-based MQTT message broker that also accepts HTTPS and WebSocket connections.

How it works

AWS IoT Core is composed of several integrated components that together handle device connectivity, message routing, and state management:

• Device gateway: The entry point for all device connections. Devices connect over MQTT (port 8883 with TLS), MQTT over WebSocket (port 443), or HTTPS. The gateway manages persistent connections, handles reconnection, and enforces per-device connection limits. Each AWS account gets a unique endpoint hostname (e.g. xxxxxxxxxxxxxx.iot.us-east-1.amazonaws.com).
• Message broker: A fully managed MQTT broker that routes messages between connected devices and to the rules engine. It supports MQTT 3.1.1 and partial MQTT 5.0 features. Standard MQTT pub/sub semantics apply: devices publish to topics, other devices or backend services subscribe to matching topics using exact names or + and # wildcards.
• Rules engine: A serverless processing layer that evaluates every inbound MQTT message against a set of SQL-like rules. Matching messages are routed to one or more AWS services (Lambda, DynamoDB, S3, Kinesis, SNS, SQS, and others) without any custom integration code. Rules can also republish messages to a different MQTT topic.
• Device shadow service: A persistent JSON store maintained by AWS IoT Core for each registered device. The shadow holds a reported state (what the device last reported about itself) and a desired state (what a backend application has requested). AWS IoT Core synchronises the two states and notifies the device of pending changes via reserved MQTT topics.
• X.509 certificate authentication: Every device must present a unique X.509 client certificate to establish a TLS connection. AWS IoT Core acts as its own certificate authority (CA) or accepts certificates signed by a customer-managed CA. IAM policies attached to certificates control which topics a device may publish to or subscribe from, providing per-device topic-level authorisation.
• Protocol support: MQTT 3.1.1, MQTT over WebSocket (enabling browser and firewall-friendly connections on port 443), and HTTPS for devices that cannot maintain a persistent TCP connection. All transports require TLS 1.2 or higher.

AWS IoT Core in RFID and IoT

AWS IoT Core is a common choice for cloud-first RFID architectures where edge readers must deliver tag events to cloud analytics, inventory systems, or event-driven workflows without operating on-premises broker infrastructure:

• Cloud ingestion for RFID reader data: Fixed UHF readers at dock doors, conveyor tunnels, or warehouse portals publish tag read events (EPC, RSSI, antenna port, timestamp) directly to AWS IoT Core over MQTT. Each reader authenticates with its own X.509 certificate, and IAM policies restrict it to publishing only to its assigned topic prefix (e.g. site/warehouse-1/dock/3/reads).
• Rules engine routing to backend services: A rules engine rule selects all tag read events using a SQL query such as SELECT * FROM 'site/+/dock/+/reads' and routes them simultaneously to an AWS Lambda function for deduplication, a DynamoDB table for real-time inventory state, a Kinesis Data Stream for analytics, and an S3 bucket for long-term archival - all without any application server in the path.
• Device shadows for reader state: The shadow service tracks operational state for each registered reader. A backend system writes a desired state to start or stop an inventory cycle; the reader picks up the change, executes it, and updates the reported state. Operations dashboards read the shadow to show current reader configuration without needing a direct connection to the reader.
• Edge gateway pattern: In sites with many readers, a local Mosquitto broker aggregates reads from all readers. A bridge or AWS IoT Greengrass component forwards filtered and deduplicated events to AWS IoT Core, reducing per-message costs and providing local resilience during WAN outages.
• Multi-region reader networks: Large retail or logistics operators with readers in multiple AWS regions can route events to regional IoT Core endpoints and use AWS services (EventBridge, Kinesis Global Tables) to aggregate data centrally.

Rules engine

The AWS IoT Core rules engine is a serverless stream-processing layer that sits between the message broker and AWS backend services. Rules are evaluated against every message that matches their topic filter.

Each rule consists of a SQL statement that queries the MQTT topic and message payload, and one or more actions that specify where matching messages are sent. The SQL dialect supports standard SELECT, FROM, and WHERE clauses, plus a library of built-in functions for string manipulation, JSON extraction, mathematical operations, and timestamp formatting.

• Topic filtering: The FROM clause is an MQTT topic filter. FROM 'rfid/+/reads' matches messages published to any single-level topic under rfid/ that ends with /reads.
• Payload projection: SELECT epc, rssi, timestamp FROM ... passes only the specified fields to downstream actions, reducing payload size before it reaches Lambda or DynamoDB.
• Conditional filtering: A WHERE rssi > -70 clause discards weak reads before they reach backend services, implementing a noise filter in the rules engine rather than in application code.
• Actions: A single rule can invoke multiple actions simultaneously. Common targets include Lambda (arbitrary processing), DynamoDB (direct item write), S3 (object storage), Kinesis Data Streams (ordered high-throughput ingestion), SNS (fan-out notifications), SQS (queued processing), and IoT Events (state machine triggers).
• Error handling: Rules can specify an error action - a fallback target (typically an S3 bucket or SQS queue) that receives messages when the primary action fails. This prevents silent data loss if a downstream service is temporarily unavailable.

Device shadows

A device shadow is a persistent JSON document in AWS IoT Core that represents the state of a physical device. The shadow exists and is queryable even when the device is offline, making it a reliable source of truth for device state in applications.

Each shadow has three top-level sections:

• desired: The state that a backend application or operator wants the device to reach. For an RFID reader, this might include the target antenna power level, a read filter configuration, or an inventoryActive: true flag to start a read cycle.
• reported: The state the device has most recently confirmed. The reader publishes updates to its shadow's reported section after applying a configuration change or completing an inventory cycle.
• delta: Automatically computed by AWS IoT Core. The delta section contains any fields where desired and reported differ. When a device reconnects, it subscribes to the delta topic and processes only the changes it has not yet applied, avoiding full-state resync on reconnection.

Devices interact with their shadow via reserved MQTT topics under the $aws/things/{thingName}/shadow/ prefix. Named shadows (multiple shadows per device) allow different subsystems - for example, antenna configuration and firmware state - to be managed independently.

Advantages

• Fully managed: No broker software to install, configure, patch, or operate. AWS handles availability, scaling, and maintenance. Suitable for teams without dedicated MQTT infrastructure expertise.
• Automatic scaling: AWS IoT Core scales to millions of concurrent connections and billions of messages per day with no capacity planning required. Traffic spikes during large inventory events or multi-site deployments are absorbed automatically.
• Deep AWS integration: Native, zero-code routing to Lambda, DynamoDB, S3, Kinesis, SNS, SQS, and other AWS services via the rules engine. No custom integration layer is needed to connect MQTT events to cloud workflows.
• Pay-per-use pricing: Costs are based on messages published and connection minutes. There is no minimum commitment or reserved capacity. Low-volume deployments are inexpensive; costs scale linearly with usage.
• Built-in security: Mutual TLS with X.509 certificates is required for all device connections. Per-device IAM policies enforce topic-level publish and subscribe permissions. Certificate rotation and revocation are managed through the AWS console or API.
• Device shadow service: Persistent, cloud-managed device state is included at no additional broker configuration cost. Applications can read and update reader state without needing a live connection to the reader.
• Global availability: Available in most AWS regions, enabling latency-appropriate endpoints for geographically distributed reader networks.

Limitations

• AWS lock-in: AWS IoT Core is tightly coupled to the AWS ecosystem. Migrating to a different broker or cloud provider requires re-provisioning certificates, updating device firmware, and rebuilding rules engine integrations. This is a significant consideration for multi-cloud or vendor-neutral architectures.
• Per-message pricing at scale: At very high read rates (hundreds of thousands of tag events per second across a large reader network), per-message costs can exceed those of a self-managed clustered broker. Cost modelling is essential before committing to a cloud-first architecture for high-throughput deployments.
• 128 KB message size limit: AWS IoT Core enforces a 128 KB maximum per MQTT message. Bulk inventory snapshots, firmware update payloads, or large configuration objects must be chunked or delivered via S3 pre-signed URLs rather than directly over MQTT.
• Latency vs on-premises brokers: Messages must traverse the public internet (or AWS Direct Connect) to reach the IoT Core endpoint. Round-trip latency is higher than a local broker on the same LAN as the readers. Time-critical edge logic should run on-premises rather than relying on cloud round trips.
• Limited MQTT 5.0 support: AWS IoT Core supports a subset of MQTT 5.0 features. Some MQTT 5.0 capabilities - including shared subscriptions, topic aliases, and the full user properties model - have limited or no support, which can affect portability from brokers with complete MQTT 5.0 implementations.
• Rules engine SQL limitations: The rules engine SQL dialect is not a full SQL implementation. Complex event processing, stateful aggregations, or joins across multiple topic streams require Lambda functions rather than pure rules engine configuration.
• No persistent sessions for QoS 1 across reconnects at scale: AWS IoT Core supports persistent sessions for offline message queuing, but session message queuing limits and retention periods are constrained by AWS service quotas, which differ from those of self-managed brokers.

AWS IoT Core vs Mosquitto vs HiveMQ

Common RFID deployments

• Cloud-first RFID architectures: Organisations building new RFID deployments on AWS often connect readers directly to AWS IoT Core rather than running on-premises middleware. Each reader is provisioned as a Thing with its own X.509 certificate. Tag reads flow from reader to IoT Core to Lambda to DynamoDB with no persistent server infrastructure required. This pattern works well for retail chains and logistics providers already operating within AWS.
• Multi-region reader networks: Manufacturers or 3PLs with facilities in multiple AWS regions connect readers to the nearest regional IoT Core endpoint to minimise MQTT connection latency. Regional rules engines route events to regional DynamoDB tables with global tables replication providing a unified view of inventory across all sites.
• Serverless RFID event processing: A rules engine rule routes each tag read to an AWS Lambda function that looks up the EPC in a product database, determines whether the tag has been seen before (deduplication via DynamoDB conditional writes), and triggers downstream actions such as an SNS notification or an SQS message to a WMS integration queue - all without a standing application server.
• Hybrid edge and cloud architectures: Sites with unreliable WAN links run a local Mosquitto broker that buffers reads during outages. An AWS IoT Greengrass component or custom MQTT bridge forwards events to AWS IoT Core when connectivity is available. The rules engine then picks up the backlog and routes it through the same Lambda and DynamoDB pipeline as live events.
• Reader fleet management via device shadows: A fleet of hundreds of fixed readers across multiple warehouses is managed centrally using device shadows. Operators update the desired state of reader configurations (antenna power, session flags, filter settings) through an AWS-hosted management console. Readers apply changes on their next connection and update reported state, giving operators confirmation of applied configuration without direct network access to each reader.

Related