Wer Amazon-Bedrock-Kosten senken will, sollte Anfragen Teams oder Anwendungen zuordnen, den Verbrauch unabhängig von den Abrechnungsdaten beobachten und eine passende Budgetgrenze festlegen. AWS beschreibt diesen Ansatz für FinOps- und Plattformteams als laufenden Prozess aus Zuordnung, Beobachtung, Durchsetzung, Optimierung und gemeinsamem Betrieb.
1. Bedrock-Ausgaben Nutzern und Anwendungen zuordnen
Lege zuerst fest, welche Kostenstellen du auseinanderhalten willst: etwa IAM-Principals, Teams oder Anwendungen. AWS beschreibt dafür den AWS Cost and Usage Report (CUR) 2.0. Das Feld line_item_iam_principal enthält die Informationen zum IAM-Prinzipal. IAM-Tags lassen sich als Kostenverteilungs-Tags aktivieren; AWS nennt für ihre Anzeige im Cost Explorer einen Zeitraum von 24 bis 48 Stunden.
Bei einem gemeinsam genutzten Gateway kann die Zuordnung an einer Stelle zusammenlaufen: AWS zufolge wird der Bedrock-Verbrauch dann der gemeinsamen IAM-Rolle zugerechnet. Um einzelne Nutzer zu unterscheiden, beschreibt AWS ein Muster mit einer angenommenen Rolle pro Person. Die Benutzerkennung steht dabei im Sitzungsnamen, geschäftliche Merkmale kommen als Session-Tags hinzu.
Für stabile Gruppierungen nach Anwendung, Modell und AWS-Region beschreibt AWS Application Inference Profiles. Aufrufer verwenden dabei die ARN des jeweiligen Profils. Bedrock Projects ordnet AWS dagegen bestimmten Workloads über bedrock-mantle mit der Responses API oder der Chat Completions API zu; ein Project kann mehrere Modelle umfassen.
2. Verbrauch schneller als CUR beobachten
CUR-Daten und operative Telemetrie beantworten unterschiedliche Fragen. AWS zufolge kann die Zuordnung im CUR ungefähr 24 Stunden nachlaufen. Ein von AWS beschriebenes Beispiel mit Amazon CloudWatch und OpenTelemetry macht Ausgaben pro Entwickler innerhalb weniger Minuten sichtbar.
Für Aufrufprotokolle nennt AWS CloudWatch Logs, Amazon S3 oder beide Ziele. CloudWatch eignet sich laut AWS für operative Abfragen; für längerfristige Auswertungen mit Business-Intelligence-Werkzeugen beschreibt AWS S3 zusammen mit Athena. Anfrage-Metadaten können Anwendung, Workflow, Mandant oder Agent kennzeichnen. Bedrock erzwingt jedoch kein einheitliches Metadatenschema. Lege daher selbst verbindliche Feldnamen fest, wenn Teams ihre Daten gemeinsam auswerten sollen.
3. Budgetkontrolle passend zum Aufrufpfad wählen
AWS beschreibt drei Wege, auf ein Budgetlimit zu reagieren. Entscheidend ist, ob eine Benachrichtigung genügt oder ob Aufrufe am Limit tatsächlich gestoppt werden sollen.
| Kontrolle | Wirkung am Budgetlimit | Reaktionszeit | Voraussetzung und Aufwand |
| AWS Budgets mit Warnmeldungen | Meldet die Überschreitung; blockiert keine Aufrufe. | Keine automatische Sperre. | Direkte Aufrufe können bestehen bleiben; ein Team muss auf die Warnung reagieren. |
| IAM-Richtlinien oder vorenthaltene Zugangsdaten | Kann den Zugriff sperren. | Eine Richtlinienänderung wirkt laut AWS verzögert, teils erst nach Sekunden bis Minuten. Bei vorenthaltenen Zugangsdaten greift die Sperre beim nächsten Aktualisieren der Zugangsdaten. | Geeignet, wenn Teams direkte Aufrufe kontrollieren möchten, ohne eine zusätzliche Komponente in den Anfragepfad einzubauen. |
| Gateway-Durchsetzung | Sperrt die Anfrage synchron; AWS nennt HTTP 429 am Limit. | Laut AWS unter einer Sekunde. | Clients müssen ihre Anfragen über das Gateway leiten. Das Gateway muss bereitgestellt, skaliert und einer Sicherheitsprüfung unterzogen werden. |
Wenn eine Überschreitung Aufrufe unmittelbar stoppen soll, beschreibt AWS die Gateway-Variante als synchrone Option. Sie greift aber nur für Anfragen, die tatsächlich durch dieses Gateway laufen. IAM-Kontrollen passen eher zu direkten Aufrufen, wenn eine verzögerte Durchsetzung akzeptabel ist. Warnmeldungen allein setzen keine harte Grenze.
4. Modellrouting und Prompt-Caching anhand des Workloads prüfen
Ein günstigeres Modell kann Kosten beeinflussen, doch AWS empfiehlt, seine Qualität zunächst für die jeweilige Aufgabe zu bewerten. Ob eine Umleitung passt, hängt also davon ab, ob das Modell die Anforderungen des konkreten Workloads erfüllt.
Für Anthropic Claude nannte AWS in einem im Oktober 2026 veröffentlichten Artikel folgende Prompt-Caching-Multiplikatoren für US East (N. Virginia): Schreibvorgänge kosten beim fünfminütigen TTL das 1,25-Fache des Basistarifs für Eingabetokens, beim einstündigen TTL das Zweifache. Lesevorgänge liegen laut AWS beim 0,1-Fachen für Claude Sonnet 4.6 und Claude Haiku 4.5 sowie beim 0,05-Fachen für Claude Sonnet 5.5 und Claude Opus 5.5.
Die Zehn-Aufrufe-Rechnung lässt sich für einen stabilen, zehnmal gleich großen Eingabepräfix nachvollziehen: ein Schreibvorgang zum 1,25-Fachen und anschließend neun Lesevorgänge. Bei einem Lese-Multiplikator von 0,1 ergibt sich (1,25 + 9 × 0,1) / 10 = 0,215, also 21,5 Prozent der Kosten für zehn ungekachte Eingabepräfixe. Bei 0,05 lautet die Rechnung (1,25 + 9 × 0,05) / 10 = 0,17, also 17 Prozent.
Diese Werte betreffen nur die Kosten des Eingabepräfixes, unter der Annahme eines Schreibvorgangs und neun gleich großen Lesevorgängen. Ausgabetokens und andere Gebühren sind nicht eingerechnet. Wird ein Cache-Eintrag nicht erneut gelesen, fällt der Schreibvorgang an, ohne dass günstigere Lesevorgänge ihn ausgleichen.
5. Kennzahlen gemeinsam überprüfen
AWS nennt als mögliche Kennzahlen die täglichen Ausgaben pro Entwickler, den Anteil kosteneffizient gerouteter Aufrufe, die Trefferquote beim Cache-Lesen und die Kosten pro erfolgreichem Ergebnis. Die Schwellenwerte des Scorecards bezeichnet AWS als Ausgangspunkte, die Teams an ihre Workloads anpassen sollen. Für Flotten mit hohem Änderungs- und Nutzungsaufkommen schlägt AWS eine wöchentliche Überprüfung vor, für andere eine zweiwöchentliche.
