📌 Language Version: Read this article in English

Hitzefrei für den Bereitschaftsdienst: Der Azure SRE Agent übernimmt die Schicht

1. Einleitung: Warum dieser Artikel, warum jetzt

Draußen sind es 35 Grad, das Büro ist leer und eigentlich wäre jetzt der perfekte Zeitpunkt für einen freien Tag. Wäre da nicht das bekannte Problem: Jemand muss Bereitschaft haben. Jemand muss auf Warnmeldungen reagieren. Jemand muss um 14 Uhr Logs durchforsten, während alle anderen Eis essen gehen. Was wäre, wenn dieser Jemand eine KI wäre?

Mit dem Azure SRE Agent hat Microsoft im März 2026 genau das allgemein verfügbar gemacht: einen autonomen digitalen Site Reliability Engineer, der Incidents untersucht, Ursachen analysiert und, abhängig von der Konfiguration, selbst Maßnahmen ergreift. Keine Preview mehr, kein Spiel mit Wartelisten. General Availability. Und damit ist es an der Zeit, sich dieses Ding ernsthaft anzusehen.

In diesem Artikel zeige ich dir, was der Azure SRE Agent tatsächlich kann, wie du ihn in einer typischen Enterprise-Landschaft bereitstellst, was er aus Sicht von Identität und Governance bedeutet und welche konkreten Kosten entstehen.

2. Was ist der Azure SRE Agent?

Wer zum ersten Mal „Azure SRE Agent“ hört, denkt meist an ein weiteres Monitoring-Dashboard mit einem KI-Aufkleber. Genau das ist er nicht.

Der Azure SRE Agent ist ein autonomes System, das kontinuierlich im Hintergrund läuft, Telemetriedaten auswertet und bei einem Incident nicht nur eine Benachrichtigung versendet, sondern selbst mit der Arbeit beginnt. Er analysiert Ursachen, prüft Hypothesen und stellt Zusammenhänge zwischen Deployments und Fehlern her, ohne dass jemand ein Chatfenster öffnen muss.

Die Root Cause Analysis ist der Kern. Der Agent korreliert Logs, Metriken und Serviceabhängigkeiten über mehrere Ebenen hinweg: Anwendung, Plattform und Infrastruktur. Das Ergebnis erklärt er klar und nachvollziehbar. Nicht „Hier sind 47 Logzeilen, viel Glück“, sondern eine strukturierte Diagnose mit einer konkreten Empfehlung.

Persistent Memory bedeutet, dass der Agent aus jeder Untersuchung lernt. Er baut eine eigene Wissensbasis auf: Ursachen, erfolgreiche Lösungswege und bekannte Muster in deiner Umgebung. Tritt ein ähnlicher Incident erneut auf, greift er auf dieses Wissen zurück. Das Erfahrungswissen, das sonst nur im Kopf des erfahrensten Teammitglieds steckt, wird systematisch verfügbar.

Background Intelligence läuft auch dann, wenn niemand aktiv mit dem Agent interagiert. Der Agent analysiert deinen Quellcode, deine Deployment-Konfigurationen und deine Betriebshistorie kontinuierlich im Hintergrund. Wenn ein Incident eintritt, ist der Kontext bereits geladen. Es gibt kein Cold-Start-Problem.

Das ist kein Konzept. Microsoft betreibt den SRE Agent seit über einem Jahr intern in der Produktion: mehr als 1.300 bereitgestellte Agents, über 35.000 entschärfte Incidents und mehr als 20.000 eingesparte Engineering-Stunden pro Monat. Seit März 2026 steht dieselbe Plattform allen Azure-Kunden zur Verfügung.

Wie autonom soll der Agent arbeiten? Das entscheidest du. Der Agent unterstützt zwei Modi. Im Review Mode schlägt er Aktionen vor und wartet auf deine Freigabe. Du siehst genau, welcher Azure-CLI-Aufruf auf welcher Ressource ausgeführt wird, bestätigst ihn und erst dann passiert etwas. Volle Kontrolle, volle Transparenz. Im Autonomous Mode handelt der Agent innerhalb festgelegter Guardrails selbstständig. Service-Neustarts, Skalierungen und Rollbacks erfolgen, ohne dass jemand um 3 Uhr morgens aufstehen muss.

Ich empfehle immer, mit dem Review Mode zu beginnen. Nicht, weil der Agent unzuverlässig wäre, sondern weil du zunächst ein Gefühl für sein Verhalten in deiner konkreten Umgebung entwickeln solltest, bevor du ihm die Schlüssel übergibst.

3. Architektur: Wie sich der Agent in deine Azure-Landschaft einfügt

Bevor du auf „Deploy“ klickst, lohnt sich ein kurzer Blick auf das Architekturprinzip. Der Azure SRE Agent folgt einer klaren Trennung der Verantwortlichkeiten, die du von Anfang an sauber umsetzen solltest.

Der Agent selbst befindet sich in einer Subscription, idealerweise in einer dedizierten Management- oder Plattform-Subscription. Von dort aus überwacht und verwaltet er Ressourcen in beliebig vielen weiteren Subscriptions. In der Praxis sieht das so aus:

Der Vorteil dieses Musters: Die Agent-Infrastruktur ist sauber von den verwalteten Workloads getrennt. Lebenszyklus, Kosten und Governance lassen sich unabhängig steuern. Außerdem vermeidest du, dass sich der Agent in derselben Subscription wie die Systeme befindet, die er überwachen soll. Das kann während eines Incidents schnell zum Problem werden.

Die Serviceabdeckung ist bereits heute sehr breit. Compute umfasst VMs, App Service, Container Apps, AKS und Functions. Storage umfasst Blob Storage, File Shares und Managed Disks. Im Netzwerkbereich werden VNets, Load Balancer, Application Gateways und NSGs unterstützt. Bei Datenbanken gehören Azure SQL, Cosmos DB, PostgreSQL, MySQL und Redis dazu. Der Zugriff erfolgt über Azure CLI und REST APIs. Für hybride Umgebungen besteht außerdem die Möglichkeit, lokale Workloads über Azure Arc anzubinden.

Das ist in der Praxis der häufigste Blocker beim Onboarding, deshalb sage ich es direkt: Ohne eine solide Monitoring-Baseline arbeitet der Agent nicht sinnvoll. Konkret bedeutet das: Azure Monitor muss für die Ziel-Workloads aktiv sein, Diagnostic Settings müssen Logs und Metriken an einen Log Analytics Workspace senden und Application Insights sollte für die anwendungsseitige Telemetrie integriert sein. Während der Einrichtung stellt der Agent automatisch einen eigenen Log Analytics Workspace und Application Insights in seiner Resource Group bereit. Das ersetzt jedoch nicht die Diagnostic Settings deiner Workload-Ressourcen. Darum musst du dich selbst kümmern. Wer hier Abkürzungen nimmt, erhält einen Agent, der zwar läuft, bei einer RCA aber im Dunkeln herumstochert.

Für europäische Kundenprojekte ist Sweden Central die naheliegende Wahl für die Control-Plane-Region. DSGVO-konform und durch die Microsoft EU Data Boundary abgedeckt. Wer Anforderungen an eine souveräne Cloud hat: Darauf gehe ich im Fazit ein, denn dort gibt es weiterhin offene Fragen.

Was viele auf den ersten Blick übersehen: Der Agent ist kein geschlossenes System. Über MCP Connectors lässt er sich mit externen Systemen wie ServiceNow, PagerDuty, Jira, Datadog und Splunk verbinden. Über benutzerdefinierte Python Tools können außerdem interne HTTP-Endpunkte integriert werden. Damit wird der Agent zur Intelligenzschicht über bestehenden Operations-Toolchains und ersetzt sie nicht.

4. Bereitstellung Schritt für Schritt

Der Einstiegspunkt ist sre.azure.com, nicht das Azure Portal. Das sorgt beim ersten Mal regelmäßig für Verwirrung.

Bevor du dort auf „Create agent“ klickst, solltest du drei Dinge klären. Du benötigst Owner oder User Access Administrator auf der Management-Subscription und auf der Ziel-Subscription. Der Assistent weist der Managed Identity automatisch RBAC-Rollen zu. Ohne diese Berechtigungen schlägt die Bereitstellung fehl. Außerdem musst du den Resource Provider einmalig registrieren:

az provider register \\
  --namespace Microsoft.SREAgent \\
  --subscription <management-sub-id>

Wenn du einen Unternehmensproxy oder Azure Firewall verwendest, muss *.azuresre.ai ausgehend über HTTPS erreichbar sein. Dieser Punkt wird regelmäßig vergessen.

Im Assistenten solltest du eine Entscheidung bewusst treffen: Unter „Azure Resources“ wählst du die Ziel-Subscription als Ganzes aus, nicht einzelne Resource Groups. Dadurch erhält der Agent den umfassendsten Blick auf die verwaltete Umgebung und stößt während einer Untersuchung nicht an Subscription-Grenzen. Der Assistent zeigt transparent an, welche RBAC-Rollen automatisch zugewiesen werden: Log Analytics Reader, Monitoring Reader, AKS Cluster User und weitere Rollen, abhängig von den vorhandenen Services.

Region: Sweden Central. DSGVO-konform, durch die EU Data Boundary abgedeckt und damit die naheliegende Wahl für europäische Kundenprojekte.

Die Bereitstellung dauert 2 bis 5 Minuten. Anschließend befinden sich folgende Ressourcen in deiner Resource Group:

Direkt nach der Bereitstellung folgen zwei kurze Smoke Tests im Chat. Erster Test, Zugriff prüfen:

Welche Subscriptions und Resource Groups kannst du aktuell sehen?

Der Agent sollte die Ziel-Subscription mit allen Resource Groups auflisten. Wenn das funktioniert, ist das Subscription-übergreifende RBAC korrekt konfiguriert. Zweiter Test:

Gib mir einen Überblick über den Integritätsstatus aller Ressourcen in der Ziel-Subscription.

Hier siehst du zum ersten Mal, wie der Agent Telemetriedaten aggregiert und darstellt. Gleichzeitig erkennst du sofort, an welchen Stellen noch Lücken in deiner Monitoring-Baseline bestehen.

5. Identität und Governance: Was Architekten wissen müssen

Sobald du den Azure SRE Agent in einer Enterprise-Umgebung einführst, stellt das Security-Team die Frage: „Welche Identität besitzt der Agent, wo ist sie sichtbar und welche Berechtigungen hat sie?“

Die Antwort überrascht regelmäßig: Während der Bereitstellung werden automatisch zwei Managed Identities erstellt. Die erste ist die User Assigned Managed Identity (UAMI). Mit dieser Identität arbeitest du. Sie befindet sich als eigenständige Ressource in deiner Resource Group (id-sre-agent-prod), du weist ihr RBAC-Rollen zu und der Assistent referenziert sie beim Einrichten von Connectors. Die zweite ist eine systeminterne Identität für Plattformvorgänge. Diese kannst du ignorieren.

Der häufigste Fehler beim ersten Onboarding: In den App Registrations im Entra Admin Center nach dem Agent zu suchen. Dort wird er nicht angezeigt, und das ist korrekt. Managed Identities sind keine App Registrations. Die richtige Stelle ist Entra Admin Center → Enterprise Applications, allerdings nur mit einem expliziten Filter: Application type == Managed Identities. Ohne diesen Filter sind sie in der Liste nicht sichtbar. Alternativ findest du die UAMI direkt als eigenständige Ressource in der Resource Group. Oder du öffnest unter sre.azure.com den Bereich Settings → Azure settings. Dort gibt es den direkten Link „Go to Identity“.

Was viele nicht auf dem Schirm haben: Der Agent erscheint in den Non-interactive Sign-in Logs, wenn er Token für Azure-API-Aufrufe abruft. Für Kunden mit strengen Compliance-Anforderungen, etwa DORA oder ISO 27001, ist das ein relevanter Punkt, der aktiv kommuniziert werden sollte. So lässt sich genau nachvollziehen, wann der Agent auf welche Ressourcen zugegriffen hat.

Für die RBAC-Konfiguration gilt ab dem ersten Tag das Least-Privilege-Prinzip. Der Assistent weist während des Onboardings automatisch Leseberechtigungen auf der Ziel-Subscription zu. Für den Review Mode ist das ausreichend. Sobald du den Autonomous Mode für bestimmte Aktionen aktivieren möchtest, darfst du Contributor niemals auf Subscription-Ebene zuweisen. Begrenze den Scope immer auf die Resource Groups, in denen der Agent tatsächlich eingreifen muss, und verwende stets die spezifischste Rolle, die den Anwendungsfall abdeckt. Für Neustarts von App Services beispielsweise Website Contributor, nicht Contributor für die gesamte Subscription.

Ein Sicherheitshinweis, den du kennen solltest: Im April 2026 hat Microsoft einen Scoping-Fehler in der Entra-ID-Rolle Agent ID Administrator behoben. Der Fix war bis zum 9. April vollständig ausgerollt, eine manuelle Aktion war nicht erforderlich. Du solltest jedoch prüfen, wer diese Rolle in deiner Organisation besitzt. Die Rolle sollte PIM-berechtigt und nicht dauerhaft zugewiesen sein.

Zum Thema Entra Agent ID, dem neuen Identitätskonzept hinter Agent-Identitäten allgemein, schreibe ich einen separaten Artikel. Das Thema verdient mehr Tiefe, als ein einzelner Abschnitt bieten kann.

6. Wissen und Memory: Was der Agent weiß und behält

Ein frisch bereitgestellter Azure SRE Agent ist wie ein neuer Kollege am ersten Arbeitstag: technisch kompetent, aber ohne Kontextwissen zu deiner konkreten Umgebung. Er kennt Azure, die APIs und Best Practices. Er weiß aber nicht, wie deine Anwendung aufgebaut ist, welche Incidents in der Vergangenheit aufgetreten sind oder welche Workarounds dein Team bereits etabliert hat. Das ändert sich, allerdings nur, wenn du aktiv daran arbeitest.

Das Memory des Agent liegt auf der von Microsoft verwalteten SRE-Agent-Plattform, nicht in deiner Subscription. In deiner Resource Group gibt es kein Storage Account, das du direkt untersuchen oder exportieren kannst. Bei DSGVO-sensiblen Projekten wird dieser Punkt in Sicherheitsbewertungen zur Sprache kommen. Ähnlich wie bei Copilot Studio akzeptierst du, dass bestimmte Inhalte deine eigene Plattforminfrastruktur verlassen. Wer Runbooks mit internen Zugangsdaten oder architektonisch sensiblen Details füllt, sollte das berücksichtigen.

Inhalt	Speicherort	Deine Kontrolle
Runbooks / Troubleshooting Guides	SRE-Agent-Plattform (verwaltet)	Upload / Löschen im Portal
SREAGENT.md	Dein GitHub- / Azure-DevOps-Repository	Volle Kontrolle
Session-Dateien	Temporärer Agent-Arbeitsbereich	Nur während des Threads
Persistent Memory (Insights)	SRE-Agent-Plattform (verwaltet)	Nicht exportierbar

Sobald du ein Code-Repository verbindest, passiert etwas Interessantes: Der Agent analysiert Projektstruktur, Tech Stack, Deployment-Konfigurationen und Serviceabhängigkeiten. Anschließend erstellt er eine SREAGENT.md als Pull Request in deinem Repository. Darin dokumentiert er sein erstes Verständnis deiner Architektur, in Markdown und versioniert. Prüfe den PR, passe ihn an und merge ihn. Der Inhalt beeinflusst direkt, wie präzise der Agent bei zukünftigen Untersuchungen arbeitet.

Unter Builder → Knowledge base verwaltest du alle weiteren Wissensquellen: hochgeladene Dateien, Webseiten per URL und verbundene Repositories. Mein empfohlener Ansatz: Erstelle ein dediziertes sre-runbooks-Repository, pflege dort alle relevanten Runbooks, Postmortems und Architekturdokumente als Markdown und binde dieses Repository als Wissensquelle in den Agent ein. Git-Versionierung, PR-Review-Prozess und Audit Trail sind damit enthalten. Gleichzeitig kann der Agent jederzeit semantisch in allen Inhalten suchen.

Der eleganteste Workflow entsteht, wenn du den Agent direkt nach einer erfolgreichen Untersuchung damit beauftragst, das Gelernte zu sichern:

Erstelle aus den Schritten, die wir gerade durchgeführt haben, einen Troubleshooting Guide und speichere ihn in den Knowledge Settings.

Der Agent erstellt ein strukturiertes Dokument, lädt es hoch und indexiert es automatisch. Beim nächsten ähnlichen Incident findet er diesen Guide und arbeitet damit. Im Laufe der Zeit entsteht eine Wissensbasis, die tatsächlich aus deiner Umgebung stammt und nicht aus generischen Best Practices. In den ersten Wochen verfügt der Agent noch über wenig Kontext. Nach zwei bis drei Monaten aktiver Nutzung und konsequentem Wissensaufbau ändert sich das spürbar. Genau dann wird der ROI greifbar.

7. Kosten: Transparent berechnet

Das Preismodell des Azure SRE Agent ist transparent. Es enthält jedoch eine fixe Kostenkomponente, die unabhängig von der tatsächlichen Nutzung anfällt. Das solltest du wissen, bevor du deinen ersten Agent erstellst. Die Abrechnung basiert auf Azure Agent Units (AAU), einer standardisierten Einheit, die Microsoft für alle vorkonfigurierten Azure Agents eingeführt hat. Deine monatliche Rechnung besteht immer aus zwei Teilen: einem festen Always-on Flow und einem variablen, tokenbasierten Active Flow.

Der Always-on Flow läuft ab dem Moment, in dem der Agent erstellt wird: 4 AAU pro Stunde, unabhängig davon, ob der Agent tatsächlich etwas tut. Bei einem AAU-Preis von 0,10 US-Dollar ergeben sich 297,60 US-Dollar pro Monat und Agent. Selbst ein gestoppter Agent verursacht weiterhin diese Kosten. Erst das Löschen des Agent beendet die Abrechnung vollständig. Für PoC-Phasen bedeutet das: Nach Abschluss des Tests konsequent löschen.

Der Active Flow ist tokenbasiert und hängt direkt vom gewählten Modell ab. Hier liegt der größte Kostenhebel:

Szenario	Claude Opus 4.6	GPT 5.3 Codex
Kurze Frage	ca. 0,38 US-Dollar	ca. 0,16 US-Dollar
Incident-Untersuchung	ca. 3,55 US-Dollar	ca. 1,37 US-Dollar
Vollständige Remediation	ca. 8,65 US-Dollar	ca. 3,39 US-Dollar
Fixkosten pro Monat (Always-on)	297,60 US-Dollar	297,60 US-Dollar

Claude Opus 4.6 ist bei der Ausgabe ungefähr dreimal so teuer wie GPT 5.3 Codex. Für Standardszenarien wie Incident-Untersuchungen, Service-Health-Checks und routinemäßige Remediations ist GPT die kosteneffizientere Wahl. Claude ist sinnvoll, wenn du sehr komplexe, mehrstufige Reasoning-Aufgaben hast. GPT 5.3 Codex unterstützt kein Prompt Caching. Deshalb erscheint auf der Rechnung kein Posten für Cache Writes.

Was das in der Praxis bedeutet: Eine vollständige automatisierte Incident-Untersuchung mit GPT kostet rund 1,37 US-Dollar. Das ist weniger als fünf Minuten Arbeitszeit eines Engineers bei einem typischen Enterprise-Tagessatz. Dieses Argument zählt, wenn der Business Case intern diskutiert wird.

Die weiteren relevanten Kostenhebel in Kürze: Ein Agent für mehrere Subscriptions spart im Vergleich zu mehreren Agents die Fixkosten jedes zusätzlichen Agent. Response Plans stellen sicher, dass nicht jede Azure-Monitor-Warnung eine vollständige Untersuchung auslöst. Unter Settings → Agent consumption kannst du außerdem ein monatliches Active-Flow-Limit festlegen. Sobald es erreicht ist, friert der Agent Chat und autonome Aktionen ein, während Always-on weiterläuft. Für den Einstieg ist das immer zu empfehlen.

Ein Hinweis für europäische Leser: Alle oben genannten Preise sind in US-Dollar angegeben. Der aktuelle Gegenwert in Euro variiert je nach Region und Art des Enterprise Agreement. Prüfe vor der Erstellung deines Business Case den aktuellen Preis für deine Region im Azure Pricing Calculator.

8. Fazit und persönliche Einschätzung

Hitzefrei gibt es eigentlich nur für Schulkinder. Die Idee dahinter, den reaktiven Modus zu verlassen und Raum für das Wesentliche zu schaffen, beschreibt jedoch ziemlich genau, worum es beim Azure SRE Agent geht.

In den vergangenen Jahren habe ich viele Ankündigungen zu „AI for Ops“ gesehen, die in der Praxis wenig geliefert haben. Der Azure SRE Agent ist anders. Nicht, weil er perfekt wäre, sondern weil Microsoft ihn intern in der Produktion einsetzt und die Zahlen real sind. Das verleiht dem Produkt eine Glaubwürdigkeit, die vielen Ankündigungen in diesem Bereich fehlt.

Mich persönlich überzeugt das Zusammenspiel aus autonomem Handeln und expliziter Governance. Der Review Mode ist kein eingeschränkter Modus, sondern der richtige Ausgangspunkt. Du lernst das Verhalten des Agent in deiner eigenen Umgebung kennen, baust Vertrauen auf und gewährst schrittweise mehr Autonomie. So gehst du verantwortungsvoll mit KI-Agents in der Produktion um.

Wo ich heute noch vorsichtig wäre: Anforderungen an souveräne Clouds wie Delos oder StackIT müssen vorab mit dem Microsoft Account Team geklärt werden. Die verfügbaren Control-Plane-Regionen sind derzeit noch begrenzt. Auch für hybride Umgebungen mit klassischem Active Directory und Kerberos-abhängigen Anwendungen ist der Agent noch nicht die richtige Antwort. Für reine Azure-Workloads gilt das nicht. Dort ist er heute produktionsreif.

Auf der Roadmap stehen VNet Integration für abgeschottete Netzwerkumgebungen und erweiterte Governance-Kontrollen über Hooks. Beide Punkte sind für Enterprise-Bereitstellungen relevant und von mir für einen Folgeartikel vorgemerkt.

---

Hinweis: Dieser Artikel entstand im Rahmen der #Hitzefrei-Kampagne — eine Community-Initiative für KI in Operations und Reliabilität.

Der Agent schwitzt. Du musst es nicht mehr. Zumindest nicht wegen Incidents.