AgentCore Observability verlässt die AWS-Grenze für Multi-Cloud-Agenten

Der Mythos vom automatischen AWS-Monitoring

Der Mythos hält sich hartnäckig: Wer KI-Agenten baut, brauche nur AWS und AgentCore, dann kümmere sich die Cloud automatisch um die eigene Beobachtung. Die Realität sieht anders aus, und ausgerechnet AWS liefert den Gegenbeweis selbst. In einem aktuellen Blogpost beschreibt das Unternehmen, wie Agenten außerhalb der eigenen Cloud über OpenTelemetry Telemetrie an AgentCore Observability senden – und macht damit deutlich, dass Monitoring für Agentenflotten längst kein AWS-only-Thema mehr ist.

Der Ausgangspunkt ist unspektakulär, aber wichtig: Wenn Sie KI-Agenten mit Frameworks wie Strands Agents, LangGraph oder CrewAI bauen, brauchen Sie Einblick in ihre Performance – unabhängig davon, ob sie auf Amazon EKS, Amazon ECS, AWS Lambda, on-premises oder bei einem anderen Cloud-Anbieter wie Google Cloud Platform oder Microsoft Azure laufen. Das ist keine Marketingfloskel, sondern die Beschreibung eines Betriebsproblems, das jedes Unternehmen mit hybrider Infrastruktur kennt: Sobald ein Agent nicht mehr im eigenen Rechenzentrum oder der eigenen AWS-Umgebung läuft, wird jede Fehlersuche zur Ratearbeit.

Beobachtbarkeit ist dabei kein Nice-to-have, sondern nach Einschätzung von AWS ein fundamentaler Baustein verantwortungsvoller KI. Wer Telemetrie an ein zentrales Dashboard weiterleitet, gewinnt Einblick in Denkketten, Tool-Aufrufe und Modellausgaben eines Agenten. Das erlaubt es, Halluzinationen zu erkennen, auffällige oder themenfremde Antworten zu überwachen, Token-Verbrauch für die Kostenkontrolle nachzuvollziehen und das Agentenverhalten über verschiedene Umgebungen hinweg zu prüfen. Gerade bei Agenten außerhalb von AWS ist das kritisch, weil problematische Ausgaben ohne zentrale Beobachtung schlicht unbemerkt bleiben.

Genau hier hätte AgentCore Observability leicht zur reinen PR-Fußnote werden können, wenn die Lösung nur für AWS-native Deployments funktioniert hätte. AWS zeigt stattdessen eine konkrete, nachvollziehbare Anleitung, wie sich diese Grenze technisch auflösen lässt, statt sie nur zu behaupten.

Was AgentCore Observability nativ tatsächlich sieht

Bevor Sie sich zu früh freuen: Amazon Bedrock AgentCore ist laut AWS eine Plattform, um Agenten in beliebigem Umfang zu bauen, zu verbinden und zu optimieren, mit jedem Framework und jedem Modell. Das klingt nach uneingeschränkter Reichweite. Die Einschränkung folgt im selben Atemzug: AgentCore Observability bietet native Tracing-, Monitoring- und Analysefunktionen, die lokale Cloud-Monitoring-Werkzeuge nicht von Haus aus liefern – aber nativ unterstützt werden ausschließlich Agenten, die auf der AgentCore Runtime in der AWS Cloud laufen.

Für alles andere gilt: zusätzliche Konfiguration nötig, um Telemetrie überhaupt an das Dashboard zu senden. Das ist der Punkt, an dem viele Teams in der Praxis stolpern, weil sie AgentCore Observability für ein universelles Cloud-Feature halten statt für ein AWS-Runtime-Feature mit Erweiterungsoption. Wer heute schon an Latenzgrenzen bei Bedrock-Agenten arbeitet, kennt dieses Muster aus unserer Analyse zur Latenzreduktion bei AWS-Bedrock-Agenten: Native Komfortfunktionen decken selten die komplette Betriebsrealität ab, sobald mehrere Umgebungen im Spiel sind.

Die eigentliche Nachricht ist also nicht, dass AgentCore Observability jetzt alles kann. Sie ist, dass AWS die Lücke offen benennt und einen Weg zeigt, sie zu schließen, statt sie zu verschweigen.

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellseedream_v4_5; quality=high; 5120x2880PromptAn operator calibrates a physical telemetry manifold connecting an on-premises case, a remote cloud capsule, and a central observation lens using only optical objects. A tight documentary composition emphasizes hands-on consequences in a fully text-free scene with blank surfaces and no legible markings. Photorealistic style image. Mood: practical, focused, and investigative. Avoid: watermark, signature, blurry, low quality, distorted, deformed.

OpenTelemetry als gemeinsamer Transport

Der technische Kern der Lösung ist unspektakulär elegant: Sie nutzt die AWS Distro for OpenTelemetry, kurz ADOT, die im selben Prozess wie die Agentenanwendung läuft. ADOT instrumentiert das Agenten-Framework automatisch, erfasst Spans nach den generativen KI-Semantikkonventionen von OpenTelemetry und exportiert die Telemetrie direkt an den OTLP-Endpunkt von Amazon CloudWatch – authentifiziert per SigV4-Signatur mit IAM-Zugangsdaten.

Damit wird OpenTelemetry zum gemeinsamen Nenner zwischen Welten, die sich sonst kaum vertragen: ein On-Premises-Server, eine GCP-Maschine, eine Azure-VM und die AWS Cloud selbst sprechen alle dieselbe Telemetriesprache und landen im selben Dashboard. Das ist kein neues Protokoll und keine AWS-Erfindung – OpenTelemetry existiert unabhängig von AWS. Die Leistung liegt darin, wie AWS die Authentifizierung und das Routing so verdrahtet hat, dass ein Standardprotokoll ohne Umbau in die firmenspezifische Infrastruktur passt.

Wer schon einmal versucht hat, Logs aus einer On-Premises-Anwendung sauber in ein Cloud-Dashboard zu bekommen, weiß, wie viel Integrationsarbeit normalerweise in solchen Brücken steckt. Genau diese Arbeit verspricht ADOT hier zu automatisieren – nicht durch Magie, sondern durch eine klar dokumentierte Kette aus Auto-Instrumentierung, Signatur und Umgebungsvariablen.

Drei Bausteine für Telemetrie von außerhalb

Damit Telemetrie von Ihrem KI-Agenten überhaupt bei AgentCore Observability ankommt, braucht es laut AWS drei Kernkomponenten. Erstens die ADOT-Auto-Instrumentierung, die die Komplexität des Exports aus Nicht-AWS-Umgebungen übernimmt. Zweitens IAM-Zugangsdaten, mit denen sich ADOT gegenüber CloudWatch authentifiziert und Traces, Metriken und Logs weiterleitet. Drittens eine Reihe von Umgebungsvariablen, die festlegen, wohin die Daten geroutet werden und wie die Authentifizierung erfolgt.

Besonders die Umgebungsvariable mit den Log-Gruppennamen hat praktische Konsequenzen: Ohne einen korrekt gesetzten Ressourcen-Attribut-Wert landen Traces schlicht in generischen CloudWatch-Logs statt im AgentCore-Observability-Dashboard. Der Agentenname, der später im Dashboard erscheint, wird direkt aus dem service.name-Attribut übernommen – ein Detail, das über Monate hinweg für Verwirrung sorgen kann, wenn Teams unterschiedliche Namenskonventionen verwenden.

Diese Kleinteiligkeit ist der eigentliche Praxistest von AgentCore Observability außerhalb von AWS: Die Architektur ist nachvollziehbar, aber sie verlangt Sorgfalt bei jeder einzelnen Umgebungsvariable. Ein vergessenes Flag, und die Telemetrie verschwindet unauffällig im falschen Log-Ziel, ohne dass irgendetwas offensichtlich fehlschlägt.

Der Praxistest: on-premises und Google Cloud Shell im Vergleich

AWS hat den eigenen Ansatz nicht nur beschrieben, sondern in zwei Nicht-AWS-Umgebungen getestet: einem simulierten On-Premises-Server und Google Cloud Shell, einem browserbasierten Terminal auf Google-Cloud-Infrastruktur. In beiden Fällen meldete ein Strands-Agent Sitzungen, Traces und Spans erfolgreich an AgentCore Observability – und zwar innerhalb von zwei bis drei Minuten nach der Ausführung.

Die Detailtiefe der Traces ist bemerkenswert: Im Dashboard erscheinen Spans wie invoke_agent, chat, execute_event_loop_cycle und modellspezifische Aufrufe mit Latenz- und Token-Metriken. Damit ist die Telemetrie aus der GCP-Umgebung laut AWS identisch zu dem, was ein auf der AgentCore Runtime gehosteter Agent produziert – dieselben Sitzungen, dieselben Spans, dieselbe Token-Auswertung, im selben Dashboard.

Das ist der eigentliche Beweis, den ein technischer Bericht mit Codebeispielen liefern kann: nicht die Behauptung, dass etwas funktioniert, sondern die dokumentierte Durchführung auf einer fremden Cloud-Plattform, deren Ergebnis sich im selben Dashboard prüfen lässt wie ein AWS-natives Deployment. Zwei validierte Umgebungen sind kein branchenweiter Beweis, aber sie sind mehr, als die meisten Cloud-Ankündigungen an Substanz liefern.

Interessant ist auch, was AWS im direkten Vergleich zwischen AgentCore-Runtime-Agenten und externen Agenten offenlegt: Bei Deployments direkt auf der AgentCore Runtime konfiguriert sich die Observability automatisch, inklusive Credential-Management über die IAM-Rolle. Bei Nicht-AWS-Umgebungen müssen Sie die OpenTelemetry-Variablen händisch setzen und Zugangsdaten selbst verwalten, gewinnen dafür aber Einsatzflexibilität für Server und Cloud-Umgebungen, die nicht zu AWS gehören. Diese Gegenüberstellung ist kein Nachteil-Versteckspiel, sondern eine ehrliche Trade-off-Beschreibung, wie sie in Cloud-Dokumentationen selten so direkt zu finden ist.

Stille Fehler und andere Fallstricke im Rollout

So saubere Architektur, so viele Stellen, an denen es leise schiefgehen kann. AWS warnt in den eigenen Empfehlungen ausdrücklich davor, dass ADOT bei fehlerhaften Zugangsdaten nicht mit einer klaren Fehlermeldung abbricht, sondern schlicht keine Telemetrie sendet. Die empfohlene Gegenmaßnahme ist unglamourös, aber wirksam: vor dem produktiven Einsatz die Zugangsdaten separat über einen einfachen Identitätsabruf verifizieren, statt sich auf das Schweigen der Konsole zu verlassen.

Zwei weitere praktische Hinweise verdienen Beachtung. ADOT benötigt mindestens Python 3.10, AWS empfiehlt jedoch ausdrücklich Python 3.12 für die beste Kompatibilität – eine Randnotiz, die in produktiven On-Premises-Umgebungen mit älteren Python-Versionen zum echten Blocker werden kann. Und für produktive Deployments rät AWS selbst dazu, langlebige Zugriffsschlüssel durch IAM Roles Anywhere zu ersetzen, weil On-Premises-Workloads damit temporäre Zugangsdaten über X.509-Zertifikate erhalten statt dauerhaft gültiger Schlüssel im Klartext.

Diese Empfehlung ist bemerkenswert selbstkritisch: Die im Bericht gezeigte Schnellkonfiguration mit statischen Zugriffsschlüsseln ist explizit als Einstieg markiert, nicht als Zielarchitektur. Wer AgentCore Observability produktiv über mehrere Clouds hinweg einsetzt, muss diesen Umbau selbst einplanen – ähnlich wie es Teams beim produktiven Einsatz von KI-gestütztem Coding erleben, wo Schnellstart und Produktionsreife regelmäßig zwei verschiedene Baustellen sind.

Ein weiterer Fallstrick betrifft die Konsistenz der Namensgebung über mehrere Umgebungen hinweg. AWS empfiehlt, den Umgebungsnamen direkt im Service-Namen zu verankern, etwa durch beschreibende Bezeichnungen, die Produktionsstatus und Standort erkennbar machen. Ohne diese Disziplin wächst mit jeder neuen Umgebung ein weiterer unklarer Eintrag im Dashboard, bis die eigentliche Beobachtbarkeit im Namenschaos untergeht – ein Risiko, das rein technisch nicht lösbar ist, sondern nur durch verbindliche Konventionen im Team.

Was das für hybride Multi-Cloud-Agentenflotten bedeutet

Am Ende bleibt eine nüchterne Bilanz: AgentCore Observability ist kein AWS-exklusives Feature mehr, sobald man bereit ist, ADOT korrekt zu konfigurieren. Die Telemetrie aus On-Premises- und GCP-Umgebungen ist laut AWS ununterscheidbar von der eines nativen AgentCore-Deployments – Sitzungen, Traces, Span-Metriken und Token-Nutzung in einer einzigen Ansicht. Und obwohl der Test mit Strands Agents arbeitet, gilt das ADOT-Muster laut AWS grundsätzlich für jedes OpenTelemetry-kompatible Agenten-Framework.

Für hybride und Multi-Cloud-Agentenlandschaften heißt das konkret: Die technische Blockade für einheitliches Monitoring existiert nicht mehr, aber die organisatorische Disziplin, die es dafür braucht, wird oft unterschätzt. Wer Namenskonventionen, Umgebungsvariablen und Rotation der Zugangsdaten nicht sauber steuert, bekommt am Ende zwar Observability-Infrastruktur, aber keine verlässliche Sicht auf die eigene Agentenflotte.

Der Mythos vom AWS-exklusiven Agenten-Monitoring ist damit widerlegt – die Behauptung, dass Beobachtbarkeit über Cloud-Grenzen hinweg von selbst funktioniert, aber ebenso. Beides beruht auf denselben Fakten, nur mit gegensätzlicher Betonung. Genau das ist der Unterschied zwischen einer Produktankündigung und einer belastbaren Betriebsentscheidung.