Azure IoT Hub – Abrechnungsinformationen

Azure IoT Hub – Preise enthält die allgemeinen Informationen zu den verschiedenen SKUs und die Preise für IoT Hub. Dieser Artikel enthält ausführliche Informationen dazu, wie die verschiedenen IoT Hub-Funktionen als Nachrichten von IoT Hub getaktet werden.

Hinweis

Einige der in diesem Artikel erwähnten Features (wie Cloud-zu-Gerät-Messaging, Gerätezwillinge und Geräteverwaltung) stehen nur im Standard-Tarif von IoT Hub zur Verfügung. Weitere Informationen zu den IoT Hub-Tarifen „Basic“ und „Standard/Free“ finden Sie unter Wählen des richtigen IoT Hub-Tarifs für Ihre Lösung.

Gebühren pro Vorgang

Ermitteln Sie anhand der folgenden Tabelle, welche Vorgänge berechnet werden. Alle abrechenbaren Vorgänge werden in Blöcken von 4 KB auf IoT-Hubs zum Basic- und Standard-Tarif berechnet. Vorgänge werden in Blöcken von 0,5 KB auf IoT-Hubs zum Free-Tarif getaktet. Details zu jeder Kategorie werden in der Spalte Abrechnungsinformationen gezeigt. Diese Spalte enthält die folgenden Informationen:

• Details dazu, wie abrechenbare Vorgänge auf IoT-Hubs zum Basic- und Standard-Tarif-getaktet werden. Nicht alle Vorgänge sind im Basic-Tarif verfügbar.
• Die Vorgänge, die zu Gebühren führen, mit entweder:
  • Einem Link zur REST-API-Dokumentation, falls vorhanden.
  • Dem Vorgangsendpunkt, wenn die REST-API-Dokumentation nicht verfügbar ist oder wenn der Vorgang nur über MQTT und/oder AMQP verfügbar ist. Beim Endpunktwert wird der führende Verweis auf den Ziel-IoT-Hub weggelassen; {fully-qualified-iothubname}.azure-devices.net.
• Ein oder mehrere kursiv formatierte(r) Begriff(e) hinter jedem Vorgang (oder Endpunkt). Diese Begriffe stellen abrechenbare Vorgänge dar, die auf das Kontingent für Ihren IoT-Hub berechnet werden. Möglicherweise werden diese Begriffe als Teil eines Einblicks in die Kontingentnutzung angezeigt, wenn Sie eine Supportanfrage im Azure-Portal einleiten. Vielleicht werden sie auch vom Kundensupport zurückgegeben. Sie können diese Begriffe anhand der nachstehenden Tabelle mit dem entsprechenden Vorgang vergleichen, damit Sie die Kontingentnutzung und Abrechnung für Ihre IoT-Lösung besser verstehen. Weitere Informationen finden im Beispiel 4.

Vorgangskategorie	Abrechnungsinformationen
Identitätsregistrierungsvorgänge (Erstellen, Aktualisieren, Abrufen, Auflisten, Löschen, Massenupdate, Statistik)	Keine Gebühren.
D2C-Nachrichten	Erfolgreich gesendete Nachrichten werden beim Eingang in IoT Hub in Blöcken von 4 KB berechnet. Beispielsweise wird eine Nachricht von 100 Byte als eine Nachricht berechnet und eine Nachricht von 6 KB als zwei Nachrichten. Geräteereignis senden: Entweder Gerät-zu-Cloud-Telemetrie oder Gerät-zu-Cloud-Telemetrie-Routing – abhängig davon, ob für den IoT-Hub Nachrichtenroutingfeatures konfiguriert wurden.
C2D-Nachrichten	Erfolgreich gesendete Nachrichten werden in Blöcken von 4 KB berechnet. Eine Nachricht mit 6 KB beispielsweise wird als zwei Nachrichten berechnet. Gerätegebundene Benachrichtigung empfangen: Cloud-zu-Gerät-Befehl
Dateiuploads	Die Dateiübertragung an Azure Storage wird von IoT Hub nicht getaktet. Nachrichten für die Initiierung und den Abschluss der Dateiübertragung werden als Nachrichten mit 4-KB-Taktung berechnet. Für die Übertragung einer Datei mit 10MB werden z.B. zusätzlich zu den Azure Storage-Kosten zwei Nachrichten berechnet. SAS-URI-für Dateiupload erstellen: Gerät-zu-Cloud-Dateiupload Status von Dateiupload aktualisieren: Gerät-zu-Cloud-Dateiupload
Direkte Methoden	Erfolgreiche Methodenanforderungen werden in Blöcken von 4KB berechnet, und Antworten werden als zusätzliche Nachrichten in Blöcken von 4KB berechnet. Anforderungen oder Antworten ohne Nutzlast werden als eine einzige Nachricht berechnet. Beispielsweise wird eine Methode mit einem Text von 4 KB, die zu einer Antwort ohne Nutzlast vom Gerät führt, als zwei Nachrichten berechnet. Eine Methode mit einem Text von 6 KB, die zu einer Antwort mit 1 KB vom Gerät führt, wird als zwei Nachrichten für die Anforderung plus eine Nachricht für die Antwort berechnet. Anforderungen an getrennte Geräte werden als Nachrichten in Blöcken von 4 KB plus einer Nachricht für eine Antwort berechnet, die angibt, dass das Gerät nicht online ist. Gerät – Aufrufmethode: Gerät – Direkte Aufrufmethode, Modul – Aufrufmethode: Modul – Direkte Aufrufmethode
Zwillingslesevorgänge vom Gerät und Modul	Zwillingslesevorgänge vom Gerät oder Modul und vom Lösungs-Back-End werden als Nachrichten in Blöcken von jeweils 4 KB berechnet. Beispielsweise wird ein Lesevorgang von einem 8 KB-Zwilling als 2 Nachrichten berechnet. Zwilling abrufen: Zwilling abrufen Modulzwilling abrufen: Modulzwilling abrufen Geräte- und Modulzwillinge aus einem Gerät lesen: Endpunkt: /devices/{id}/twin (nur MQTT, AMQP): D2C Get Twin Endpunkt: /devices/{deviceid}/modules/{moduleid}/twin (nur MQTT, AMQP): Modul D2C Get Twin
Geräte- und Modulzwillingsupdates (Tags und Eigenschaften)	Zwillingsupdates vom Gerät oder Modul und vom Lösungs-Back-End werden als Nachrichten in Blöcken von jeweils 4 KB berechnet. Beispielsweise wird ein 12-KB-Update für einen Zwilling als 3 Nachrichten berechnet. Zwilling aktualisieren: Zwilling aktualisieren Modulzwilling aktualisieren: Modulzwilling aktualisieren Zwilling ersetzen: Zwilling ersetzen Modulzwilling ersetzen: Modulzwilling ersetzen Aktualisieren Sie gemeldete Geräte- oder Modulzwillingseigenschaften aus einem Gerät: Endpunkt: /twin/PATCH/properties/reported/ (nur MQTT, AMQP): D2-Patch ReportedProperties oder Modul-D2-Patch ReportedProperties Empfangen Sie Aktualisierungsbenachrichtigungen für gewünschte Eigenschaften auf einem Gerät: Endpunkt: /twin/PATCH/properties/desired/ (nur MQTT, AMQP): D2C Notify DesiredProperties oder Modul-D2C Notify DesiredProperties
Abfragen von Geräte- und Modulzwillingen	Abfragen für devices oder devices.modules werden als Nachrichten je nach Ergebnisgröße in Blöcken von 4 KB berechnet. Abfragen für jobs werden nicht in Rechnung gestellt. Zwillinge abrufen (Abfrage für Sammlungen vom Typ devices oder devices.modules): Geräte abfragen
Lesevorgänge von digitalen Zwillingen	Lesevorgänge von digitalen Zwillingen vom Lösungs-Back-End werden als Nachrichten in Blöcken von 4 KB berechnet. Beispielsweise wird ein Lesevorgang von einem 8 KB-Zwilling als 2 Nachrichten berechnet. Digitalen Zwilling abrufen: Digitalen Zwilling abrufen
Updates von digitalen Zwillingen	Updates von digitalen Zwillingen vom Lösungs-Back-End werden als Nachrichten in Blöcken von 4 KB berechnet. Beispielsweise wird ein 12-KB-Update für einen Zwilling als 3 Nachrichten berechnet. Digitalen Zwilling aktualisieren: Digitalen Zwilling patchen
Befehle für digitale Zwillinge	Erfolgreiche Befehle werden in Blöcken von 4 KB berechnet, und Antworten werden als zusätzliche Nachrichten in Blöcken von ebenfalls 4 KB berechnet. Anforderungen oder Antworten ohne Text werden als eine einzige Nachricht berechnet. Beispielsweise wird ein Befehl mit einem Text von 4 KB, der zu einer Antwort ohne Text vom Gerät führt, als zwei Nachrichten berechnet. Ein Befehl mit einem Text von 6 KB, der zu einer Antwort von 1 KB vom Gerät führt, wird als zwei Nachrichten für den Befehl plus einer weiteren Nachricht für die Antwort berechnet. Befehle für getrennte Geräte werden als Nachrichten in Blöcken von 4 KB plus einer Nachricht für eine Antwort berechnet, die angibt, dass das Gerät nicht online ist. Komponentenbefehl aufrufen: Komponentenbefehl für digitalen Zwilling Befehl auf Stammebene aufrufen: Stammbefehl für digitalen Zwilling
Auftragsvorgänge (Erstellen, Abbrechen, Abrufen, Abfragen)	Keine Gebühren.
Vorgänge vom Typ „Aufträge pro Gerät“	Auftragsvorgänge (z. B. Zwillingsupdates und Methoden) werden in Blöcken von 4 KB berechnet. Ein Auftrag, der beispielsweise zu 1.000 Methodenaufrufen mit Anforderungen von 1 KB und Antworten vom Typ „empty-payload“ (leere Nutzlast) führt, wird mit 2.000 Nachrichten berechnet (jeweils eine Nachricht für Anforderung und Antwort). Auftrag für Gerätezwilling aktualisieren Aufrufmethode für Geräteauftrag
Konfigurationsvorgänge (Erstellen, Aktualisieren, Abrufen, Auflisten, Löschen, Testabfrage)	Keine Gebühren.
Konfigurationsvorgänge pro Gerät	Konfigurationsvorgänge werden als Nachrichten in Blöcken von 4 KB berechnet. Antworten werden nicht in Rechnung gestellt. Beispielsweise wird ein Konfigurationsvorgang vom Typ „Anwenden“ mit einem Textkörper von 6 KB als zwei Nachrichten berechnet. Auf Edge-Gerät anwenden: Konfigurationsdienst „Anwenden“.
Keep-Alive-Nachrichten	Bei der Verwendung von AMQP- oder MQTT-Protokollen wird Folgendes nicht berechnet: Nachrichten, die zum Herstellen der Verbindung ausgetauscht wurden, Nachrichten, die während der Aushandlung ausgetauscht wurden, oder ausgetauschte Nachrichten, damit die Verbindung geöffnet und aktiv blieb.
Gerätestreams (Vorschau)	Gerätestreams befinden sich in der Vorschau, und Vorgänge werden noch nicht berechnet. Endpunkt: /twins/{deviceId}/streams/{streamName}: Gerätestreams Endpunkt: /twins/{deviceId}/modules/{moduleId}/streams/{streamName}: Modul „Gerätestreams“

Hinweis

Bei allen Berechnungen der Größen wird die Nutzlastgröße in Byte berücksichtigt (Protokollframing wird ignoriert). Bei Nachrichten, die über Eigenschaften und Text verfügen, wird die Größe unabhängig vom Protokoll berechnet. Weitere Informationen finden Sie unter IoT Hub-Nachrichtenformat.

Maximale Nachrichtengrößen unterscheiden sich bei verschiedenen Arten von Vorgängen. Weitere Informationen finden Sie unter IoT Hub-Kontingente und Drosselung.

Bei einigen Vorgängen können Sie mithilfe von Batch- und Komprimierungsstrategien die Kosten senken. Ein Beispiel für die Verwendung von Gerät-zu-Cloud-Telemetrie finden Sie unter Beispiel 3.

Beispiel 1:

Ein Gerät sendet eine 1-KB-D2C-Nachricht pro Minute an IoT Hub, die dann von Azure Stream Analytics gelesen wird. Das Lösungs-Back-End ruft auf dem Gerät alle zehn Minuten eine Methode (mit einer Nutzlast von 512Bytes) auf, um eine bestimmte Aktion auszulösen. Das Gerät antwortet auf die Methode mit einem Ergebnis von 200 Byte.

Das Gerät verbraucht Folgendes:

• 1 Nachricht × 60 Minuten × 24 Stunden = 1440 Nachrichten pro Tag für die D2C-Nachrichten.

• Zwei Nachrichten (Anforderung plus Antwort) x 6 Vorkommen pro Stunde x 24 Stunden = 288 Nachrichten für die Methoden.

Diese Berechnung ergibt eine Gesamtsumme von 1728 Nachrichten pro Tag.

Beispiel 2:

Ein Gerät sendet jede Stunde eine D2C-Nachricht mit 100 KB. Außerdem aktualisiert es alle vier Stunden seinen Gerätezwilling mit 1-KB-Nutzlasten. Das Lösungs-Back-End liest einmal pro Tag den 14-KB-Gerätezwilling und aktualisiert ihn mit 512-Byte-Nutzlasten, um Konfigurationen zu ändern.

Das Gerät verbraucht Folgendes:

• 25 (100 KB/4 KB) Nachrichten × 24 Stunden für D2C-Nachrichten.

• Eine Nachricht (1 KB / 4 KB) × 6 Vorkommen pro Tag für Updates von Gerätezwillingen.

Diese Berechnung ergibt eine Gesamtsumme von 606 Nachrichten pro Tag.

Das Lösungs-Back-End verbraucht 4 Nachrichten (14 KB / 4 KB) für das Lesen vom Gerätezwilling plus eine Nachricht (512 / 4 KB) für dessen Update. Dies ergibt insgesamt 5 Nachrichten.

Insgesamt verbrauchen das Gerät und das Lösungs-Back-End 611 Nachrichten pro Tag.

Beispiel 3

Abhängig von Ihrem Szenario kann die Batchverarbeitung von Nachrichten Ihre Kontingentnutzung verringern.

Betrachten Sie beispielsweise ein Gerät mit einem Sensor, der bei jedem Lesevorgang nur 100 Byte an Daten generiert:

• Wenn das Gerät 40 Sensor-Lesevorgänge in einer einzigen Gerät-zu-Cloud-Nachricht mit einer Nutzlast von 4 KB (40 x 100 Byte) als Batch verarbeitet, wird nur eine Nachricht auf das Kontingent berechnet. Wenn das Gerät den Sensor 40-mal pro Stunde liest und diese Lesevorgänge in einer einzigen Geräte-zu-Cloud-Nachricht pro Stunde als Batch verarbeitet, würde es 24 Nachrichten/Tag senden.

• Wenn das Gerät eine Gerät-zu-Cloud-Nachricht mit einer Nutzlast von 100 Byte für jeden Sensor-Lesevorgang sendet, verbraucht es 40 Nachrichten vom Kontingent für dieselbe Datenmenge. Wenn das Gerät den Sensor 40-mal pro Stunde liest und jede Nachricht einzeln sendet, würde es 960 Nachrichten/Tag (40 Nachrichten x 24) senden.

Ihre Batchverarbeitungsstrategie ist abhängig von Ihrem Szenario und davon, wie zeitkritisch die Daten sind. Wenn Sie große Datenmengen senden, können Sie auch eine Implementierung der Datenkomprimierung in Betracht ziehen, um die Auswirkungen auf das Nachrichtenkontingent weiter zu verringern.

Beispiel 4

Wenn Sie eine Supportanfrage im Azure-Portal öffnen, wird eine Diagnose durchgeführt, die für Ihr gemeldetes Problem spezifisch ist. Das Ergebnis wird auf der Registerkarte Lösungen Ihrer Anfrage als Einblick angezeigt. Ein solcher Einblick meldet die Kontingentnutzung für Ihren IoT-Hub mithilfe der in der Tabelle oben kursiv formatierten Begriffe. Ob dieser bestimmte Einblick zurückgegeben wird, ist abhängig von den Ergebnissen der Diagnose, die auf Ihrem IoT-Hub für das von Ihnen gemeldete Problem durchgeführt wird. Wenn der Einblick in die Kontingentnutzung gemeldet wird, können Sie die gemeldeten Nutzungsbegriffe anhand der Tabelle mit den Vorgängen vergleichen, auf die sie verweisen.

Der folgende Screenshot zeigt beispielsweise eine Supportanfrage, die bei einem Problem mit der Gerät-zu-Cloud-Telemetrie eingeleitet wurde.

Nach der Auswahl von Weiter: Lösungen wird der Einblick in die Kontingentnutzung von der Diagnose unter Aufschlüsselung des täglichen IoT Hub-Nachrichtenkontingents zurückgegeben. Sie zeigt die Aufschlüsselung für Gerät-zu-Cloud-Nachrichten, die an den IoT-Hub gesendet wurden. In diesem Fall ist das Nachrichtenrouting auf dem IoT-Hub aktiviert, sodass die Nachrichten als Gerät-zu-Cloud-Telemetrie-Routing angezeigt werden. Beachten Sie, dass der Einblick in die Kontingentnutzung bei dem gleichen Problem auf einem anderen IoT-Hub möglicherweise nicht zurückgegeben wird. Die jeweilige Rückgabe ist abhängig von der Aktivität und dem Status dieses IoT-Hubs.