TL;DR:
- AWS IoT Greengrass suits teams already on AWS — Lambda, SageMaker, and S3 integration is first-class
- Azure IoT Edge wins for Windows-heavy environments, OPC-UA industrial protocols, and teams using Azure ML
- Both platforms support Docker containers; the decision usually comes down to your existing cloud commitment
AWS IoT Greengrass vs Azure IoT Edge is one of the most common questions edge architects face when moving IoT workloads out of the cloud. Both platforms are mature, both support ML inference at the edge, and both handle the hard parts of OTA updates and device management. The differences come down to language support, deployment model, and how deeply embedded you already are in each cloud ecosystem.
Feature Comparison
The fastest way to understand the tradeoffs is side by side:
| Feature | AWS IoT Greengrass v2 | Azure IoT Edge |
|---|---|---|
| Container runtime | Greengrass nucleus + Docker | Moby (Docker-compatible) |
| Supported languages | Python, Java, C++, Node.js | Any (via containers) |
| ML inference | SageMaker Edge Manager, DLR | Azure ML, ONNX Runtime |
| Edge runtime footprint | ~50MB (nucleus) | ~50MB (edge agent + hub) |
| Protocol support | MQTT, HTTP | MQTT, AMQP, HTTP |
| Local messaging | AWS IoT Core shadow, stream manager | IoT Edge Hub (local broker) |
| Windows support | Limited | Full (Windows containers) |
| OPC-UA support | Via custom components | Native (Industrial IoT) |
| Pricing model | Per device per month | Per message (IoT Hub tier) |
Greengrass v2 introduced a component-based architecture that replaced the Lambda-centric model from v1. Components are deployable units — your code, third-party software, or AWS-managed components like Stream Manager or Secret Manager. Deployment recipes define dependencies, startup commands, and lifecycle hooks. More flexible than v1, but there’s a bit more conceptual overhead to get your head around.
Azure IoT Edge is structured around modules — Docker containers connected by routes defined in a deployment manifest. The edgeHub module is a local MQTT broker and message router between modules, which is architecturally cleaner for complex multi-module pipelines.
ML Inference Support
Both platforms have credible ML inference stories, but they integrate differently.
AWS Greengrass paired with SageMaker Edge Manager lets you compile models with Neo, deploy them as SageMaker Edge Agent components, and monitor model performance from the SageMaker console. Supported frameworks include TensorFlow, PyTorch, MXNet, and XGBoost. The Deep Learning Runtime (DLR) runs compiled models with low overhead on ARM and x86.
Azure IoT Edge takes a more open approach via ONNX Runtime — any model exportable to ONNX format runs on the edge with an execution provider swap. Azure ML handles training and model versioning; the az ml model deploy workflow pushes models to IoT Hub, which deploys them as edge modules. This works well with models from PyTorch, scikit-learn, or custom training pipelines.
For GPU-accelerated inference, both platforms support NVIDIA Jetson. Azure has a slight edge with its Nvidia DeepStream integration for video analytics pipelines.
Deployment Models
Greengrass uses fleet provisioning with AWS IoT Core — devices get X.509 certificates provisioned at manufacture time or via a claim certificate workflow. Deployments target thing groups, so you can roll out component updates to thousands of devices based on fleet metadata.
Azure IoT Edge uses automatic device provisioning (DPS) with IoT Hub. Deployment manifests are JSON documents specifying modules, Docker image references, environment variables, and routing rules. The layered deployment model lets you layer base configurations with role-specific overrides — useful for managing heterogeneous fleets.
Both handle OTA updates with rollback. Greengrass marks a deployment failed and rolls back if health checks fail; Azure IoT Edge tracks module restart counts and flags unhealthy deployments.
When to Choose Each
Choose AWS IoT Greengrass if your workloads already use Lambda, S3, Kinesis, or DynamoDB — local Greengrass components call these services natively. You’re using SageMaker for model training. Your devices run Linux. Your team is AWS-certified and doesn’t want to manage a second cloud control plane.
Choose Azure IoT Edge if you’re in a mixed Windows/Linux environment — Azure is the only platform with full Windows container support. You’re working with industrial equipment using OPC-UA; Azure’s Industrial IoT suite has native OPC-UA publishing built in. Your data scientists use Azure ML or the ONNX ecosystem. You need deep integration with Azure Stream Analytics or Azure Digital Twins.
For UK organisations running Microsoft-heavy IT infrastructure — which is a fair chunk of British enterprise — Azure IoT Edge tends to be the path of least resistance, since the operational tooling is already familiar.
Pricing Reality Check
Greengrass pricing is $0.16/device/month for the first 10,000 devices, dropping to $0.08 for larger fleets. Data transfer and IoT Core message costs are additional.
Azure IoT Edge pricing is tied to IoT Hub tier — Standard S1 is $25/month for 400,000 messages/day and covers unlimited edge devices. For large device fleets, Azure’s per-hub model can work out cheaper than Greengrass’s per-device fee.
To be honest, neither platform’s pricing is simple to project without knowing message volume and device count. Build a cost model before committing — the numbers can be surprising at scale.
The Bottom Line
If you’re an AWS shop, use Greengrass. The integration with SageMaker, Lambda, and IoT Core is genuinely better than bolting Azure onto an AWS-native stack. If you’re an Azure shop, use Azure IoT Edge — Windows container support, OPC-UA integration, and Azure ML connectivity make it the natural choice. The platform you’re already paying for and your team already understands will almost always beat the technically marginally superior alternative.