// Sicherheit & Gesellschaft 24.09.2026 · 12:33 Uhr 12 Min. Lesezeit

AWS erweitert CloudWatch zur Analyseplattform für Anwendungen und KI-Systeme

Mindverse News

KI-gestützt erstellt 6 Quellen Arbeitsweise

AWS erweitert CloudWatch zur Analyseplattform für Anwendungen und KI-Systeme — Symbolbild

Das Wichtigste in Kürze

Amazon Web Services erweitert CloudWatch um CloudWatch Omni, eine eigenständige Oberfläche für die Beobachtung klassischer Anwendungen und KI-basierter Systeme.
Die Plattform soll Metriken, Logs, Traces, Alarme und OpenTelemetry-Daten in einer anwendungsbezogenen Sicht zusammenführen.
Ein automatisch erstellter Abhängigkeitsgraph soll Betriebsteams dabei unterstützen, Fehler über mehrere Services hinweg einzugrenzen.
Der Amazon DevOps Agent kann Telemetriedaten korrelieren, mögliche Fehlerpfade identifizieren und nächste Untersuchungsschritte vorschlagen.
Für KI-Agenten bietet Omni hierarchische Traces und Evaluierungen unter anderem für Faktentreue, Kohärenz, Nützlichkeit und Tool-Auswahl.
Die KI liefert Hinweise und Hypothesen, ersetzt jedoch weder die Prüfung durch Fachpersonal noch eine belastbare Incident-Response-Organisation.
Für eine Einführung in Unternehmen sind unter anderem Identitätsmanagement, Berechtigungen, Datenzugriff, Verschlüsselung und die Aufbewahrung von Untersuchungsdaten zu klären.

// Inhalt · 10 Abschnitte

CloudWatch entwickelt sich vom Monitoring-Dienst zur Untersuchungsplattform
Was AWS mit CloudWatch Omni bündelt
Incident Response mit kontextbezogenen Signalen
CloudWatch Investigations und automatisch erzeugte Fakten
Incident-Reports für Nachbereitung und Governance
Besondere Anforderungen beim Betrieb von KI-Agenten
Einführung im Unternehmen: technische und organisatorische Fragen
Welche Bedeutung die Neuerung für Betriebsteams hat
Einordnung: Unterstützung statt autonomer Ursachenentscheidung
Ausblick auf den Betrieb komplexer KI-Systeme
Quellen

CloudWatch entwickelt sich vom Monitoring-Dienst zur Untersuchungsplattform

Amazon Web Services baut die Funktionen seines Monitoring-Dienstes CloudWatch aus. Mit CloudWatch Omni hat AWS eine neue Oberfläche vorgestellt, die den Betrieb verteilter Anwendungen und KI-Agenten in einer gemeinsamen Arbeitsumgebung unterstützen soll. Im Mittelpunkt steht nicht nur die Darstellung einzelner Messwerte, sondern die Verbindung verschiedener Signale zu einer zusammenhängenden Sicht auf Anwendungen, Abhängigkeiten und Störungen.

Für Unternehmen ist diese Entwicklung relevant, weil moderne Anwendungen in der Regel aus zahlreichen Komponenten bestehen. Ein einzelner Geschäftsprozess kann beispielsweise mehrere Container, Datenbanken, Warteschlangen, externe Schnittstellen und KI-Modelle einbeziehen. Fällt eine Komponente aus oder verschlechtert sich ihre Leistung, ist die Ursache nicht zwangsläufig dort zu finden, wo der erste Alarm ausgelöst wird. Die eigentliche Herausforderung besteht darin, zeitliche Zusammenhänge und Abhängigkeiten über mehrere Systeme hinweg zu erkennen.

CloudWatch Omni soll diese Analyse in einer stärker an Anwendungen orientierten Oberfläche bündeln. Die Lösung läuft als eigenständige Webanwendung außerhalb der klassischen AWS-Managementkonsole. Bestehende CloudWatch-Daten sollen dabei ebenso einbezogen werden wie Telemetrie, die über offene Standards wie OpenTelemetry angebunden wird.

Was AWS mit CloudWatch Omni bündelt

CloudWatch ist seit Jahren ein zentraler Bestandteil der AWS-Betriebsumgebung. Der Dienst sammelt und verarbeitet unter anderem Metriken, Logdaten, Traces und Alarme. Diese Informationen bilden die Grundlage für die Überwachung von Infrastruktur und Anwendungen sowie für die Reaktion auf technische Störungen.

CloudWatch Omni setzt auf diesen bereits vorhandenen Daten auf. Ein Team kann einen sogenannten Space anlegen, in dem Anwendungen, Services und die jeweils zugehörigen Telemetriedaten zusammengefasst werden. Dadurch soll die Analyse nicht mehr ausschließlich über einzelne Dashboards, Alarmansichten oder Logabfragen erfolgen, sondern ausgehend von einem konkreten Anwendungskontext.

Nach Angaben von AWS kann Omni Services und deren Beziehungen automatisch erkennen und als Topologie darstellen. Eine solche Darstellung macht sichtbar, welche Komponenten voneinander abhängig sind und an welcher Stelle eines Verarbeitungspfads ein Problem auftreten könnte. Die Qualität dieser Sicht hängt allerdings von der Vollständigkeit und Konsistenz der verfügbaren Telemetriedaten ab.

CloudWatch Omni soll außerdem Überwachungsansichten und Alarme an Veränderungen einer Anwendung anpassen können. Wird beispielsweise ein zusätzlicher Service eingeführt oder eine bestehende Architektur erweitert, soll die Beobachtung dieser Struktur nicht vollständig manuell neu aufgebaut werden müssen. Für Unternehmen mit häufigen Deployments und dynamischen Umgebungen kann dies den Pflegeaufwand für Monitoring-Konfigurationen reduzieren.

Unterstützung für offene Telemetriestandards

Ein wesentlicher Bestandteil der Plattform ist die Zusammenführung unterschiedlicher Datenquellen. Bereits in CloudWatch gespeicherte Metriken, Logs, Traces und Alarme sollen ohne eine erneute Instrumentierung verfügbar sein. Zusätzlich können Workloads Telemetrie über das OpenTelemetry Protocol, kurz OTLP, an Omni übermitteln.

OpenTelemetry wird von vielen Unternehmen eingesetzt, um Beobachtungsdaten unabhängig von einem einzelnen Anbieter zu erfassen und weiterzuleiten. Die Unterstützung dieses Standards kann insbesondere für Organisationen interessant sein, die hybride oder multicloudbasierte Umgebungen betreiben. Sie kann jedoch nicht automatisch mit einer vollständigen Herstellerunabhängigkeit gleichgesetzt werden. Entscheidend bleibt, welche Datenquellen, Konnektoren und Analysefunktionen in der jeweiligen Umgebung tatsächlich zur Verfügung stehen.

Für die technische Umsetzung nennt AWS unter anderem ADOT, den AWS Distro for OpenTelemetry, sowie OpenInference für die Instrumentierung von KI-Anwendungen. Die Plattform soll außerdem verschiedene Frameworks und Software Development Kits unterstützen. Dazu gehören nach Angaben von AWS unter anderem LangChain, LangGraph, CrewAI, das OpenAI SDK, Strands und das Vercel AI SDK für Python und TypeScript.

Incident Response mit kontextbezogenen Signalen

Bei einer Störung zählt für Betriebsteams vor allem die Geschwindigkeit, mit der aus einem Alarm eine belastbare Arbeitshypothese entsteht. Ein Alarm über steigende Fehlerraten liefert zunächst nur ein Symptom. Für die Ursachenanalyse sind zusätzliche Informationen erforderlich: Gab es kurz zuvor eine Bereitstellung? Ist die Latenz eines abhängigen Dienstes ebenfalls gestiegen? Sind bestimmte Regionen, Mandanten oder Schnittstellen besonders betroffen?

CloudWatch Omni soll eine Untersuchungssitzung mit solchen Signalen anreichern. Wird ein Alarm ausgelöst, kann die Plattform beispielsweise relevante Metriken, Logeinträge, Traces, Deployment-Ereignisse und die Topologie der betroffenen Services zusammenstellen. Das Ziel besteht darin, die Zahl der manuellen Suchschritte zu verringern und den zeitlichen Zusammenhang zwischen verschiedenen Ereignissen sichtbar zu machen.

Für die gemeinsame Bearbeitung können weitere Teammitglieder derselben Untersuchungssitzung beitreten. AWS sieht dafür Single Sign-on über das IAM Identity Center und SAML-2.0-kompatible Identitätsanbieter vor. Als Beispiele werden Okta und Microsoft Entra ID, früher Azure Active Directory, genannt. Der Zugriff soll möglich sein, ohne dass jedes Mitglied des Incident-Response-Teams über vollständigen Zugang zur AWS-Managementkonsole verfügen muss.

Diese Trennung kann für größere Organisationen von Bedeutung sein. Nicht jedes Mitglied eines Bereitschaftsteams benötigt oder soll Zugriff auf sämtliche Cloud-Ressourcen erhalten. Eine anwendungsbezogene Oberfläche mit klar definierten Berechtigungen kann dazu beitragen, den Zugriff auf notwendige Informationen zu begrenzen. Die konkrete Sicherheitswirkung hängt jedoch von der Rollenverteilung, den IAM-Richtlinien und der Konfiguration des jeweiligen Unternehmens ab.

Der Amazon DevOps Agent als Analysehilfe

Ein Bestandteil der Untersuchungen ist der Amazon DevOps Agent. Dieser soll Ereignisse über mehrere Services hinweg miteinander in Beziehung setzen, mögliche Fehlerpfade in einem Abhängigkeitsgraphen verfolgen und weitere Untersuchungsschritte vorschlagen. Die Funktion richtet sich damit vor allem an Situationen, in denen ein Incident nicht durch ein einzelnes isoliertes Signal erklärt werden kann.

Die Arbeitsweise lässt sich als Kombination aus automatisierter Datensichtung und hypothesenbasierter Analyse beschreiben. Der Agent untersucht verfügbare Telemetrie, sucht nach zeitlichen und technischen Zusammenhängen und präsentiert daraus abgeleitete Hinweise. AWS beschreibt die Ergebnisse als Unterstützung für die Fehlersuche. Eine automatische Behebung der zugrunde liegenden Störung ist aus den vorliegenden Produktinformationen nicht abzuleiten.

Für die Praxis bedeutet das: Die KI kann den Einstieg in eine Untersuchung beschleunigen, muss aber in den bestehenden Prozess der technischen Verifikation eingebettet werden. Ein Vorschlag über eine mögliche Ursache ist noch kein Nachweis. Gerade bei geschäftskritischen Systemen sollten Teams daher prüfen, ob die angeführten Signale tatsächlich zur beobachteten Auswirkung passen und ob alternative Ursachen ausgeschlossen wurden.

CloudWatch Investigations und automatisch erzeugte Fakten

Neben Omni stellt AWS CloudWatch Investigations als generative-KI-gestützte Funktion für die Untersuchung von Incidents bereit. Die Funktion kann Telemetriedaten durchsuchen und Informationen anzeigen, die mit einem Problem in Zusammenhang stehen könnten. Dazu gehören unter anderem Metriken, Logs, Bereitstellungsereignisse und Hypothesen zur möglichen Ursache.

Wenn mehrere Ressourcen betroffen sind, können Zusammenhänge auch visuell dargestellt werden. Nach Angaben von AWS nutzt CloudWatch Investigations die Berechtigungen des angemeldeten Benutzers, um die Ressourcen zu untersuchen, die mit einem Alarm, einer Metrik oder einer Logs-Insights-Abfrage verbunden sind. Damit ist die Reichweite der Analyse nicht nur eine technische, sondern auch eine organisatorische Frage: Die KI kann nur auf Daten zugreifen, für die der jeweilige Kontext die erforderlichen Rechte besitzt.

AWS erläutert in seiner Dokumentation außerdem das Konzept sogenannter KI-abgeleiteter Fakten. Dabei handelt es sich um Informationen, die das System auf Grundlage einer umfassenden Analyse als objektiv zutreffend oder mit hoher Wahrscheinlichkeit zutreffend einstuft. Die Herleitung soll eine Kombination aus Mustererkennung und systematischer Überprüfung verwenden.

Für Anwenderinnen und Anwender ist diese Unterscheidung wichtig. Auch wenn ein Ergebnis als Fakt bezeichnet wird, bleibt es ein von einem automatisierten System erzeugtes Analyseergebnis. Unternehmen sollten daher nachvollziehen können, aus welchen Daten ein Ergebnis abgeleitet wurde, welche Unsicherheiten bestehen und welche Prüfungen durch Menschen vorgesehen sind. Die Nachvollziehbarkeit ist insbesondere bei regulatorisch relevanten Anwendungen, bei Sicherheitsvorfällen und bei späteren Post-Incident-Analysen von Bedeutung.

Incident-Reports für Nachbereitung und Governance

Eine Störung endet nicht mit der technischen Wiederherstellung eines Dienstes. In vielen Unternehmen folgt eine strukturierte Nachbereitung. Dabei werden Zeitabläufe, Auswirkungen, technische Ursachen, getroffene Maßnahmen und Verbesserungsmöglichkeiten dokumentiert. AWS bietet für CloudWatch Investigations eine Funktion zur Erstellung von Incident-Reports an.

Die Berichte sollen innerhalb kurzer Zeit eine strukturierte Zusammenfassung der Untersuchung liefern. AWS orientiert sich dabei an etablierten Mustern für Post-Incident-Analysen. Die Ergebnisse können für die Information des Managements, die Abstimmung zwischen Betriebsteams und die Planung präventiver Maßnahmen verwendet werden.

Die automatische Berichtserstellung kann die Dokumentation vereinfachen, wenn während der Untersuchung ausreichend Daten gesammelt wurden. Sie ersetzt jedoch nicht die redaktionelle und fachliche Prüfung des Berichts. Automatisch erzeugte Zusammenfassungen können Zusammenhänge verkürzt darstellen, Unsicherheiten nicht deutlich genug hervorheben oder die Perspektive einzelner Datenquellen überbewerten.

Für die Erzeugung von Incident-Reports sind zusätzliche Berechtigungen erforderlich. AWS nennt dafür unter anderem eine verwaltete Richtlinie mit der Bezeichnung AIOpsAssistantIncidentReportPolicy. Bei der Einrichtung von Investigation Groups wird eine IAM-Rolle verwendet, die den Zugriff auf die für die Untersuchung vorgesehenen Ressourcen regelt.

Besondere Anforderungen beim Betrieb von KI-Agenten

CloudWatch Omni richtet sich nicht nur an klassische Webanwendungen und Backend-Systeme. Ein weiterer Schwerpunkt liegt auf generativer KI und agentischen Anwendungen. Diese Systeme unterscheiden sich von herkömmlicher Software, weil ihre Ausgaben nicht allein durch fest definierte Programmabläufe entstehen.

Ein KI-Agent kann beispielsweise ein Sprachmodell aufrufen, ein externes Werkzeug auswählen, Daten aus einer Wissensbasis abrufen, eine API ansprechen und anschließend eine Antwort formulieren. In komplexeren Szenarien kommen mehrere Modelle, Unteragenten oder Verarbeitungsschritte hinzu. Ein technischer Status wie „Anfrage erfolgreich abgeschlossen“ sagt dann noch nicht aus, ob das Ergebnis sachlich korrekt, vollständig oder für den jeweiligen Zweck geeignet ist.

Die klassischen Monitoring-Kennzahlen bleiben relevant. Antwortzeit, Fehlerrate, Ressourcenauslastung und Verfügbarkeit zeigen, ob ein System technisch funktioniert. Für KI-Agenten müssen sie jedoch um Qualitäts- und Verhaltensdaten ergänzt werden. Zu prüfen ist beispielsweise, ob ein Agent das richtige Tool verwendet, ob er den vorgesehenen Bearbeitungspfad einhält oder ob sich seine Ergebnisse nach einer Änderung des Prompts verschlechtern.

Trace Explorer und Evaluierungen

Omni soll dafür einen Trace Explorer bereitstellen. Dieser schlüsselt Aufrufe von Sprachmodellen, Werkzeugen und weiteren Verarbeitungsschritten hierarchisch auf. Entwicklerteams können dadurch nachvollziehen, welche Schritte zu einer bestimmten Ausgabe geführt haben und an welcher Stelle ein Fehler oder eine Qualitätsabweichung entstanden sein könnte.

Der Vergleich mehrerer Traces soll außerdem helfen, die Auswirkungen unterschiedlicher System-Prompts, Modellversionen oder Konfigurationen zu untersuchen. Ein solcher Vergleich kann beispielsweise zeigen, ob eine Änderung die Antwortzeit erhöht, zusätzliche Tool-Aufrufe auslöst oder die Qualität der Ergebnisse verändert.

Ergänzend nennt AWS Evaluierungen für Kriterien wie Kohärenz, Nützlichkeit, Faktentreue und die korrekte Auswahl von Werkzeugen oder Bearbeitungspfaden. Insgesamt verweist AWS auf 17 integrierte Evaluatoren. Welche Aussagekraft diese Bewertungen haben, hängt von den verwendeten Prüfkriterien, Referenzdaten und Anwendungsszenarien ab. Eine hohe Bewertung in einem einzelnen Kriterium bedeutet nicht automatisch, dass ein Agent für den produktiven Einsatz geeignet ist.

Unternehmen sollten Evaluierungen daher als Teil eines mehrstufigen Qualitätsprozesses betrachten. Neben automatisierten Bewertungen können fachliche Stichproben, Sicherheitstests, Datenschutzprüfungen und Belastungstests erforderlich sein. Besonders bei KI-Systemen ist zudem zu berücksichtigen, dass sich Ergebnisse durch Modelländerungen, neue Datenquellen oder veränderte Prompts verändern können.

Einführung im Unternehmen: technische und organisatorische Fragen

Bestehende CloudWatch-Kunden können CloudWatch Omni nach den vorliegenden AWS-Informationen über eine entsprechende Schaltfläche in der CloudWatch-Konsole aktivieren. Für eine organisationsweite Nutzung sind zusätzliche Einrichtungsschritte vorgesehen. Dazu gehören die Konfiguration einer Domain, die Anbindung eines Identitätsanbieters sowie die Definition von Spaces für Teams, Anwendungen oder Umgebungen.

Vor einer Einführung sollten Verantwortliche mehrere Fragen klären:

Welche Anwendungen und Datenquellen sollen in der ersten Phase überwacht werden?
Welche Metriken, Logs und Traces sind für die wichtigsten Geschäftsprozesse tatsächlich verfügbar?
Welche Rollen dürfen Untersuchungen starten, Daten einsehen oder Berichte erstellen?
Wie werden sensible Inhalte in Logs, Traces und KI-Eingaben erkannt und geschützt?
Wie lange sollen Untersuchungsdaten, Telemetrie und automatisch erzeugte Berichte gespeichert werden?
Welche menschlichen Freigaben sind erforderlich, bevor eine vermutete Ursache oder Maßnahme in den Incident-Prozess übernommen wird?
Wie werden Daten aus AWS, lokalen Rechenzentren und anderen Cloud-Umgebungen zusammengeführt?

Auch die Kosten- und Datenmengenentwicklung sollte in die Planung einfließen. Eine detailliertere Instrumentierung und die dauerhafte Speicherung von Traces können das Datenvolumen deutlich erhöhen. Bei KI-Agenten kommen zusätzliche Informationen über Modellaufrufe, Tool-Nutzung und Zwischenschritte hinzu. Unternehmen müssen deshalb Aufbewahrungsfristen, Filterregeln und die gewünschte Detailtiefe aufeinander abstimmen.

Berechtigungen und Datenschutz

Incident-Analyse kann Zugriff auf besonders sensible Informationen erfordern. Logs enthalten unter Umständen Kundendaten, interne Zugangsinformationen, Geschäftsgeheimnisse oder Inhalte aus Geschäftsvorgängen. Bei KI-Agenten können Traces zudem Prompt-Inhalte, Dokumentenausschnitte oder Antworten externer Systeme enthalten.

Die Nutzung von IAM-Rollen und rollenbasiertem Zugriff ist deshalb ein wesentlicher Bestandteil der Einführung. Für jede Benutzergruppe sollte festgelegt werden, welche Daten sie für ihre Aufgabe benötigt. Eine möglichst weitreichende Berechtigung kann die Analyse vereinfachen, erhöht aber zugleich die Folgen eines Fehlers oder Missbrauchs.

Darüber hinaus sind interne Vorgaben und gegebenenfalls regulatorische Anforderungen zu berücksichtigen. Dazu zählen die Klassifizierung von Daten, die Protokollierung von Zugriffen, Anforderungen an die Aufbewahrung und die Frage, ob bestimmte Inhalte von automatisierten Analysefunktionen ausgeschlossen werden müssen.

Welche Bedeutung die Neuerung für Betriebsteams hat

Mit CloudWatch Omni verbindet AWS mehrere Entwicklungslinien: Observability, AIOps, kollaborative Incident Response und die Qualitätskontrolle von KI-Anwendungen. Für Betriebsteams entsteht dadurch eine Oberfläche, die nicht nur den Zustand einzelner Ressourcen anzeigen, sondern auch die Beziehungen zwischen Services und die Entwicklung eines Incidents nachvollziehbar machen soll.

Der praktische Nutzen hängt maßgeblich von der bestehenden Arbeitsweise ab. Teams mit bereits gut gepflegten Metriken, Logs, Traces und Deployment-Daten können eher von einer automatisierten Korrelation profitieren. In Umgebungen mit lückenhafter Instrumentierung besteht dagegen das Risiko, dass die KI nur einen unvollständigen Ausschnitt der Systemrealität analysiert.

Auch die Rollenverteilung verändert sich nicht automatisch durch den Einsatz eines KI-Assistenten. Verantwortlichkeiten für Alarmierung, Eskalation, Ursachenanalyse, Kommunikation und Wiederherstellung müssen weiterhin eindeutig definiert sein. Die Plattform kann einzelne Tätigkeiten beschleunigen, ersetzt aber weder Bereitschaftsmodelle noch Runbooks oder Übungen für kritische Ausfallszenarien.

Für Unternehmen, die KI-Agenten selbst entwickeln, liegt der Mehrwert vor allem in der Verbindung von technischer Beobachtung und qualitativer Bewertung. Ein Agent kann verfügbar sein und dennoch falsche Antworten liefern. Trace-Daten und Evaluierungen ermöglichen eine differenziertere Betrachtung als reine Infrastrukturmetriken. Voraussetzung ist, dass die Organisation festlegt, was im jeweiligen Anwendungsfall als korrekte, nützliche und sichere Ausgabe gilt.

Einordnung: Unterstützung statt autonomer Ursachenentscheidung

AWS positioniert die Funktionen als Assistenz für die Incident-Untersuchung. Die Systeme sammeln relevante Signale, stellen mögliche Zusammenhänge her und schlagen Hypothesen oder nächste Schritte vor. Daraus folgt ein Einsatzmodell, bei dem Fachkräfte die Ergebnisse bewerten und in den technischen Kontext einordnen.

Diese Einordnung ist für die Betriebssicherheit entscheidend. Ein automatisiertes System kann Muster in großen Datenmengen schneller erkennen als ein Mensch, verfügt aber nur über die Daten und Berechtigungen, die ihm zur Verfügung stehen. Zudem kann eine Korrelation zeitlich zusammenfallender Ereignisse entstehen, ohne dass tatsächlich ein kausaler Zusammenhang besteht.

Für eine belastbare Nutzung sollten Unternehmen daher klare Prüfmechanismen etablieren. Dazu gehören die Kennzeichnung von Hypothesen, die Anzeige der zugrunde liegenden Signale, die Dokumentation menschlicher Entscheidungen und eine Möglichkeit, fehlerhafte oder unvollständige Ergebnisse zu korrigieren. Die aus einer Untersuchung gewonnenen Erkenntnisse können anschließend in Runbooks, Alarmregeln und Architekturentscheidungen einfließen.

CloudWatch Omni adressiert damit eine zentrale Herausforderung moderner IT-Organisationen: Die Menge der verfügbaren Betriebsdaten wächst, während die Zeit für die Analyse eines Incidents begrenzt bleibt. Ob die neue Oberfläche diese Lücke in der Praxis zuverlässig schließt, wird von der Qualität der Datenintegration, der Transparenz der KI-Ergebnisse und der Einbettung in bestehende Prozesse abhängen.

Ausblick auf den Betrieb komplexer KI-Systeme

Mit der zunehmenden Verbreitung von KI-Agenten verschiebt sich der Schwerpunkt der Überwachung. Neben der Frage, ob ein Dienst erreichbar ist, muss geprüft werden, wie er Entscheidungen trifft, welche Werkzeuge er verwendet und ob seine Ausgaben den fachlichen Anforderungen entsprechen. Dafür benötigen Unternehmen eine Kombination aus klassischem Application Performance Monitoring, Distributed Tracing, Modellbeobachtung und systematischer Evaluation.

CloudWatch Omni versucht, diese Bereiche in einer gemeinsamen Umgebung abzubilden. Die Unterstützung mehrerer Frameworks und die Nutzung von OpenTelemetry- beziehungsweise OpenInference-basierten Verfahren zielen darauf, die Instrumentierung unterschiedlicher Anwendungen zu vereinheitlichen. Für Nutzerinnen und Nutzer bedeutet dies zugleich, dass die Auswahl der Datenquellen und die Definition der Qualitätsmaßstäbe weiterhin eine eigene konzeptionelle Aufgabe bleiben.

Für Sie als Verantwortliche oder Verantwortlicher in Entwicklung, IT-Betrieb, Plattformmanagement oder Informationssicherheit empfiehlt sich deshalb ein schrittweises Vorgehen. Beginnen Sie mit einem klar abgegrenzten Anwendungsszenario, definieren Sie die relevanten Signale und vergleichen Sie automatisierte Vorschläge mit den Ergebnissen erfahrener Incident-Teams. Erst auf dieser Grundlage lässt sich beurteilen, ob CloudWatch Omni die Analysezeiten verkürzt, die Dokumentation verbessert und die Qualität des Betriebs tatsächlich erhöht.