| title | description | author | ms.author | ms.date | ms.topic | ms.service | services |
|---|---|---|---|---|---|---|---|
Limits and restrictions - Azure IoT Edge | Microsoft Docs |
Description of the limits and restrictions when using IoT Edge. |
raisalitch |
ralitchf |
01/28/2022 |
conceptual |
iot-edge |
iot-edge |
[!INCLUDE iot-edge-version-all-supported]
This article explains the limits and restrictions when using IoT Edge.
IoT Edge gateway hierarchies have a default limit of up to 100 connected child devices. This limit can be changed by setting the MaxConnectedClients environment variable in the parent device's edgeHub module.
For more information, see Create a gateway hierarchy.
IoT Hub enforces the following restrictions:
- An 8-kb size limit on the value of tags.
- A 32-kb size limit on both the value of
properties/desiredandproperties/reported.
For more information, see Module twin size.
An IoT Edge device has a limit of five layers of IoT Edge devices linked as children below it.
For more information, see Parent and child relationships.
IoT Hub has the following restrictions for IoT Edge automatic deployments:
- 50 modules per deployment
- This limit is superseded by the IoT Hub 32-kb module twin size limit. For more information, see Be mindful of twin size limits when using custom modules.
- 100 deployments (including layered deployments per paid SKU hub)
- 10 deployments per free SKU hub
IoT Edge certificates have the following restrictions:
- The common name (CN) can't be the same as the "hostname" that will be used in the configuration file on the IoT Edge device.
- The name used by clients to connect to IoT Edge can't be the same as the common name used in the edge CA certificate.
For more information, see Certificates for device security.
When using TPM attestation with the device provisioning service, you need to use TPM 2.0.
For more information, see TPM attestation device requirements.
IoT Edge and IoT Hub routing syntax is almost identical. Supported query syntax:
Not supported query syntax:
Don't use on-unhealthy or on-failure as values in modules' restartPolicy because they are unimplemented and won't initiate a restart. Only never and always restart policies are implemented.
The recommended way to automatically restart unhealthy IoT Edge modules is noted in this workaround. Configure the Healthcheck property in the module's createOptions to handle a failed health check.
IoT Hub only supports file upload APIs for device identities, not module identities. Since IoT Edge exclusively uses modules, file upload isn't natively supported in IoT Edge.
For more information on uploading files with IoT Hub, see Upload files with IoT Hub.
Changes made in config.toml to edgeAgent environment variables like the hostname aren't applied to edgeAgent if the container already existed. To apply these changes, remove the edgeAgent container using the command sudo docker rm -f edgeAgent. The IoT Edge daemon recreates the container and starts edgeAgent in about a minute.
:::moniker range="iotedge-2018-06"
When using Node.js to send device to cloud messages with the AMQP protocol to an IoT Edge runtime, messages stop sending after 2047 messages. No error is thrown and the messages eventually start sending again, then cycle repeats. If the client connects directly to Azure IoT Hub, there's no issue with sending messages. This issue has been fixed in IoT Edge 1.2.
:::moniker-end
For more information, see IoT Hub other limits.