AWS IoT Core vs Azure IoT Hub - Platform Comparison for CTOs

Why choosing between AWS IoT Core and Azure IoT Hub is important?

You're three months into building a connected industrial sensor. The firmware works. The mobile app connects. Now your team is evaluating cloud platforms, and it's come down to AWS IoT Core and Azure IoT Hub.

Both say they handle millions of devices. Both support MQTT. Both promise reliable message delivery. But here's the thing: the architectural differences between AWS IoT Core and Azure IoT Hub will determine your device management complexity, your monthly cloud bill, and whether your OTA update strategy actually works when you hit production scale.

By the end of this post, you'll know which platform matches your device architecture, what each one really costs in production, and which technical trade-offs actually matter for your use case.

Why the AWS IoT Core vs Azure IoT Hub Decision Matters

Choosing between AWS IoT Core and Azure IoT Hub isn't just picking a message broker. You're choosing the architectural foundation for device state management, firmware updates, security certificate workflows, and how your engineering team debugs connection issues at 2 AM.

On paper, the platforms look similar. Both are managed MQTT brokers. Both handle device authentication. Both integrate with their cloud ecosystems. But the implementation details - how device shadows work, how OTA updates are structured, how pricing scales - create completely different operational experiences once you're managing 10,000+ devices in production.

Pick the wrong one and six months from now you're rewriting device provisioning logic because the certificate rotation workflow doesn't match your hardware constraints. Or you're paying 3× what you budgeted because message pricing doesn't align with your data pattern. Or your OTA update mechanism needs a complete redesign because the platform's approach doesn't support your rollback requirements.

Understanding the technical differences between AWS IoT Core and Azure IoT Hub before you commit code to production changes everything about how smoothly your IoT infrastructure scales.

Core Architecture: How AWS and Azure Actually Handle Device Connections

The fundamental architectural difference between AWS IoT Core and Azure IoT Hub shapes everything downstream - how you structure firmware, how you manage state, how you route messages.

AWS IoT Core Architecture

AWS IoT Core is built around a rules engine and topic-based message routing. Devices publish to MQTT topics. Rules process those messages and route them to other AWS services - Lambda functions, DynamoDB tables, S3 buckets, SQS queues.

Device state lives in the device shadow service - a separate AWS service that maintains a JSON document representing each device's last reported state and desired state. Your firmware subscribes to shadow topics to receive state updates and publishes to shadow topics to report current state.

Here's how message flow works in AWS IoT Core:

1. Device publishes telemetry to device/deviceId/telemetry

2. IoT Core rules engine evaluates the message against defined rules

3. Rules route the message to appropriate AWS services

4. Applications query device shadows for current device state

5. Applications publish to shadow topics to send commands to devices

This architecture separates message routing (rules engine) from state management (device shadow service). That separation gives you flexibility in how you process telemetry versus how you track device state.

Azure IoT Hub Architecture

Azure IoT Hub is built around device twins and direct methods. Device twins are JSON documents stored within IoT Hub that represent device state, metadata, and configuration. Direct methods allow cloud-to-device RPC calls with request/response semantics.

Here's how message flow works in Azure IoT Hub:

1. Device sends telemetry to IoT Hub endpoint

2. IoT Hub routes messages to Event Hub, Service Bus, or Azure Functions

3. Applications read/update device twin to get device state or send configuration

4. Applications invoke direct methods on devices for immediate commands

5. Devices report state updates through device twin reported properties

Azure's architecture integrates state management (device twins) directly into the IoT Hub service. You don't manage a separate state service—device twins are part of IoT Hub itself.

The architectural choice affects how you structure firmware. AWS IoT requires subscribing to shadow topics and parsing JSON updates. Azure IoT uses built-in SDK methods to read twin properties and respond to direct method calls.

Feature Comparison: Device Shadow, OTA, MQTT, Pricing, SDK

Here's how AWS IoT Core and Azure IoT Hub compare across the features that actually matter for production IoT systems:

What This Table Doesn't Tell You

The feature table shows capabilities. What really matters in production is how these capabilities map to your specific use case.

Device shadow vs device twin: AWS shadows are MQTT-first—your firmware subscribes to topics and reacts to messages. Azure twins are SDK-first—your firmware calls methods to read/update properties. If you're building on a resource-constrained MCU with a minimal MQTT stack, AWS's approach requires less code. If you're running on embedded Linux with full SDK support, Azure's approach is cleaner.

OTA updates: AWS IoT Jobs provides a purpose-built OTA framework with job tracking, device targeting, and progress monitoring. Azure requires you to build your own OTA logic on top of device twins and direct methods. AWS is simpler if you need OTA out of the box. Azure gives you more control if you have custom OTA requirements.

MQTT 5.0 support: AWS supports MQTT 5.0, which adds request/response patterns, shared subscriptions, and user properties. If your architecture relies on MQTT 5.0 features, AWS is your only option. If MQTT 3.1.1 is enough, both platforms work fine.

Pricing model differences: AWS charges per message—every telemetry publish, every shadow update. Azure charges per message batch (400 messages) plus a per-device cost in some tiers. At low volumes, Azure can be cheaper. At high message rates with fewer devices, AWS can be cheaper. You really need to model your specific message pattern against both pricing structures.

AWS IoT Core: When It's the Right Choice

AWS IoT Core makes sense when your IoT architecture needs tight integration with other AWS services, complex message routing logic, or when you're already operating in the AWS ecosystem.

Use AWS IoT Core when:

Your message routing is complex You need to send device telemetry to three different destinations based on message content—some to S3 for long-term storage, some to Lambda for real-time processing, some to DynamoDB for operational dashboards. The AWS IoT rules engine handles this natively without you writing routing code.

You need purpose-built OTA management AWS IoT Jobs provides tracking, rollout control, and success rate monitoring for firmware updates. If you're managing OTA updates across thousands of devices with staged rollouts, Jobs saves you weeks of development time compared to building equivalent tracking on top of Azure device twins.

Your stack is already AWS-native Your application backend runs on Lambda. Your databases are DynamoDB and RDS. Your analytics use Kinesis and Redshift. Using AWS IoT Core means authentication, IAM policies, and service integration all use the same AWS primitives your team already knows.

You have resource-constrained devices The AWS IoT Device SDK for Embedded C is optimized for MCUs with 128KB RAM. The MQTT-focused architecture means simpler firmware—subscribe to topics, parse JSON, respond. No heavyweight SDK required.

You need detailed device monitoring AWS IoT Device Defender detects anomalies in device behavior - unexpected connection patterns, unusual message rates, certificate issues. The integration is native - no additional configuration or infrastructure needed.

Trade-offs with AWS IoT Core:

The rules engine is powerful but has a learning curve. Writing SQL-like rules to transform and route messages takes iteration. The syntax supports complex logic, but debugging rules in production requires careful CloudWatch log monitoring.

Device shadow pricing can surprise you. Every shadow update is a billable message - both the device reporting state and the application reading state. On projects where devices report state every 30 seconds and applications poll state frequently, shadow costs can exceed telemetry costs.

The AWS ecosystem assumes you're building cloud-native. If your backend is on-premises or uses non-AWS services heavily, the AWS IoT integration advantages disappear and you're just paying for a managed MQTT broker.

Azure IoT Hub: When It's the Right Choice

Azure IoT Hub makes sense when your infrastructure is Microsoft-focused, when you need tight integration with Azure AI and analytics services, or when direct method RPC patterns match your device control requirements.

Use Azure IoT Hub when:

Your infrastructure is Azure-native Your backend runs on Azure Functions or App Service. Your data platform uses Cosmos DB or Azure SQL. Your analytics run on Azure Stream Analytics and Power BI. Azure IoT Hub integrates natively with all of these—authentication through Azure AD, data flow through Event Hub, monitoring through Azure Monitor.

You need strong device twin integration Device twins are built into IoT Hub, not a separate service. Reading device state, updating configuration, and querying device metadata all happen through the same IoT Hub API. If your application architecture relies heavily on querying device state—"show me all devices in building 5 with firmware version 2.1 and battery below 20%"—Azure's twin query language handles this really well.

Your devices support rich SDKs If your devices run embedded Linux, Windows IoT, or Android, the Azure IoT device SDKs provide high-level abstractions. You're calling methods like UpdateReportedPropertiesAsync() instead of manually constructing MQTT messages and parsing JSON.

You need hybrid cloud or edge compute Azure IoT Edge brings IoT Hub capabilities to the edge. Modules run locally, process data on-premises, and synchronize with the cloud when connectivity allows. If your architecture requires edge AI inference or local data processing, IoT Edge is more mature than AWS IoT Greengrass.

You prefer predictable pricing at high message volumes Azure's message batching (charged per 400 messages) can be more cost-effective than AWS's per-message pricing when devices send telemetry frequently. A device sending 10,000 messages per day costs the same as one sending 400 messages per day within Azure's 400-message unit.

Trade-offs with Azure IoT Hub:

Direct methods are synchronous - cloud calls device, waits for response. That works great for real-time commands but doesn't fit every use case. Devices that sleep aggressively or operate on cellular with poor connectivity can't reliably respond to direct methods. AWS's asynchronous shadow updates work better for intermittently connected devices.

OTA update management is DIY. Azure gives you device twins and direct methods. You build the OTA orchestration—tracking which devices need updates, monitoring download progress, handling failures. This is fine if you have custom OTA requirements. It's extra work if you just need basic OTA functionality.

MQTT 5.0 isn't supported. If your device architecture relies on shared subscriptions, request/response patterns, or other MQTT 5.0 features, Azure IoT Hub doesn't support them. You're limited to MQTT 3.1.1 capabilities.

Decision Framework: How to Choose Between AWS IoT Core and Azure IoT Hub

Use this framework to evaluate which platform matches your technical requirements, not just which one has better marketing.

Start with Your Cloud Ecosystem

If your infrastructure is AWS-heavy:

• Application backend on Lambda, ECS, or EC2

• Data storage in S3, DynamoDB, RDS

• Analytics using Kinesis, Athena, Redshift

• Authentication via AWS IAM

→ AWS IoT Core is the path of least resistance. You're not paying for platform switching costs. Your team already understands AWS security models, deployment patterns, and monitoring tools.

If your infrastructure is Azure-heavy:

• Application backend on Azure Functions, App Service, or AKS

• Data storage in Cosmos DB, Blob Storage, Azure SQL

• Analytics using Stream Analytics, Data Lake, Power BI

• Authentication via Azure AD

→ Azure IoT Hub integrates naturally. You gain operational simplicity by staying within one cloud provider's tooling and identity systems.

If your infrastructure is multi-cloud or on-premises: Neither platform gives you a strong ecosystem advantage. Evaluate based on technical features (next sections) rather than cloud lock-in.

Evaluate Your Device Constraints

If your devices are resource-constrained (Cortex-M0/M3, <256KB flash): → AWS IoT Core. The embedded SDK is smaller and the MQTT-focused architecture requires less code.

If your devices run embedded Linux or have significant resources: → Either platform works. Azure's richer SDK abstractions can simplify firmware if your device can handle the code size.

If your devices are intermittently connected (cellular, satellite): → AWS IoT Core. Asynchronous shadow updates work better than Azure's synchronous direct methods for devices that aren't always online.

If your devices need edge compute capabilities: → Azure IoT Edge is more mature than AWS IoT Greengrass for running containerized workloads at the edge.

Assess Your OTA Requirements

If you need managed OTA with tracking and staged rollouts: → AWS IoT Jobs provides this out of the box. Azure requires building equivalent functionality yourself.

If you have custom OTA logic and need flexibility: → Azure device twins give you primitives to build exactly what you need without framework constraints.

If OTA isn't critical or handled outside the IoT platform: → This doesn't differentiate the platforms. Evaluate based on other factors.

The Bottom Line

AWS IoT Core and Azure IoT Hub both handle device connectivity, state management, and message routing reliably at scale. Neither is objectively better - they're optimized for different technical patterns and cloud ecosystems.

Choose AWS IoT Core when your infrastructure is AWS-native, when you need purpose-built OTA management through IoT Jobs, when your devices are resource-constrained, or when complex message routing to multiple AWS services matters.

Choose Azure IoT Hub when your infrastructure is Azure-native, when device twin query capabilities align with your application requirements, when you need mature edge computing through IoT Edge, or when your pricing model favors message batching over per-message costs.

The platform decision locks in device firmware architecture, cloud integration patterns, and operational tooling for the product's lifetime. Switching later is expensive. Model your message patterns against both pricing structures, prototype device firmware against both SDKs, and evaluate which platform's operational model matches how your team actually works.

If you're architecting an IoT product and need a realistic assessment of which cloud platform matches your device constraints, message patterns, and backend integration requirements - CoreFragment's IoT team has built connected products on both AWS and Azure. We can review your architecture and give you a direct recommendation based on your specific technical requirements, not just platform marketing.