Entwicklung eines autonomen AWS SRE Copilot mit MCP, Bedrock Nova und menschlicher Freigabe.

Seit etwa einem Jahr konzentriert sich die Branche auf ChatOps: Das Hinzufügen von LLMs zu Slack oder Telegram als clevere Umhüllungen um CI/CD-Pipelines. Chatbots sind jedoch nur die sichtbare Spitze des Eisbergs. Der eigentliche Unternehmenswert entsteht durch den Übergang von reaktiven Chatbots zu autonomen Agenten. Ein autonomer Site Reliability Engineering (SRE)-Copilot, der auf Amazon Bedrock (Nova), dem Model Context Protocol (MCP) und AWS basiert, zeigt, wie das aussehen kann. Er tut mehr als nur Pipelines auszulösen – er untersucht eigenständig aktuelle Produktionsvorfälle, zieht Metriken und Protokolle heran, ermittelt die Ursachen und wendet Korrekturen an, alles innerhalb einer sicheren Vertrauensgrenze mit menschlicher Beteiligung.

Die verwaltete Lösung: AWS DevOps Agent

Vor dem Entwickeln von etwas Speziellem sollte ein Architekt prüfen, ob AWS dies bereits anbietet. Tatsächlich bietet AWS eine solche Lösung – wenn auch in einer bestimmten Form. AWS führte den DevOps Agent auf der re:Invent 2025 ein, stellte ihn ab Dezember 2025 in einer Vorabversion zur Verfügung und machte ihn ab März 2026 allgemein verfügbar. Es handelt sich um ein leistungsstarkes Mehr-Agenten-System, das auf eine autonome Reaktion auf Vorfälle in AWS abzielt.

Es geht dabei weit über ältere Tools wie DevOps Guru hinaus:

• Autonome Reaktion auf Vorfälle. Ein ausgelöster CloudWatch-Alarm startet eine Untersuchung, bei der Telemetriedaten, Protokolle, Spuren, Codeänderungen sowie Bereitstellungsverläufe miteinander verglichen werden, um die Ursache zu ermitteln und Maßnahmen zur Beseitigung vorzuschlagen.
• Proaktive Prävention. Das System analysiert historische Muster von Vorfällen und schlägt Verbesserungen in Bezug auf die Überwachungsfähigkeit, die Infrastruktur sowie die Arbeitsabläufe vor.

Prüfungen auf Bereitschaft für die Veröffentlichung. Es überprüft Codeänderungen sowie Deployment-Pipelines, bevor sie in die Produktion gelangen.

Mehre-Agenten-Design. Ein leitender Orchesterator steuert spezialisierte Unteragenten für Aufgaben wie Log-Analyse und Ursachenforschung – dasselbe Muster wird auch bei dieser Implementierung verwendet.

Weite Integrationen. Datadog, Dynatrace, New Relic, Splunk, PagerDuty, GitHub, GitLab, ServiceNow und Slack sind direkt integrierbar.

Ursprünglich deckt es alles ab, was ein SRE-Team sich wünschen könnte.

Warum eines eigens entwickeln?

Das Problem ist der Zugang. Der DevOps Agent ist im AWS Support für die Ebenen Business+ und Enterprise enthalten und steht der Allgemeinheit nicht auf Anfrage zur Verfügung. Organisationen mit Developer Support, Startups, unabhängige Teams oder Berater, die ohne Enterprise Support in einem Kundenkonto arbeiten, können ihn einfach nicht nutzen.

Dienste mit Verwaltungsfunktionen eignen sich für Teams, die bereits Enterprise Support nutzen und nach den gängigen AWS-Mustern arbeiten, da AWS bereits die schwierige Arbeit übernommen hat und die Integrationen umfangreich sind. Für einen KI-Architekten ist jedoch die wichtigere Frage, ob das jeweilige Muster gut genug verstanden wird, um es unabhängig zu entwickeln und dort weiterzuentwickeln, wo das verwaltete Produkt endet. Genau das zeigt dieses Projekt.

Das zentrale Problem: Tools in großem Maßstab

Modelle wie Amazon Nova verstehen verteilte Systeme, AWS-Architekturen sowie komplexe Fehlersuche. Aus der Box heraus sind sie jedoch weiterhin nur „Gehirne in einer Flasche“ – sie können weder CloudWatch-Metriken einsehen noch DynamoDB-Tabellen bearbeiten.

Die Verwendung solcher Tools für Large Language Models bedeutete traditionell anfälligen, maßgeschneiderten Code:

1. Eine JSON-Schema für das Tool definieren.
2. Eine Python-Funktion schreiben, die es ausführt.
3. Die AWS-Anmeldeinformationen direkt in den Laufzeitcode des Agents einbauen.

Das bindet den Agenten eng an die Infrastruktur, was Sicherheitsprobleme und Wartungsengpässe verursacht.

Einführung des MCP

Das Model Context Protocol, das von Anthropic eingeführt wurde und schnell zum Branchenstandard wird, löst dieses Problem elegant. Es handelt sich um ein standardisiertes Protokoll – ähnlich wie USB-C für KI – das Modelle mit externen Datensätzen und Tools verbindet. Anstatt AWS-Tools direkt im Agenten zu kodieren, wird ein separater MCP-Server erstellt. Dieser befindet sich innerhalb der AWS-Umgebung mit den notwendigen IAM-Rollen und stellt über das Standardprotokoll streng typisierte, semantische Tools zur Verfügung. Der Agent, der überall laufen kann, verbindet sich als MCP-Klient. Er benötigt keine AWS-Anmeldeinformationen, da er einfach vom Server bittet, die Tools für ihn auszuführen.

Freiheit bei der Auswahl des Modells

Weil MCP nicht darauf achtet, welches Modell am anderen Ende vorhanden ist, kann der SRE-Agent-Orchestrator das jeweils passende Modell verwenden:

Amazon Nova  ─┐
Claude 3.5   ─┼──→  SRE Agent Orchestrator  ──→  MCP Server  ──→  AWS Cloud
OpenAI GPT-4o─┘          (agent.py)                (server.py)

Die Bewertung eines Modells von einem anderen Anbieter bedeutet, eine Zeile Code zu ändern. Der MCP-Server sowie alle von ihm bereitgestellten sicheren AWS-Werkzeuge bleiben dabei völlig unverändert.

Architektur des SRE-Copilots

1. Die Zielinfrastruktur

Damit dem Agenten etwas zum Beheben zur Verfügung steht, wird mithilfe von Terraform ein standardmäßiger serverloser Microservice bereitgestellt: Ein API Gateway vor einer Lambda-Funktion, die in eine DynamoDB-Tabelle schreibt. Der absichtliche Fehler besteht darin, dass die Tabelle nur mit 1 Lese- und 1 Schreibkapazitäts-Einheit ausgestattet ist. Unter jeglicher tatsächlichen Last wirft diese API ProvisionedThroughputExceededException-Fehler aus.

2. Der MCP-Server

Ein Python-FastMCP-Server übernimmt die Rolle des „Händlers“ und „Auges“ und stellt vier SRE-Funktionen zur Verfügung:

• describe_architecture findet alle AWS-Ressourcen (ARNs), die eine Anwendungs-Tags tragen.

query_cloudwatch_metrics holt Zeitreihendaten wie ThrottledRequests ab.

query_cloudwatch_logs führt CloudWatch Logs Insights-Abfragen durch, um Stack-Traces zu finden.

remediate_dynamodb_capacity ist ein verändernder Tool, das die Tabellebegriffen erhöht.

Die Vertrauensgrenze ist der Punkt, an dem der Mensch eingreift. Die nur zum Lesen bestimmten Tools sind vollständig autonom, sodass das Modell sie nach Belieben zur Untersuchung nutzen kann. Das Behebungstool hingegen erzwingt jedoch eine strenge Kontrolle durch den Menschen. Bevor es die AWS-API aufruft, stoppt es und bittet den Operator im Terminal um eine [y/N]-Zustimmung, wobei die Begründung des Modells angezeigt wird. Ein prüfbarer Kontrollpunkt bei jeder handlungsverändernden Aktion, der durch die eigenen Regeln einer Organisation geprägt ist, wird weder von DevOps Guru noch von Amazon Q bereitgestellt.

3. Der autonome Agent

Der Agent ist ein kleines Python-Skript, das über boto3 mit der Amazon Bedrock Converse API kommuniziert, wobei die Amazon Nova-Modellfamilie aufgrund ihrer Funktionalitäten und geringen Kosten ausgewählt wurde. Es führt einen autonomen while-Loop aus:

1. Es erhält eine Anfrage wie „Die Benutzer melden, dass die Payment API Zeitüberschreitungen aufweist. Beheben Sie das.“
2. Es fragt den MCP-Server nach verfügbaren Tools.
3. Es wandelt die MCP-Tool-Schemata direkt in das Bedrock Converse-Format um.
4. Es beginnt mit der Analyse: Es sucht nach den Ressourcen der Payment API, überprüft deren Metriken und liest anschließend die Protokolle.
5. Es ruft Tools über MCP auf, leitet die Ergebnisse an Bedrock zurück und setzt die Prozedur fort, bis eine Lösung gefunden wurde und das Behebungstool ausgelöst wird.

Der Loop in Aktion

Wird auf die eingeschränkt nutzbare DynamoDB-Tabelle hingewiesen und gefragt, warum die Demo-API 429- und 500-Antworten zurückgibt, führt der Agent diese Schritte aus:

1. Es ruft describe_architecture auf, um die ARNs der Lambda- und DynamoDB-Tabelle zu finden.
2. Dann ruft es query_cloudwatch_metrics auf der Tabelle auf, prüft den Wert ProvisionedThroughputExceededRequests und erkennt einen starken Anstieg.
3. Zur Sicherheit ruft es query_cloudwatch_logs auf der Lambda-Funktion auf, analysiert die JSON-Logs und bestätigt einen ProvisionedThroughputExceededException.
4. Daraufhin kommt es zu dem Schluss, dass die Kapazität unzureichend ist, und ruft remediate_dynamodb_capacity auf, um 50 RCU und 50 WCU anzufordern.

Hier unterbricht der MCP-Server den Aufruf und fragt den Benutzer:

=======================================================
⚠️ URGENT: AGENT REQUESTING PERMISSION TO MODIFY INFRASTRUCTURE
=======================================================
Action: Scale DynamoDB Table 'sre-copilot-payments-dev'
New Capacity: Read=50, Write=50
Agent's Reason: The table is experiencing severe throttling (ProvisionedThroughputExceededException). Scaling up to mitigate the incident.
=======================================================
Approve this change? [y/N]: y

Derselbe Agent läuft auch als Streamlit-Chat-Anwendung, die die vorgeschlagene Lösung sowie den Freigabeschritt anzeigt. Sobald der Mensch zustimmt, wird die Kapazität aktualisiert und das Problem gelöst.

Vorteile dieser Architektur

Durch die Trennung des „Gehirns“ (Amazon Nova über Bedrock) von den „Händen“ (AWS-APIs) mithilfe von MCP entsteht eine Flexibilität, die herkömmliche AWS-Tools nicht erreichen können:

• Portabilität von LLMs. Der Wechsel von Nova zu Claude oder GPT-4o erfordert lediglich eine Konfigurationsänderung.
• Sicherheit. Rohdaten der Anmeldedaten erreichen niemals den LLM-Laufzeitumgebung.
• Sicherheit im Umgang mit Aktionen. Veränderte Aktionen müssen durch einen anpassbaren Freigabeschritt eines Menschen gehen.
• Erweiterbarkeit. Ein neues Tool – egal ob PagerDuty, eine Datadog-API-Anfrage oder eine Überprüfung eines ServiceNow-Tickets – wird durch eine einzige @mcp.tool()-Funktion verfügbar.

Autonomie. Der Agent kann die ausschließlich zum Lesen bestimmten Telemetriedaten frei durchsuchen, wodurch er ungewöhnliche Probleme diagnostizieren kann, die Tools zur Mustererkennung wie DevOps Guru übersehen würden.

Es sieht so aus, als würden sich Cloud-Operationen von monolithischen, verwalteten Diensten entfernen, die Teams einschränken, und stattdessen zu komponierbaren, modellunabhängigen, überprüfbaren Agenten übergehen, die von den Teams selbst entwickelt, betrieben und ständig weiterentwickelt werden. Dies ist ein Ansatz, der für die Produktion geeignet ist – nicht nur eine Demonstration.

Zur Referenz: Die MCP-Spezifikation ist unter modelcontextprotocol.io veröffentlicht, und AWS Labs stellt open-source-Referenz-MCP-Server bereit.