In the lifecycle of any connected product, there is a distinct point of no return: the selection of the cloud ingress broker. For the CTO, this is rarely a question of "which platform works?" - both Amazon Web Services (AWS) and Microsoft Azure have proven they can ingest telemetry at hyperscale. The real question, the one that determines your Total Cost of Ownership (TCO) and architectural velocity for the next five years, is about alignment.
Choosing between AWS IoT Core and Azure IoT Hub is not a feature checklist exercise; it is a decision between two fundamentally different philosophies regarding concurrency, billing, and state management. As an engineering team, we have deployed fleets ranging from 10,000 to 1 million endpoints on both platforms. This analysis strips away the marketing abstractions to evaluate the mechanical and financial realities of scaling on these two hyperscalers.
For years, the industry standardized on MQTT v3.1.1. It was lightweight and sufficient. However, as edge logic becomes more complex, the limitations of v3.1.1 -specifically regarding error reporting and flow control-have become technical debt triggers.
AWS IoT Core has aggressively adopted MQTT v5, and for a greenfield architecture in 2025, this is a significant differentiator. MQTT v5 introduces features that solve specific distributed system headaches without requiring custom application-layer logic:
Request/Response Pattern: Historically, implementing a synchronous command over MQTT required correlating publish/subscribe topics manually. MQTT v5 handles this natively with response topics, simplifying the firmware logic for command-and-control operations.
User Properties: This allows you to add key-value pairs to the message header. You can route messages based on metadata (e.g., firmware_version=2.1) without parsing the payload, significantly reducing compute costs in the cloud processing layer.
Shared Subscriptions: This is perhaps the most critical feature for scalability. It allows multiple backend services to subscribe to a single topic and have the broker load-balance the messages between them. On AWS, this allows for backend consumer scaling without complex sharding logic.
Azure IoT Hub supports MQTT, but its architecture has historically leaned heavily on AMQP for advanced features.1 While Azure supports MQTT v3.1.1 and v5 via its newer "IoT Operations" connectors, the native Hub experience often forces architects into AMQP if they need robust file upload or complex feedback loops. For a fleet of resource-constrained microcontrollers (e.g., Cortex-M4 running Zephyr), implementing a heavy AMQP stack is often non-viable compared to a lightweight MQTT client.
Architectural Takeaway: If your fleet relies on modern, lightweight, standard-compliant communication (especially if you are using Rust/Embassy on the edge), AWS IoT Core’s native MQTT v5 support offers a cleaner implementation path with less firmware overhead.
Both platforms offer a mechanism to synchronize state between the device and the cloud - AWS calls them Device Shadows, and Azure calls them Device Twins. While they serve the same function (storing reported and desired states), their implementation dictates your application architecture.
AWS treats the Shadow as a document store. A device can have multiple "Named Shadows," which is a powerful feature for separation of concerns.
Use Case: You can have one shadow for "Firmware Status" (managed by the DevOps team) and a separate shadow for "User Configuration" (managed by the mobile app team). This prevents race conditions where an update to the user's LED color preference accidentally overwrites the firmware update status.
Cost Implication: AWS charges for Shadow operations (reads/writes). If your application polls the shadow aggressively, costs scale linearly with user activity.
Azure’s Device Twin is part of a broader, graph-based narrative. While it supports tags and properties like AWS, it integrates tightly with Azure Digital Twins (ADT).
The Graph Model: Azure pushes you toward modeling the relationship between devices (e.g., "Sensor A" is contained in "Room B" which is part of "Building C"). This is defined using the Digital Twins Definition Language (DTDL).
Use Case: This is superior for complex, spatial environments like smart buildings or factories where the context of the data is as important as the data itself.
Architectural Takeaway: If your device is an atomic unit (e.g., a consumer smartwatch), AWS Named Shadows provide a simpler, modular development experience. If your device is a node in a complex hierarchy (e.g., an HVAC controller in a smart campus), Azure’s graph-based approach reduces the need for a separate relational database to map assets.
This is where the "Enterprise Architect" must work closely with the CFO. The billing models of the two platforms are diametrically opposed, creating different risk profiles.
AWS utilizes a pay-as-you-go model. You are billed separately for connectivity (minutes connected), messaging (number of messages), and shadow operations.
Pros: Zero idle cost. If you have 100,000 devices that only report once a day, your bill is negligible. It scales perfectly with actual usage.
Cons: Bill Shock. A firmware bug that causes a device to enter a retry loop (e.g., publishing an error log every 100ms) can generate astronomical bills in hours. You strictly need AWS Budgets and throttling rules (Device Defender) to mitigate this.
Azure requires you to choose a "Tier" (Basic or Standard) and a "Unit" size (1, 2, 3). Each unit buys you a daily quota of messages.
Pros: Predictability. You know exactly what your bill will be at the end of the month. It acts like CapEx-you buy the capacity, and you own it.
Cons: The "Step Function" Cost. If you need 401,000 messages per day, and a Unit provides 400,000, you must buy a second Unit, effectively doubling your cost for a 0.25% increase in traffic. You pay for reserved capacity regardless of whether you use it.
Architectural Takeaway:
Choose AWS for fleets with highly variable traffic or low-duty-cycle devices (e.g., asset trackers reporting twice daily).
Choose Azure for fleets with predictable, high-frequency telemetry (e.g., industrial vibration sensors reporting at 1Hz continuous), where you can saturate the provisioned capacity to achieve a lower per-message cost.
Ingesting data is only the first step. The "Scalability" of a platform is defined by how easily it moves data to a hot storage or analytics layer.
For industrial clients, AWS offers IoT SiteWise. It is a managed service specifically designed to model industrial assets and ingest time-series data.
Integration: It sits directly behind the IoT Core Rule engine.
Strength: It solves the "Historian" problem. It automatically computes metrics (aggregates, averages) and provides a highly performant API for retrieving historical trends. It is the engine behind "Predictive Maintenance" dashboards.
Azure excels in integration with the Microsoft enterprise stack. The path from IoT Hub to Azure Data Explorer (ADX) or Microsoft Fabric is seamless.
Strength: For organizations already deeply invested in the Microsoft ecosystem (PowerBI, Dynamics 365), Azure IoT Hub acts as a native data pump. The ability to query raw telemetry using Kusto Query Language (KQL) in ADX is a superpower for debugging fleet issues that AWS CloudWatch Logs struggles to match in terms of query speed.
Security is the primary gatekeeper for scaling. Managing 100 certificates is easy; managing 1 million requires automation.
Azure Device Provisioning Service (DPS): Azure’s DPS is widely considered the gold standard for secure, zero-touch provisioning. It supports complex enrollment policies and TPM attestation out of the box. It allows for "Late Binding"-manufacturing devices without knowing which specific IoT Hub they will belong to until they are turned on.
AWS Device Defender: AWS focuses heavily on behavioral security. Device Defender can monitor metrics (e.g., "Why is this thermostat sending 50MB of data outbound?") and trigger audits or disconnects. This serves as an intrusion detection system (IDS) specifically for your IoT fleet.
There is no "winner" in a vacuum, but there is certainly a "wrong choice" for your specific business model.
Select AWS IoT Core if:
Your pattern is Event-Driven: You need granular, sub-second scaling for consumer devices.
You need MQTT v5: Your firmware architecture relies on modern protocol features like shared subscriptions.
Your traffic is "Bursty": You don't want to pay for idle capacity during the night.
Select Azure IoT Hub if:
Your pattern is High-Throughput/Industrial: You have predictable data streams that make tiered pricing more economical.
You value the "Digital Twin" Graph: Your problem domain is spatial or hierarchical (Smart Buildings/Factories).
You require Enterprise Integration: Your business stakeholders live in PowerBI and Microsoft Fabric.
At Hacod, we advise our clients to look past the initial "Hello World" connection. The cost of migrating 100,000 devices from one cloud to another involves truck rolls, firmware refactoring, and data migration nightmares. The scalable choice is the one that aligns with your unit economics and your data strategy - not just today, but at 10x your current scale.
Step-by-step tutorial on how to send large files from embedded devices running Zephyr RTOS to an AWS S3 bucket using the HTTP API for efficient and...