Edge Computing in IoT: How It Works and Real Deployments

A connected car generates 25GB of data per hour. A modern wind turbine produces 2TB per day. A single smart factory floor with 500 sensors creates more telemetry in a week than most companies store in a year. Sending all of that to the cloud for processing is not just expensive. It is physically impossible at the latencies these systems require.

Edge computing in IoT solves this by moving computation to where data originates. Instead of shipping raw sensor readings across cellular networks to a distant data center, edge systems process, filter, and act on data locally. The cloud still exists, but it receives summaries instead of firehoses.

This is not a theoretical concept. It is running today across millions of devices. This post covers how IoT edge computing works, where it delivers measurable results, and how to evaluate whether your IoT deployment needs it.

What Is Edge Computing in IoT?

Edge computing in IoT is the practice of processing data on or near the device that generates it, rather than sending everything to a centralized cloud. “The edge” is not a single location. It is any compute resource between the IoT sensor and the cloud data center: a gateway in a factory, a server in a cell tower, an onboard computer in a vehicle, or a ruggedized box on an oil platform.

The concept is simple. The execution is hard.

The Data Gravity Problem

IoT devices produce data at a rate that outpaces network capacity. The world generated an estimated 120 zettabytes of data in 2023. IoT devices accounted for a growing share, and that share accelerates every year as sensor density increases and sampling rates climb.

The traditional approach, sending everything to the cloud for processing, breaks down when you do the math. A fleet of 10,000 sensors sampling at 1kHz produces 864 billion data points per day. At 8 bytes per reading, that is 6.4TB of raw data daily. Uploading 6.4TB over cellular networks would cost roughly $576 per day in data transfer alone, assuming LTE speeds can even sustain the throughput (they often cannot).

Edge computing addresses this by processing data at the source. Filter out noise. Aggregate readings into summaries. Detect anomalies locally. Send only the 5-20% of data that matters to the cloud.

Edge Computing vs. Embedded Computing

Edge computing is not the same as running code on a microcontroller. Embedded systems execute fixed firmware for specific control tasks: reading a temperature sensor, triggering a relay, maintaining a PID loop. Edge computing runs general-purpose processing pipelines that can be updated, reconfigured, and orchestrated remotely.

The distinction matters because edge computing brings cloud-like programmability to the physical world. You can deploy a new filtering rule to 8,500+ edge nodes in <30 seconds without touching a single device physically. Embedded systems require firmware updates that often need maintenance windows, physical access, or reboot cycles.

How IoT Edge Computing Works

An IoT edge architecture has three layers. Each has a specific job.

The Device Layer

Sensors and actuators generate raw data: temperature, vibration, voltage, GPS coordinates, video frames, acoustic signatures. These devices typically run constrained hardware (low power, limited memory) and communicate over protocols like MQTT, Modbus, OPC UA, or BLE.

Most IoT devices cannot run edge computing workloads directly. They lack the CPU and memory. Instead, they push data to the next layer over local protocols.

The Edge Layer

This is where edge computing happens. Gateways, edge servers, or on-device processors receive raw data from the device layer and execute processing pipelines.

A processing pipeline at the edge typically does five things:

1. Ingest. Accept data from multiple protocols (MQTT from sensors, HTTP from APIs, Modbus from PLCs, file drops from legacy systems).
2. Parse and normalize. Convert proprietary formats into structured records. A Modbus register value becomes a named field with units and metadata.
3. Filter. Remove duplicate readings, out-of-range values, and heartbeat noise that carries no informational value. A temperature sensor reporting the same 22.1C every second for an hour generates 3,600 records that a single summary can replace.
4. Enrich. Add context: device location, asset ID, maintenance schedule, threshold alerts. This context is expensive to join in the cloud but cheap to add at the source.
5. Route. Send filtered data to the right destination. Anomalies go to the alerting system immediately. Aggregated summaries go to the data warehouse hourly. Raw data stays in local buffer for forensic queries.

The Cloud Layer

The cloud receives filtered, enriched data and handles workloads that benefit from centralization: long-term storage, historical analysis, ML model training, cross-site correlation, and business intelligence dashboards.

The key insight is that cloud systems (Splunk, Datadog, Snowflake) work better when they receive clean data. A Tier-1 bank reduced daily Splunk ingest from 14.3TB to 5.2TB by deploying edge processing agents. Their Splunk costs dropped from $3.7M to $1.4M annually (62% reduction), and search performance improved 4x because the indexed data was smaller and more relevant.

Why IoT Needs Edge Computing

Four constraints make edge computing necessary for IoT at scale. These are not preferences. They are physics and economics.

Latency

Cloud round-trip latency from an IoT device typically ranges from 40ms to 200ms, depending on geography, network conditions, and cloud region distance. For many IoT applications, this is too slow.

An autonomous vehicle making a braking decision cannot wait 100ms for a cloud response. A robotic arm on an assembly line cannot pause for 50ms between movements. A security system detecting an intrusion needs to act in single-digit milliseconds, not triple digits.

Edge processing eliminates the round trip. An automotive security deployment across 2.3 million vehicles detects cyberattacks in 0.8ms at the vehicle. A sports broadcast system reduced production latency from 150ms to 8ms by processing video telemetry at the venue instead of in a remote data center.

Bandwidth and Cost

Cellular data is expensive. Satellite data is expensive. Even wired connections to remote sites carry meaningful per-GB costs once you account for ISP fees, hardware, and maintenance.

A forest conservation deployment monitoring remote sensor stations reduced cloud infrastructure costs from $127K to $14K per month (an 89% reduction) by processing data at edge stations and sending only actionable results. The sensors generate the same volume of raw data. The difference is that 90%+ of it never leaves the edge.

Cellular costs compound with fleet size. The automotive deployment that processes telemetry at the vehicle reduced cellular costs by 94%. At 2.3 million vehicles, even a small per-device savings multiplies into millions per year.

Reliability and Offline Operation

IoT devices often operate in environments where connectivity is intermittent or nonexistent. Oil platforms, ships at sea, underground mines, rural agricultural sites, and military field operations all have unreliable or no network access.

Cloud-dependent IoT systems stop working when the network drops. Edge computing systems keep working because the processing logic runs locally. When connectivity returns, buffered data synchronizes automatically.

A Navy deployment operating across air-gapped networks improved model update success from 23% to 97% using edge-first processing. The previous cloud-dependent approach failed for 77% of updates because ships could not maintain stable connections to shore-based servers.

Data Sovereignty and Compliance

GDPR requires that personal data of EU residents stay within the EU unless specific legal mechanisms are in place. HIPAA restricts how health data moves between systems. Data sovereignty laws in 140+ countries impose similar constraints.

Edge computing makes compliance architectural rather than procedural. If a temperature sensor in a German factory processes data on a gateway in the same facility, the data never crosses a border. No transfer impact assessments. No standard contractual clauses. The data stays put because the compute is local.

Edge Computing Applications in IoT: Real Deployments

Theory becomes credible with production numbers. Here are IoT edge computing deployments operating at scale.

Telecommunications

A major telecom operator deployed edge processing agents across 3,847 cell tower sites. Each site generates telemetry from Radio Access Network (RAN) equipment: signal quality metrics, handover events, resource utilization, and alarm data.

Before edge processing, all of that telemetry went directly to Splunk for analysis. After deploying edge agents, the operator reduced telemetry volume by 78% at the source. RAN Intelligent Controller (RIC) latency dropped from 2.3 seconds to 89ms. Splunk costs fell by 47%.

The agents run on existing hardware at each site. No new infrastructure. No additional rack space. The filtering rules propagate from a central control plane to all 3,847 sites simultaneously.

Automotive Cybersecurity

A global automotive manufacturer deployed Expanso agents across a fleet of 2.3 million connected vehicles. Each vehicle’s agent monitors CAN bus traffic, network interfaces, and firmware integrity for signs of cyberattack.

The edge processing model detects threats in 0.8ms at the vehicle. A cloud-based approach would add 100ms+ of latency, making real-time response impossible during active attacks. The system reduced cellular data costs by 94% because only threat alerts and periodic summaries leave the vehicle. The full telemetry stays in local buffer, available for forensic investigation when needed.

Smart Cities and Public Safety

A metropolitan area deployed 14,847 cameras with edge processing for public safety analytics. The edge layer handles video processing locally: motion detection, object classification, and event tagging happen on compute nodes at camera clusters.

Investigation time dropped from 3 days to 4 hours. Instead of pulling footage from thousands of cameras and scanning manually, investigators query tagged events across the edge network. Only the relevant clips transfer to the central evidence system.

The cost reduction is equally significant. Streaming 14,847 cameras continuously to cloud storage would require bandwidth and storage costs that exceed the entire program’s budget. Edge processing reduces the data that moves to less than 1% of the raw footage.

Live Sports Broadcasting

A major broadcast network deployed edge computing for live sports production. Camera telemetry, audio feeds, graphics overlays, and replay systems generate massive data volumes during live events. Traditional production sends these feeds to a central production facility for mixing.

By processing at the venue edge, the network reduced broadcast production latency from 150ms to 8ms. They also eliminated $1.2 million per year in data egress costs by keeping raw production feeds local and sending only the mixed output to distribution networks.

Forest Conservation

A conservation organization monitors remote forest areas using sensor networks that track temperature, humidity, acoustic activity (chainsaws, vehicles), and satellite imagery. These stations operate on solar power with cellular or satellite backlinks.

Edge processing at each station filters and aggregates sensor data locally. The organization reduced their AWS infrastructure costs from $127K to $14K per month (89% reduction). The sensors produce the same data volume. Edge processing ensures that only anomalies and daily summaries consume expensive satellite bandwidth.

Edge vs. Cloud vs. Fog: Clearing Up the Architecture

The terminology in this space creates confusion. Here is how the three models relate.

Cloud Computing

All processing happens in centralized data centers. Data moves from devices to cloud. Results move from cloud back to devices (or dashboards). Simple architecture. High latency. High data transfer costs. Works well when data volumes are modest and latency requirements are relaxed (business analytics, batch reporting, ML model training on historical data).

Fog Computing

A Cisco-coined term for intermediate processing between devices and cloud. Fog nodes sit in local network infrastructure (routers, switches, local servers) and handle time-sensitive processing. The cloud handles everything else. In practice, fog computing and edge computing overlap so much that the distinction is academic. Most practitioners use “edge computing” to cover both.

Edge Computing

Processing happens at or near the data source. The edge can be the device itself (a vehicle’s onboard computer), a gateway (a ruggedized box in a factory), or a local server (a micro data center at a cell tower). The defining characteristic is location: compute is placed where data originates, not where the cloud provider’s nearest region happens to be.

When to Use Which

Building an IoT Edge Architecture

Here is what you need to design, deploy, and operate an IoT edge computing system.

Hardware Selection

Edge hardware ranges from $35 Raspberry Pi boards for prototyping to $15,000+ industrial edge servers for production workloads. The right choice depends on three factors:

Environment. Outdoor installations need IP67-rated enclosures, extended temperature ranges (-40C to 85C), and vibration resistance. Indoor factory deployments can use standard server hardware. Vehicle installations need automotive-grade components (AEC-Q100 certification).

Compute requirements. Text-based telemetry processing (filtering, parsing, aggregation) runs comfortably on ARM-based systems with 4GB RAM. Computer vision workloads need GPUs or NPUs. An Expanso agent runs on anything from a Raspberry Pi to an industrial server; how much memory and CPU it uses depends on the pipeline and connectors it runs.

Power and connectivity. Remote sites may have only solar power and satellite links. The edge compute must fit within the power budget. A single binary with no runtime dependencies (no JVM, no container runtime, no library dependencies) starts faster and uses less power than a full Kubernetes node.

Software Architecture

A production IoT edge stack has four components:

1. Data ingestion layer. Connectors for every protocol your devices speak: MQTT, OPC UA, Modbus, HTTP, Kafka, file drops, serial ports. Expanso supports 180+ connectors, which matters because IoT environments always have more protocols than expected.

2. Processing pipeline. Rules that transform raw data into actionable information. Filter noise, aggregate windows, mask PII, detect anomalies, enrich with context. The pipeline must be hot-reloadable (update without restart) and remotely manageable (push changes from central control plane).

3. Local buffer. Network outages happen. The edge system must buffer data locally and replay it when connectivity returns. Size the buffer for your longest expected outage. A 10GB buffer holds several days of filtered telemetry for most deployments.

4. Management plane. Something must deploy, configure, monitor, and update all your edge nodes. Doing this manually at 100 sites is annoying. At 1,000 sites it is impractical. At 10,000 sites it is impossible. Centralized management with configuration propagation in <30 seconds is a requirement, not a luxury.

Deployment Patterns

Single gateway. One edge device per site. Simple. Adequate for sites with under 100 sensors and modest data volumes. No local redundancy.

Clustered edge. Multiple edge nodes per site for redundancy and horizontal scaling. Appropriate for factories with thousands of sensors or locations where downtime is unacceptable. Adds coordination complexity.

Hierarchical edge. Edge nodes report to regional aggregators, which report to the cloud. Useful when you need intermediate summarization. A telecom operator might have edge agents at 3,847 towers, regional aggregators at 50 switching centers, and a central analytics platform in the cloud.

Security and Compliance at the Edge

Distributing compute to thousands of locations multiplies your attack surface. Here is how production deployments handle it.

Device Identity and Authentication

Every edge node needs a unique, verifiable identity. X.509 certificates are the standard approach. The initial provisioning (getting the first certificate onto the device securely) remains the hardest part. Solutions include hardware TPMs (Trusted Platform Modules) that store private keys in tamper-resistant silicon, and automated certificate rotation that replaces keys on a regular schedule without human intervention.

Data Protection in Transit and at Rest

Data between edge nodes and the cloud travels over TLS 1.3. Data at rest on the edge node uses filesystem encryption (LUKS on Linux, BitLocker on Windows). The encryption keys themselves are the vulnerability. They must be stored in hardware security modules or TPMs, not in configuration files.

Zero-Trust Edge Networks

Traditional network security assumes everything inside the perimeter is trusted. Edge computing has no perimeter. Each edge node operates in a potentially hostile environment: a cell tower cabinet, a vehicle OBD port, a factory floor with physical access by dozens of contractors.

Zero-trust means every request is authenticated and authorized, regardless of network location. Mutual TLS (mTLS) between nodes. Short-lived tokens instead of long-lived API keys. Least-privilege access so a compromised edge node cannot pivot to the control plane.

Compliance at Scale

Processing data at the edge simplifies compliance in some ways (data residency) but complicates it in others (you now have 10,000 locations storing regulated data instead of 3 cloud regions).

The solution is centralized policy enforcement. Define compliance rules once in the control plane. Push them to all edge nodes. Audit automatically. A pipeline rule that masks social security numbers or redacts health identifiers runs at every edge node without exception. No human remembers to configure it. No site gets missed.

The Economics of IoT Edge Computing

Edge computing has upfront costs (hardware, deployment) that cloud computing avoids. The question is whether operational savings justify the investment. Here is the math from real deployments.

Total Cost of Ownership Comparison

For a 1,000-site IoT deployment processing 10TB/day of telemetry:

Cloud-only approach:

• Ingest: 10TB/day to cloud at $0.09/GB egress = $900/day ($328K/year)
• Processing: Cloud compute for filtering and aggregation = $150K/year
• Storage and analytics platform licensing (e.g., Splunk at $100/GB/day indexed) = $365K/year
• Total: approximately $843K/year

Edge-first approach:

• Edge processing hardware (amortized over 3 years) = $120K/year
• Reduced ingest: 2TB/day to cloud (80% reduction) at $0.09/GB = $180/day ($66K/year)
• Reduced platform licensing (smaller ingest) = $73K/year
• Edge management platform = $60K/year
• Total: approximately $319K/year

The edge-first approach saves roughly $524K per year (62%). These numbers align with production results: the enterprise deployment that cut observability spend from $240K to $71K per month (70% reduction), and the Tier-1 bank that reduced Splunk costs by 62%.

Payback Period

Edge hardware and deployment costs typically pay for themselves in 3-6 months through reduced data transfer and platform licensing costs. The forest conservation deployment that dropped from $127K to $14K per month in AWS costs recovered their edge infrastructure investment in under 60 days.

Hidden Savings

The cost models above capture direct savings. Edge computing also delivers indirect savings that are harder to quantify but often larger:

• Faster incident response. The smart city deployment reduced investigation time from 3 days to 4 hours. The labor savings dwarf the infrastructure savings.
• Reduced compliance overhead. Processing data locally eliminates cross-border data transfer assessments. For multinational deployments, this saves months of legal review.
• Extended equipment life. Predictive maintenance at the edge detects failures early. Replacing a $200 bearing before it destroys a $50,000 motor is a common use case that is hard to model but easy to measure in practice.

FAQ

What is the difference between edge computing and IoT?

IoT (Internet of Things) is the network of connected devices: sensors, actuators, cameras, and controllers. Edge computing is a processing architecture: running computation near data sources instead of in the cloud. IoT generates data. Edge computing processes it locally. You can have IoT without edge computing (send everything to cloud), and you can have edge computing without IoT (CDNs, gaming servers). But IoT at scale almost always requires edge computing because the data volumes and latency requirements exceed what cloud-only architectures can handle economically.

How much data can edge computing filter before sending to the cloud?

Production deployments typically reduce data volumes by 60-90% at the edge. The exact reduction depends on the telemetry type. High-frequency sensor data (vibration, current, temperature sampled at kHz rates) often compresses by 90%+ through downsampling and aggregation. Event-driven data (logs, alerts, transactions) reduces by 50-70% through deduplication and noise filtering. One telecom deployment reduced telemetry by 78% across 3,847 sites.

What hardware do I need for IoT edge computing?

It depends on the workload. Text-based telemetry processing (filtering, parsing, routing) runs on commodity ARM hardware with 2-4GB RAM. Computer vision needs GPUs (NVIDIA Jetson series is the standard). Industrial deployments need ruggedized hardware rated for extreme temperatures and vibration. Expanso’s agent runs on anything from a Raspberry Pi to a multi-core server; its footprint scales with the pipeline you give it.

Is edge computing secure enough for production IoT?

Edge computing is as secure as your implementation. The attack surface is larger (more locations with physical access), but the data exposure is smaller (sensitive data stays local instead of transiting networks). Production deployments use mutual TLS, hardware security modules, certificate rotation, and zero-trust networking. The Navy deployment that passed Department of Defense security review processes classified data on air-gapped edge nodes, which is arguably more secure than sending it to a cloud data center.

How do I manage thousands of edge nodes?

Centralized management with automated configuration propagation. You define processing pipelines and policies in a control plane, which pushes them to all edge nodes. Expanso’s control plane propagates configuration changes to 8,500+ nodes in <30 seconds. Individual node management (SSH into each device) does not scale past a few dozen sites.

Can edge computing work with my existing cloud analytics tools?

Yes. Edge computing sits upstream from your existing tools, not instead of them. Splunk, Datadog, Snowflake, Databricks, Elasticsearch all receive data from edge nodes the same way they receive data from any other source. The difference is that they receive filtered, enriched data instead of raw firehoses. This is why the Tier-1 bank’s Splunk searches got 4x faster after deploying edge processing: less data to index means faster queries.

Bottom Line

IoT edge computing isn’t a future trend. It’s a production reality running across millions of devices today. The organizations getting it right share a common approach: process at the source, send only what matters, and let centralized platforms do what they do best with clean, filtered data.

Ready to see how edge processing fits your IoT architecture? Book a data consultation to discuss your deployment.

Related Articles

• Splunk Pricing Guide: What Does Splunk Cost in 2026?
• Splunk Architecture Guide: How It Works Under the Hood
• Splunk Edge Processor vs. Upstream Processing
• How to Reduce Splunk Costs Without Losing Visibility
• What Is an Observability Pipeline?
• SIEM Cost Comparison: Splunk vs. Elastic vs. Alternatives