aws-genai-llm-chatbot: Ein CDK-Blueprint mit Modellwechsel und RAG, aber ohne fertige Betriebsantworten

Welches Problem der Stack adressiert und für wen er gedacht ist

Ein Chatbot mit Retrieval Augmented Generation besteht aus vielen Teilen, die einzeln wenig nützen: ein Modellendpunkt, ein Vektorspeicher, ein Dokumentenspeicher, eine Anmeldung, eine API und eine Oberfläche. Das Repository liefert genau diese Teile als ein AWS-CDK-Projekt. Die Beschreibung nennt es eine modulare Lösung, um einen Multi-LLM- und Multi-RAG-Chatbot auf AWS auszurollen. Der Adressat ist damit klar umrissen: ein Team, das bereits in AWS arbeitet, Infrastruktur als Code akzeptiert und die Modellwahl nicht fest verdrahten will. Die Themenliste des Repositories deutet auf Anbindungen an Amazon Bedrock, SageMaker, Kendra, OpenSearch, Aurora und pgvector hin. Wer dagegen einen Chatbot sucht, den man ohne Cloud-Konto startet, ist nicht die Zielgruppe. Auch für einzelne Anwendungsfälle ohne RAG ist der Umfang größer als nötig.

Was im Repository tatsächlich als Mechanismus sichtbar ist

Das README beschreibt die Architektur in Form einer Dienstreihung: Amazon Bedrock für den Modellzugriff, Amazon OpenSearch als Vektorspeicher, Amazon S3 für Dokumente, Amazon Cognito für Authentifizierung, AWS Lambda für serverseitige Verarbeitung und Amazon API Gateway als Schnittstelle, dazu eine React-Oberfläche. Der Datenfluss, der sich daraus ableiten lässt, verläuft vom Dokument in S3 über eine Einbettung in den Vektorindex in OpenSearch bis zur Abfrage, die den Kontext an das Modell weitergibt. Als Modellquellen nennt das README Amazon Bedrock mit Claude und Llama 2, SageMaker und benutzerdefinierte Endpunkte; die Repository-Beschreibung ergänzt Anthropic, HuggingFace, OpenAI, Meta, AI21, Cohere und Mistral. Die Beschreibung spricht außerdem von einem GenAIEH Gateway für zusätzlichen Modellzugriff. Wie die Auswahl zwischen diesen Quellen im Code erfolgt, welcher Konfigurationsschlüssel welchen Anbieter aktiviert und wie die Einbettungsmodelle zu den Vektordimensionen passen, geht aus dem vorliegenden Material nicht hervor. Genau dort liegt der Aufwand, den ein Blueprint nicht abnimmt.

Inbetriebnahme: CDK-Version, SeedFarmer und der Schemafehler

Das README nennt als Voraussetzungen ein AWS-Konto mit passenden Rechten, konfigurierte AWS-CLI-Zugangsdaten, Node.js 18 oder neuer mit npm, Python 3.8 oder neuer und eine CDK-CLI, die zu aws-cdk-lib 2.206.0 oder neuer passt. Die Installation erfolgt global über npm:

npm install -g aws-cdk@latest cdk --version

Der Hinweis im README ist konkret: Wenn während des Deployments ein Fehler mit der Meldung Cloud assembly schema version mismatch auftritt, liegt das an einer zu alten CDK-CLI, und das Update über den genannten Befehl behebt ihn. Das ist ein nützlicher Hinweis, weil er einen der häufigsten Einstiegsfehler bei CDK-Projekten benennt. Für den eigentlichen Ausrollvorgang nennt das README AWS CDK und SeedFarmer als Werkzeuge, ohne die vollständige Befehlskette wiederzugeben. Die Dokumentation verweist für Details auf das GitHub-Repository und die Projektseite. Wer den Stack produktiv betreibt, muss also mit der dortigen, hier nicht vorliegenden Anleitung arbeiten. Das ist keine Kritik am Projekt, sondern eine Einschränkung dieser Bewertung: Ohne die vollständige Dokumentation lassen sich weder die genauen Stack-Namen noch die Konfigurationsparameter für Vektorindex oder Modellauswahl bestätigen.

Die Versionsbindung an aws-cdk-lib 2.206.0 ist der wunde Punkt

Das README bindet die CDK-CLI ausdrücklich an die im Projekt verwendete aws-cdk-lib-Version, aktuell 2.206.0. Diese Kopplung ist üblich und trotzdem eine echte Einschränkung: Ein Team, das mehrere CDK-Projekte im selben Konto pflegt, muss die global installierte CLI-Version mit allen Projekten in Einklang bringen. Ein Upgrade der CLI kann ein älteres Projekt brechen, ein Downgrade das neue. Der im README beschriebene Schemafehler ist die sichtbare Folge davon. Hinzu kommt der Versionsrhythmus: Zwischen v4.0.14 im August 2024 und v5.0.0 im Januar 2025 liegt ein größerer Sprung, während die Zwischenreleases davor im Abstand von etwa sechs Wochen erschienen. Ein Major-Sprung bei einer Vorlage dieser Größe bedeutet in der Regel Anpassungsbedarf an bestehenden Forks. Ob v5.0.0 die Modellliste, die Vektorspeicher oder die Authentifizierung umgestellt hat, lässt sich aus dem vorliegenden Material nicht sagen; die Release Notes liegen nicht vor. Wer das Blueprint als Basis forkt, sollte die eigene Anpassung deshalb als Patch auf einen festen Tag behandeln und nicht als dauerhaften Branch.

RAG mit OpenSearch: sinnvoll, aber nicht die einzige Bauform

Das Blueprint setzt für den Vektorspeicher auf Amazon OpenSearch, die Themenliste nennt zusätzlich OpenSearch Serverless, Aurora und pgvector. Das ist eine bewusste Entscheidung für einen verwalteten Suchdienst mit Vektorunterstützung. Der Vorteil liegt in der Betriebsübernahme durch AWS und in der Vertrautheit für Teams, die OpenSearch bereits für Logs oder Volltextsuche nutzen. Der Preis ist ein zusätzlicher Dienst im Konto mit eigener Dimensionierung, eigener Zugriffssteuerung und eigenen Kosten, die unabhängig vom Chatvolumen anfallen. Eine schlankere Alternative wäre pgvector auf einer vorhandenen PostgreSQL-Instanz, etwa Aurora, wodurch ein separater Suchcluster entfällt. Das Repository nennt pgvector als Thema, was darauf hindeutet, dass dieser Weg im Projekt vorgesehen ist. Bestätigen lässt sich aus dem Material nicht, ob beide Speicher gleichwertig unterstützt werden oder ob OpenSearch der Standardpfad ist. Wer RAG nur für wenige tausend Dokumente braucht, sollte diese Frage vor der Entscheidung klären, weil sie die Betriebskosten stärker beeinflusst als die Modellwahl.

Was das README nicht beantwortet

Die Dokumentation im vorliegenden Auszug bleibt auf der Ebene der Aufzählung. Sie nennt Sicherheitsmerkmale wie feinkörnige Zugriffssteuerung, Audit-Logging und Verschlüsselung, ohne zu sagen, welche Cognito-Konstrukte das umsetzen oder wo die Protokolle landen. Sie nennt Kostenoptimierung über Token-Erfassung, ohne ein Kostenmodell oder eine Auswertungsoberfläche zu beschreiben. Sie nennt Gesprächsverlauf mit dauerhafter Speicherung, ohne den Speicher zu benennen. Für eine Bewertung ist das relevant, weil diese Punkte genau die Fragen sind, die im Betrieb auftauchen: Wer darf welches Modell aufrufen, wie lange bleiben Chats liegen, und wie wird der Verbrauch abgerechnet. Ein Blueprint, das diese Antworten nur in der vollständigen Repository-Dokumentation führt, verlagert die Prüfung in den Code. Das ist machbar, kostet aber Zeit, und diese Zeit sollte man vor dem Deployment einplanen, nicht danach.

Lizenz MIT-0 und was sie für Forks bedeutet

Das Projekt steht unter MIT-0. Diese Variante der MIT-Lizenz verzichtet auf die Bedingung, den Urheberrechtshinweis in Kopien oder wesentlichen Teilen mitzuführen. Für ein Unternehmen, das den Code in ein eigenes Produkt einbaut, ist das die entgegenkommendste der gängigen permissiven Lizenzen: keine Namensnennungspflicht, keine Copyleft-Wirkung auf abgeleitete Werke. Das ist keine Rechtsberatung, und die Lizenzdatei im Repository ist maßgeblich. Ein Punkt bleibt trotzdem: Der Code ist ein AWS-Sample. Das bedeutet nicht, dass er unbrauchbar ist, aber es bedeutet, dass der Support über das Repository und die dortige Dokumentation läuft und nicht über einen AWS-Support-Vertrag. Wer den Stack produktiv betreibt, übernimmt Wartung, Upgrades und Sicherheitsupdates selbst. Bei Abhängigkeiten wie aws-cdk-lib, LangChain und den Modell-SDKs ist das ein laufender Posten, der mit jedem Major-Release des Blueprints neu anfällt.

Für wen sich der Einstieg lohnt und was zuerst zu prüfen ist

Der Stack passt zu einem Team, das in AWS zu Hause ist, die Modellwahl offen halten will und RAG auf eigenen Dokumenten braucht. Er passt nicht zu einem Team, das einen Chatbot ohne Cloud-Infrastruktur sucht, oder zu einem, das einen einzelnen Modellendpunkt ohne Vektorsuche betreiben will; dafür ist der Fußabdruck aus OpenSearch, Cognito, S3, Lambda und API Gateway zu groß. Als Alternative mit anderem Ansatz sei LangChain genannt: Es ist eine Bibliothek, keine Infrastrukturvorlage, und überlässt dem Entwickler die Wahl von Vektorspeicher, API-Schicht und Authentifizierung. Der Unterschied ist grundsätzlich. Das Blueprint nimmt Entscheidungen vorweg und liefert lauffähige Infrastruktur; LangChain liefert Bausteine und verlangt diese Entscheidungen. Wer schnell zu einem vorführbaren System kommen will, ist mit dem Blueprint besser bedient. Wer die Kontrolle über jede Komponente braucht, baut mit einer Bibliothek selbst. Vor dem ersten Deploy sind drei Dinge zu klären: die exakte aws-cdk-lib-Version, die das Repository pinnt, die Verfügbarkeit der gewünschten Bedrock-Modelle in der Zielregion und der Vektorspeicher, den das Projekt standardmäßig konfiguriert.

Redaktionelles Fazit

Wer einen AWS-zentrierten Chatbot mit austauschbarem Modell und Vektor-RAG als Ausgangspunkt für eigene Anpassungen sucht, findet hier ein CDK-Blueprint, das diesen Rahmen abdeckt. Wer eine verwaltete Chat-Plattform ohne Infrastrukturarbeit, einen reinen API-Dienst oder ein System mit dokumentierter Upgrade-Garantie erwartet, sollte woanders suchen. Vor dem ersten Deploy ist zu prüfen, welche aws-cdk-lib-Version das Repository tatsächlich pinnt, welche Region für Bedrock-Modelle freigeschaltet ist und ob die im README genannten Dienste (OpenSearch, Cognito, S3, Lambda, API Gateway) im Zielkonto bereits belegt sind.

Offizielle Quellen

1. aws-samples/aws-genai-llm-chatbot on GitHub
2. License: MIT-0
3. Project website
4. README
5. Releases