Edge Computing vs. the Cloud for Industry: How to Choose in 2026?

· 14 min read
14 min read
Eziwan Team
Eziwan Team
IoT Infrastructure

"Put everything in the cloud" was the mantra of industrial digital transformation until 2020. Then the projects ran into the reality on the ground: a pumping station with 500 ms of network latency cannot close a control loop via the cloud. A production site that generates 2 TB of data per day cannot send it all to AWS without incurring prohibitive bandwidth costs. And a defense contractor cannot host its production data on a server whose physical location is beyond its control.

In 2026, the dominant architecture in industrial IoT is hybrid: local processing at the source for tasks that require it, and the cloud for tasks that benefit from scale and centralization. This guide helps you make the right decision for each use case.

Definitions: edge, cloud, fog — without the jargon​

Before we compare them, let's clarify what these terms actually mean in an industrial context.

The cloud is a collection of remote servers accessible via the Internet or a private WAN. In industrial applications, the cloud hosts monitoring dashboards, historical databases, advanced analytics algorithms, and collaborative tools. The dominant hyperscalers are AWS, Microsoft Azure, and Google Cloud, but French sovereign cloud offerings (OVHcloud, Outscale/Dassault, Scaleway) are becoming increasingly relevant for sensitive data.

Edge computing refers to processing data as close as possible to its source—physically on-site, in the control cabinet, or within the equipment itself. The “edge” in “edge computing” is the boundary between the field OT network and the rest of the network—that’s where the industrial gateway is located. In practice, the edge is your gateway or your local server.

Fog computing is an intermediate term referring to distributed processing in the layers between the field and the cloud (zone aggregators, building servers, factory servers). By 2026, the term “fog” is used less frequently in the industry than in academic publications—most industry professionals simply refer to a hybrid edge + cloud architecture.

The Hierarchy in a Factory:

  • Level 0: Sensors, actuators (no processing)
  • Level 1: PLCs, RTUs (real-time processing, cycle time <10 ms)
  • Level 2: Local SCADA, HMI (site monitoring and control)
  • Level 3: Edge gateway (data collection, normalization, pre-processing, local alerts)
  • Level 4: Cloud (long-term data archiving, analytics, multi-site monitoring)

The Eziwan industrial gateway operates at level 3 of this hierarchy: it serves as the interface between the field OT network and the monitoring cloud.

When Edge Computing Is Mandatory​

There are three situations in which cloud-based processing alone is technically insufficient or unacceptable.

Real-time latency constraint

The control loop of an industrial PLC must complete in less than 1 to 10 ms, depending on the process. This requirement is physically incompatible with a round-trip network connection to a remote cloud, which takes at least 10 to 50 ms over a 4G LTE connection and 5 to 20 ms over a fiber connection to the nearest server in France.

Applications that require local processing to function:

  • Emergency shutdown when a threshold is exceeded (machine shutdown if temperature > 85 °C)
  • Flow or pressure control (closed-loop PID control via edge gateway)
  • Abnormal vibration detection with local alarm activation
  • Vision-based quality control with rejection of defective parts from the production line

Bandwidth Constraint

A high-frequency industrial vibration sensor (10 kHz accelerometer) generates approximately 80 MB of raw data per minute. A production line with 100 such sensors generates 8 GB per minute, or 11.5 TB per day. Transmitting all of this data in real time to the cloud would cost tens of thousands of euros per month in bandwidth and cloud storage.

The edge device solves this problem through two mechanisms:

  • Downsampling: reducing the sampling frequency from 10 kHz to 1 Hz for routine monitoring, and transmitting high-frequency data only on event (threshold exceeded)
  • Feature extraction: locally calculate relevant indicators (vibration RMS, characteristic FFT frequencies) and transmit only these indicators, rather than the raw data

In practice, edge computing can reduce the amount of data transmitted to the cloud by 70 to 95 percent, depending on the application.

Data Sovereignty Requirement

Certain types of industrial data cannot leave the company or the country:

  • Production data related to confidential markets (defense, aerospace, nuclear)
  • Product formulas and process parameters that constitute trade secrets
  • Data covered by client confidentiality agreements
  • Data whose location is subject to regulatory requirements (health data under the SNDS, financial data)

In these cases, both edge processing and storage are local. The cloud may receive anonymized or aggregated data (performance KPIs), but not sensitive raw data.

When the Cloud Alone Is Enough​

For most industrial monitoring applications, the cloud alone is perfectly suited and greatly simplifies the architecture.

Non-critical supervision and monitoring

Remote monitoring of a pumping station (level, pressure, and flow rate readings every 5 seconds) has no latency requirements below 1 second. A “low level” alarm that is triggered in 200 ms rather than 10 ms has no operational impact: the operator sees the alarm within a second, and the pumping process has response times on the order of minutes or hours.

Analytics and Machine Learning Using Historical Data

Predictive maintenance algorithms trained on 18 months of historical data run very efficiently in the cloud, where computing resources are elastic and storage is inexpensive. An anomaly detection model that runs once an hour on data from the past 24 hours does not need to be deployed at the edge.

Centralized Multi-Site Monitoring

A network manager overseeing 50 water treatment plants spread across a department has every reason to centralize data in the cloud: unified dashboards, cross-site correlation, performance benchmarking, and automated regulatory reports. Implementing these functions across 50 local edge devices would not only be costly but also nearly impossible to maintain.

Update and Configuration Management

Centralized management of router configurations, firmware versions, and alert rules is a native cloud feature. Zero Touch Provisioning (ZTP) is, by definition, a cloud service that configures devices remotely.

Hybrid Edge + Cloud Architecture: The Best of Both Worlds​

The recommended architecture for serious industrial IoT projects in 2026 is a hybrid one, with a clear division of responsibilities between the edge and the cloud.

Roles of the edge (local industrial gateway):

  • Local collection of field data via Modbus RTU/TCP, OPC-UA, Profibus, SNMP
  • Data normalization and formatting (unit conversion, local timestamping, equipment identifiers)
  • Local evaluation of alarm rules and triggering of alerts without network dependency
  • Store & forward: temporary storage if connectivity is interrupted, automatic retransmission upon reconnection
  • Pre-processing: downsampling, feature extraction, outlier filtering
  • VPN tunnel to the cloud: TLS encryption, mutual authentication

Cloud Functions:

  • Collection and archiving of standardized data
  • Real-time and historical dashboards
  • Advanced alerting engine (multi-site correlation, trend-based alerts)
  • Analytics and machine learning
  • User management, access rights, security audits
  • APIs for integration with ERP, CMMS, and BI systems
  • Monitoring of the gateway fleet (network health, connectivity, firmware versions)

The Synchronization Protocol: The gateway publishes data to the cloud via MQTT over TLS or HTTPS REST, depending on the configuration. In the event of a loss of connectivity, data is buffered locally (typically in 4 to 32 GB of flash storage) and sent in bulk once connectivity is restored. This architecture ensures that no data is lost, even in the event of a network outage lasting several hours.

Monitoring the gateway itself: The edge gateway itself must be monitored from the cloud: availability, LTE signal (RSRP/RSRQ), CPU/RAM usage, disk space, and firmware version. A gateway that has been silently down for 48 hours without being detected is unacceptable at a critical site.

Edge Computing in Practice: Examples by Industry​

Food Industry — Cold Storage Monitoring

A cold storage room requires a local alarm in the event that the temperature is exceeded (> +4 °C for a positive-temperature room), regardless of network connectivity. The edge gateway measures the temperature locally and triggers a local audible alarm, sends an SMS, and makes an on-call alert within 30 seconds, without any round-trip communication to the cloud. At the same time, temperature data is uploaded to the cloud every 5 minutes for traceability and HACCP compliance.

Water Distribution — Pressure Regulation

A pumping station equipped with a variable-frequency drive on the main pump uses the edge for local pressure control (setpoint 3.5 bars, measured every 100 ms, pump speed adjustment). This control loop runs entirely locally—it cannot tolerate the latency of a round trip to the cloud. The cloud receives pressure and energy consumption trends every minute.

Energy — Solar Farm

A 500 kWp solar farm with 10 inverters generates approximately 50,000 Modbus values per hour. The edge device calculates the Performance Ratio and the soiling indicator locally every 5 minutes, compares the strings with each other, and generates an alert if a string is more than 15% below the median. The cloud receives the calculated metrics (not the 50,000 raw values), the aggregated production curves, and the alerts.

Construction and Civil Engineering — Equipment Monitoring

A compactor on a construction site generates data on vibration, speed, and GPS position. The edge device calculates “compaction passes” (a combination of GPS position and compaction energy) locally and uploads only the business-relevant result (compaction map) to the cloud. This reduces the volume of LTE data transmitted by a factor of 100 and allows the device to operate even in areas with weak coverage.

Edge Computing with Eziwan: What the Gateway Does Locally​

The Eziwan gateway is designed as an industrial edge computing node, not as a simple transparent router.

Data Collection and Local Normalization: The gateway polls field devices (Modbus RTU controllers, M-Bus meters, local MQTT sensors) at configurable intervals ranging from 100 ms to 24 hours, depending on the data type. The values are normalized (unit, scale factor, offset) and precisely time-stamped (NTP synchronized with French time servers).

Local Alarm Rules: Simple alarm rules (high threshold, low threshold, out-of-range value, loss of communication) are evaluated on the gateway. Alerts can be sent via SMS, email, or webhook directly from the edge, without relying on the Eziwan cloud. This ensures that critical alerts are delivered even during cloud platform maintenance.

Store and forward: The collected data is buffered locally on the gateway’s flash memory. In the event of a connectivity outage (loss of LTE signal, network maintenance), the data is stored locally and automatically transmitted to the cloud once connectivity is restored. The local storage capacity allows the system to handle outages lasting several days without any data loss.

Permanent VPN Tunnel: The connection between the gateway and the Eziwan cloud is established via OpenVPN, initiated from the gateway (no inbound ports on the device). Remote access to local OT devices goes exclusively through this encrypted tunnel, without ever exposing a port to the Internet.

Locally Supported Protocols:

  • Modbus RTU (RS-232, RS-485)
  • Modbus TCP
  • Local MQTT broker
  • SNMP
  • M-Bus (sub-meters for electricity, water, and gas)
  • Local REST API for custom integrations

How to Plan Your Edge/Cloud Architecture​

A successful edge/cloud architecture is defined before selecting the equipment. Here is the recommended process.

Step 1: Map Data Sources List each piece of equipment or sensor, its communication protocol, its data generation frequency, the volume of raw data, and the business criticality of the data.

Step 2: Classify Constraints by Use Case For each use case (alarm, control, reporting, analytics), identify the main constraint: latency (< 100 ms? < 1 s?), offline availability (yes/no), sovereignty (sensitive data?), volume (> 1 MB/min per source?).

Step 3: Apply the decision rule

ConstraintEdge processingCloud processing
Latency < 500 msRequiredNot possible
Offline availabilityRequiredNot possible
Volume > 1 MB/min per sourceRecommendedCostly
Sensitive data (sovereignty)RequiredSubject to conditions
ML analytics on historical dataOptionalRecommended
Multi-site monitoringOptionalRecommended
User interfaceOptionalRecommended

Step 4: Sizing the Edge Calculate the CPU, RAM, and storage required for the local processing tasks identified in Step 3. An entry-level gateway with 512 MB of RAM and 1 GB of storage covers 90% of typical industrial edge requirements. Video analytics and on-device ML inference applications require more powerful gateways (4–8 GB of RAM, on-device GPU).

Step 5: Verify Connectivity Estimate the network bandwidth required after edge preprocessing. An uplink bandwidth of 1 Mbps is sufficient for most industrial IoT installations with edge processing (a few hundred normalized data points per minute). Compare this with the M2M SIM plans available in your area.

This process takes 2 to 4 hours for a standard industrial site and results in better-sized architectures that are less costly in the long run and more robust under actual operating conditions.

FAQ​

What exactly is industrial edge computing—is it complicated to deploy? In practice, industrial edge computing refers to your IoT gateway executing local processing logic: calculating averages, detecting thresholds, filtering, and aggregating data. At Eziwan, these rules are configured via the cloud dashboard (no programming required). For advanced processing (embedded ML, Docker containers), a more complex deployment is required, but most industrial needs are covered by rule configuration.

When is edge computing not enough, and is the cloud absolutely necessary? When data needs to be correlated across multiple sites (e.g., comparing the performance of 50 factories), when analysis requires a long history (18 months of trends), or when remote teams need access to monitoring. Edge computing alone cannot provide consolidated, multi-site visibility—that’s the role of the cloud.

Does 4G LTE latency (30–100 ms) prevent the use of the cloud for critical alerts? For critical alerts requiring a response in less than 500 ms, yes—the cloud alone is not reliable. But with edge computing, detection and local alert triggering (SMS, relay, audible alarm) occur in a matter of milliseconds. The cloud receives the alert notification a few seconds later. The combination of edge and cloud computing offers the best of both worlds.

Does edge computing on an IoT gateway allow you to send write commands to the PLC? Yes. The edge device can send Modbus TCP write commands to the PLC (setpoints, on/off commands). This feature should be used with caution: it requires a security analysis (determining who can write what), limits on permitted values, and comprehensive logging. NIS2 mandates traceability for all remote actions on OT systems.

What is the difference between store-and-forward and edge computing? Store-and-forward is a feature of edge computing: data is collected locally and buffered if the cloud connection is unavailable, then transmitted as soon as the connection is restored. Edge computing in the broader sense also includes local processing (calculations, alerts, control), not just buffering. Both are useful and complementary.

Further Reading​

Want to learn more? The Eziwan team helps manufacturers design and deploy edge/cloud architectures tailored to their specific needs. Discover the edge capabilities of the Eziwan gateway or check out our industrial remote management solutions to discuss your project.

Additional Resources​