Ein AWS-Beitrag für FinOps- und Plattformteams beschreibt das Kostenmanagement für Amazon Bedrock als fortlaufenden Zyklus aus fünf Stufen: zuordnen, beobachten, durchsetzen, optimieren und betreiben. Die Stufen bauen aufeinander auf. Die Zuordnung bestimmt den Kosteneigentümer, die Beobachtung ergänzt Kontext zu einzelnen Anfragen, die Durchsetzung reagiert auf Budgetüberschreitungen, die Optimierung verbessert Plattformvorgaben und der Betrieb macht aus den Signalen einen wiederkehrenden Prozess.

Kosten einem Eigentümer zuordnen

Amazon Bedrock ordnet Inferenzkosten automatisch dem aufrufenden IAM-Principal zu. Die ARN des Aufrufers steht in CUR 2.0 in der Spalte line_item_iam_principal. Damit besteht eine unmittelbare Grundlage, um Verbrauch mit der technischen Identität zu verbinden, die ihn ausgelöst hat.

Eine aussagekräftigere Aufteilung lässt sich mit Tags von IAM-Principals ergänzen, die als Kostenzuordnungs-Tags aktiviert wurden. In CUR 2.0 erscheinen sie mit dem Präfix iamPrincipal/. Im Cost Explorer werden sie innerhalb von 24 bis 48 Stunden nach der Aktivierung in der Kategorie IAM sichtbar. Bei der Analyse neuer Daten muss diese Verzögerung berücksichtigt werden, weil ein frisch aktiviertes Tag nicht sofort verfügbar sein muss.

Verwendet ein Gateway nur eine gemeinsame IAM-Rolle, werden sämtliche zugehörigen Amazon-Bedrock-Ausgaben dieser Rolle zugerechnet. Die Rolle allein unterscheidet somit nicht zwischen den Benutzern hinter dem Gateway. Als Lösung beschreibt der Beitrag benutzerspezifische Rollensitzungen, bei denen die Identität im Sitzungsnamen und weitere Attribute in Sitzungstags mitgeführt werden.

Zuordnung und Beobachtbarkeit verbinden

Application Inference Profiles bieten eine Zuordnung nach Anwendung, Modell und Region für Workloads über bedrock-runtime. Projekte können mehrere Modelle umfassen und die Zuordnung für OpenAI-kompatible Workloads am Endpunkt bedrock-mantle bereitstellen. Welcher Mechanismus passt, hängt damit vom Zugriffsweg und von der benötigten Darstellung der Verantwortlichkeit ab.

Das Model Invocation Logging von Amazon Bedrock kann Anfrage- und Antwortdaten sowie Metadaten an CloudWatch Logs, Amazon S3 oder an beide Ziele senden. Amazon Bedrock erzwingt die Metadaten einer Anfrage jedoch nicht. Der Beitrag empfiehlt deshalb, verpflichtende Metadaten zentral über einen gemeinsamen SDK-Wrapper oder ein Gateway einzufügen und zu normalisieren. Die Metadatenabdeckung soll außerdem als Kennzahl für den Plattformzustand verfolgt werden. Dadurch wird sichtbar, welcher Anteil des Datenverkehrs den erforderlichen Kontext trägt.

Drei Stufen der Budgetdurchsetzung

1. Überwachung und Warnungen: Eine Überschreitung wird gemeldet, ohne Anfragen zu blockieren.
2. Asynchrone IAM-basierte Ablehnung: Nach einer Überschreitung wird der Zugriff über Berechtigungen verweigert.
3. Synchrone Gateway-Blockierung: Das Gateway lehnt eine Anfrage unmittelbar ab, wenn ein Benutzer oder Team sein Limit überschritten hat.

Die IAM-basierte Durchsetzung kann Sekunden bis Minuten nach dem überschreitenden Aufruf oder erst bei der nächsten Erneuerung der Anmeldedaten wirksam werden. Ein Gateway kann dagegen HTTP 429 zurückgeben, sobald das Limit eines Benutzers oder Teams überschritten ist. Damit stehen sich eine verzögerte Autorisierungsänderung und eine Entscheidung direkt im Anfragepfad gegenüber.

Bei einer direkten Verbindung zu Amazon Bedrock ohne Proxy sind dem Beitrag zufolge nur Überwachung mit Warnungen und IAM-basierte Durchsetzung möglich. Für die synchrone Blockierung muss sich ein Gateway im Anfragepfad befinden.

Optimierung im korrekten Preiskontext

Die Cache-Kosten müssen mit ihrem Datum, ihrer Region und ihrem Modellbezug gelesen werden. Nach den für Oktober 2026 zitierten Preisen für Anthropic-Claude-Modelle in US East (N. Virginia) wurde ein fünfminütiger Cache-Schreibvorgang mit dem 1,25-Fachen des Basispreises für Eingaben berechnet. Ein einstündiger Cache-Schreibvorgang kostete das Doppelte dieses Basispreises. Die Multiplikatoren für Cache-Lesevorgänge unterschieden sich je nach Modell. Die Angaben gelten nur für den genannten Zeitpunkt und Bereich.

Regelmäßig betreiben und prüfen

Das beschriebene Betriebs-Dashboard verfolgt Modellmix, Raten fehlgeschlagener Anfragen, Cache-Wirksamkeit und Metadatenabdeckung. Diese Kennzahlen zeigen gemeinsam, was eingesetzt wird, wo Aufrufe scheitern, wie wirksam der Cache ist und ob der für Zuordnung und Analyse nötige Kontext vorliegt.

Für Flotten mit hoher Veränderungsgeschwindigkeit werden wöchentliche Scorecard-Prüfungen empfohlen, ansonsten ein zweiwöchentlicher Rhythmus. So schließt sich der Zyklus: Verantwortlichkeit, Beobachtbarkeit, Durchsetzung und Optimierungsentscheidungen werden regelmäßig erneut bewertet. Das Modell geht damit über einen einmaligen Kostenbericht hinaus und verbindet Kostendaten mit wiederkehrenden Plattformentscheidungen.