AWS IoT Core vs Azure IoT Hub vs Google Cloud IoT: 2024 Honest Comparison

Choosing an IoT cloud platform is one of the highest-leverage decisions you will make during your product build. Get it wrong and you will spend months migrating device fleets, rewriting SDKs, and retraining your team. Get it right and the platform becomes an accelerator rather than an anchor.

At Code Caracal we have shipped production systems on all three major clouds. This guide is the comparison we wish existed before we started: specific, opinionated, and grounded in real project experience.

Why the Choice Is Harder Than It Looks

Marketing pages from AWS, Microsoft, and Google all promise the same features: device management, MQTT support, cloud integration, security. The differences only reveal themselves when you are 12 weeks into a project and discover that your chosen platform does not support QoS 2 at scale, or that its device shadow synchronisation adds 400 ms of latency, or that the regional availability in Southeast Asia means your devices in Malaysia lose connectivity.

Feature Comparison at a Glance

| Feature | AWS IoT Core | Azure IoT Hub | Google Cloud IoT | |---|---|---|---| | Protocol support | MQTT, MQTT-WS, HTTP, LoRaWAN | MQTT, AMQP, HTTP | MQTT, HTTP | | Device shadows | Yes (Device Shadow) | Yes (Device Twin) | Yes (Device Config) | | Device management | AWS IoT Device Management | Azure IoT Hub DM | Limited (Cloud IoT Core deprecated) | | OTA updates | AWS IoT Jobs | Azure Device Update | Manual / third-party | | Edge compute | AWS Greengrass | Azure IoT Edge | Google Distributed Cloud Edge | | ML integration | SageMaker | Azure ML | Vertex AI (best-in-class) | | Time-series database | Amazon Timestream | Azure Time Series Insights | BigQuery | | Rules engine | IoT Rules Engine → Lambda/DynamoDB | IoT Hub routing → Event Hubs | Pub/Sub → Dataflow | | Message broker retention | None (fire and forget) | 1–7 day built-in retention | Pub/Sub: 7 days | | Free tier devices | 500K messages/month | 8,000 messages/day | Deprecated platform | | Pricing model | Per message (0.08 USD per million) | Per unit tier | Per message | | Regional availability | 19 regions | 54 regions | 36 regions | | Certification standard | FIPS 140-2 | FIPS 140-2 | FIPS 140-2 |

AWS IoT Core: The Ecosystem Advantage

AWS IoT Core is our default recommendation for most greenfield IoT projects, and the reason is simple: ecosystem depth. No other cloud connects IoT data to downstream services as seamlessly as AWS.

Rules Engine to Lambda means a single MQTT message can trigger data transformation, storage to DynamoDB, fan-out to SNS, and alerting to PagerDuty — all configured without writing routing code. The rule SQL syntax is intuitive:

SELECT topic(3) as deviceId,
       timestamp() as ts,
       temperature,
       humidity
FROM 'devices/+/telemetry'
WHERE temperature > 30

This single rule extracts the device ID from the topic, adds a server timestamp, and filters only hot-temperature events — forwarding them to a Lambda function in milliseconds.

AWS IoT Device Management provides fleet indexing, bulk provisioning, and remote actions at a scale that Azure and Google simply do not match today. When you need to push a configuration change to 50,000 devices grouped by firmware version and geographic region, AWS IoT Jobs handles it natively.

Greengrass v2 is the most mature edge compute runtime available. If your use case requires local inference (anomaly detection on the factory floor without cloud round-trips), Greengrass lets you deploy Lambda functions and ML models directly to gateway hardware, with automatic synchronisation when connectivity is restored.

Weakness: AWS IoT Core has the steepest learning curve of the three. IAM policies for IoT devices, certificate-based authentication, and the Rules Engine all require IoT-specific expertise. Mistakes in IAM policy scoping are a common security gap in first-time AWS IoT deployments.

Azure IoT Hub: Enterprise Integration and Edge Modules

If your buyer is an enterprise IT department running on Microsoft infrastructure, Azure IoT Hub is often the path of least resistance. The integration story with Azure Active Directory, Azure Monitor, and Power BI is compelling for organisations already in the Microsoft ecosystem.

Device Twins are functionally equivalent to AWS Device Shadows but with a richer querying syntax. You can query the entire device fleet by twin properties in a single API call — something AWS requires fleet indexing to approximate.

Azure IoT Edge uses Docker containers (called modules) for edge workloads. This is more developer-friendly than Greengrass if your team already knows containers. You can run a custom MQTT broker, an ML inference module, and a protocol translation module side-by-side on a Raspberry Pi gateway, all managed from the cloud.

Azure Device Update (acquired from DeploymentStack) provides binary delta updates, which reduces OTA payload size significantly — important for devices on constrained cellular connections.

Weakness: Azure IoT Hub's pricing tier model is less predictable than AWS's per-message model. You commit to a tier (Free, S1, S2, S3) that caps both messages per day and maximum throughput. Hitting the cap means either upgrading the tier or dropping messages. For bursty IoT workloads this can be expensive.

Google Cloud IoT: ML Integration and Pub/Sub

Here is important context: Google deprecated the original Cloud IoT Core in 2023. Google's current IoT positioning is through Pub/Sub as the message ingestion layer and Vertex AI for on-device and cloud ML. This is a significant strategic shift.

If your IoT product's primary differentiator is machine learning — predictive maintenance using sensor time series, computer vision on edge cameras, or NLP on voice-enabled devices — Google Cloud's ML tooling is genuinely best-in-class. Vertex AI's AutoML, model monitoring, and feature store integrate directly with BigQuery, where your telemetry naturally lands via Pub/Sub.

The Pub/Sub message retention (up to 7 days with replay) is a real architectural advantage over AWS IoT Core's fire-and-forget model. If your backend goes down for 4 hours, Pub/Sub holds your messages; AWS IoT Core drops them.

Weakness: Without a dedicated IoT Core service, you are assembling your own device management layer. Certificate rotation, device provisioning, and fleet commands all require custom code or third-party tooling. For early-stage products this is a significant overhead.

Our Recommendation by Use Case

Choose AWS IoT Core if: You are building a production IoT system with 500+ devices, need mature OTA and fleet management, or your team does not have a prior cloud preference. The ecosystem depth pays off at scale.

Choose Azure IoT Hub if: Your customer is a mid-to-large enterprise on Microsoft infrastructure, you need native Active Directory integration, or your edge compute requirements are Docker-container-based.

Choose Google Cloud (Pub/Sub + Vertex AI) if: Your product's core value proposition is ML-driven intelligence (predictive failure, anomaly detection, recommendation), and you have engineering bandwidth to build your own device management layer.

Avoid Google Cloud IoT if: You need a managed MQTT endpoint, device shadows, or OTA updates out of the box — you will spend months building what the other two platforms provide natively.

A Note on Multi-Cloud IoT

We have seen startups attempt to build cloud-agnostic IoT layers using platforms like Losant, Particle, or ThingsBoard. In our experience, the abstraction cost (custom APIs, reduced feature access, added latency hops) usually outweighs the vendor lock-in risk for devices shipping under 100,000 units. Pick one cloud and go deep.

---

Ready to choose your IoT cloud stack and start building? [Talk to our team at Code Caracal](/contact) — we will scope your architecture in a free 30-minute call and tell you exactly which platform fits your use case.