Azure Load Testing: der Microsoft-Dienst im Überblick

Azure Load Testing ist der verwaltete Dienst von Microsoft, um JMeter- und Locust-Tests in großem Maßstab aus Azure auszuführen, abgerechnet pro virtueller Benutzerstunde. Er passt gut, wenn das getestete System auf Azure läuft, denn er kann Servermetriken aus Azure Monitor holen und private Endpunkte in einem virtuellen Netzwerk erreichen. Teams, die k6-Skripte schreiben, kein Azure-Abonnement haben oder von außerhalb der Azure-Regionen testen wollen, finden andere Dienste einfacher.

Wir haben Azure Load Testing für dieses Review nicht selbst ausgeführt. Die Fakten stammen aus der Dokumentation und der Preisseite von Microsoft, geprüft am 19. Oktober 2026; die Einschätzungen sind unsere eigenen.

Was ist Azure Load Testing?

Ein vollständig verwalteter Dienst, der Ihren Lasttest auf Test-Engines von Microsoft ausführt, sodass Sie nie Lastgeneratoren aufbauen oder patchen. Sie legen in einer gewählten Azure-Region eine Load-Testing-Ressource an, fügen ihr Tests hinzu und starten Läufe aus dem Portal, der Azure CLI oder einer Pipeline.

Laut Übersichtsseite kann die getestete Anwendung überall laufen: in Azure, on-premises oder in einer anderen Cloud. Microsoft führt den Dienst inzwischen im Azure-App-Testing-Hub neben Playwright Workspaces; der Locust-Schnellstart legt die Ressource über diesen Hub an (geprüft am 19. Oktober 2026).

Welche Testarten und Tools unterstützt er?

Drei Wege: ein URL-basierter Schnelltest, ein hochgeladenes JMeter-Skript oder ein hochgeladenes Locust-Skript. Die Dokumentation sagt klar, dass kein anderes Test-Framework unterstützt wird.

Der Schnelltest nimmt bis zu fünf HTTP-Anfragen und eine Zielzahl virtueller Benutzer oder Anfragen pro Sekunde. Jede Engine bewältigt bis zu 250 virtuelle Benutzer, 400 Benutzer laufen also auf zwei Engines mit je 200.

Mit JMeter können Sie Plugins von jmeter-plugins.org nutzen oder eigene hochladen, und laut Übersicht funktioniert jedes Protokoll, das JMeter unterstützt, etwa eine Datenbankverbindung oder eine Message Queue. Mit Locust können Sie Locust-Plugins und andere Python-Bibliotheken hinzufügen. Die Locust-Dokumentation verweist selbst auf den Dienst als gehostete Option, und unser Locust-Review behandelt das Tool selbst. k6-, Gatling- und Artillery-Skripte laufen hier nicht (geprüft am 19. Oktober 2026).

Wie funktionieren Engines, virtuelle Benutzer und Limits?

Sie skalieren einen Test, indem Sie Engine-Instanzen hinzufügen. Bei JMeter ist die Gesamtlast die Zahl der Benutzer im Testplan mal die Zahl der Engines; bei Locust legen Sie die Gesamtzahl der Benutzer fest und wählen, wie viele Engines sie erzeugen.

Die Konzeptseite nennt beide Formeln, und die Seite zu den Dienstlimits legt die Obergrenzen pro Region und Abonnement fest (geprüft am 19. Oktober 2026):

• Engine-Instanzen pro Testlauf: standardmäßig 1 bis 400 je nach Angebot, höchstens 400.
• Gleichzeitige Engine-Instanzen: standardmäßig 5 bis 400, auf Anfrage bis 1.000.
• Testdauer: standardmäßig 3 bis 24 Stunden, höchstens 24 Stunden.
• Fehlerkriterien: bis zu 50 pro Test.
• Aufbewahrung: serverseitige Metriken 90 Tage, clientseitige Metriken 365 Tage, Testergebnisse und Logs 6 Monate.

Ein höheres Standardlimit erfordert eine Supportanfrage; über die genannten Maximalwerte geht nichts hinaus.

Kann er private Endpunkte testen und Last aus mehreren Regionen erzeugen?

Ja, beides, mit einem Haken: Es lässt sich nicht kombinieren. Last aus mehreren Regionen funktioniert nur gegen öffentliche Endpunkte.

Standardmäßig laufen die Engines in der Region Ihrer Load-Testing-Ressource. Mit der Anleitung für mehrere Regionen wählen Sie bis zu 5 Regionen pro Test und verteilen die Last auf sie, und der Test wird dabei auf öffentlichen Verkehr umgestellt. Für Dienste ohne öffentlichen Endpunkt platziert die VNet-Injektion die Engines in dem Netzwerk, das die Anwendung enthält (geprüft am 19. Oktober 2026).

Was zeigen die Ergebnisse und Servermetriken?

Das Dashboard zeigt während des Laufs live clientseitige Metriken wie virtuelle Benutzer, Antwortzeit und Anfragen pro Sekunde. Für Apps auf Azure kommen serverseitige Metriken aus Azure Monitor, Application Insights und Container Insights auf derselben Zeitachse hinzu.

Diese Kombination ist der größte Vorteil des Dienstes: Sie sehen die Datenbank oder den Container, der genau dann an seine Grenze kommt, wenn die Antwortzeiten steigen, ohne ein separates Dashboard zu bauen. Die Anleitung zu serverseitigen Metriken beschreibt die Schritte. Frühere Läufe lassen sich nebeneinander vergleichen, und Sie können Ergebnisse für andere Tools herunterladen.

Wie funktionieren Pass/Fail-Kriterien und CI?

Sie setzen Fehlerkriterien auf Client- oder Servermetriken, und der Lauf gilt als fehlgeschlagen, sobald eines verletzt ist. Pipelines in Azure DevOps, GitHub Actions oder jedem CI-Tool, das die Azure CLI aufrufen kann, können einen Test starten und auf dieses Ergebnis prüfen.

Laut Anleitung zu Fehlerkriterien ist ein Kriterium ein Aggregat einer Clientmetrik, etwa durchschnittliche Antwortzeit oder Fehleranteil, verglichen mit einem Schwellenwert, entweder für den ganzen Test oder für eine benannte Anfrage. Für Servermetriken braucht die Ressource eine verwaltete Identität mit Lesezugriff. Auto-Stop beendet einen Lauf, wenn die Fehlerrate ein Limit überschreitet, damit eine falsche URL nicht weiter kostet. Die CI/CD-Anleitung behandelt GitHub Actions und Azure Pipelines (geprüft am 19. Oktober 2026). Unser Leitfaden zu Pass/Fail-Kriterien für Lasttests erklärt, wie Sie die Limits wählen.

Was kostet Azure Load Testing?

Sie zahlen pro virtueller Benutzerstunde (VUH): 0,15 $ pro VUH für die ersten 10.000 VUH und 0,06 $ pro VUH danach, in jeder Region der Preisseite gleich. Seit dem 1. März 2026 gibt es zudem eine Mindestgebühr pro Testlauf.

Die Preisseite definiert eine VUH als virtuelle Benutzer mal Minuten, geteilt durch 60, gezählt alle 10 Sekunden; 1.000 Benutzer für 30 Minuten sind 500 VUH, also 75 $ zum Preis der ersten Stufe. Das Minimum sind 10 virtuelle Benutzer pro Engine für die Dauer des Laufs, mindestens 10 Minuten. Ein 3-stündiger Lauf mit 5 Benutzern auf einer Engine wird daher mit 30 VUH abgerechnet statt mit 15 (geprüft am 19. Oktober 2026).

Wann sollten Sie etwas anderes wählen?

Wählen Sie eine andere Option, wenn Ihre Skripte, Ihre Cloud oder Ihr Budget woandershin zeigen.

Unser Überblick über Open-Source-Lasttest-Tools behandelt die Tools, die Sie selbst betreiben können.

Wählen Sie stattdessen LoadFocus, den Herausgeber dieser Website, wenn Sie JMeter-Testpläne und k6-Skripte ohne Azure-Abonnement aus 25 Cloud-Regionen ausführen wollen. LoadFocus führt kein Locust aus und fährt k6-Arrival-Rate-Szenarien mit einer festen Zahl von Benutzern.

Wählen Sie stattdessen Grafana Cloud k6 oder den k6-operator, wenn Ihre Tests für k6 geschrieben sind, das Azure Load Testing nicht ausführen kann (geprüft am 19. Oktober 2026).

Wählen Sie stattdessen selbst betriebenes Locust, wenn Sie bereits Kubernetes oder freie Maschinen haben: Sein verteilter Modus ist kostenlos, und Sie zahlen nur die Hardware.

FAQ

Unterstützt Azure Load Testing k6? Nein. Er führt Apache-JMeter- und Locust-Tests aus, dazu URL-basierte Schnelltests, aus denen er selbst ein Skript erzeugt. k6-Skripte brauchen einen anderen Dienst oder eigene Infrastruktur.

Kann ich Azure Load Testing für eine App nutzen, die nicht auf Azure läuft? Ja. Die Test-Engines können jeden öffentlichen Endpunkt ansprechen. Serverseitige Metriken werden nur für Azure-Ressourcen erfasst, bei anderem Hosting lesen Sie Servermetriken aus Ihrem eigenen Monitoring.

Gibt es eine kostenlose Stufe? Die Preisseite nennt für Lasttests nur Preise pro Stunde, mit einem Minimum pro Testlauf. Neue Azure-Konten erhalten laut derselben Seite für die ersten 30 Tage ein Guthaben von 200 $.

Weiterlesen

• Locust-Lasttests: das Python-Tool im Überblick
• Open-Source-Lasttest-Tools: sechs Optionen im Überblick
• Pass/Fail-Kriterien für Lasttests: so legen Sie sie fest
• Locust vs JMeter: Python-Skripte oder JMeter-Testpläne?
• Lasttests in GitHub Actions: ein praktischer Leitfaden

Die technischen Aussagen in diesem Artikel wurden nicht unabhängig geprüft.