KI-Kosten auf AWS steuern: Budgets, Token-Alarme und Kostenzuordnung für Bedrock und Agenten

Der Beitrag richtet sich an Plattformteams, Cloud-Verantwortliche und das IT-Controlling in Unternehmen, die Bedrock-Modelle oder Agenten auf AWS einsetzen. Sinnvoll beginnt man nicht mit dem Budget, sondern mit der Frage, wem welche Kosten gehören. Ohne Zuordnung meldet ein Budget nur, dass „Bedrock“ teurer wird, aber nicht welche Anwendung. Wie Bedrock Anfragen auf Regionen verteilt, haben wir im Bedrock-EU-Check beschrieben, Identität und Rechte von Agenten im AgentCore-Beitrag.

Wo Kostenkontrolle im AWS-Angebot steht

AWS rechnet Bedrock nach Nutzung ab, bei den meisten Modellen nach Ein- und Ausgabetokens, dazu je nach Funktion weitere Posten wie Websuche, Speicherung angepasster Modelle oder bereitgestellter Durchsatz. Agenten über AgentCore verursachen zusätzlich verbrauchsabhängige Kosten für Laufzeit, Speicher und Werkzeuge, wie wir im AgentCore-Beitrag beschrieben haben. Die Werkzeuge zur Kostenkontrolle sitzen nicht in Bedrock selbst, sondern in der Abrechnung von AWS: AWS Budgets, Cost Explorer, die Kosten- und Nutzungsberichte (CUR) und Cost Anomaly Detection. Dazu kommen die Laufzeitmetriken von Bedrock in CloudWatch. Den Überblick über das gesamte Angebot gibt die Seite Amazon AWS für Unternehmen.

Nicht behandelt werden hier konkrete Modellpreise; sie stehen je Region auf der Bedrock-Preisseite und ändern sich häufig. Auch Rabattmodelle wie bereitgestellter Durchsatz sind ein eigenes Thema.

Warum ein Budget allein zu spät warnt

AWS schreibt in der Budget-Dokumentation selbst, dass zwischen der Nutzung einer Ressource und der Benachrichtigung eine Verzögerung liegen kann und die Kosten in dieser Zeit über die Schwelle hinaus weiter steigen können. Die Budgetdaten werden bis zu dreimal am Tag aktualisiert, typischerweise 8 bis 12 Stunden nach der vorherigen Aktualisierung. Ein Alarm auf tatsächliche Kosten kommt laut den Best Practices nur einmal je Budget und Zeitraum, beim ersten Erreichen der Schwelle. Prognose-Alarme brauchen rund fünf Wochen Nutzungsdaten, bevor sie überhaupt auslösen können. Für ein neues KI-Projekt fallen sie in den ersten Wochen also aus.

Die Laufzeitmetriken von Bedrock laufen dagegen nicht über die Abrechnung. Laut AWS veröffentlicht der Endpunkt bedrock-runtime unter anderem Invocations, InputTokenCount, OutputTokenCount und InvocationThrottles im Namensraum AWS/Bedrock, auch je Modell. Für den neueren Endpunkt bedrock-mantle gibt es eigene Metriken. Ein CloudWatch-Alarm auf die Tokenzahl pro Stunde zeigt einen außer Kontrolle geratenen Agenten deshalb früher als jedes Budget, allerdings in Tokens statt in Euro. Die Umrechnung in Kosten muss das Team mit den Preisen der genutzten Modelle selbst hinterlegen.

Redaktionelle, schematische Darstellung der unterschiedlichen Aktualisierung auf Basis der Budget-Dokumentation und der Bedrock-Laufzeitmetriken von AWS. Abstände und Schwelle sind illustrativ, keine Messung.

Kosten zuordnen, bevor sie entstehen

Bedrock bietet laut Kostendokumentation mehrere Wege, Kosten Anwendungen, Teams oder Nutzern zuzuordnen. Sie lassen sich kombinieren:

Eigene Zusammenfassung der Bedrock-Dokumentation zu Kostenzuordnung, IAM-Identitäten und Anwendungs-Inferenzprofilen, Stand 10. November 2026.

Drei Einschränkungen sind für die Planung wichtig. Erstens liefern die abrechnungsnahen Wege Kosten laut AWS höchstens je Nutzungsart und Tag, keine Kosten je Anfrage. Zweitens müssen Tags in der Abrechnungskonsole als Kostenzuordnungs-Tags aktiviert werden; sie erscheinen bis zu 24 Stunden später in Cost Explorer und gelten zunächst nur ab Aktivierung. Das Verwaltungskonto kann laut AWS eine Nachberechnung für bis zu zwölf Monate anstoßen. Sie füllt aber nur Zeiträume, in denen das Tag schon an der Ressource oder Rolle hing. Ein Tag, das erst nach dem Start gesetzt wird, ordnet die Kosten davor also auch nachträglich nicht zu. Drittens weisen die Responses- und Chat-Completions-APIs ein Anwendungs-Inferenzprofil mit einem Fehler ab. Wer diese Schnittstellen nutzt, ordnet über IAM-Identität, Projekte oder Metadaten zu.

Ein häufiger Fall ist ein zentrales KI-Gateway, das Bedrock für viele Anwendungen aufruft. Dann sieht AWS nur die Rolle des Gateways. AWS empfiehlt, dass das Gateway je Nutzer oder Mandant eine eigene Rollensitzung mit Sitzungstags annimmt oder die Anwendung in den Metadaten jeder Anfrage mitgibt. Ohne eine dieser Maßnahmen landen alle Kosten auf einer einzigen Rolle.

Budgets mit Aktionen als letzte Sicherung

Ein Budget kann laut AWS beim Erreichen einer Schwelle eine Aktion ausführen, automatisch oder nach manueller Freigabe. Möglich sind eine IAM-Richtlinie, eine Dienststeuerungsrichtlinie (SCP) aus dem Verwaltungskonto der Organisation oder das Stoppen bestimmter EC2- und RDS-Instanzen. Für Bedrock heißt das in der Praxis: Eine vorbereitete Richtlinie, die bedrock:InvokeModel und verwandte Aufrufe für die Rolle der Anwendung verweigert, wird beim Überschreiten der Schwelle angehängt. Das ist eine Empfehlung von AI-Fabrik auf Basis der dokumentierten Aktionstypen, keine fertige Vorlage von AWS.

Benachrichtigungen gehen laut Best Practices an bis zu zehn E-Mail-Adressen und ein SNS-Thema je Alarm. Überwachung und Benachrichtigung sind laut Preisseite kostenlos; die ersten zwei Budgets mit Aktionen ebenfalls, danach kostet jedes weitere 0,10 US-Dollar pro Tag. Ergänzend erkennt Cost Anomaly Detection ungewöhnliche Ausgaben mit einem Lernmodell, etwa je Dienst, Konto oder Kostenzuordnungs-Tag. Sie wertet Ausgaben aus, nicht die Laufzeitmetriken, und ersetzt den schnellen Token-Alarm deshalb nicht.

Die Kostenstaffel für Agenten

Für Agenten, die länger laufende Aufgaben übernehmen, empfiehlt sich aus diesen Bausteinen eine Staffel. Die erste Ebene liegt in der Anwendung selbst: eine Obergrenze für Schritte, Modellaufrufe oder Tokens je Vorgang, die der Agent nicht überschreiten kann. Die zweite Ebene sind CloudWatch-Alarme auf Tokens je Modell und Stunde, die an das Betriebsteam gehen. Die dritte Ebene ist ein Monatsbudget je Anwendung mit einer Aktion. Die erste Ebene verhindert den teuren Einzelfall, die zweite meldet ungewöhnliche Muster, die dritte begrenzt den Schaden, wenn alles andere versagt.

Ein hypothetisches Beispiel: Ein Händler lässt einen Agenten nachts Produktbeschreibungen für 20.000 Artikel überarbeiten. Durch einen Fehler in der Schleife ruft der Agent für jeden Artikel das Modell immer wieder auf. Eine Schrittgrenze je Artikel in der Anwendung bricht den einzelnen Vorgang ab. Fällt sie weg, meldet der Token-Alarm den Anstieg noch in der Nacht. Damit das etwas nützt, muss vorher feststehen, wer den Alarm annimmt, etwa die Rufbereitschaft des Plattformteams, und dass diese Person genau diese Anwendung stoppen darf, zum Beispiel durch Entzug der Bedrock-Rechte ihrer Rolle. Das Monatsbudget hätte den Fehler erst nach der nächsten Datenaktualisierung gesehen, unter Umständen erst am Morgen.

Kleine Teams kommen mit einer eigenen IAM-Rolle je Anwendung, einem Token-Alarm und einem Monatsbudget mit E-Mail-Benachrichtigung aus. Auch dort gehört zu jedem Alarm eine benannte Person mit dem Recht, die Anwendung anzuhalten, und eine Vertretung. Wer mehrere Agenten produktiv betreibt, ergänzt Anwendungs-Inferenzprofile oder Projekte, Metadaten je Anfrage, Cost Anomaly Detection je Kostenzuordnungs-Tag und Budget-Aktionen mit vorab festgelegter Freigabe.

Pilotfragen vor dem Einsatz

1. Lassen sich die Bedrock-Kosten jeder Anwendung einem Team und einer Kostenstelle zuordnen, und sind die Tags vor dem Start aktiviert?
2. Welche Grenze für Schritte oder Tokens je Vorgang setzt die Anwendung selbst, unabhängig von AWS?
3. Gibt es CloudWatch-Alarme auf Tokens je Modell, und wer reagiert nachts und am Wochenende?
4. Welche Anwendung darf eine Budget-Aktion automatisch stoppen, und für welche braucht es eine Freigabe?
5. Wie rechnen wir Tokens in Kosten um, und wer pflegt die Preise, wenn AWS oder der Modellanbieter sie ändert?

Fazit: Kosten steuert, wer vor der Abrechnung misst

Quellen

Weiterführende Artikel auf AI-Fabrik