AWS zeigt, wie sich ein Tokenomics-Data-Lake für Amazon Bedrock aufbauen lässt

Eine zentrale Ansicht für Amazon-Bedrock-Aufrufe

Amazon Bedrock bietet bereits eine Protokollierung von Modellaufrufen, die vollständige Anforderungs- und Antwortdatensätze an Amazon Simple Storage Service oder Amazon CloudWatch senden kann. Laut AWS besteht die Einschränkung darin, dass diese Daten innerhalb einzelner AWS-Konten verbleiben. Dadurch ist es schwierig, Aktivitäten im gesamten Unternehmen zu verstehen.

Der vorgeschlagene Data-Lake sammelt unverarbeitete Aufrufprotokolle verknüpfter Konten in einem zentralen Konto. Er richtet sich an Teams, die eine große Zahl von Amazon-Bedrock-Workloads verwalten und über eine aggregierte Rechnung hinausblicken wollen. Abfragen können zeigen, welcher Prompt gesendet wurde, welche Antwort zurückkam, wie viele Token verwendet wurden, welches Modell die Anfrage verarbeitet hat und ob eine Antwort abgeschnitten wurde.

Die aufbereiteten Daten umfassen den Prompt, die Modellantwort, die Anzahl der Eingabe- und Ausgabe-Token, den Modellnamen, den Beendigungsgrund, das Konto, den Zeitstempel und die AWS-Identity-and-Access-Management-Rolle. Laut AWS verändert dies die Perspektive von einer Gesamtsumme wie der Anzahl verwendeter Token hin zu einem aufrufbezogenen Bild davon, welche Inhalte jeder Modellaufruf enthielt und wie effizient er ausgeführt wurde.

So funktioniert die Architektur in fünf Stufen

Das Konzept beginnt damit, dass Amazon Bedrock ein Aufrufprotokoll in eine CloudWatch-Loggruppe schreibt. Abonnementfilter leiten Ereignisse aus jedem Quellkonto an ein CloudWatch-Logs-Ziel im zentralen Konto weiter.

Eine Lambda-Funktion entpackt die komprimierten und codierten Stapel, entfernt Verwaltungsnachrichten von CloudWatch und verschiebt die Identität des Aufrufers in ein einfacheres Feld. Amazon Data Firehose puffert die Datensätze anschließend, konvertiert sie von JSON in Parquet und schreibt sie mithilfe datumsbasierter Pfade wie year=2026/month=08/day=27/ in einen Amazon-S3-Bucket.

Eine AWS-Glue-Tabelle teilt Amazon Athena mit, wie die Dateien gelesen werden sollen. Teams können dann SQL verwenden, um Token-Nutzung, Modellauswahl, Prompts und Aktivitäten nach Nutzer oder Konto zu untersuchen. Laut AWS wird die Architektur als Infrastructure as Code über zwei AWS-CloudFormation-Templates bereitgestellt.

Bereitstellung und Zuordnung von Kosten

Für die Bereitstellung sind ein zentrales Konto und mindestens ein verknüpftes Konto erforderlich. AWS weist jedoch darauf hin, dass es sich dabei um dasselbe Konto handeln kann. Außerdem benötigen Nutzer die mit Zugangsdaten für jedes Konto konfigurierte AWS Command Line Interface, CloudFormation-Berechtigungen, Python 3 mit Boto3 sowie eine geklonte Kopie des AWS Sample Bedrock Invocation Data Lake GitHub-Repositorys.

Der zentrale CloudFormation-Stack muss zuerst bereitgestellt werden. Die Stacks der verknüpften Konten verweisen anschließend auf den ARN des CloudWatch-Logs-Ziels. Danach muss die Protokollierung von Amazon-Bedrock-Modellaufrufen in jedem Quellkonto separat aktiviert werden, da es sich um eine Einstellung auf Kontoebene und nicht um eine CloudFormation-Ressource handelt.

Sobald die Daten den Data-Lake erreichen, können Teams die aufbereitete Tabelle mit Daten aus dem AWS Cost and Usage Report 2.0 verknüpfen. AWS nennt den IAM-ARN als Verknüpfungsschlüssel. Damit lassen sich unter anderem die Kosten von Prompts nach Tag, Team oder Konto sowie die am wenigsten effizienten Aufrufe abfragen.

Warum das Konzept für Bedrock-Teams wichtig ist

Der Data-Lake schließt eine Lücke zwischen kontobezogener Abrechnung und detaillierter operativer Transparenz. Durch die zentrale Erfassung von Aufrufdatensätzen können Plattform- und Machine-Learning-Teams Nutzungsspitzen untersuchen, die Modellnutzung vergleichen, ineffiziente Prompts identifizieren und Aktivitäten Konten oder IAM-Rollen zuordnen.

AWS stellt die CloudFormation-Templates, den Lambda-Code und SQL-Abfragen in seinem AWS Sample Bedrock Invocation Data Lake GitHub-Repository bereit. Das veröffentlichte Konzept bietet Organisationen damit eine wiederholbare Möglichkeit, die Pipeline über mehrere Konten hinweg bereitzustellen. Die resultierenden Daten können Teams anschließend über Amazon Athena abfragen.