MicrosoftDocs
diff --git a/‎articles/iot-hub/iot-hub-devguide-pricing.md
Lines changed: 16 additions & 16 deletions b/‎articles/iot-hub/iot-hub-devguide-pricing.md
Lines changed: 16 additions & 16 deletions
@@ -11,9 +11,9 @@ ms.date: 04/07/2022
 ms.custom: [amqp, mqtt]
 ---
 
-# Azure IoT Hub pricing information
+# Azure IoT Hub billing information
 
-[Azure IoT Hub pricing](https://azure.microsoft.com/pricing/details/iot-hub) provides the general information on different SKUs and pricing for IoT Hub. This article contains additional details on how the various IoT Hub functionalities are metered as messages by IoT Hub.
+[Azure IoT Hub pricing](https://azure.microsoft.com/pricing/details/iot-hub) provides the general information on different SKUs and pricing for IoT Hub. This article contains details on how the various IoT Hub functionalities are metered as messages by IoT Hub.
 
 [!INCLUDE [iot-hub-basic](../../includes/iot-hub-basic-partial.md)]
 
@@ -31,21 +31,21 @@ Use the following table to help determine which operations are charged. All bill
 | --------- | ------------------- |
 | Identity registry operations <br/> (create, update, get, list, delete, bulk update, statistics) | Not charged. |
 | Device-to-cloud messages | Successfully sent messages are charged in 4-KB chunks on ingress into IoT Hub. For example, a 100-byte message is charged as one message, and a 6-KB message is charged as two messages. <br/><br/> [Send Device Event](/rest/api/iothub/device/send-device-event), Either *Device to Cloud Telemetry* or *Device to Cloud Telemetry Routing* depending on whether the IoT hub has message routing features configured. In either case, messages are only charged on ingress into IoT Hub. |
-| Cloud-to-device messages | Successfully sent messages are charged in 4-KB chunks. For example, a 6-KB message is charged as 2 messages. <br/><br/> [Receive Device Bound Notification](/rest/api/iothub/device/receive-device-bound-notification), *Cloud To Device Command* |
-| File uploads | File transfer to Azure Storage is not metered by IoT Hub. File transfer initiation and completion messages are charged as messaged metered in 4-KB increments. For example, transferring a 10-MB file is charged as two messages in addition to the Azure Storage cost. <br/><br/> [Create File Upload Sas Uri](/rest/api/iothub/device/create-file-upload-sas-uri), *Device To Cloud File Upload* <br/> [Update File Upload Status](/rest/api/iothub/device/update-file-upload-status), *Device To Cloud File Upload* |
-| Direct methods | Successful method requests are charged in 4-KB chunks, and responses are charged in 4-KB chunks as additional messages. Requests or responses with no payload are charged as one message. For example, a method with a 4-KB body that results in a response with no payload from the device is charged as two messages. A method with a 6-KB body that results in a 1-KB response from the device is charged as two messages for the request plus another message for the response. Requests to disconnected devices are charged as messages in 4-KB chunks plus one message for a response that indicates the device is not online. <br/><br/> [Device - Invoke Method](/rest/api/iothub/service/devices/invoke-method), *Device Direct Invoke Method*, <br/> [Module - Invoke Method](/rest/api/iothub/service/modules/invoke-method), *Module Direct Invoke Method* |
-| Device and module twin reads | Twin reads from the device or module and from the solution back end are charged as messages in 4-KB chunks. For example, reading an 8-KB twin is charged as 2 messages.   <br/><br/> [Get Twin](/rest/api/iothub/service/devices/get-twin), *Get Twin*  <br/> [Get Module Twin](/rest/api/iothub/service/modules/get-twin), *Get Module Twin* <br/><br/> Read device and module twins from a device: <br/> **Endpoint**: `/devices/{id}/twin` ([MQTT](iot-hub-mqtt-support.md#retrieving-a-device-twins-properties), AMQP only), *D2C Get Twin* <br/> **Endpoint**: `/devices/{deviceid}/modules/{moduleid}/twin` (MQTT, AMQP only), *Module D2C Get Twin* |
-| Device and module twin updates (tags and properties) | Twin updates from the device or module and from the solution back end are charged as messages in 4-KB chunks. For example, a 12-KB update to a twin is charged as 3 messages.  <br/><br/> [Update Twin](/rest/api/iothub/service/devices/update-twin), *Update Twin* <br/> [Update Module Twin](/rest/api/iothub/service/modules/update-twin), *Update Module Twin* <br/> [Replace Twin](/rest/api/iothub/service/devices/replace-twin), *Replace Twin* <br/> [Replace Module Twin](/rest/api/iothub/service/modules/replace-twin), *Replace Module Twin* <br/><br/> Update device or module twin reported properties from a device: <br/> **Endpoint**: `/twin/PATCH/properties/reported/` ([MQTT](iot-hub-mqtt-support.md#update-device-twins-reported-properties), AMQP only), *D2 Patch ReportedProperties* or *Module D2 Patch ReportedProperties* <br/><br/> Receive desired properties update notifications on a device: <br/> **Endpoint**: `/twin/PATCH/properties/desired/` ([MQTT](iot-hub-mqtt-support.md#receiving-desired-properties-update-notifications), AMQP only), *D2C Notify DesiredProperties* or *Module D2C Notify DesiredProperties* |
-| Device and module twin queries | Queries are charged as messages depending on the result size in 4-KB chunks. <br/><br/> [Get Twins](/rest/api/iothub/service/query/get-twins)  (query against **devices** or **devices.modules** collections), *Query Devices* <br/><br/> Queries against **jobs** collection are not charged. |
-| Digital twin reads | Digital twin reads from the solution back end are charged as messages in 4-KB chunks. For example, reading an 8-KB twin is charged as 2 messages. <br/><br/> [Get Digital Twin](/rest/api/iothub/service/digital-twin/get-digital-twin), *Get Digital Twin* |
-| Digital twin updates | Digital twin updates from the solution back end are charged as messages in 4-KB chunks. For example, a 12-KB update to a twin is charged as 3 messages. <br/><br/> [Update Digital Twin](/rest/api/iothub/service/digital-twin/update-digital-twin), *Patch Digital Twin* |
-| Digital twin commands | Successful commands are charged in 4-KB chunks, and responses are charged in 4-KB chunks as additional messages.  Requests or responses with no body are charged as one message. For example, a command with a 4-KB body that results in a response with no body from the device is charged as two messages. A command with a 6-KB body that results in a 1-KB response from the device is charged as two messages for the command plus another message for the response. Commands to disconnected devices are charged as messages in 4-KB chunks plus one message for a response that indicates the device is not online. <br/><br/> [Invoke Component Command](/rest/api/iothub/service/digital-twin/invoke-component-command), *Digital Twin Component Command*  <br/> [Invoke Root Level Command](/rest/api/iothub/service/digital-twin/invoke-root-level-command), *Digital Twin Root Command*  |
+| Cloud-to-device messages | Successfully sent messages are charged in 4-KB chunks. For example, a 6-KB message is charged as two messages. <br/><br/> [Receive Device Bound Notification](/rest/api/iothub/device/receive-device-bound-notification), *Cloud To Device Command* |
+| File uploads | File transfer to Azure Storage isn't metered by IoT Hub. File transfer initiation and completion messages are charged as messaged metered in 4-KB increments. For example, transferring a 10-MB file is charged as two messages in addition to the Azure Storage cost. <br/><br/> [Create File Upload Sas Uri](/rest/api/iothub/device/create-file-upload-sas-uri), *Device To Cloud File Upload* <br/> [Update File Upload Status](/rest/api/iothub/device/update-file-upload-status), *Device To Cloud File Upload* |
+| Direct methods | Successful method requests are charged in 4-KB chunks, and responses are charged in 4-KB chunks as additional messages. Requests or responses with no payload are charged as one message. For example, a method with a 4-KB body that results in a response with no payload from the device is charged as two messages. A method with a 6-KB body that results in a 1-KB response from the device is charged as two messages for the request plus another message for the response. Requests to disconnected devices are charged as messages in 4-KB chunks plus one message for a response that indicates the device isn't online. <br/><br/> [Device - Invoke Method](/rest/api/iothub/service/devices/invoke-method), *Device Direct Invoke Method*, <br/> [Module - Invoke Method](/rest/api/iothub/service/modules/invoke-method), *Module Direct Invoke Method* |
+| Device and module twin reads | Twin reads from the device or module and from the solution back end are charged as messages in 4-KB chunks. For example, reading an 8-KB twin is charged as two messages.   <br/><br/> [Get Twin](/rest/api/iothub/service/devices/get-twin), *Get Twin*  <br/> [Get Module Twin](/rest/api/iothub/service/modules/get-twin), *Get Module Twin* <br/><br/> Read device and module twins from a device: <br/> **Endpoint**: `/devices/{id}/twin` ([MQTT](iot-hub-mqtt-support.md#retrieving-a-device-twins-properties), AMQP only), *D2C Get Twin* <br/> **Endpoint**: `/devices/{deviceid}/modules/{moduleid}/twin` (MQTT, AMQP only), *Module D2C Get Twin* |
+| Device and module twin updates (tags and properties) | Twin updates from the device or module and from the solution back end are charged as messages in 4-KB chunks. For example, a 12-KB update to a twin is charged as three messages.  <br/><br/> [Update Twin](/rest/api/iothub/service/devices/update-twin), *Update Twin* <br/> [Update Module Twin](/rest/api/iothub/service/modules/update-twin), *Update Module Twin* <br/> [Replace Twin](/rest/api/iothub/service/devices/replace-twin), *Replace Twin* <br/> [Replace Module Twin](/rest/api/iothub/service/modules/replace-twin), *Replace Module Twin* <br/><br/> Update device or module twin reported properties from a device: <br/> **Endpoint**: `/twin/PATCH/properties/reported/` ([MQTT](iot-hub-mqtt-support.md#update-device-twins-reported-properties), AMQP only), *D2 Patch ReportedProperties* or *Module D2 Patch ReportedProperties* <br/><br/> Receive desired properties update notifications on a device: <br/> **Endpoint**: `/twin/PATCH/properties/desired/` ([MQTT](iot-hub-mqtt-support.md#receiving-desired-properties-update-notifications), AMQP only), *D2C Notify DesiredProperties* or *Module D2C Notify DesiredProperties* |
+| Device and module twin queries | Queries are charged as messages depending on the result size in 4-KB chunks. <br/><br/> [Get Twins](/rest/api/iothub/service/query/get-twins)  (query against **devices** or **devices.modules** collections), *Query Devices* <br/><br/> Queries against **jobs** collection aren't charged. |
+| Digital twin reads | Digital twin reads from the solution back end are charged as messages in 4-KB chunks. For example, reading an 8-KB twin is charged as two messages. <br/><br/> [Get Digital Twin](/rest/api/iothub/service/digital-twin/get-digital-twin), *Get Digital Twin* |
+| Digital twin updates | Digital twin updates from the solution back end are charged as messages in 4-KB chunks. For example, a 12-KB update to a twin is charged as three messages. <br/><br/> [Update Digital Twin](/rest/api/iothub/service/digital-twin/update-digital-twin), *Patch Digital Twin* |
+| Digital twin commands | Successful commands are charged in 4-KB chunks, and responses are charged in 4-KB chunks as additional messages.  Requests or responses with no body are charged as one message. For example, a command with a 4-KB body that results in a response with no body from the device is charged as two messages. A command with a 6-KB body that results in a 1-KB response from the device is charged as two messages for the command plus another message for the response. Commands to disconnected devices are charged as messages in 4-KB chunks plus one message for a response that indicates the device isn't online. <br/><br/> [Invoke Component Command](/rest/api/iothub/service/digital-twin/invoke-component-command), *Digital Twin Component Command*  <br/> [Invoke Root Level Command](/rest/api/iothub/service/digital-twin/invoke-root-level-command), *Digital Twin Root Command*  |
 | Jobs operations <br/> (create, cancel, get, query) | Not charged. |
 | Jobs per-device operations | Jobs operations (such as twin updates, and methods) are charged as normal in 4-KB chunks. For example, a job resulting in 1000 method calls with 1-KB requests and empty-payload responses is charged 2000 messages (one message each for the request and response * 1000). <br/><br/> *Update Twin Device Job* <br/> *Invoke Method Device Job* |
 | Configuration operations <br/> (create, update, get, list, delete, test query) | Not charged.|
-| Configuration per-device operations | Configuration operations are charged as messages in 4-KB chunks. Responses are not charged. For example, an apply configuration operation with a 6-KB body is charged as two messages. <br/><br/> [Apply on Edge Device](/rest/api/iothub/service/configuration/apply-on-edge-device), *Configuration Service Apply*. |
-| Keep-alive messages | When using AMQP or MQTT protocols, messages exchanged to establish the connection and messages exchanged in the negotiation or to keep the connection open and alive are not charged. |
-| Device streams (preview) | Device streams is in preview and operations are not yet charged. <br/><br/> **Endpoint**: `/twins/{deviceId}/streams/{streamName}`, *Device Streams* <br/> **Endpoint**: `/twins/{deviceId}/modules/{moduleId}/streams/{streamName}`, *Device Streams Module* |
+| Configuration per-device operations | Configuration operations are charged as messages in 4-KB chunks. Responses aren't charged. For example, an apply configuration operation with a 6-KB body is charged as two messages. <br/><br/> [Apply on Edge Device](/rest/api/iothub/service/configuration/apply-on-edge-device), *Configuration Service Apply*. |
+| Keep-alive messages | When using AMQP or MQTT protocols, messages exchanged to establish the connection and messages exchanged in the negotiation, or to keep the connection open and alive, aren't charged. |
+| Device streams (preview) | Device streams is in preview and operations aren't charged yet. <br/><br/> **Endpoint**: `/twins/{deviceId}/streams/{streamName}`, *Device Streams* <br/> **Endpoint**: `/twins/{deviceId}/modules/{moduleId}/streams/{streamName}`, *Device Streams Module* |
 
 > [!NOTE]
 > All sizes are computed considering the payload size in bytes (protocol framing is ignored). For messages, which have properties and body, the size is computed in a protocol-agnostic way. For more information, see [IoT Hub message format](iot-hub-devguide-messages-construct.md).
@@ -92,11 +92,11 @@ For example, consider a device that has a sensor that only generates 100 bytes o
 
 - If the device sends a device-to-cloud message with a 100-byte payload for each sensor read, then it consumes 40 messages against quota for the same amount of data. If the device reads the sensor 40 times each hour and sends each message individually, it would send 960 messages/day (40 messages * 24).
 
-Your batching strategy will depend on your scenario and on how time-critical the data is. If you're sending large amounts of data, you can also consider implementing data compression to further reduce the impact on message quota.
+Your batching strategy depends on your scenario and on how time-critical the data is. If you're sending large amounts of data, you can also consider implementing data compression to further reduce the impact on message quota.
 
 ## Example #4
 
-When you open a support request on Azure portal, diagnostics specific to your reported issue are run. The result is displayed as an insight on the **Solutions** tab of your request. One such insight reports quota usage for your IoT hub using the terms in italics in the table above. Whether this particular insight is returned will depend on the results of the diagnostics performed on your IoT hub for the problem you're reporting. If the quota usage insight is reported, you can use the table above to cross-reference the reported usage term or terms with the operation(s) that they refer to.
+When you open a support request on Azure portal, diagnostics specific to your reported issue are run. The result is displayed as an insight on the **Solutions** tab of your request. One such insight reports quota usage for your IoT hub using the terms in italics in the table earlier. Whether this particular insight is returned will depend on the results of the diagnostics performed on your IoT hub for the problem you're reporting. If the quota usage insight is reported, you can use the table to cross-reference the reported usage term or terms with the operation(s) that they refer to.
 
 For example, the following screenshot shows a support request initiated for a problem with device-to-cloud telemetry.