A plant that already publishes MQTT from its gateways is most of the way to AWS, because AWS IoT Core is at heart a managed MQTT broker with a rules engine bolted on. The interesting part is not getting a message into the broker but what happens after it arrives: how a single tag reading can be routed to a time-series database, an object store, and a stream all at once without the field device knowing or caring. This page walks through how field telemetry reaches IoT Core, how its rules engine fans data out to downstream services, how device certificates secure the gateways, and where IoT Core earns its place over a plain broker.
SCADA to AWS IoT Core integration in one line: SCADA to AWS IoT Core integration is the practice of connecting field gateways that publish MQTT or Sparkplug telemetry into AWS IoT Core, a managed MQTT broker and rules engine, so that tag data can be routed into AWS services. Gateways authenticate with X.509 device certificates and publish to MQTT topics, and the IoT Core rules engine matches those topics with SQL-like statements to fan each reading out to destinations such as Amazon Timestream, S3, and Kinesis. This turns a field MQTT stream into a managed cloud ingestion pipeline without the plant running its own broker infrastructure.
The feature that distinguishes IoT Core from a bare MQTT broker is its rules engine. A rule is defined with a SQL-like statement that selects from a topic filter, optionally transforms the payload, and then routes the result to one or more actions. Because a single incoming message can trigger multiple rules and each rule can have several actions, one tag reading published to a topic like a site's telemetry channel can be inserted into Amazon Timestream for time-series querying, written to S3 for durable low-cost storage, and pushed onto a Kinesis stream for real-time processing, all from the one message arriving. The field gateway simply publishes once and the fan-out happens entirely in the cloud.
The topic hierarchy is what makes this manageable at scale. A well-structured topic scheme, encoding site, area, and measurement into the topic levels, lets rules use wildcards to match broad or narrow slices of the telemetry. A rule can subscribe to all telemetry from every site with a multi-level wildcard, or narrow to a single site's pressure readings, without the publisher changing anything. Designing the topic tree carefully up front pays off here, because the routing logic is expressed as topic filters, and a clean hierarchy means new sites and new measurement types slot in without rewriting rules.
The SQL-like rule language can also reshape the payload in flight, pulling specific fields out of a JSON message, adding metadata, or filtering so that only readings meeting a condition are forwarded. This keeps unnecessary data out of expensive destinations, for instance sending every reading to cheap S3 storage while only forwarding readings that cross a threshold onto a stream that triggers downstream logic. That per-destination selectivity is a large part of why the rules engine is the workhorse of the integration rather than an afterthought.
IoT Core does not let anonymous clients connect. Each device, which in a SCADA context usually means an edge gateway aggregating many field tags rather than an individual sensor, authenticates with an X.509 certificate. The certificate identifies the gateway, and an attached policy declares exactly which topics that gateway is allowed to publish to and subscribe from. This gives fine-grained control: a gateway at one site can be restricted so its certificate only permits publishing to that site's topic branch, so a compromised or misconfigured device cannot flood or read topics belonging to other sites.
Managing certificates is an operational discipline rather than a one-time setup. Certificates are provisioned when a gateway is commissioned, they can be rotated on a schedule so that a long-lived credential is not left in place indefinitely, and they can be revoked immediately if a gateway is decommissioned or suspected of being compromised. Because revocation takes effect at the broker, pulling a certificate cuts a gateway off cleanly without touching the field device, which matters when a unit is physically remote. Registering certificates against a certificate authority and using a provisioning flow keeps this from becoming a manual chore for every new gateway.
There is also a modeling feature worth knowing about, the device shadow, which is a JSON document IoT Core maintains for each device holding its reported and desired state. For a SCADA gateway the shadow is less about individual tag values, which stream through as telemetry, and more about the gateway's configuration and connectivity, letting a cloud application read the last known state of a device even while it is offline and stage a desired configuration for the device to pick up when it reconnects. It is a way to reason about the device's status separately from the flood of measurement data passing through it.
It is fair to ask why a plant would use IoT Core instead of simply running its own MQTT broker, which is a mature and well-understood piece of infrastructure. The answer is that a raw broker moves messages and stops there. It authenticates clients and delivers publishes to subscribers, but it has no built-in notion of routing a message into a database, archiving it, or triggering downstream logic, so all of that has to be built and operated as separate consumer applications. IoT Core folds authentication, the routing rules engine, and the integrations with cloud services into one managed layer, which is what a team is really buying: less custom plumbing to build and keep running.
The trade-off is coupling and cost model. Committing telemetry ingestion to IoT Core ties that part of the architecture to AWS, and the pricing is based on messages and rule actions, so a very high-frequency stream with heavy fan-out is metered accordingly. A plant that only needs to move messages between systems on its own premises, with no cloud analytics ambitions, may find a self-hosted broker simpler and cheaper. The decision usually comes down to whether the value is in the field-to-field messaging, where a plain broker suffices, or in getting telemetry into a rich set of cloud services with minimal custom code, where the rules engine earns its keep.
In many real deployments IoT Core sits behind an edge layer rather than talking to individual field devices, and this is where a monitoring platform fits. A platform such as Merobix can collect SCADA tags across mixed field protocols, normalize them, and publish a clean MQTT stream that a gateway forwards into IoT Core, so the cloud side deals with consistent, well-formed messages rather than raw device output. That separation lets IoT Core and the AWS services behind it focus on storage and analytics while operators keep a live operational view in the monitoring layer, with each part of the stack doing the job it is best suited to.
The rules engine matches incoming MQTT messages against SQL-like statements on topic filters and routes each match to one or more actions, so a single tag reading can be inserted into Timestream, written to S3, and pushed onto Kinesis at once. Rules can also reshape and filter the payload in flight, sending only readings that meet a condition to expensive destinations. This fan-out happens entirely in the cloud, so the field gateway just publishes once.
Each gateway authenticates with an X.509 certificate, and an attached policy declares exactly which topics that gateway may publish to and subscribe from. This lets you restrict a site's gateway to its own topic branch so a compromised device cannot reach other sites. Certificates are provisioned at commissioning, can be rotated on a schedule, and can be revoked at the broker to cut a gateway off cleanly without touching the field device.
Use IoT Core when the value is in getting telemetry into cloud services with minimal custom code, because it bundles authentication, a routing rules engine, and integrations with databases and streams into one managed layer. A raw broker only moves messages, so routing to a database or triggering downstream logic has to be built and operated separately. If you only need on-premises message passing with no cloud analytics, a self-hosted broker is often simpler and cheaper.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.