Platform Architecture on Embedded Systems Development

AWS IoT Core

Mon, 01 Jan 0001 00:00:00 +0000

AWS IoT Core#

AWS IoT Core is Amazon’s managed MQTT broker and device management service for IoT workloads. It handles device authentication, message routing, and state synchronization for fleets ranging from a handful of prototypes to millions of production devices. The service is built around a registry of “things,” X.509 certificate-based mutual TLS authentication, a device shadow mechanism for state synchronization, and a rules engine that routes messages to downstream AWS services. Understanding the provisioning models, topic namespace, shadow document structure, and policy language is necessary for building firmware that connects reliably and securely at scale.

Azure IoT Hub

Mon, 01 Jan 0001 00:00:00 +0000

Azure IoT Hub#

Azure IoT Hub is Microsoft’s managed service for bidirectional communication between IoT devices and the cloud. It provides device authentication, message routing, state synchronization via device twins, command-and-control through direct methods, and fleet-scale provisioning through the Device Provisioning Service (DPS). IoT Edge extends the hub’s capabilities to gateway devices running containerized workloads. The platform’s device model differs from AWS IoT Core in significant ways — authentication options are broader (connection strings, X.509, TPM), the messaging architecture is built around Event Hubs rather than a pure MQTT broker, and the twin/direct method split separates state management from imperative commands more explicitly.

GCP IoT

Mon, 01 Jan 0001 00:00:00 +0000

GCP IoT#

Google Cloud IoT Core was Google’s managed service for connecting and managing IoT devices. It was retired on August 16, 2023, after less than six years in production. The shutdown is significant not because of the service itself — its feature set was narrower than AWS IoT Core or Azure IoT Hub — but because it demonstrated the real cost of platform dependency in IoT deployments where device lifetimes routinely exceed 5–10 years. This page documents what IoT Core provided, why it was retired, the migration paths that emerged, and the architectural patterns for building IoT workloads on GCP without a dedicated managed service.

Self-Hosted MQTT Brokers

Mon, 01 Jan 0001 00:00:00 +0000

Self-Hosted MQTT Brokers#

Self-hosted MQTT brokers provide the same publish/subscribe messaging layer that cloud IoT platforms offer — but under full operational control. The broker runs on private infrastructure (bare metal, VMs, containers, or Kubernetes), handles device authentication and authorization locally, and delivers messages without routing through a cloud provider’s endpoint. This eliminates per-message cloud fees, keeps data on-premises for sovereignty requirements, and removes dependency on external service availability. The tradeoff is operational responsibility: scaling, patching, monitoring, TLS certificate management, and persistence all shift to the deploying organization.

Self-Hosted Device Management

Mon, 01 Jan 0001 00:00:00 +0000

Self-Hosted Device Management#

Cloud IoT platforms bundle device management as a suite of managed services — AWS IoT Core provides thing registries and fleet provisioning, Azure DPS handles zero-touch enrollment, and both offer device shadows/twins for state synchronization. Self-hosted deployments must build each of these capabilities from individual components: a provisioning server for device enrollment, a certificate authority for identity management, an OTA update server for firmware delivery, and a state synchronization mechanism for configuration management. The operational surface area is significantly larger, but the architecture is fully customizable and free from cloud vendor constraints.

Hybrid Architectures

Mon, 01 Jan 0001 00:00:00 +0000

Hybrid Architectures#

Hybrid IoT architectures split infrastructure between local (on-premises or edge) and cloud components. A local MQTT broker handles device-facing traffic — low-latency messaging, store-and-forward during connectivity gaps, and data that must stay on-premises — while cloud services provide analytics, long-term storage, fleet-wide dashboards, and integrations that benefit from elastic scale. This is not a compromise between cloud-managed and self-hosted; it is a distinct architectural pattern that addresses requirements neither approach satisfies alone.