Wenn eure Amazon-Bedrock-Rechnung springt und niemand sagen kann, welches Feature dafür verantwortlich war, habt ihr kein Preisproblem. Ihr habt ein Observability-Problem. Die Rechnung sagt euch, dass der Account mehr für Tokens ausgegeben hat. Sie sagt euch nicht, welcher Agent, welcher Tenant oder welcher Codepfad das Geld ausgegeben hat, und ohne diese Zuordnung ist jedes Kostengespräch eine Vermutung. Man kann nicht optimieren, was man nicht misst, und die meisten Teams messen die Summe und nichts darunter.

Token-Spend hat eine Eigenschaft, die das schlimmer macht als gewöhnliche Cloud-Kosten: Er wird von einem nicht-deterministischen System erzeugt. Eine Prompt-Änderung, eine Retry-Schleife, ein geschwätziger Agent oder ein Nutzer, der einen Weg gefunden hat, das Modell härter denken zu lassen, können alle die Rechnung bewegen, und keines davon taucht als neue Ressource auf der Rechnung auf. Der Spend versteckt sich in einer einzigen Bedrock-Zeile. Die Aufgabe ist, diese Zeile aufzuschlüsseln, bevor sie einen überrascht, nicht danach.

Zuordnung ist das ganze Spiel

Die Frage, die zählt, ist nie "wie viel haben wir für Bedrock ausgegeben." Sie ist "wie viel hat das hier ausgegeben, und lohnt es sich." Um das zu beantworten, braucht man eine Dimension auf jeder Einheit Token-Spend. Mindestens sollte man jeden Aufruf taggen mit:

  • Feature oder Produktbereich, damit man fragen kann, ob der Summarizer oder der Chat-Assistent der Kostentreiber ist.
  • Tenant oder Kunde, damit man sehen kann, ob ein Account von den anderen quersubventioniert wird und ob die eigene Preisgestaltung die Bedienkosten deckt.
  • Agent oder Workflow, damit die Kosten einer mehrstufigen Pipeline pro Schritt sichtbar sind statt als eine undurchsichtige Summe.
  • Modell, damit man erkennen kann, wenn teurer Traffic an ein Frontier-Modell geht, das ein günstigeres genauso hätte bewältigen können.

Ohne diese Dimensionen verkommt Kostenoptimierung zu pauschalen Maßnahmen: alle deckeln, oder Features abschalten und beobachten, welche Beschwerde eintrifft. Mit ihnen kann man auf genau den Pfad zeigen, der gewachsen ist, und entscheiden, ob er sich das Wachstum verdient hat.

Zwei Schichten der Instrumentierung

Cost Allocation Tags für die Rechnung

AWS Cost Allocation Tags sind die grobe Schicht. Man taggt die Ressourcen und Anfragen, die den Bedrock-Verbrauch treiben, sodass die Billing-Daten selbst die eigenen Dimensionen tragen, und Kostenreports lassen sich nach Feature oder Umgebung gruppieren statt eine undifferenzierte Bedrock-Zahl zu zeigen. Das ist die Ansicht, in der Finance und Plattform-Owner leben. Sie ist monatlich granuliert und gut für das Gespräch "wo geht das Geld hin", nicht dafür, einen Spike im Moment zu erwischen.

CloudWatch-Metriken für das Echtzeitbild

Die Rechnung ist ein nachlaufender Indikator. Der vorlaufende Indikator ist Token-Durchsatz, und der gehört in CloudWatch. Bedrock stellt Usage-Metriken bereit, und man kann eigene Custom Metrics dimensioniert pro Agent, pro Tenant oder pro Feature direkt aus der Anwendung veröffentlichen:

# emit token counts as custom metrics, dimensioned
put_metric_data(
  namespace = "LLM/Usage",
  metric    = "InputTokens",
  value     = usage.input_tokens,
  dimensions = { "Feature": "summarizer", "Tenant": tenant_id }
)
# same for output_tokens, and cache read/write counts

Jetzt ist Spend ein Graph, auf den man alarmieren kann. Eine Token-Metrik pro Agent, die sich über Nacht verdreifacht, löst am Dienstag einen Alert aus, statt am Monatsende eine Finance-Frage. Man liest Input und Output getrennt, weil Output höher bepreist ist und eine außer Kontrolle geratene Generierung dort zuerst auftaucht.

Was die Sichtbarkeit ermöglicht

Sobald jedes Token zugeordnet ist, hören die Optimierungen auf, stumpf zu sein. Man kann die billigen, mechanischen Aufrufe, die eine Metrik pro Agent aufdeckt, zu einem kleineren Modell umleiten und das Frontier-Modell für das Reasoning behalten, das es verdient. Man kann den Tenant finden, dessen Bedienkosten seinen Plan übersteigen, und die Preisgestaltung oder die Nutzung reparieren. Man kann die Retry-Schleife erwischen, die eine Prompt-Änderung eingeführt hat, weil ihre Token-Zahl sprang, während ihre Request-Zahl das nicht tat. Jeder dieser Schritte braucht das Wissen, welches Stück der Rechnung zu kürzen ist, genau das, was die Instrumentierung liefert und die rohe Rechnung nie wird.

Das Fazit

Eine Bedrock-Rechnung, die man nicht zerlegen kann, ist eine Rechnung, die man nicht steuern kann. Man behandelt Token-Spend als Telemetrie, nicht nur als Rechnungsposten: taggt ihn mit Cost Allocation Tags für die Billing-Sicht, sendet Token-Metriken pro Agent und pro Tenant an CloudWatch für die Echtzeit-Sicht, und alarmiert auf dem vorlaufenden Indikator, sodass ein Spike ein Page ist, kein Postmortem. Die Teams, deren LLM-Kosten unter Kontrolle bleiben, sind nicht die mit den besten Preisen. Es sind die, die jederzeit genau sehen können, welches Feature, welcher Tenant und welcher Agent das Geld ausgibt.

Weiterlesen

Für das FinOps- und Cloud-Kostensichtbarkeits-Playbook jenseits von LLMs gibt es die Cloud-Notizen auf ercan.cloud, und der Hub ist unter ercanermis.com.