Welche Nachrichten an den IoT-Hub belasten das Kontingent? Gehören da auch die Connectivity Checks dazu?

Question

Welche Nachrichten an den IoT-Hub belasten das Kontingent? Gehören da auch die Connectivity Checks dazu?

Andreas Froidl 20

Im Tarif S1 für einen IOT-Hub sind 400000/Tag enthalten. In den Metriken kann man sehen, dass ein angemeldetet Gerät die "total number of messages used" alle 5 min. um 1 erhöht. Ebenfalls habe ich gesehen, dass "successful twin updates from device" alle 5 min. 1 ist. Durch Nachforschung und ausprobieren konnte ich durch die Umgebungsvariable "ConnectivityCheckFrequencySecs" in der edgeHub Konfiguration das Interval der reporteten Nachrichten beeinflussen. Wenn der Wert auf z.B. 7200 gesetzt ist, werden in den Metriken die Nachrichten nur noch alle 2 Std. aufgelistet.
So weit so gut. Aber bei der Recherche bin ich darauf gestoßen, dass der zyklische Connectivity Check gar nicht das Nachrichten-Kontingent des IOT-Hubs belasten sollte!
Wer weiß da etwas sicheres? Oder stellt die "total number of messages used" gar nicht die Anzahl der Nachrichten dar, die das Kontingent belasten?

Antwort, die vom Frageautor angenommen wurde

2 zusätzliche Antworten

Ihre Antwort

Answer 1

Hallo Andreas Froidl,

Willkommen bei Microsoft Q&A und vielen Dank für Ihre Anfrage.

Ich verstehe, dass Sie wissen möchten, ob das IoT Hub-Nachrichtenkontingent durch Verbindungsprüfungen beeinflusst wird und warum die Metrik „Gesamtzahl der verwendeten Nachrichten“ regelmäßig ansteigt. Ihre Beobachtungen sind berechtigt, und das beobachtete Verhalten ist zu erwarten, sobald der Unterschied zwischen Verbindungsprüfungen, Twin-Updates und Metriken klar ist.

Was wird auf das IoT Hub-Nachrichtenkontingent angerechnet (S1 – 400.000/Tag)?

Ihr S1 IoT Hub-Nachrichtenkontingent wird nur durch abrechnungsfähige Vorgänge verbraucht, darunter:

Gerät-zu-Cloud (D2C)-Telemetrienachrichten

Jeder 4-KB-Block zählt als eine Nachricht

Cloud-zu-Gerät (C2D)-Nachrichten

Gemeldete Twin-Updates von Geräten

Antworten direkter Methoden

Benachrichtigungen über Datei-Uploads

Zugestellte weitergeleitete Nachrichten

Diese Vorgänge tragen zu Ihrer tatsächlichen täglichen Nachrichtenkontingentnutzung bei.

Verbindungsprüfungen: Verbrauchen sie Kontingent?

Nein. Reine Verbindungsprüfungen (Keep-Alive-Signale, MQTT-Pings, AMQP-Verbindungswartung und interne IoT-Edge-Zustandsprüfungen) werden nicht auf Ihr Nachrichtenkontingent angerechnet und sind daher kostenlos.

Dies entspricht der Dokumentation und ist so vorgesehen.

Warum die Metriken alle 5 Minuten steigen

Die Verwirrung entsteht durch Folgendes:

„Gesamtzahl der verwendeten Nachrichten“ ist kein reiner Abrechnungszähler.

Bei IoT-Edge-Bereitstellungen führt die periodische Verbindungslogik im Rahmen der Zustandsprüfung häufig eine gemeldete Zwillingsaktualisierung durch. Daher wird Folgendes angezeigt:

Erfolgreiche Zwillingsaktualisierungen vom Gerät = 1

Die Gesamtzahl der verwendeten Nachrichten steigt im gleichen Intervall (standardmäßig ca. 5 Minuten).

Wichtiger Unterschied:

Verbindungsprüfung selbst → Nicht abgerechnet

Durch diese Prüfung ausgelöste gemeldete Zwillingsaktualisierung → Abgerechnet

Da gemeldete Zwillingsaktualisierungen abrechnungspflichtige Vorgänge sind, verbrauchen sie berechtigterweise Nachrichtenkontingent und erscheinen sowohl in den Metriken als auch in der Kontingentnutzung.

Warum die Änderung von ConnectivityCheckFrequencySecs funktioniert

Durch Erhöhung von:

ConnectivityCheckFrequencySecs = 7200

Sie haben Folgendes reduziert:

Die Häufigkeit gemeldeter Aktualisierungen von Zwillingsdaten

Die entsprechenden Erhöhungen der Gesamtzahl der verwendeten Nachrichten

Den tatsächlichen Verbrauch abrechnungsfähiger Nachrichten

Dies widerspricht nicht der Aussage, dass Verbindungsprüfungen kostenlos sind; es reduziert lediglich die Häufigkeit, mit der im Rahmen dieses Prozesses ein abrechnungsfähiger Schreibvorgang für Zwillingsdaten ausgelöst wird.

Metriken richtig verstehen

Gesamtzahl der verwendeten Nachrichten

Diese Metrik gibt die Gesamtzahl der vom IoT Hub erfassten logischen nachrichtenbezogenen Operationen an. Sie umfasst sowohl abrechnungspflichtige Operationen (wie Telemetrie- und Twin-Updates) als auch bestimmte interne oder dienstbezogene Operationen. Daher sollte sie nicht als direkter Indikator für abgerechnete Nachrichten verwendet werden.

Erfolgreiche Twin-Updates vom Gerät

Diese Metrik zählt die von Geräten an den IoT Hub gesendeten gemeldeten Eigenschaftsaktualisierungen. Diese Operationen sind abrechnungspflichtig und tragen zu Ihrem täglichen Nachrichtenkontingent bei.

Abgerechnete Nachrichten (Rechnung)

Die tatsächliche Anzahl der abgerechneten Nachrichten wird vom IoT Hub-Dienst separat berechnet und nur auf der Azure-Rechnung oder in der Kostenverwaltung angezeigt. Sie kann nicht exakt aus den einzelnen Metriken rekonstruiert werden.

Bitte beachten Sie Folgendes.

Ich hoffe, das hilft Ihnen weiter. Melden Sie sich gerne, falls Sie weitere Fragen haben.

Vielen Dank!

Answer 2

Andreas Froidl 20

Hello Srilakshmi,
thank you very much for your answer. I understood now and I think I will change the periode of connectivity check because it isn't really necessary in our application. We also have no need for very quick response if we (in very rare situation) need to reconfigure our devices via Twin update.
Thanks again for your answer.

SRILAKSHMI C 14,815 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-02-17T10:33:26.5733333+00:00

Hallo Andreas Froidl!

Vielen Dank für die Bestätigung der Lösung. Da ich meinen vorherigen Kommentar in eine Antwort umgewandelt habe, wäre ich Ihnen dankbar, wenn Sie diese kurz als akzeptiert markieren könnten. So können andere Community-Mitglieder mit der gleichen Frage die Lösung leichter finden. Vielen Dank!

Answer 3

Andreas Froidl 20

Hallo,
vielen Dank erstmal. Hat mir sehr weitergeholfen.
Aber Sie schreiben "Bei IoT-Edge-Bereitstellungen führt die periodische Verbindungslogik im Rahmen der Zustandsprüfung häufig eine gemeldete Zwillingsaktualisierung durch."

Das ist dann aber duch ziemlicher Quatsch. Die Verbindungsprüfung erfolgt alle 5min. Wenn die zwar selbst nicht das Kontingent belastet, aber dadurch eine Aktion ausgelöst wird, die das Kontingent belastet, dann braucht es doch einen vernünftigen und sicheren Weg, die Häufigleit der Kontingent-Belasteten Nachrichten zu reduzieren! Wenn jedes Gerät im Hub alle 5min. einen Connectivity Check macht und dadurch eine Zwillingsaktualisierung ausgelöst wird die das Kontingent Belastet, dann kann ich ja bei max. 400.000 Nachrichten pro Tag höchstens 1388 Geräte pro Hub betreiben! Nicht sehr wirtschaftlich.
Wie soll ich also einen Hub oder ein Gerät sinnvoll konfigurieren, dass nur Nachrichten versendet werden, wenn auch Nachrichten benötigt werden. Ein Zwillingsupdate brauch man höchstens 1x am Tag, so oft wird da nichts umkonfiguriert!

SRILAKSHMI C 14,815 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-02-12T04:58:22.2366667+00:00
Hello Andreas Froidl,

Thank you for the follow-up, and you’re absolutely right to question this from a scalability perspective.

Let me clarify something important:

A connectivity check itself does not require or inherently trigger a twin update at the IoT Hub level.

What you’re observing (a twin update every ~5 minutes) is specific to IoT Edge runtime behavior, particularly how the edgeHub module reports its health/status. That behavior is not required by IoT Hub, and it is configurable.

Key Clarification

IoT Hub does not force a twin update during connectivity checks.

MQTT keep-alives and AMQP heartbeats are free and do not consume quota.

The periodic twin update is coming from the IoT Edge runtime, not from IoT Hub.

So your math (400,000 / 288 per device per day ≈ 1388 devices) would only apply if every device were forced to send 5-minute twin updates which is not required behavior.

Why you’re seeing a twin update every 5 minutes

In IoT Edge:

edgeHub performs connectivity/health checks

It reports certain runtime properties via reported properties

That reported property write is a billable twin update

This is meant for monitoring, but it is not mandatory at that frequency.

How to configure this sensibly

If your use case does not require frequent twin updates, you have several options:

Increase ConnectivityCheckFrequencySecs (which you already tested)

This reduces how often edgeHub reports health status.

For example:

7200 seconds (2 hours)

86400 seconds (once per day)

If you only need daily reporting, setting it to 86400 is reasonable.

Review whether IoT Edge is required

If your devices:

Do not need local module orchestration

Do not need offline routing

Do not require edge deployments

Then using a non-Edge device client avoids this periodic twin update behavior entirely.

Standard device SDKs:

Do not send twin updates unless your application code does

Only consume quota when you explicitly send telemetry or update twin

Only update twin when configuration actually changes

Best practice is:

Send reported twin properties only when state changes

Avoid periodic “heartbeat” twin writes

Use telemetry for health signals if needed (smaller and more controllable)

Economical scaling perspective

In a properly optimized setup:

Connectivity checks → free

Twin updates → only when configuration/state changes

Telemetry → only when required

It is absolutely possible to operate tens of thousands of devices on S1 without burning quota on unnecessary twin updates.

The 5-minute twin update pattern is a runtime default for monitoring — not a quota requirement.

Recommendation

If you:

Only need twin updates once per day,

Do not rely on frequent edge health reporting,

Then setting:

ConnectivityCheckFrequencySecs = 86400

is completely reasonable.

Alternatively, disable or reduce health reporting logic if operationally acceptable.

IoT Hub is not designed in a way that forces uneconomical scaling. What you’re observing is configurable runtime behavior, not a structural quota trap.

Thank you!
SRILAKSHMI C 14,815 Zuverlässigkeitspunkte Externe Microsoft-Mitarbeiter Moderator

2026-02-13T01:49:29.7733333+00:00

Hi Andreas Froidl,

Did you get any chance to review the above response. Do let me know if you have any further queries.

Thank you!

Freigeben über

Welche Nachrichten an den IoT-Hub belasten das Kontingent? Gehören da auch die Connectivity Checks dazu?

2 zusätzliche Antworten

Ihre Antwort