TL;DR:
- AWS IoT Greengrass wins if your team already runs workloads on AWS — IAM and native service triggers save real engineering hours
- Azure IoT Edge wins for Microsoft-stack teams — the container module model extends what you already know
- Losant wins on speed and simplicity — fastest time-to-first-dashboard, no hyperscaler lock-in
This IoT platform comparison covers AWS IoT Greengrass v2, Azure IoT Edge, and Losant — deployed with the same edge workload on the same hardware in the same week. Test hardware: Raspberry Pi 5 (8GB, Ubuntu 22.04 LTS arm64, NVMe SSD). Workload: MQTT subscriber ingesting DHT22 readings at 1Hz, running a 60-second spike detection check, POSTing alerts to an HTTP endpoint. Cloud receives only alerts and a 5-minute heartbeat.
AWS IoT Greengrass v2
AWS IoT Greengrass is AWS’s edge runtime. It manages components — Lambda functions, Docker containers, or custom executables — that communicate with AWS IoT Core over MQTT, triggering Lambda, writing to DynamoDB, or invoking any AWS service.
Time to first message: 45 minutes.
The IAM policy setup is the main friction point: greengrass:*, iot:*, and policies for whatever AWS services your components use. The Greengrass Core installer is a Java application — it installs the JDK automatically (~200MB to disk, 3–5 minutes). It’s not the smoothest onboarding experience you’ll have.
Strengths: native AWS integration lets components write directly to DynamoDB, SQS, or Lambda with a single SDK call. Unique X.509 per device, Greengrass policies scoped to MQTT topics, and component versioning with rollback across device groups all work well.
Weaknesses: requires a live AWS connection for deployments and log access. Debugging is slow — correlating logs across device, Greengrass Core, and IoT Core is painful. The Java runtime adds ~150MB RAM at idle.
Cost at 100K messages/day: IoT Core ($3/month) + Lambda invocations ($0.60/month) + CloudWatch Logs (~$1/month) = roughly $4–$8/month per device. At 100 devices: $400–$800/month before storage and data transfer. That starts to add up.
Azure IoT Edge
Azure IoT Edge runs workloads as Docker containers called modules. The Edge runtime is two containers (edgeAgent and edgeHub); your workload is a third container deployable from any registry.
Time to first message: 35 minutes.
The azure-iot-edge apt package installs cleanly on Ubuntu 22.04 arm64. Module routing uses a SQL-like syntax — $upstream routes to IoT Hub; local routing between modules never hits the cloud.
Strengths: true container flexibility — deploy Rust, Python, ONNX Runtime inference, or any containerised workload without modification. Best ML integration — Azure ML exports models directly to IoT Edge modules. AKS teams can reuse their operational knowledge directly, which is a real advantage for UK enterprises already running Azure.
Weaknesses: IoT Hub pricing scales steeply — the free tier is 8,000 messages/day; Standard S1 is $25/month. Higher memory floor — two management containers plus modules means it’s not suitable for sub-1GB devices. Devices behind strict firewalls need IoT Edge gateway configuration.
Cost at 100K messages/day: IoT Hub Standard S1 ($25/month) + Azure Container Registry Basic (~$5/month) = roughly $30–$35/month per device.
Losant
Losant is a purpose-built managed IoT platform — not a hyperscaler service. It provides device management, MQTT/HTTP ingestion, a visual workflow builder, real-time dashboards, and the Losant Edge Agent.
Time to first message: 20 minutes.
The Edge Agent is an npm package. Register a device in the web dashboard, download credentials, drop them in the config file, start the agent. No IAM policies, no JSON deployment manifests. Edge flows are built visually (MQTT In → Threshold Check → Conditional → HTTP Request) and pushed to devices from the web interface. Fair enough — it’s genuinely quick to get up and running.
Strengths: fastest to value, with a working dashboard with live sensor data in under 30 minutes. Built-in device management — last-seen timestamps, connection status, custom attributes — first-class. No hyperscaler lock-in. Self-hosted option available. Best dashboard tooling in this comparison — drag-and-drop charts, maps, gauges in real time.
Weaknesses: less flexible for custom compute — ML models require a Function node plus local npm modules. Smaller ecosystem and community. Sandbox plan caps at 10 devices.
Pricing: Maker plan is $25/month for 200 devices, 1M data points/month. At 50 devices × 100K messages/day, expect roughly $26/month total.
Platform Comparison
| Platform | Deploy Time | Containers | Dashboard | Cost (50 devices) | Best For |
|---|---|---|---|---|---|
| AWS Greengrass v2 | 45 min | Yes | No (separate tooling) | $200–$400/month | AWS-invested teams |
| Azure IoT Edge | 35 min | Yes (native) | No (Azure tooling) | $50–$150/month | Microsoft-stack teams |
| Losant | 20 min | No (agent-based) | Yes (built-in) | ~$26/month | Speed, vendor-neutral |
Choosing the Right Platform
Choose AWS IoT Greengrass v2 if you have existing Lambda functions, DynamoDB tables, or S3 buckets to integrate, your team knows IAM, or you need KMS-backed security.
Choose Azure IoT Edge if your backend runs on Azure, you want to deploy ML models trained in Azure ML, or your team already uses Docker and AKS. For UK organisations already in the Microsoft 365 and Azure ecosystem, this is often the natural choice.
Choose Losant if you want a working end-to-end IoT system without building infrastructure, need to avoid hyperscaler lock-in, or your edge logic is primarily data transformation and threshold routing.
Don’t choose any of these if hardware is under 512MB RAM (use Eclipse Mosquitto + Node-RED instead) or you need truly offline-first operation — all three require cloud connectivity for updates.
The Bottom Line
The platform decision is primarily a team and ecosystem decision, not a technical one. AWS Greengrass integrates best with the AWS ecosystem but costs more at scale. Azure IoT Edge has the cleanest container model and best ML workflow. Losant is the fastest path to a working system and most cost-effective at typical fleet sizes. Match the platform to where your team already lives, not to vendor benchmark sheets.