Bedrock Chat: ein AWS-natives Chat-Frontend mit Bot-Store, RAG und Agents
AWS-native chatbot using Bedrock
Auf einen Blick
- Was ist das?
- aws-samples/bedrock-chat ist ein TypeScript-Projekt, das Amazon Bedrock über eine React-Oberfläche, Cognito, DynamoDB und optional OpenSearch Serverless zugänglich macht. Der interessante Teil ist nicht der Chat, sondern die Mandantenfähigkeit der Knowledge Bases und die Rechtevergabe über Cognito-Gruppen.
- Für wen ist es gedacht?
- Wer Bedrock ohne eigenen Frontend-Bau evaluieren will und ohnehin in einer der genannten Regionen mit OpenSearch Serverless arbeitet, bekommt hier eine vollständige Referenzarchitektur über CDK. Wer einen schlanken Chat-Endpunkt für eine einzelne Anwendung braucht, ist mit dem direkten Converse-API-Aufruf oder einem kleineren Wrapper besser bedient, weil Cognito, DynamoDB-Tabellen und Step Functions sonst nur mitlaufen.
- Darf ich es kommerziell nutzen?
- Ja. MIT-0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 1 Tag.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich TypeScript, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Welches Problem BrChat löst und für wen es gedacht ist
Ein Modellzugriff über Amazon Bedrock ist schnell aufgerufen. Was danach kommt, ist die eigentliche Arbeit: Authentifizierung, Gesprächsverlauf, Rechte, Wissensanbindung, Kostenübersicht. Genau diese Schicht liefert das Repository mit. Das README beschreibt die Anwendung als mehrsprachige generative KI-Plattform auf Basis von Amazon Bedrock und nennt vier Funktionen: Chat, angepasste Bots mit Wissen (RAG), Weitergabe von Bots über einen Bot-Store und Aufgabenautomatisierung mit Agents.
Die Zielgruppe lässt sich am Aufbau ablesen. Es ist kein SDK und keine Bibliothek, sondern eine deploybare Anwendung mit React-Frontend, Cognito, DynamoDB und einem CDK-Stack namens BedrockChatStack. Wer eine interne Chat-Oberfläche für eine Organisation braucht und die Betriebsverantwortung in AWS behalten will, findet hier eine Vorlage. Wer nur programmatisch mit einem Modell sprechen will, findet hier zu viel.
Bemerkenswert ist die Governance-Position im README. Angepasste Bots darf nicht jeder anlegen. Nur Mitglieder der Cognito-Gruppe CreatingBotAllowed dürfen das, und die Gruppe wird laut Dokumentation über die Konsole oder die AWS CLI gepflegt. Das ist eine bewusste Einschränkung: die Plattform geht davon aus, dass Bot-Erstellung ein privilegierter Vorgang ist, weil daran Kosten und Datenzugriff hängen.
Multi-Tenant Knowledge Bases: der eigentliche technische Kniff
Der interessanteste Abschnitt des README behandelt ein Kontingentproblem. In Amazon Bedrock Knowledge Bases liegt die Zahl der Knowledge Bases pro AWS-Konto standardmäßig bei 100. Wer vielen Bots eigenes Wissen geben will, läuft gegen diese Wand. Die Lösung im Projekt heißt Multi-Tenant-Modus: eine Knowledge Base mit gemeinsamen Einstellungen wird von mehreren Bots geteilt, und die von jedem Bot hochgeladenen Dateien werden über die Bot-ID als Metadaten gefiltert.
Das ist ein sauberer Ansatz, aber er verschiebt die Komplexität. Die Trennung liegt jetzt in den Metadaten und in der Filterlogik, nicht mehr in der physischen Trennung der Indizes. Ein Fehler bei der Metadatenzuordnung wäre ein Fehler bei der Datentrennung. Das README benennt dieses Risiko nicht, und die Dokumentation zu den Filtern liegt außerhalb des hier vorliegenden Materials.
Neu erstellte Bots haben den Multi-Tenant-Modus laut README standardmäßig aktiv. Für Bestandsbots gibt es zwei Wege: in den Bot-Wissenseinstellungen auf Create a tenant in a shared Knowledge Base umstellen, oder in großen Mengen per DynamoDB-Statement. Das README zeigt dafür ein aws dynamodb execute-statement mit einem UPDATE auf BedrockKnowledgeBase.type='shared' und SyncStatus='QUEUED' sowie anschließend ein aws stepfunctions start-execution auf die EmbeddingStateMachineArn. Wer das nachvollziehen will, muss die Tabellen- und State-Machine-Namen aus dem CloudFormation-Stack kennen. Das ist Massenmigration per CLI, kein geführter Assistent.
Deployment über bin.sh und die Regionalgrenzen
Der Einstieg ist bewusst kurz gehalten. Das README nennt vier Schritte: in us-east-1 den Bedrock Model access öffnen, Manage model access wählen, die gewünschten Modelle markieren und Save changes drücken. Danach CloudShell in der Zielregion starten und folgende Befehle ausführen:
git clone https://github.com/aws-samples/bedrock-chat.git cd bedrock-chat chmod +x bin.sh ./bin.sh
Das Skript fragt laut README, ob ein neuer Nutzer angelegt wird oder ob v3 verwendet wird. Der letzte Satz der vorliegenden README-Fassung bricht an dieser Stelle ab, das weitere Verhalten von bin.sh lässt sich aus dem Material nicht belegen.
Die Regionalgrenzen sind der praktische Knackpunkt. Für Bots und Knowledge Bases empfiehlt das README eine Region, in der OpenSearch Serverless und die Ingestion-APIs verfügbar sind, weil OpenSearch Serverless die Standardwahl ist. Genannt werden unter anderem us-east-1, us-east-2, us-west-1, us-west-2, ap-south-1, ap-northeast-1, ap-northeast-2, ap-southeast-1, ap-southeast-2, ca-central-1, eu-central-1, eu-west-1, eu-west-2, eu-south-2, eu-north-1 und sa-east-1, Stand August 2025. Der Parameter bedrock-region muss zusätzlich in einer Region liegen, in der Bedrock selbst verfügbar ist. Zwei Regionen müssen also zusammenpassen, und wer Datenresidenz in einer nicht gelisteten Region braucht, ist hier falsch.
Bots, Bot-Store und publizierte APIs
Ein Bot besteht im Projekt aus Instruktionen und Wissen. Das Wissen kann aus eigenen Uploads stammen oder aus einer bereits vorhandenen Amazon Bedrock Knowledge Base importiert werden. Das README zeigt dazu einen Screenshot mit der Bezeichnung import_existing_kb. Die Feinheit steckt in der Rechtevergabe: Screenshots tragen die Namen fine_grained_permission und bot_store, und das README verweist auf ein separates Dokument PUBLISH_API.md, wenn ein angepasster Bot als eigenständige API veröffentlicht werden soll.
Das ist mehr als ein Chatfenster. Ein Bot wird zu einem Artefakt, das andere Nutzer über den Store finden und das nach außen als Endpunkt auftreten kann. Genau hier wird die Cognito-Gruppe CreatingBotAllowed relevant: die Erlaubnis zur Bot-Erstellung ist gleichzeitig die Erlaubnis, etwas zu bauen, das später geteilt oder veröffentlicht wird.
Die administrativen Funktionen liegen in einem eigenen Dokument ADMINISTRATOR.md. Das README nennt API Management, das Markieren von Bots als essential und die Auswertung der Bot-Nutzung. Ein Screenshot heißt admin_bot_analytics. Wie diese Auswertung technisch entsteht, ob über CloudWatch, DynamoDB-Streams oder Athena, geht aus dem vorliegenden Material nicht hervor.
Agents und der Unterschied zum reinen RAG-Bot
Das README trennt Agents ausdrücklich von der Wissensanbindung. Bei einem Bot mit Wissen wird eine Frage gegen einen Index gestellt. Ein Agent dagegen kann laut Dokumentation Informationen aus externen Werkzeugen holen oder eine Aufgabe in mehrere Schritte zerlegen. Das Beispiel im README ist genau das: eine Nutzerfrage beantworten, indem der Agent nötige Informationen beschafft oder die Aufgabe aufteilt.
Für Betreiber bedeutet das eine andere Fehlerklasse. Ein RAG-Bot liefert eine schlechte Antwort, wenn der Index nichts Passendes enthält. Ein Agent kann zusätzlich an einem Werkzeug scheitern, an einer Zwischenentscheidung oder an einer Schleife. Die Dokumentation dazu liegt in AGENT.md, das hier nicht vorliegt. Wer Agents produktiv einsetzen will, sollte diese Datei vor der Entscheidung lesen, weil dort die Grenzen der Werkzeuganbindung stehen müssen.
Die Themenliste des Repositories nennt unter anderem websockets und streaming-response. Der Chat läuft also nicht über klassische Anfrage-Antwort-Zyklen, sondern über eine persistente Verbindung. Das ist für lange Modellantworten sinnvoll, macht aber die Fehlerbehandlung aufwendiger: ein Abbruch mitten im Stream ist ein anderer Zustand als eine fehlgeschlagene HTTP-Anfrage.
Die V2-zu-V3-Migration ist die größte Fallgrube
Das README setzt eine Warnung direkt unter den Titel. V3 ist erschienen, und ohne sorgfältige Prüfung des Migrationsleitfadens werden Bots aus V2 unbrauchbar. Der Satz ist in Großbuchstaben gesetzt, was in einer ansonsten sachlichen README auffällt. Die Ursache ist plausibel: mit V3 ändert sich das Datenmodell der Bots, sichtbar an Tabellennamen wie BotTableNameV3 und an einem neuen Feld BedrockKnowledgeBase.type. Wer von V2 kommt, muss also nicht nur neu deployen, sondern Datenbestände umschreiben.
Für die Bewertung heißt das: die Upgrade-Kosten dieses Projekts sind nicht auf das Deployment beschränkt. Ein Sprung über eine Hauptversion kann eine Datenmigration über DynamoDB-Statements und einen Step-Functions-Lauf erfordern. Wer die Anwendung nur testet, merkt davon nichts. Wer sie mit echten Bots betreibt, muss den Migrationsleitfaden unter docs/migration/V2_TO_V3.md vor dem Update lesen.
Die Release-Historie passt zu einem aktiv gepflegten Projekt: v3.15.6 und v3.16.0 im April 2026, v3.17.0 im Juni 2026, der letzte Push im September 2026. Die Abstände sind unregelmäßig, aber nicht groß. Ob Fehlerkorrekturen oder Funktionserweiterungen überwiegen, lässt sich aus den hier vorliegenden Daten nicht ableiten.
Lizenz MIT-0 und was das praktisch bedeutet
Das Repository steht unter MIT-0. Das ist die MIT-Lizenz ohne die Bedingung, den Urheberrechtsvermerk in Kopien weiterzuführen. Für Teams, die den Code als Ausgangspunkt für ein internes oder kommerzielles Produkt nehmen wollen, ist das die niedrigste denkbare Hürde auf der Lizenzseite. Eine Rechtsberatung ersetzt das nicht, und die Lizenz des Repositories sagt nichts über die Bedingungen der AWS-Dienste, die die Anwendung aufruft.
Der wichtigere Vorbehalt steht im Repository-Namen selbst: aws-samples. Es handelt sich um ein Beispielprojekt der AWS-Organisation, nicht um ein verwaltetes Produkt mit Support-Vertrag. Das README verweist auf einen Roadmap-Label in den Issues und auf einen Workshop im AWS-Katalog. Beides deutet auf Pflege hin, aber niemand garantiert Reaktionszeiten oder Rückwärtskompatibilität. Die V2-zu-V3-Warnung ist der Beleg dafür, dass Hauptversionen ohne Rücksicht auf Bestandsdaten möglich sind.
Für die Betriebskosten heißt das: die Wartung liegt beim eigenen Team. Bei einem CDK-Stack dieser Größe bedeutet ein Upgrade typischerweise, den Stack neu auszurollen und dabei die Datenmigration einzuplanen. Genau dieser Aufwand sollte vor der Entscheidung geschätzt werden, nicht nach dem ersten Produktiveinsatz.
Wann ein direkter Bedrock-Aufruf die bessere Wahl ist
Die naheliegende Alternative ist kein anderes Chatprodukt, sondern der Verzicht auf eine eigene Anwendungsschicht. Amazon Bedrock bietet mit der Converse-API einen Aufruf, der Modell, Nachrichten und Systemanweisung entgegennimmt. Wer eine einzelne interne Anwendung mit einem festen Modell und einer festen Anweisung braucht, kommt damit aus. Der Unterschied liegt nicht in der Antwortqualität, sondern im Umfang: kein Cognito, keine DynamoDB-Tabellen für Verlauf und Bots, keine Step Functions für Embedding-Synchronisation, kein Bot-Store.
Bedrock Chat lohnt sich, sobald mehrere Nutzer mit unterschiedlichen Rechten auf dieselbe Instanz zugreifen, sobald Wissen pro Bot getrennt werden muss und sobald Bots wiederverwendet statt neu gebaut werden sollen. Genau diese drei Anforderungen erzeugen den Aufwand, den das Projekt bereits gelöst hat.
Umgekehrt gibt es einen Fall, in dem BrChat das falsche Werkzeug ist: wenn die Knowledge Bases bereits außerhalb der Anwendung verwaltet werden und nur eine Oberfläche fehlt. Dann bringt man Cognito, Bot-Tabellen und die Multi-Tenant-Logik mit, ohne sie zu nutzen. Der Import bestehender Knowledge Bases ist möglich, aber die Frage, ob der Multi-Tenant-Modus dabei greift oder ob die importierte Base unverändert bleibt, lässt sich aus dem vorliegenden README nicht beantworten.
Redaktionelles Fazit
Wer Bedrock ohne eigenen Frontend-Bau evaluieren will und ohnehin in einer der genannten Regionen mit OpenSearch Serverless arbeitet, bekommt hier eine vollständige Referenzarchitektur über CDK. Wer einen schlanken Chat-Endpunkt für eine einzelne Anwendung braucht, ist mit dem direkten Converse-API-Aufruf oder einem kleineren Wrapper besser bedient, weil Cognito, DynamoDB-Tabellen und Step Functions sonst nur mitlaufen. Wer einen bestehenden Knowledge-Base-Bestand migriert, sollte vor allem den Zustand der Bot-Datensätze prüfen: der Sprung von V2 auf V3 macht Bots ohne Migration unbrauchbar, und die im README gezeigten execute-statement-Befehle setzen voraus, dass BotTableNameV3 und EmbeddingStateMachineArn bereits bekannt sind.
Community-Notizen