Embedded IoT Solutions: Connecting Hardware to the Cloud

A connected device has two halves. The hardware and firmware running on the device itself, and the cloud infrastructure receiving, storing, and processing the data it sends. Both halves are well-understood problems. The challenge that causes most embedded IoT solutions to fail in production sits in the layer between them: the connectivity stack that bridges the device to the cloud.

Getting that layer wrong is expensive in ways that are hard to fix after deployment. More than 90% of new cars sold in North America and Western Europe now feature embedded cellular connectivity, according to IoT Analytics data from 2025, which illustrates how far embedded IoT has moved from prototype curiosity to production infrastructure. The same data shows 21 billion connected IoT devices active globally. At that scale, a connectivity architecture that does not hold up is a field recall problem, not a software bug. As we cover in our post on embedded software in IoT, the software layer on the device shapes every decision about how data reaches the cloud.

This post covers the technical decisions that determine whether an embedded IoT solution connects reliably to cloud infrastructure, the failure patterns that appear most often in production, and how to structure the connectivity layer so it holds up when device populations grow.

What the Connectivity Layer Actually Involves

The connectivity layer in an embedded IoT solution is the set of components that takes data from the device and delivers it reliably to a cloud endpoint. It includes the communication protocol running on the device, the network access technology carrying the data, the message broker or ingestion service receiving it at the cloud end, and the logic that handles failures at every step in between.

Each of these components involves choices that interact with each other. The protocol you choose for device-to-cloud messaging affects the power budget. The network technology constrains which protocols are viable. The cloud ingestion service shapes how data is formatted and how failures are handled. None of these decisions can be made in isolation, and none of them can be easily reversed after hardware has been manufactured.

The specific challenges differ by application. IoT in smart homes puts the emphasis on low-power WiFi and BLE, seamless connectivity recovery, and consumer-grade set-up experiences. Industrial IoT prioritizes determinism and uptime, typically using cellular or wired industrial protocols with more tolerance for complexity in the setup process. The connectivity decisions that work for one context are often wrong for the other.

Choosing the Right Protocol for Device-to-Cloud Communication

The protocol stack is the single most consequential connectivity decision in an embedded IoT solution. It determines the power consumption of every transmission, the reliability guarantees the device can offer, and the complexity of the cloud infrastructure required to receive data at scale.

MQTT is the most widely deployed protocol for embedded IoT device-to-cloud communication. Its low overhead makes it appropriate for constrained devices, and its quality-of-service levels let you choose the right tradeoff between reliability and bandwidth for each message type. MQTT works well when devices have reliable enough connectivity to maintain a persistent broker connection, which rules it out for intermittent cellular environments without careful engineering of the reconnection logic.

CoAP suits the most constrained devices, where even MQTT's overhead is too large. It follows a request-response model similar to HTTP but designed for embedded systems, and it works over UDP rather than TCP, which matters in high-latency or lossy network environments. CoAP is common in sensor networks where the device spends most of its time asleep and transmits small payloads infrequently.

HTTPS is the simplest choice from a cloud integration perspective, since every cloud service supports it natively. The tradeoff is overhead: TLS handshakes are expensive for battery-powered devices, and the connection setup cost makes HTTPS impractical for devices that send frequent small messages. It works well for devices that wake, send a batch of data, and sleep again on a long duty cycle.

AMQP is common in enterprise environments where the IoT data needs to flow into existing message queuing infrastructure. It offers strong message delivery guarantees and fits well when the IoT system is one data source among several feeding a shared integration platform. The overhead is higher than MQTT, making it less appropriate for heavily constrained devices.

Network Technology: Matching the Radio to the Deployment 

The network technology carries the data from the device to the internet. The right choice depends on three things: the geographic coverage of the deployment environment, the data volume the device generates, and the power budget available for radio operation.

WiFi offers high throughput and is appropriate where infrastructure is guaranteed. It is the natural choice for devices deployed in controlled environments like factories, warehouses, and homes. Its weakness is power consumption: maintaining a WiFi connection keeps the radio active continuously, which is incompatible with long battery life unless the device sleeps aggressively between transmissions.

Cellular (4G/5G/LTE-M/NB-IoT) is the right choice for devices deployed in environments without guaranteed WiFi coverage: vehicles, field equipment, mobile assets, and infrastructure distributed across large areas. LTE-M and NB-IoT are the variants designed specifically for IoT, offering lower power consumption than standard LTE at the cost of lower data throughput. Cellular chipsets grew 19% year-over-year in 2024, reflecting the shift of embedded IoT deployments toward cellular as 4G and 5G coverage expands.

LoRaWAN and LPWAN suit sensors that need long range and very low power but generate small data volumes: soil moisture sensors, utility meters, asset trackers. The tradeoff is throughput: LoRaWAN is not appropriate for devices that need to send frequent or large payloads. It is the right choice when battery life measured in years matters more than data volume.

BLE covers short-range, low-power communication, typically between a device and a smartphone or local gateway that then relays data to the cloud. It is common in wearables, medical devices, and consumer IoT products where the device communicates with a paired phone rather than directly to a cloud endpoint.

The Cloud Side: Ingestion, Storage, and Processing 

The cloud infrastructure that receives data from embedded IoT devices needs to be designed for the data volume at full deployment scale, not the pilot. A device sending one reading per minute generates 525,600 data points per year. At ten thousand devices, that is 5.25 billion data points annually. The ingestion pipeline, the storage architecture, and the query patterns all need to be sized for production volume from the start.

Message brokers and ingestion services handle the incoming data stream from devices. AWS IoT Core, Azure IoT Hub, and similar managed services provide device management, authentication, and message routing alongside data ingestion, which reduces the infrastructure a team needs to build and maintain. When data volumes are very high or latency requirements are strict, a dedicated message streaming platform such as Apache Kafka provides the throughput and replay capability that managed IoT services do not always match.

The storage layer needs to match the query patterns. Time-series data from sensors queries differently from event data or device configuration. Using a general-purpose relational database for high-volume IoT time-series data is one of the most common cloud-side mistakes in embedded IoT solutions, and it tends to surface only when device populations grow and query performance degrades. Our post on how IoT is revolutionising the logistics industry covers how these cloud architecture decisions translate into operational outcomes in one of the most demanding IoT verticals.

The Failure Patterns That Show Up Most Often

Connectivity failures in embedded IoT solutions fall into a consistent set of patterns. Understanding them before designing the connectivity layer is the most reliable way to avoid discovering them in production.

No offline behaviour defined. Devices in real environments lose connectivity. A firmware design that assumes the network is always available will lose data when it is not. Every device needs a defined strategy for what to do during disconnection: queue messages locally, discard them after a threshold, or make decisions autonomously. This needs to be designed in from the start, not added as an afterthought when field reports of missing data arrive.

TLS overhead underestimated on constrained hardware. Establishing a TLS connection requires significant processing and power on a microcontroller. Teams that test on development hardware with external power often discover that TLS handshakes are too expensive for their target device only after the hardware is finalized. The protocol and security stack need to be profiled on the actual target hardware, not assumed from specifications.

Data format chosen for convenience, not scale. JSON is readable and easy to work with during development. At scale, the parsing overhead on a constrained device and the bandwidth cost of verbose JSON payloads add up. Binary formats like CBOR or protocol buffers are significantly more efficient and are worth the additional tooling investment for deployments beyond a few hundred devices.

No OTA update path for connectivity firmware. The cellular modem firmware, the protocol stack, and the security credentials on the device will need to be updated after deployment. Devices without a reliable over-the-air update path for these components are effectively frozen at their factory configuration. As we cover in our post on firmware development for embedded systems, OTA capability needs to be designed into the system from the start, not added after the first field problem requires it.
 

How Exaud Approaches Embedded IoT Solutions

Our embedded IoT work covers both sides of the connection: the firmware and connectivity stack running on the device, and the cloud infrastructure receiving and processing the data. We have built embedded IoT solutions for industrial monitoring, connected medical devices, and logistics fleet management, across cellular, WiFi, and BLE connectivity environments.

The connectivity layer is where we spend the most design time relative to what teams expect, because the decisions made there are genuinely hard to change after hardware is in production. We validate protocol and network technology choices against the actual deployment environment before the hardware design is finalized, not against the development environment where everything works.

If you are scoping an embedded IoT solution and want to talk through the connectivity architecture before committing to a hardware design, get in touch and we can work through the specifics of your deployment environment.

Frenquantly Asked Questions

What is an embeded IoT Solution?

An embedded IoT solution is a connected product where purpose-built software runs directly on a physical device, collects data from sensors or actuators, and communicates that data to cloud infrastructure for storage, processing, and analysis. The embedded component refers to the software running on the device itself, which operates under constraints that general-purpose software does not face: limited memory and processing power, restricted power budgets, and the requirement to run reliably without human intervention for months or years. The IoT component refers to the connectivity layer and cloud infrastructure that makes the device part of a larger data system. Getting both halves right, and getting the connection between them right, is what embedded IoT solutions development involves.

Which connectivity protocol is bet for embedded IoT devices?

The right protocol depends on the device's power budget, the data volume it generates, and the network environment it will operate in. MQTT is the most widely deployed choice for devices that maintain a persistent connection and need reliable message delivery with low overhead. CoAP suits the most power-constrained devices operating over lossy networks. HTTPS is straightforward to integrate at the cloud end but too expensive in power and overhead for devices sending frequent small messages. The mistake most teams make is choosing the protocol the team is most familiar with rather than the one that fits the device's actual constraints. Protocol selection needs to be validated against the target hardware under realistic power conditions, not assumed from vendor specifications.

How do you handle data loss when IoT devices loses connectivity?

Every embedded IoT device needs a defined strategy for what happens when the network is unavailable, and that strategy needs to be built into the firmware from the start. The options are local queuing, where the device stores messages in flash memory until connectivity is restored; data aggregation, where the device computes a summary of the missed period rather than transmitting every individual reading; and autonomous decision-making, where the device continues to operate and act on sensor data locally without needing to report to the cloud. The right choice depends on how long disconnections are expected to last, how much local storage the device has, and whether the cloud system needs every raw data point or can work with aggregated values.

What cloud infrastructure does an embedded IoT solution need?

At minimum, an embedded IoT solution needs a message ingestion service to receive data from devices, a storage layer suited to the query patterns the data will be used for, and a device management system to handle authentication, configuration, and over-the-air updates. Managed IoT platforms such as AWS IoT Core or Azure IoT Hub bundle the first and third of these. The storage choice depends on whether the primary use is time-series analysis, event processing, or operational reporting: each has a different optimal storage technology. The critical design principle is to size the infrastructure for the full deployment scale from the start, because migrating a high-volume IoT data pipeline after it is in production is substantially more disruptive than designing it correctly the first time.

How is embedded IoT different from standard IoT development? 

Standard IoT development often refers to building the cloud platform, analytics, and application layer for a connected product. Embedded IoT development covers the device side: the firmware running on the microcontroller or processor, the radio driver and protocol stack, the power management logic, and the local data processing that happens before anything reaches the cloud. The distinction matters because the embedded layer operates under constraints, power budgets, memory limits, real-time requirements, that the cloud layer does not face. Teams with strong cloud or mobile development backgrounds consistently underestimate the embedded layer, which is where most production failures in connected products originate.