AWS beschreibt fünf Stufen der Bedrock-Kostensteuerung von Zuordnung und Protokollen bis Budgets und Cache

AWS veröffentlichte am 30. Oktober einen fünfstufigen Betriebsansatz für Amazon-Bedrock-Kosten: zuordnen, beobachten, Budgets durchsetzen, Grundeinstellungen optimieren und regelmäßig steuern. Unsere technische Ausgabe erscheint am 1. November und belässt das Originaldatum. Der Beitrag ist eine Anleitung des Anbieters für Plattform- und FinOps-Teams, kein von dieser Redaktion gemessener Einsparbericht. Agentische Aufgaben können viele Modellaufrufe und wachsenden Kontext enthalten; die Anzahl sichtbarer Nutzerdialoge unterschätzt daher möglicherweise die Tokens und Kosten eines Workflows.

Stufe eins klärt die Verantwortung für Ausgaben. Laut AWS lässt sich Bedrock-Inferenz in CUR 2.0 über die Spalte `line_item_iam_principal` dem aufrufenden IAM-Prinzipal zuordnen. Dazu werden Prinzipaldaten im Export aktiviert, IAM-Identitäten nach Team oder Anwendung markiert, diese Merkmale als Kostenverteilungstags freigeschaltet und anschließend analysiert. In Cost Explorer können sie erst 24 bis 48 Stunden nach Aktivierung erscheinen. Ruft ein Gateway für alle Nutzer über dieselbe IAM-Rolle auf, wird alles dieser gemeinsamen Rolle zugerechnet. AWS empfiehlt pro Nutzer eine übernommene Aufrufrolle mit Sitzungsnamen und -tags sowie zeitweilig zwischengespeicherten Zugangsdaten, um die Zuordnung wiederherzustellen. Dafür sind passende IAM-Rechte und ein sorgfältiges Sitzungsmodell nötig.

Stufe zwei macht einzelne Anfragen sichtbar. CUR zeigt die finanzielle Zuordnung, nicht den Grund für hohen Tokenverbrauch einer Anfrage. AWS rät zu Modellaufrufprotokollen mit geprüfter Zustellung, Aufbewahrung und Verschlüsselung. Sie können in CloudWatch Logs, S3 oder beiden landen. Einheitliche Metadaten für Anwendung, Workflow und Mandant sollen jeder Anfrage beigegeben werden. Bedrock erzwingt diese Angaben nicht; ein gemeinsames SDK oder Gateway kann sie zentral setzen und die Abdeckung messen. Protokolle können sensible Inhalte enthalten und brauchen eigene Schutzregeln. CUR ist ungefähr einen Tag verzögert, während Betriebsdaten schneller Hinweise liefern können; eine schnelle Schätzung ist nicht die abschließende Rechnung.

Stufe drei wählt die gewünschte Verzögerung der Budgetdurchsetzung. Ebene 1 nutzt AWS Budgets für Warnungen ohne Aufrufblockade. Ebene 2 zählt Verbrauch und aktualisiert eine IAM-Sperre oder verweigert beim nächsten Erneuern Zugangsdaten. Sie kann Kosten begrenzen, wirkt aber asynchron: Richtlinien können Sekunden bis Minuten nach einer überschreitenden Anfrage greifen, Zugangsdaten erst beim nächsten Austausch. Ebene 3 setzt ein Gateway in den Inferenzpfad, das beim Überschreiten synchron HTTP 429 zurückgeben kann. Dafür muss ein weiterer kritischer Baustein betrieben, skaliert und sicherheitlich geprüft werden. Wer Bedrock direkt aufruft, erhält nicht ohne Umleitung die synchrone Sperre eines Gateways.

Stufe vier verbessert Standards für Modellauswahl, Tokenlimits und Prompt-Cache. Günstigere Modelle sollten erst nach Qualitätsprüfungen mit den tatsächlichen Aufgaben eingesetzt werden. Caching hilft nur, wenn ein stabiler gemeinsamer Präfix wiederholt gelesen wird. Im AWS-Beispiel vom Oktober 2026 für bestimmte Claude-Modelle in US East kostet ein Cache-Schreibvorgang mit fünf Minuten Laufzeit das 1,25-Fache des Basiseingabepreises; eine Leseoperation je nach Modell das 0,1- oder 0,05-Fache. Ein einstündiger Schreibvorgang kostet das Doppelte. Diese Faktoren hängen von Zeit, Region und Modell ab und sind keine dauerhaft weltweiten Tarife. Ein nie wieder gelesener Cache-Eintrag kann Ausgaben erhöhen.

Stufe fünf führt die Daten in einer regelmäßigen Entscheidungsschleife zusammen. AWS nennt Modellmix, Fehlversuche und Retries, Cache-Lesequote und Vollständigkeit der Metadaten. Eine Anfrage, die auf dem Dienst noch fertigläuft, während der Client sie schon aufgegeben hat, kann bei erneutem Versuch zusätzliche berechnete Arbeit verursachen. Die Beispieltabelle teilt tägliche Ausgaben pro Entwickler in unter 100 Dollar, 100 bis 300 Dollar und über 300 Dollar ein. AWS nennt solche Grenzen Ausgangspunkte zur eigenen Kalibrierung, keine Vorschriften. Wirtschaftlich aussagekräftiger ist der Preis eines erfolgreichen Ergebnisses als der reine Tokenpreis.

Die Reihenfolge ist begründet: Ohne Zuordnung und Beobachtung lässt sich nicht prüfen, ob Routing oder Cache wirklich helfen. Budgets auf verzögerten Rechnungsdaten garantieren keinen unmittelbaren Stopp. Ein Team sollte zunächst die Identitäts- und Protokollabdeckung prüfen, die passende Durchsetzungsstufe wählen, Qualität vor einem Modellwechsel testen und Kosten zusammen mit Ergebnissen auswerten. Unsere Redaktion hat den Ansatz nicht eingesetzt und keine Einsparung reproduziert. Belegt sind der AWS-Plan und die vom Anbieter beschriebenen Mechanismen und Grenzen.

Die gesonderte AWS-Dokumentation zu CloudTrail nennt eine weitere Voraussetzung für die Prüfung. Trails und Ereignisdatenspeicher erfassen Datenereignisse standardmäßig nicht; Event history zeigt ausschließlich Verwaltungsereignisse. Wer Bedrock-Datenoperationen über CloudTrail nachvollziehen will, muss die passenden Datenereignis-Selektoren ausdrücklich konfigurieren. Die Protokollierung von Modellaufrufen ist eine getrennt zu aktivierende Quelle und kann sensible Eingaben oder Antworten enthalten. Zugriffs-, Anfrage-, Abrechnungs- und Anwendungseinträge sollten über eine verlässliche Kennung zusammengeführt werden, statt einen einzelnen Log als vollständig anzusehen.