Michael JohnsonAWS kündigte CloudWatch Omni am 22. September 2026 an und führte es am 23. September als allgemein verfügbar auf. Die Daten bezeichnen zwei unterschiedliche Ereignisse: die Ankündigung und den Beginn der allgemeinen Verfügbarkeit. Omni vereint die Beobachtbarkeit von Anwendungen und KI-Agenten in einer Oberfläche – mit einer eigenständigen Weboberfläche und IDE-Erweiterungen sowie der Integration in CloudWatch. AWS’ Ankündigung zu CloudWatch Omni
Diese Kombination geht einen blinden Fleck im Produktivbetrieb an: Eine Agentenanfrage kann ohne herkömmlichen Dienstfehler abgeschlossen werden und trotzdem eine schlechte Antwort liefern oder das falsche Werkzeug auswählen. AWS zufolge können Teams Agenten-Traces und Evaluierungen zusammen mit Anwendungstelemetrie untersuchen. Entscheidend ist, ob diese Signale in einem gemeinsamen Arbeitsbereich nützlich sind – und welche Daten, Zugriffsrechte und Kosten mit ihrer Weiterleitung dorthin verbunden sind.
Das Produkt umfasst mehr als Agenten-Traces
Omni ist eine Erweiterung von CloudWatch, kein Ersatz dafür. AWS zufolge funktionieren bestehende CloudWatch-Alarme, Dashboards, APIs und Konsolenabläufe weiterhin. Bereits an CloudWatch gesendete Telemetrie kann ohne Neukonfiguration in Omni erscheinen; andere instrumentierte Workloads können Daten über das OpenTelemetry Protocol (OTLP) senden. AWS beschreibt außerdem die Erkennung von Diensten und die Zuordnung von Abhängigkeiten sowie Bereiche, in denen sich Telemetriedaten aus mehreren Konten und Regionen zusammenführen lassen, wenn dies entsprechend konfiguriert ist. AWS-Dokumentation zu CloudWatch Omni
Die Oberfläche ist nicht auf die AWS-Managementkonsole beschränkt. AWS bietet eine eigenständige Weboberfläche mit einmaliger Anmeldung sowie IDE-Erweiterungen für VS Code, Cursor und Kiro. Der Veröffentlichungshinweis vom 23. September nennt die allgemeine Verfügbarkeit in US East (N. Virginia), US West (Oregon) und Europa (Irland). Teams sollten die regionale Unterstützung prüfen, bevor sie Omni in eine Produktionsarchitektur aufnehmen.
Für Agenten beschreibt AWS die Untersuchung von Traces, Evaluierungen und Experimente mit Frameworks wie OpenAI Agents SDK, LangGraph, CrewAI, Vercel AI SDK und Strands. Bei Untersuchungen von Anwendungen können Nutzer Fragen in natürlicher Sprache stellen oder Telemetriedaten direkt erkunden; AWS zufolge werden die KI-gestützten Untersuchungsfunktionen von DevOps Agent bereitgestellt. Im Blogbeitrag zum Start für Anwendungen heißt es außerdem, dass DevOps Agent in jeder Omni-Untersuchungssitzung standardmäßig aktiviert ist. Administratoren sollten dieses Verhalten bei der Bewertung des Arbeitsablaufs berücksichtigen.
Warum die Zusammenführung der Signale wichtig sein könnte
Herkömmliche Überwachung zeigt, ob ein Dienst reagiert, wie lange er braucht und ob er Fehler zurückgibt. Sie macht möglicherweise nicht sichtbar, dass ein Agent eine Anfrage missverstanden, ein ungeeignetes Werkzeug gewählt oder eine falsche Antwort gegeben hat. Wenn ein Team ein Evaluierungsergebnis zusammen mit dem Trace und den Anwendungssignalen betrachtet, kann es ein Qualitätsproblem möglicherweise entlang der Ausführung des Agenten zurückverfolgen.
Das ist ein plausibler betrieblicher Vorteil, aber kein nachgewiesenes Leistungsergebnis. AWS beschreibt in den Startmaterialien den kombinierten Arbeitsablauf, belegt jedoch nicht, dass damit Vorfälle schneller behoben werden als mit bestehenden Werkzeugen. Teams müssen mit ihren eigenen Workloads prüfen, ob Omni-Evaluierungen und -Untersuchungen hilfreich sind.
OpenTelemetry kann das Senden von Telemetriedaten aus bestehender Instrumentierung erleichtern, doch ein gemeinsames Protokoll macht Beobachtungsplattformen nicht austauschbar. Die OTLP-Spezifikation legt fest, wie Telemetriedaten übertragen werden; Teams müssen weiterhin prüfen, von welchen Signalen, Abfragen und plattformspezifischen Funktionen ihre Arbeitsabläufe abhängen.
Zentralisierung erfordert Konfiguration
Omni kann Daten aus mehreren Konten und Regionen zusammenführen. Teams sollten jedoch nicht davon ausgehen, dass durch die Aktivierung der Oberfläche automatisch die Telemetriedaten sämtlicher Konten aggregiert werden. In der AWS-Einrichtungsdokumentation wird beschrieben, wie Domains und Bereiche erstellt und anschließend die Übernahme von Telemetriedaten aus mehreren Konten in einen Bereich konfiguriert wird. Bestehende CloudWatch-Daten lassen sich ohne erneute Instrumentierung anzeigen, doch die Organisation muss den vorgesehenen Zugriff und Datenfluss weiterhin einrichten. AWS-Anleitung zur Omni-Einrichtung
Diese Unterscheidung ist sowohl für die Bereitstellung als auch für die Kosten wichtig. Die Preisseite von AWS unterscheidet zwischen Gebühren für die Aufnahme, Speicherung und Analyse von Telemetriedaten. Sie nennt auch Gebühren für zusätzliche zentralisierte Kopien; die erste zentralisierte Kopie ist laut den aufgeführten Preisen kostenlos. Die Abfragekosten hängen von der gescannten Datenmenge und den Freikontingenten ab; Agenten-Evaluierungen werden zu den Tarifen für Amazon Bedrock AgentCore Evaluations abgerechnet. Eine aussagekräftige Schätzung muss daher Datenvolumen, Aufbewahrungsdauer, Abfragemuster, Kopien und Häufigkeit der Evaluierungen berücksichtigen – nicht nur die Anzahl der Agenten.
Inhalte der Traces und Zugriffsrechte müssen geprüft werden
Agenten-Traces können Prompts, Antworten, abgerufene Dokumente und personenbezogene Daten enthalten. AWS zufolge erkennt oder schwärzt Omni personenbezogene Daten nicht automatisch. Die AWS-Hinweise zum Schutz sensibler Daten empfehlen, festzulegen, an welcher Stelle die Filterung erfolgt. Die Schwärzung bereits bei der Erfassung verhindert, dass sensible Inhalte die Anwendung verlassen.
AWS gibt außerdem an, Kundeninhalte weder zum Trainieren von Basismodellen noch zur Verbesserung von Omni selbst zu verwenden. Das bedeutet nicht, dass Inhalte nirgendwo sonst verarbeitet werden: Einige Funktionen senden Daten an Dienste wie Bedrock oder AgentCore, und AWS dokumentiert die regionsübergreifende Inferenz für KI-Funktionen. Daten bleiben in der Region des jeweiligen Bereichs gespeichert, KI-Anfragen können jedoch an anderer Stelle innerhalb desselben geografischen Gebiets verarbeitet werden. Teams sollten die AWS-Richtlinie zur Datennutzung und die Details zur regionsübergreifenden Inferenz prüfen – insbesondere, wenn ihre Richtlinien einschränken, wo Trace-Inhalte verarbeitet werden dürfen.
Zugriffskontrollen verdienen ebenso viel Aufmerksamkeit wie die Telemetrie-Pipeline. AWS zufolge können Mitglieder eines Bereichs standardmäßig alle darin enthaltenen Telemetriedaten lesen; Datenbereiche können einschränken, welche Zeilen aus Protokollen und Traces ein Mitglied sieht. Diese Bereiche blenden jedoch keine Felder innerhalb einer Zeile aus und ersetzen daher nicht die Schwärzung von Inhalten, die bestimmte Nutzer niemals sehen dürfen. AWS-Anleitung zu Sichtbarkeitsbeschränkungen
Omni mit Augenmaß bewerten
Teams, die CloudWatch bereits nutzen, können mit einem begrenzten Test herausfinden, ob die gemeinsame Anwendungs- und Agentenansicht von Omni bei einem konkreten Arbeitsablauf hilft. Bevor sie Produktions-Traces senden, sollten sie die benötigten Signale bestimmen, Filter konfigurieren, den Zugriff auf Konten und Regionen festlegen und die Kosten für Aufnahme, Speicherung, Analyse und Evaluierungen schätzen. Anschließend können sie die erzeugten Untersuchungen und Evaluierungsergebnisse mit den aktuellen Verfahren zur Vorfallbearbeitung vergleichen.
Für Organisationen, die andere Beobachtungsplattformen verwenden, ist der Start ein Anlass, den Arbeitsablauf zu bewerten – für sich genommen jedoch kein Grund für eine Migration. Omni bringt Signale zur Agentenqualität näher an den Anwendungsbetrieb. Sein Nutzen hängt jedoch davon ab, wie hilfreich die Untersuchungen sind, ob die Kontrollen den Anforderungen entsprechen und welche Kosten der Datenfluss verursacht.
