An industrial field gateway and a cloud IoT gateway are often described as competing options, but in practice they sit on different layers of the same plant network, with the field gateway doing protocol aggregation and store-and-forward while the cloud IoT gateway focuses on northbound MQTT/HTTPS uplink and remote fleet management [S1][S2].
The decision is not binary: most plants run a field protocol gateway at the cell level to translate Modbus/OPC UA and buffer data, then push summaries through a cloud IoT gateway (often with cellular) for dashboards and analytics, a layered pattern confirmed across current vendor literature [S3][S5].
What a field gateway actually does at the cell level
A field gateway aggregates data from many sensors and PLCs, translates between field protocols (Modbus RTU/TCP, OPC UA, BACnet, Zigbee, LoRaWAN) and northbound formats (MQTT, AMQP, OPC UA over TLS), and forwards the result to a higher system such as a historian, OEE platform, or cloud [S1][S5]. Core functions are protocol translation, data aggregation, filtering, local buffering during network outages, and enforcement of a security perimeter with TLS, role-based access, and device authentication [S1].
Industrial field gateways are ruggedized (often wide-temperature, fanless, with TPM, redundant power, and multiple serial/Ethernet ports) and run modular software stacks such as AWS IoT Greengrass, Azure IoT Edge, Eclipse Kura, or EdgeX Foundry, with containerized microservices for updates without service interruption [S1]. For a typical brownfield cell, the gateway turns a heterogeneous set of legacy devices into a single normalized data stream, which is the practical definition of a fieldbus gateway role.
What a cloud IoT gateway adds on top
A cloud IoT gateway, sometimes marketed as an industrial IoT gateway or edge router, adds the WAN uplink: cellular LTE/5G, Wi-Fi client, or broadband Ethernet, plus a device-management agent (for example RCMS paired with Robustel EG5120) that reports the device to a cloud platform for remote visibility, OTA firmware, and fleet dashboards [S2][S4].
Beyond connectivity, the cloud IoT gateway is where data is prepared for cloud ingestion: payload compression, JSON normalisation, time-series tagging, and selective forwarding so that only filtered, pre-processed data reaches the cloud tier, with the cloud reserved for deep analytics, AI/ML, long-term archiving, and enterprise dashboards [S2][S4]. This split keeps bandwidth, cellular data cost, and cloud egress under control, especially at remote sites such as water stations, EV chargers, or utility cabinets [S2].
Selection criteria: latency, bandwidth, connectivity, security
For real-time control loops that need sub-10 ms response, the field gateway is the only option: WAN round-trip latency to the cloud typically reaches hundreds of milliseconds, which is incompatible with deterministic local control [S1][S3]. If the requirement is sub-second local analytics such as anomaly detection, OEE calculation, or vibration-triggered shutdown, an edge device (often a hardened PC or smart sensor) is the right layer, while the field gateway still aggregates the rest [S5].
For bandwidth-constrained or intermittently connected sites, the field gateway must store-and-forward during WAN outages and resync when the link returns, a capability the cloud IoT gateway depends on but does not itself provide [S1][S2]. Security-wise, modern gateways embed hardware root-of-trust, TPM, secure boot, certificate rotation, and TLS on every northbound session, with the field gateway enforcing the OT/IT boundary and the cloud IoT gateway enforcing the site/Internet boundary [S1][S4].
Decision matrix: field gateway vs cloud IoT gateway vs hybrid
On four decision criteria, the practical comparison is: (1) Compute location: field gateway does minimal local compute, cloud IoT gateway does light prep + cloud offload, edge device does heavy local compute. (2) Latency target: field gateway typically seconds, cloud IoT gateway tens to hundreds of ms, edge device sub-second to ms. (3) Bandwidth tolerance: field gateway needs reliable LAN, cloud IoT gateway tolerates cellular/Wi-Fi variability, edge device tolerates near-zero uplink. (4) Integration effort: field gateway requires OT protocol expertise, cloud IoT gateway requires cloud SDK / IAM setup, edge device requires app containerisation [S1][S2][S3][S5].
For most plants, the recommended pattern is hybrid: a field data logger + protocol-translation tier at the cell, feeding a cloud IoT gateway at the site, with an edge device added only where latency or bandwidth forces compute toward the sensor [S3][S5]. This is consistent with the layered architecture in the Repair vs Replace an Aging PLC decision framework, where the gateway is treated as the OT/IT bridge whose replacement or upgrade is driven by protocol and bandwidth constraints, not by PLC hardware alone.
Use cases and common failure modes
A water or energy utility with cellular-connected RTUs is the canonical cloud IoT gateway case: local store-and-forward, selective reporting, RCMS-style remote management, and cloud dashboards for multi-site comparison [S2]. A discrete manufacturing cell with many legacy PLCs is the canonical field gateway case: many protocols to normalise, one northbound stream, no need for on-device AI [S1][S4]. A high-speed vision or vibration line needs edge compute plus a field gateway for everything else, because raw video or high-rate vibration cannot be uplinked in real time [S3][S5].
Common failure modes: treating the field gateway as a "smart sensor" and overloading it with vision or ML inference; treating the cloud IoT gateway as a protocol-translation device and discovering that Modbus RTU slave polling does not match MQTT publish models; ignoring store-and-forward sizing so that multi-day cellular outages overflow local buffers; and shipping a gateway without OTA, secure boot, or certificate rotation, which makes any later security audit a redesign rather than a config change [S1][S2][S4].
Standards, sourcing, and verifiable signals to track
No single IEC/ISO standard defines "field gateway" versus "cloud IoT gateway" as a product class; instead the relevant references are OPC UA for the OT/IT protocol bridge, MQTT (ISO/IEC 20922) for the northbound publish/subscribe pattern, and the IEC 62443 series for industrial cybersecurity zones and conduits, which together describe the layering these gateways implement [S1]. Sourcing should weight vendor claims against whether the device ships with TLS, certificate rotation, OTA, a documented southbound protocol list (Modbus, OPC UA, BACnet, DNP3 where applicable), and a buffer spec expressed in days of outage at the expected sample rate [S1][S2].
Trackable signals for the next 6 months: container runtime support (Docker/Podman) on industrial gateways becoming table-stakes rather than premium; native OPC UA over MQTT (Pub/Sub) replacing broker-specific JSON wrappers in brownfield retrofits; and the emergence of clearly named "edge + cloud" bundled SKUs from vendors such as Robustel, Moxa, Advantech, and OnLogic that bill the two layers as one product line, simplifying spec sheets for plant engineers [S1][S2][S8].