Praktische Anwendung von Bedrock AgentCore: Terraform, LangGraph und die dabei auftretenden Probleme.
Was AgentCore’s Runtime, Gateway, Memory und Identity leisten, plus sechs typische Probleme bei der Implementierung, ungefähre Kosten sowie ein Vergleich mit dem Hosten eines selbst erstellten Agents auf AWS.
Quellen: Amazon Bedrock AgentCore, What It Is, How to Use It, and What Hosting Looks Like
Das Manuell-Hosten eines KI-Agenten auf AWS bedeutet, dass man selbst Probleme wie Sitzungsisolation, Tool-Zugriff, Speicherverwaltung und Authentifizierung lösen muss. Amazon Bedrock AgentCore ist die verwaltete Version für dieses Problem und steht seit Oktober 2025 allgemein zur Verfügung. Eine praktische Möglichkeit, eine solche Plattform zu bewerten, besteht darin, auf das Lesen darüber zu verzichten und etwas Reales zu entwickeln – ein kleiner, nur zum Lesen geeigneter DevOps-Triage-Agent erfüllte hier diesen Zweck. Er wurde mit Terraform statt des eigenen CLI-Wizards von AWS bereitgestellt und mit LangGraph anstelle des Strands SDK von AWS programmiert. Beide Entscheidungen waren bewusst getroffen, denn es ging darum zu erfahren, was außerhalb der vorgegebenen Wege funktioniert.
Was AgentCore ist
AgentCore ist eine Sammlung von verwalteten Komponenten, die die langweiligen, leistungsrelevanten Aspekte des Betriebs eines Agents in der Produktion abdecken und es ermöglichen, dass jedes bestehende Agent-Framework unverändert bleibt. Das Versprechen bezüglich beliebiger Frameworks ist das Hauptversprechen von AgentCore und hält größtenteils Ein. LangGraph, LangChain, CrewAI, Strands sowie einfache API-Aufrufe werden alle akzeptiert.
Die Komponenten und ihre Aufgaben:
- Runtime speichert den Code des Agents und stellt jeder Sitzung eine eigene, isolierte MicroVM zur Verfügung. Er skaliert auf Null, wenn er nicht in Gebrauch ist, und wird während der Arbeit sekundengenau abgerechnet.
- Gateway wandelt bestehende Lambda-Funktionen oder APIs in MCP-kompatible Tools um, die ein Agent aufrufen kann – somit ist kein handgeschriebener MCP-Server erforderlich.
- Memory speichert den Konversationsverlauf als kurzfristige Ereignisse und kann optional langfristiges semantisches Wissen über verschiedene Sitzungen hinweg extrahieren.
In einer Ankündigung auf dem AWS Summit im Juni 2026 wurden eine Harness-Schicht sowie eine native Websuchfunktion hinzugefügt. Beide sind noch zu neu, um bereits für kritische Infrastrukturen verwendet zu werden.
Die Onboarding-Prozesse wurden bereits einmal umgestaltet. Das ursprüngliche Starter Toolkit CLI gilt nun als veraltet und wurde durch ein auf CDK basierendes npm-Paket namens @aws/agentcore ersetzt. Ein Tutorial, das die Konfiguration sowie den Start von agentcore als getrennte Schritte zeigt, beschreibt den alten Ablauf. Diese Details sind wichtig, da sie das Tempo des Wandels verdeutlichen: Neun Monate nach der allgemeinen Verfügbarkeit wurde der Einstiegsweg bereits erneut überarbeitet, wodurch alles, was über das Produkt geschrieben wird, eine begrenzte Gültigkeit hat.
Das Testprojekt
Der Agent beantwortet Fragen wie zum Beispiel, ob irgendwelche CloudWatch-Alarms ausgelöst werden oder wie der Status einer bestimmten EC2-Instanz ist. Er verfügt über zwei echte, nur zum Lesen geeignete Tools, sodass nichts von dem, was er nutzen kann, die Infrastruktur ändern, sondern lediglich beobachten kann. Er merkt sich die Gespräche über mehrere Interaktionen hinweg, und jeder Übergang zwischen Komponenten wird authentifiziert.
LangGraph wurde gegenüber Strands gewählt, weil Strands das eigene Framework von AWS ist und in allen offiziellen Beispielen die reibungsloseste Umsetzung bietet. Die Verwendung eines anderen Frameworks stellte die eigentliche Prüfung für die Behauptung, dass jedes Framework geeignet sei, dar – und es passte zu den bereits vorhandenen Tools. Aus dem gleichen Grund wurde Terraform gegenüber der CLI bevorzugt. Der Assistent ist darauf ausgelegt, eine Demo schnell zum Laufen zu bringen; das Ziel bestand darin, alle IAM-Vertrauensbeziehungen sowie alle Verbindungen zwischen Komponenten sichtbar zu machen, anstatt sie unsichtbar generieren zu lassen. Diese Sichtbarkeit erwies sich als wichtiger, als erwartet.
Die Architektur besteht aus einem Laufzeit-Container, der den LangGraph-Agenten ausführt. Dieser kommuniziert mit einem Gateway, das über MCP zwei von Lambda unterstützte Tools bereitstellt. AgentCore Memory speichert die Konversationen, und Cognito stellt für jeden Schritt Machine-to-Machine-Tokens aus.
Klicken Sie vor dem Scripting weiter
Bevor irgendein Terraform-Code geschrieben wurde, wurde die Konsole-Version der Einrichtung einmal durchgearbeitet, hauptsächlich um zu erkennen, was automatisiert wurde. Diese Gewohnheit lohnt sich auch dann, wenn Terraform die eigentliche Bereitstellung übernimmt, denn das Lesen der Infrastrukturdateien fällt viel leichter, nachdem man die Formulare gesehen hat, die sie ausfüllen.
Das Container-Registry verdient eine manuelle Durchführung, unabhängig davon, welches Tool den Rest übernimmt, da es der Schritt ist, den Terraform nicht ausführen kann. Die Erstellung des Repositoriums geschieht auf einem einzigen Konsolebildschirm. Das Image hingegen muss auf andere Weise bereitgestellt werden, da die Konsole keinen Button besitzt, mit dem ein Dockerfile erstellt werden kann. Das geschieht in einer Terminal-Sitzung mit „docker buildx build“ für die Linux/Arm64-Plattform, gefolgt von einem „push“. Das Manuell-Nennen der Plattform ist dabei entscheidend. Wenn man dies weglässt, wird das Image problemlos erstellt, wird aber anschließend stillschweigend abgelehnt, wenn Runtime versucht, es zu starten – schließlich läuft Runtime nur auf Graviton.
Sobald das Image bereitsteht, zeigt die Konsole seine genaue URI an. Dieser String ist der einzige Zustandswert, der von der manuellen Arbeit in das Wissen von Terraform übertragen werden muss – egal ob in eine tfvars-Datei oder in das Feld für das Container-Image von Runtime für diejenigen, die weiterhin in der Konsole arbeiten.
Die AgentCore-Einstellungen für Memory, Gateway und Runtime befinden sich in eigenen Abschnitten der Bedrock-Konsole. Jede davon ist ein Formular mit denselben Feldern wie bei Terraform, was sinnvoll ist, da Terraform im Hintergrund dieselbe API verwendet.
- Memory fragt nach einem Namen sowie der Dauer, für die kurzfristige Ereignisse gespeichert werden sollen.
- Gateway fragt nach einem Protokoll, einer Ausführungsrolle sowie einer Methode zur Authentifizierung der Aufrufer. Das unten beschriebene Problem mit Cognito’s Audience versus Client ID tritt hier auf, in Form eines Dropdown-Menüs, das eine Auswahl erzwingt.
- Runtime fragt nach der Registry-URI, einer Rolle sowie derselben Autorisierungs-Einrichtung wie bei Gateway.
Alles ist einfach, sobald die Formulare vor einem liegen. Terraform bleibt dennoch die bessere Wahl für alles, was dauerhaft genutzt werden soll – schließlich ist das Durchklicken von sieben Formularen in drei Konsoolenabschnitten kein Deployment-Prozess, den jemand wiederholen oder einem Kollegen übergeben möchte.
Where it bit
Images must be ARM64
Runtime is Graviton-only, with no exceptions. A plain docker build on most laptops yields an amd64 image that is silently refused at deploy time. Every build needs the buildx command with the arm64 platform flag. A comment directly above the FROM line in the Dockerfile is a cheap safeguard, because it will be forgotten otherwise.
The Gateway's Lambda contract
Mehrere Blogbeiträge zeigen ein Lambda-Event, das in einem Umfeld mit toolName und Parametern eingebettet ist. Das eigentliche Event sind die Eingabeeigenschaften der Tool als flaches Dictionary. Der tatsächliche Tool-Name wird über context.client_context.custom unter dem Schlüssel bedrockAgentCoreToolName bereitgestellt, vorangestellt vom Namen des Gateway-Ziels sowie einem Trennzeichen aus drei Unterstrichen. Der Unterschied wurde erst durch das direkte Lesen der eigenen Lambda-Ziel-Dokumentation von AWS und nicht durch das Vertrauen auf indirekte Zusammenfassungen offensichtlich. Ein Großteil dessen, was über dieses Produkt verbreitet wird, stammt aus der Vorab-Testphase oder ist einfach falsch.
Cognito-Tokens enthalten keinen aud-Claim
Dieses Problem erforderte wirklich Zeit zum Nachdenken. Bei der Verwendung von Cognito für die Authentifizierung zwischen Maschinen über den Grant „client_credentials“ ohne menschliches Anmelden gibt Cognito ein Zugriffstoken aus und kein ID-Token. Zugriffstokens enthalten niemals den Wert „aud“. Nur ID-Tokens tun das, und bei einem M2M-Flow gibt es kein ID-Token, da es keinen Benutzer gibt, dem eines ausgestellt werden könnte. Wenn der JWT-Autorisator von AgentCore den Wert „allowed_audience“ gegen ein solches Token überprüft, ergibt sich eine 403-Fehlermeldung ohne offensichtlichen Grund. Die Lösung ist der Parameter „allowed_clients“, der die in Cognito-Zugriffstoken enthaltene Angabe „client_id“ überprüft.
boto3 kann keinen durch JWT geschützten Runtime aufrufen
Das war die größte Überraschung – es handelt sich dabei nicht um eine Workaround-Lösung, sondern um einen Satz in AWSs eigener API-Dokumentation. Wenn der Agent eine OAuth-basierte Eingangsauthentifizierung verwendet, kann InvokeAgentRuntime überhaupt nicht über das AWS SDK aufgerufen werden. Stattdessen wird eine raw HTTPS-Anfrage mit einemBearer-Token im Authorization-Header gesendet, die an eine manuell erstellte URL übermittelt wird, bei der der ARN des Laufzeitumfelds im Pfad prozentenkodiert ist. Jedes boto3-Beispiel geht davon aus, dass die Standard-IAM- und SigV4-Pfade verwendet werden. Sobald ein custom_jwt_authorizer konfiguriert ist – was für alles Notwendige außerhalb rein interner Systeme der Fall sein sollte – gilt diese ganze Kategorie von Beispielen nicht mehr.
Konflikt mit einem Python-Paket
Das mcp Python-Paket veröffentlichte eine Major-Version 2.0.0, bei der interne Module umbenannt wurden, während langchain-mcp-adapters noch nicht nachgezogen hat. Es deklariert Kompatibilität mit mcp ab Version 1.24.0, ohne Obergrenze festzulegen; daher führt ein einfacher pip install mittlerweile zu einer fehlerhaften Kombination. Zumindest tritt ein deutlicher Fehler auf – ein Importfehler statt eines subtilen Bugs. Das Testprojekt festlegt mcp auf Version 1.29.0. Überprüfen Sie, ob diese Festlegung noch notwendig ist, da stille Patches eine Korrektur in überflüssigen Code umwandeln können.
Die Bereitstellung ist mehr als nur ein Apply
Die Runtime-Ressource benötigt ein Container-Bild, das bereits im Registry vorhanden ist, und Terraform kann kein Bild in seinem eigenen Apply-Prozess erstellen und hochladen. Die richtige Reihenfolge besteht darin, zunächst nur das Registry-Repository zu erstellen, das Bild außerhalb von Terraform zu bauen und hochzuladen, und anschließend den Rest anzuwenden. Ingenieure in weitaus größeren AgentCore-Stacks haben CodeBuild über null_resource in das Terraform-Diagramm integriert, um diese Lücke zu schließen. Das ist ein sinnvoller nächster Schritt und zeigt, dass dieses Problem weit verbreitet ist und kein persönlicher Fehler darstellt.
Der Gesprächszustand sollte an einem Ort gespeichert werden
Es handelt sich nicht um einen Fehler, sondern um eine strukturelle Entscheidung: Der Agent verwendet absichtlich nicht LangGraphs eigenen Checkpointer für den Gesprächszustand, obwohl die meisten LangGraph-Tutorials diesen als Standard vorsehen. Laufende Sitzungen können auf Null skaliert werden und zwischen den Aufrufen eine neue MicroVM übergeben, wodurch alles, was nur im Prozessspeicher gespeichert ist, verschwindet. AgentCore Memory stellt die dauerhafte Speicherung auf dieser Seite dar. Der Betrieb eines lokalen Checkpointers neben Memory führt dazu, dass derselbe Dialog zwei konkurrierende Aufzeichnungen erhält, die früher oder später unterschiedliche Angaben zum Gesagten machen werden. Man muss sich für eine Lösung entscheiden. Memory ist die sinnvollere Wahl, da sie auch bei einem Neustart erhalten bleibt.
Kosten
Die Preise basieren auf dem Verbrauch ohne Mindestbetrag – ein guter Ansatz für etwas, das den größten Teil seiner Zeit damit verbringt, auf eine Antwort eines LLM zu warten. Die Folge ist, dass die Rechnung aus mehreren kleinen, separat gemessenen Posten besteht und nicht aus einer einzigen Zahl. Stand derzeit:
- Die Laufzeitkosten betragen etwa 9 Cent pro vCPU-Stunde und rund 1 Cent pro GB-Stunde; sie werden sekundengenau abgerechnet, wobei eine Mindestdauer von einer Sekunde gilt. Somit kostet eine dreisekündige Anfrage drei Sekunden und nicht eine aufgerundete Minute.
- Die Gateway-Kosten liegen bei etwa 0,5 Cent pro tausend MCP-Aufrufe.
- Der Speicher wird mit 0,25 Cent pro 1.000 gespeicherten Ereignissen sowie 0,5 Cent pro 1.000 abgerufenen Ereignissen berechnet.
- Es fallen keine Kosten für die Identitätsverwaltung an, wenn sie über Runtime oder Gateway genutzt wird anstelle eines direkten Aufrufs – das gilt für fast die gesamte Konfiguration.
Davon sind die Aufrufe des Modells nicht enthalten, die bei etwas mehr als nur leichtem Test die höchste Kostenposition darstellen und auf die AgentCore keinen Einfluss hat. Das ist einfach der Preis, den Bedrock für das ausgewählte Modell verlangt. Neue Konten erhalten zweihundert Dollar an AgentCore-Credits, was ausreicht, um ein solches Projekt mehrfach zu erstellen und wieder zu zerstören. Vor der Verwendung irgendwelcher Zahlen sollte die offizielle Preisseite überprüft werden, da sich die Preise seit der allgemeinen Verfügbarkeit bereits mehrfach geändert haben und voraussichtlich wieder ändern werden.
Gemanagte Plattform oder selbst erstellte Hosting-Lösung
Eine selbst erstellte Agent-Hosting-Stack-Lösung bietet einen nützlichen Vergleich, und das ehrliche Fazit hat zwei Seiten. AgentCore bietet Sitzungsisolation, ein verwaltetes MCP-Gateway, dauerhafte Speicherung sowie ein Authentifizierungsmodell, die perfekt miteinander zusammenarbeiten – schneller als das manuelle Erstellen der IAM-Vertrauensrichtlinien, wofür hier Stunden aufgewendet wurden. Das bedeutet eine große Menge an unstrukturiertem Infrastrukturarbeit, die dadurch entfällt. Für alle, deren Aufgabe es ist, den Agent zu entwickeln und nicht die darunterliegende Hosting-Plattform, lohnt sich dieser Tausch vermutlich.
Was die Plattform nicht bietet, ist eine Beurteilung darüber, was einem Agenten erlaubt werden sollte, wie viel es in der Praxis kosten sollte oder ob irgendein Framework im Stillen dasjenige bedeutet, bei dem AWSs eigene Lösung den am besten dokumentierten Weg bietet. Auch Stabilität fehlt. Die CLI wurde bereits einmal umgebaut, und es traten mindestens drei Fälle auf, in denen die AWS-Dokumentation in kleinen, aber entscheidenden Aspekten nicht mit der tatsächlichen API übereinstimmte. All das macht das Produkt noch lange nicht schlecht. Es beschreibt einfach einen jungen, schnell entwickelten Managed Service, den man besser vor dem Start kennen sollte als erst mitten in einem Deployment herauszufinden.
Alles davon wurde tatsächlich implementiert, nicht nur beschrieben. Jede Ressource wird über Terraform verwaltet, der Agent ist vollständig, die Lambda-Tools existieren, und das Testumfeld benötigt keine AWS-Anmeldeinformationen – daher wurde zunächst alles überprüft, was überprüft werden konnte. Bei einer ähnlichen Implementierung sind die wahrscheinlichsten Stellen, an denen man auf dieselben Probleme stößt, die ARM64-Plattformflagge für das Image sowie der Parameter allowed_clients in der Cognito-Autorisierungs-Einstellung.