Amazon-Bedrock-Kosten end-to-end steuern: Ein Playbook für FinOps- und Plattform-Teams

Kostenmanagement für generative KI ist eine gemeinsame Verantwortung zwischen den Teams, die Anwendungen entwickeln, und den Teams, die für die Cloud-Ausgaben verantwortlich sind. Viele Teams beginnen damit, tokenbezogene Preismodelle zu vergleichen und die Anwendungsteams zu bitten, ihre Prompts zu kürzen. Diese Schritte helfen, aber sie beantworten nicht die Fragen, die Finanz- und Engineering-Führungskräfte stellen, wenn die Nutzung skaliert: Welches Team hat dies ausgegeben, für welche Workload, und lag diese Ausgabe innerhalb eines genehmigten Budgets?

Agentische Workloads machen diese Fragen dringlicher. Ein dialogbasierter Assistent löst typischerweise eine Modellinvocation pro Benutzerzug aus. Ein agentischer Workflow, etwa ein KI-Coding-Assistent, der eine Änderung plant, Dateien liest, Tools aufruft und iteriert, löst viele Invocations pro Aufgabe aus und trägt bei jeder einen größeren Kontext mit sich. Der Tokenverbrauch skaliert daher mit dem Grad der Autonomie, die Sie dem Workflow einräumen, und mit der Größe des mitgeführten Kontexts, und nicht mit der Anzahl der Benutzerinteraktionen. Da der Verbrauch eine Funktion davon ist, wie eine Workload entworfen und betrieben wird, ist Kostenmanagement für generative KI eine architektonische und betriebliche Disziplin. Veröffentlichte Durchschnittswerte sind ein schlechter Ersatz für Ihre eigenen Zahlen: Nutzen Sie den AWS Pricing Calculator und die Amazon Bedrock Pricing-Seite , um Preismodelle zu berechnen, und nutzen Sie Schritt 2 dieses Beitrags, um zu messen, was Ihre Workloads tatsächlich verbrauchen.

Die Lösung ist kein günstigeres Modell oder ein kürzerer Prompt. Es ist ein Betriebsmodell: eine wiederholbare Schleife, die jeden Dollar einem Verantwortlichen zuordnet, jede Anfrage beobachtbar macht, vor compoundierender Überschreitung bei Budgets alarmiert und diese durchsetzt, die Plattform-Standardeinstellungen optimiert, die den meisten Verschwendung verursachen, und das gesamte System in einem festen Zyklus überprüft.

In diesem Beitrag lernen Sie, wie Sie die Amazon Bedrock -Kosten in fünf Schritten steuern. Sie ordnen jeden Dollar einem Verantwortlichen zu, machen jede Anfrage beobachtbar, kontrollieren die Ausgaben mit Budgets und Durchsetzungsmechanismen, optimieren die Plattform-Standardeinstellungen, die den meisten vermeidbaren Aufwand verursachen, und betreiben einen Prüfzyklus, der Daten in Entscheidungen umwandelt. Dieser Ansatz basiert auf AWS-Bausteinen, und Sie können ihn anpassen und auf Ihre eigene Umgebung anwenden. Der Beitrag richtet sich an zwei Zielgruppen: FinOps-Praktiker, die für Zuordnung, Chargeback, Budgets und Anomalieprüfung zuständig sind, und Platform-Engineering-Teams, die für Logging, Anfragemetadaten, Durchsetzung und Routing-Standardeinstellungen verantwortlich sind.

Das Betriebsmodell auf einen Blick

Fünf Phasen, als Schleife betrieben. Zuordnen (Attribute): jeder Amazon-Bedrock-Dollar landet in der Abrechnungspipeline bei einer Identität, einem Team und einer Anwendung. Beobachten (Observe): jede Anfrage wird mit ausreichenden Metadaten protokolliert, um zu erklären, was die Ausgaben verursacht hat. Durchsetzen (Enforce): Budgets haben Zähne, mit Alarmen als Minimum und harten Sperren, wo das Risiko es erfordert. Optimieren (Optimize): die Plattform-Standardeinstellungen (Modell-Routing, Caching, Token-Limits) beseitigen Verschwendung zentral, statt jedes Team zur Vorsicht aufzufordern. Betreiben (Operate): ein kleines Scorecard und ein Prüfzyklus verwandeln die Daten in Entscheidungen. FinOps leitet die Phasen eins und fünf. Platform Engineering leitet zwei bis vier. Die Prüfung erfolgt gemeinsam. Die Phasen sind bewusst sequenziert. Jede hängt von den vorherigen ab, und Teams, die ohne Zuordnung und Observability direkt zur Optimierung springen, raten nur.

Abbildung 1: Das fünfphasige Betriebsmodell, betrieben als kontinuierliche Schleife

Phase 1: Jeden Dollar zuordnen

Sie können nicht steuern, was Sie nicht zuordnen können, und alles Weitere (Chargeback, Budgets, Durchsetzung, Anomalieerkennung) hängt von dieser Phase ab. Die Grundlage ist die granulare Kostenzuordnung von Amazon Bedrock (siehe Introducing granular cost attribution for Amazon Bedrock): Amazon Bedrock ordnet Inferenzkosten automatisch dem AWS Identity and Access Management (IAM)-Principal zu, der den Aufruf getätigt hat, über alle Modelle hinweg, ohne dass Ressourcen verwaltet werden müssen. Die ARN des Aufrufers landet in der line_item_iam_principal Spalte des AWS Cost and Usage Report (CUR) 2.0, und die Abdeckung umfasst IAM-Benutzer, Rollen, föderierte Identitäten und API-Schlüssel.

Die Einrichtung besteht aus vier Schritten:

1. Aktivieren Sie IAM-Principal-Daten in Ihrem CUR 2.0-Datenexport.
2. Versehen Sie Ihre IAM-Principals mit Tags für Geschäftsfakten wie Team, Anwendung und Kostenstelle. Konfigurieren Sie bei föderiertem Zugriff Ihren Identity Provider so, dass Sitzungsnamen und Tags über OIDC- oder SAML-Claims durchgereicht werden.
3. Aktivieren Sie diese Tags als Kostenzuordnungs-Tags in AWS Billing (Konsole oder die UpdateCostAllocationTagsStatus API).
4. Analysieren Sie die Tags: Sie erscheinen in CUR 2.0 mit einem iamPrincipal/ Präfix (zum Beispiel, iamPrincipal/team) und werden in AWS Cost Explorer unter der IAM-Kategorie innerhalb von 24–48 Stunden nach der Aktivierung, bereit für Filterung und Gruppierung nach Team, Anwendung oder Kostenstelle.

Dies ist eine Abrechnungs-qualifizierte Zuordnung pro Identität ohne benutzerdefinierte Infrastruktur.

Das Problem der geteilten Rollen

Das Muster, das die meiste Aufmerksamkeit verdient, ist das Problem geteilter Rollen, denn dort verlieren die meisten Plattformen stillschweigend die Zuordnung. Ein Large Language Model (LLM)-Gateway, das Amazon Bedrock über eine einzelne IAM-Rolle aufruft, schreibt jeden Dollar dieser einen Rolle zu und eliminiert die Sichtbarkeit pro Benutzer vollständig. Die Lösung ist ein sitzungsbezogenes Benutzermanagement. Das Gateway übernimmt die Amazon Bedrock-Aufrufrolle einmal pro Benutzer, übergibt die Identität des Benutzers als Rollensitzungsnamen und seine Attribute als Session-Tags und speichert diese Anmeldedaten dann für bis zu eine Stunde im Cache (ein AWS Security Token Service (AWS STS)-Aufruf pro Benutzer pro Stunde, nicht pro Anfrage).

Dies erfordert zwei Rollen: eine Gateway-Ausführungsrolle mit sts:AssumeRole - und sts:TagSession -Berechtigungen sowie die Amazon Bedrock-Aufrufrolle, die sie übernimmt. Das Ergebnis sind line_item_iam_principal -Einträge wie assumed-role/BedrockRuntimeRole/gw-alex, die jeweils die Tags ihres Benutzers tragen: Zuordnung pro Benutzer und pro Mandant hinter einem gemeinsamen Gateway wiederhergestellt.

import boto3

sts = boto3.client("sts")

# One call per user; cache the returned credentials up to 1 hour
response = sts.assume_role(
    RoleArn="arn:aws:iam::123456789012:role/BedrockRuntimeRole",
    RoleSessionName="gw-alex", # the user, not the gateway
    Tags=[
        {"Key": "team", "Value": "sales-ai"},
        {"Key": "application", "Value": "renewal-agent"},
        {"Key": "costCenter", "Value": "CC-2041"}
    ]
)

Eine Anmerkung zu Anwendungs-Inferenzprofilen und Projekten

Amazon Bedrock bietet zwei weitere Zuordnungsmechanismen, die jeweils für ein anderes Muster geeignet sind. Anwendungs-Inferenzprofile sind vorab erstellte, anwendungsbezogene Ressourcen auf dem bedrock-runtime -Endpunkt, die Kostenzuordnungstags tragen. Sie erstellen ein Profil pro Anwendung pro Modell pro AWS-Region, und Aufrufer verweisen auf den Profil-ARN, was für Teams mit einer kleinen und stabilen Menge an Anwendungen und Modellen passt. Projekte und Workspaces dienen dem bedrock-mantle -Endpunkt (Responses API, Chat Completions API). Ein Projekt ist nicht an ein bestimmtes Modell gebunden, daher umfasst eine einzelne Projekt-ID viele Modelle, was für Teams passt, deren Modellnutzung häufig wechselt. Sie übergeben die Projekt-ID bei der Client-Initialisierung, und ihre Tags fließen in CUR 2.0 und Cost Explorer (siehe Manage AI costs with Amazon Bedrock Projects). Projekte sind der Zuordnungspfad für OpenAI-kompatible Workloads auf Amazon Bedrock.

Für bedrock-runtime -Workloads empfehlen wir die IAM-Principal-Zuordnung über Session-Tags als primären Mechanismus. Sie skaliert mit Ihrem Identitätssystem, erfordert keine vorab erstellten Ressourcen und deckt jedes Modell und jeden API-Vorgang ab. Anwendungs-Inferenzprofile funktionieren gut, wenn eine kleine, stabile Menge von Geschäftsbereichen eine abrechnungsgenaue Kosten trennung ohne Änderungen am Identitätsdesign benötigt. Verwenden Sie Projekte für bedrock-mantle -Workloads, die die Responses API oder die Chat Completions API nutzen.

Stufe 2: Machen Sie jede Anfrage beobachtbar

CUR sagt Ihnen, wer ausgegeben hat. Aufrufprotokolle sagen Ihnen, was passiert ist. Amazon Bedrock unterstützt Modellaufruf-Protokollierung von Anfragedaten, Antwortdaten und Metadaten in Amazon CloudWatch Logs, Amazon Simple Storage Service (Amazon S3) oder beides. Verwenden Sie Amazon CloudWatch für schnelle operative Abfragen und S3 plus Amazon Athena für langfristigen Business-Intelligence (BI)-Zugriff. Behandeln Sie Protokollierung als Infrastruktur, nicht als manuellen Schalter: Stellen Sie die Protokollgruppe oder den Bucket über Code bereit, definieren Sie Aufbewahrungs- und Verschlüsselungsrichtlinien und validieren Sie die Zustellung während der Umgebungseinrichtung. Wenn Protokollierung nur in der Entwicklung oder nur in einer Region existiert, wird Ihr Kostenprogramm fragmentarisch, sobald die Nutzung wächst.

Protokollierung schließt auch die Latenzlücke: Die CUR-Zuordnung hinkt etwa 24 Stunden hinterher, aber CloudWatch plus OpenTelemetry kann Near-Real-Time-Dashboards antreiben, die den Verbrauch pro Entwickler innerhalb von Minuten zeigen (Analyzing Claude Code usage with CloudWatch and OpenTelemetry demonstriert dies vollständig von Anfang bis Ende).

Anfragemetadaten für die Zuordnung auf Workload-Ebene

Rohprotokolle beantworten Fragen auf Identitätsebene. Um Fragen auf Workload-Ebene zu beantworten (welches Feature, welcher Workflow oder welcher Mandant die Tokens erzeugt hat), stempeln Sie Anfragemetadaten auf jeden Aufruf. Amazon Bedrock erfasst diese Metadaten in den Aufrufprotokollen für die spätere Analyse:

Das folgende Beispiel verwendet Anthropic Claude Sonnet 5.5 auf Amazon Bedrock über das US-Cross-Region-Inferenzprofil. Die vollständige Liste der Modelle finden Sie unter Supported foundation models in Amazon Bedrock. Informationen zur Verfügbarkeit nach Region finden Sie unter Modellunterstützung nach AWS-Region in Amazon Bedrock.

response = client.converse(
    modelId="us.anthropic.claude-sonnet-5-5",
    messages=[...],
    requestMetadata={
        "application": "renewal-copilot",
        "workflow": "renewal-risk-summary",
        "tenant": "enterprise-sales",
        "agent": "renewal-agent"
    }
)

Amazon Bedrock erzwingt keine Request-Metadaten, und Teams verfallen schnell in inkonsistente Schemas, wenn jede Anwendung ihr eigenes Ding macht. Das Platform-Team sollte obligatorische Metadaten zentral in einem gemeinsamen SDK-Wrapper oder Gateway injizieren, den Schlüsselsatz normalisieren und die Metadaten-Abdeckung als Plattform-Gesundheitsmetrik behandeln.

Diagnoseabfragen

Mit Logs und Metadaten an Ort und Stelle beantwortet CloudWatch Logs Insights die wiederkehrenden Fragen. Wer verbraucht die meisten Tokens:

fields @timestamp, identity.arn as caller, modelId,
input.inputTokenCount as inTokens,
output.outputTokenCount as outTokens
| stats sum(inTokens + outTokens) as totalTokens,
count(*) as calls
by caller, modelId
| sort totalTokens desc
| limit 25

Dieselbe Abfrage, gruppiert nach requestMetadata.application und requestMetadata.workflow anstelle von caller ergibt die Workload-Highscore-Liste: die Ansicht, die Produkt- und Engineering-Teams im Moment, in dem Chargeback-Gespräche beginnen, von FinOps anfordern werden.

Hinweis: Die in der vorherigen Abfrage gezeigten Feldpfade sind illustrativ. Verifizieren Sie sie anhand Ihres Invocation-Log-Schemas, das je nach Modell, API-Operation und Logging-Konfiguration variieren kann.

Stufe 3: Budgets durchsetzen

Mit Attribution und Observability wird Durchsetzung zu einer Architekturentscheidung statt einem Wunsch. Es gibt drei praktikable Stufen. Die richtige hängt von Ihrer Ausgabengeschwindigkeit, Ihrer Risikotoleranz gegenüber Überschreitungen und davon ab, wie Ihre Tools sich mit Amazon Bedrock verbinden.

Stufe 1: Überwachen und Alarmieren (keine Blockierung)

Amazon Bedrock schreibt die Principal-Identität automatisch in die Billing-Pipeline. Sie legen AWS Budgets darüber für Schwellenwert-Alarme, wobei die OpenTelemetry-Dashboards aus Stufe 2 die 24-Stunden-Lücke des CUR für die tägliche Sichtbarkeit schließen. Nichts zu deployen, natives AWS Billing und keine zusätzliche Latenz bei Inferenzaufrufen. Es funktioniert mit Tools, die Amazon Bedrock direkt aufrufen. Nichts kann Ausgaben hart stoppen, sodass Sie das Problem erst danach sehen. Geeignet für die frühe Einführung, wo Alarmierung plus menschliches Eingreifen ausreichend ist. Zwei Builder-Guides führen hindurch: Limiting Bedrock usage and controlling costs, sowie Deep dive on managing Bedrock in Claude Code with AWS Budgets and Tags.

Stufe 2: IAM-Tag-Durchsetzung (Ablehnung bei Überschreitung)

Eine Aggregator-AWS-Lambda-Funktion summiert benutzerbezogene Token- und Dollar-Zähler in Amazon DynamoDB aus Invocation-Log-Daten. Wenn ein Benutzer seinen Schwellenwert überschreitet, fügt die Funktion seine Identität einer gemeinsamen IAM-Deny-Policy hinzu (die bedrock:*ablehnt), bis ein monatlicher Reset oder ein Admin-Override erfolgt. Diese Durchsetzung läuft vollständig auf IAM und Amazon Bedrock Logging, ohne Drittkomponente im Inferenzpfad, und funktioniert mit Tools, die Amazon Bedrock direkt aufrufen. Die Guidance for Claude Code with Amazon Bedrock in der AWS Solutions Library bietet eine deploybare Variante. Sie prüft bei der Ausstellung von Credentials die Nutzung jedes Benutzers gegen benutzer- und teambezogene Limits und verweigert Credentials, sobald ein Benutzer sein Limit überschreitet. Da diese Prüfung nutzungstelemetrie verwendet, die vom Client gesendet wird, können ihre Werte vom CUR abweichen. In beiden Formen ist die Durchsetzung asynchron. Eine Sperre wird Sekunden bis Minuten nach dem überschreitenden Aufruf bei einem IAM-Policy-Update wirksam, oder beim nächsten Credential-Refresh bei der Credential-Prüfung. Ihr Plattform-Team besitzt die Pipeline. Diese Stufe ist richtig für Teams, die echte Durchsetzung benötigen, diese Verzögerung tolerieren können und Drittanbieter-Software aus dem Datenpfad fernhalten wollen.

Stufe 3: Gateway-Durchsetzung (synchroner Block)

Ein Gateway sitzt im Inferenz-Datenpfad und setzt Budgets synchron durch, indem es HTTP 429 zurückgibt, sobald ein Benutzer oder Team sein Limit überschreitet. Sie erhalten Blockierung im Sub-Sekunden-Bereich, benutzerbezogene Modell-Allowlists, Token-Rate-Limits und zentral durchgesetzte Routing-Regeln. Der Nachteil: eine Komponente im Datenpfad, die deployt, skaliert und sicherheitsüberprüft werden muss. Clients müssen so konfiguriert werden, dass sie ihre Anfragen über das Gateway senden.

Für Claude-Code- und Claude-Desktop-Fleeten ist die Claude apps gateway for AWS die offizielle Empfehlung. Sie wird in der CLI-Binary ausgeliefert und läuft als einzelner zustandsloser Container, der von PostgreSQL unterstützt wird. Sie bietet OIDC-Identität, zentral verwaltete Policies, OpenTelemetry-Telemetrie, Multi-Region-Amazon-Bedrock-Routing sowie benutzer-/gruppen-/organisationsbezogene Ausgabenlimits ab Werk. Für Mixed-Model-Workloads über mehrere Provider hinweg bleiben allgemeine Gateways die richtige Wahl: LiteLLM über die Amazon Elastic Container Service (Amazon ECS) on AWS Fargate reference architectureoder eine serverlose Alternative, beschrieben in Build a proactive AI cost management system for Amazon Bedrock, Part 2.

Wahl der Stufe

Zwei Faktoren dominieren.

Konnektivität: Wenn Entwickler Amazon Bedrock direkt ohne Proxy aufrufen, sind nur die Stufen 1 und 2 machbar.

Ausgabengeschwindigkeit: Wenn die Ausgaben bereits bei Millionen pro Monat liegen, bauen Sie die Durchsetzung jetzt. Wenn Alarme noch ein weiteres Quartal halten können, investieren Sie zuerst in die Stufen 1 und 2 und fügen Sie Durchsetzung hinzu, wenn die Daten es verlangen.

Die meisten Organisationen sollten es phasenweise angehen: auf Stufe 1 beobachten, dann eskalieren. Betrachten Sie alle drei als Brücken, nicht als Ziele: die Well-Architected Agentic AI Lens kodifiziert Agent-Cost-Governance bereits als eigenständiges Architekturthema, und die Attributions-Grundlage aus Stufe 1 ist das Fundament, auf dem jede verwaltete Durchsetzung sitzen wird.

Stufe 4: Die Standardwerte optimieren

Der meiste Amazon Bedrock-Verschwendung ist keine individuelle Nachlässigkeit. Es sind Plattform-Standardeinstellungen, die niemand festgelegt hat. Die beiden Hebel mit der größten Wirkung liegen beide in der Kontrolle der Plattform.

Modell-Routing

Nicht jede Aufgabe benötigt ein Frontier-Modell. Routine-Vervollständigungen (Boilerplate, Linting-Vorschläge, kleine Refactorings) können auf kleineren, günstigeren Modellen laufen, während Qualität für komplexe Schlussfolgerungen reserviert bleibt, und zwar durch intelligentes Prompt-Routing innerhalb einer Modellfamilie oder durch Routing-Regeln am Gateway (siehe Kosten und Latenz mit Amazon Bedrock Intelligent Prompt Routing und Prompt-Caching reduzieren für die vollständige Anleitung). Welche Workflows herabgestuft werden können, ist eine empirische Frage: Ziehen Sie die Workload-Bestenliste aus Stage 2 heran, führen Sie eine Qualitätsevaluierung des günstigeren Modells für die Top-Einträge durch und leiten Sie alles dorthin, was besteht. Bei agentischen Coding-Flotten, bei denen Boilerplate den Großteil des Aufrufvolumens ausmacht, ist ein Ziel von mehr als der Hälfte der Aufrufe auf günstigeren Modellen erreichbar.

Prompt-Caching

Prompt-Caching belohnt stabile, wiederholte Präfixe. Stand Oktober 2026 werden bei den veröffentlichten Amazon Bedrock-Preisen für Anthropic Claude-Modelle in US East (N. Virginia) Cache-Schreibvorgänge mit dem 1,25-fachen des Basiseingabepreises bei einer 5-Minuten-Time-to-Live (TTL) abgerechnet (das 2-fache bei der 1-Stunden-TTL). Ein Cache-Lesevorgang wird bei Claude Sonnet 4.6 und Claude Haiku 4.5 mit dem 0,1-fachen des Basiseingabepreises und bei Claude Sonnet 5.5 und Claude Opus 5.5 mit dem 0,05-fachen abgerechnet. Prüfen Sie die Preisseite für Ihr Modell und Ihre Region, da diese Multiplikatoren je nach Modell variieren und sich ändern können. Die Break-Even-Rechnung ist günstiger, als Teams annehmen. Mit der 5-Minuten-TTL zahlt bereits eine einzige Wiederverwendung den Schreibvorgang, und zehn Aufrufe gegen ein stabiles Präfix kosten ungefähr ein Fünftel des unzwischengespeicherten Preises (etwa 22 Prozent bei einem 0,1-fachen Lesesatz, 17 Prozent bei 0,05). Der einzige Verlustfall sind Schreibvorgänge, die nie wieder gelesen werden; diese kosten 25 Prozent Aufpreis mit der 5-Minuten-TTL und das Doppelte mit der 1-Stunden-TTL. Das Plattform-Dashboard sollte daher das Cache-Lesevolumen gegen das Cache-Schreibvolumen pro Workflow verfolgen. Ein niedriges Leseverhältnis bedeutet, dass das Präfix tatsächlich nicht stabil ist (meistens ein Zeitstempel oder eine Sitzungs-ID, die vor dem Cache-Punkt eingebettet ist).

Kandidaten ergeben sich direkt aus den Aufrufprotokollen:

fields requestMetadata.workflow as workflow, modelId,
input.inputTokenCount as inTokens
| stats count(*) as calls,
avg(inTokens) as avgInputTokens,
sum(inTokens) as totalInputTokens
by workflow, modelId
| filter calls > 50 and avgInputTokens > 2000
| sort totalInputTokens desc
| limit 25

Hinweis: Die in der vorstehenden Abfrage gezeigten Feldpfade sind beispielhaft. Überprüfen Sie sie anhand Ihres Aufrufprotokoll-Schemas, das je nach Modell, API-Operation und Protokollierungskonfiguration variieren kann.

Optimierung auf Anwendungsebene

Eine dritte Klasse von Einsparungen (Just-in-Time-Abruf statt gestopftem Kontext, Kompaktion langer Konversationen, Destillation stabiler Workflows mit hohem Volumen auf kleinere Modelle) gehört zu den Anwendungsteams und nicht zur Plattform. Die Aufgabe der Plattform besteht darin, diese Einsparungen sichtbar zu machen: Veröffentlichen Sie die Token-Bestenliste pro Workflow, setzen Sie Token-Limits pro Modell und Workflow und lassen Sie die Teams, denen teure Workflows gehören, genau sehen, wo sie stehen.

Stage 5: Betreiben Sie die Schleife

Die ersten vier Stufen erzeugen Daten. Diese verwandelt sie in Entscheidungen. Das Plattform-Team betreibt ein ständiges Health-Dashboard mit vier Signalen:

• Modellmix: Welche Modelle aufgerufen werden und wie oft – das direkte Maß für Routing-Disziplin.
• Fehlgeschlagene Anfragen-Raten: Fehler, Drosselungen und Timeouts. Jeder Wiederholungsversuch erhöht die Latenz, und ein clientseitiges Timeout bei einer Anfrage, die auf der Dienstseite dennoch abgeschlossen wird, kann doppelt abgerechnet werden – einmal für den abgebrochenen Aufruf und einmal für den Wiederholungsversuch.
• Cache-Effektivität: Das Lesen-Schreiben-Verhältnis aus Stage 4.
• Metadaten-Abdeckung: Der Prozentsatz der Produktionsaufrufe mit vollständigen Metadaten. Jeder nicht abgedeckte Aufruf ist ein blinder Fleck bei der Zuordnung, der stillschweigend alle anderen Zahlen verschlechtert.

Wenn ein Signal abweicht, ist die Korrektur eine Richtlinienänderung (Routing-Regeln, Token-Limits, Metadaten-Durchsetzung), keine E-Mail, in der Teams gebeten werden, vorsichtig zu sein.

Die Geldschleife

FinOps betreibt die Geldschleife auf denselben Daten. Wenn die Zuordnung sauber ist, wird die Anomalieerkennung zu einem Untersuchungsstrom statt zu einer panischen Gesamtkonferenz: Ein Anstieg bei einem getaggten Team oder einer Anwendung löst eine Suche in der Stage-2-Bestenliste aus, keinen Krisenstab. Die interne Verrechnung (Chargeback) erfolgt aus CUR-Gruppierungen nach Team und Anwendung.

Scorecard

Die folgenden Schwellenwerte sind Ausgangspunkte, keine Vorschriften. Kalibrieren Sie sie anhand Ihrer eigenen Flottendaten und Preisklasse, bevor Sie sie als Richtlinie übernehmen.

Grün bedeutet, dass die Workload innerhalb ihrer wirtschaftlichen Grenzen arbeitet. Gelb bedeutet, dass das Routing oder die Caching-Disziplin nachlässt. Rot bedeutet, dass sich die Ausgaben auf Premium-Modelle oder nicht zwischengespeicherten Kontext konzentrieren, und die Kontrollen der Stufen 3 und 4 sind der Weg zur Behebung. Überprüfen Sie dieses Scorecard in einem regelmäßigen Rhythmus (wöchentlich für hochfrequente Flotten, ansonsten zweiwöchentlich) und behandeln Sie es als gemeinsame FinOps-plus-Plattform-Entscheidungsgrundlage.

Fazit

In diesem Beitrag haben Sie gelernt, wie man ein Fünf-Stufen-Betriebsmodell aufbaut, das die Amazon-Bedrock-Ausgaben von unkontrolliert zu vollständig gesteuert führt:

1. Jeden Dollar mithilfe von IAM-Principal-Tags, Session-Tags und CUR 2.0 einem Verantwortlichen zuordnen.
2. Jede Anfrage durch Model-Invocation-Logging und gestempelte Anfragemetadaten beobachten.
3. Budgets auf der Ebene durchsetzen, die Ihrem Risiko entspricht: nur Überwachung, IAM-Deny bei Überschreitung oder synchrones Gateway-Blocking.
4. Plattform-Standardeinstellungen mit intelligentem Prompt-Routing und Prompt-Caching optimieren, um Verschwendung zentral zu beseitigen.
5. Eine Scorecard und einen Überprüfungsrhythmus betreiben, der Telemetrie in politische Entscheidungen umwandelt.

Beachten Sie die erste Zeile dieser Scorecard: Kosten pro erfolgreichem Ergebnis, nicht Kosten pro Aufruf. Genau in dieser Unterscheidung endet dieses Playbook. Alles hier macht Amazon-Bedrock-Ausgaben sichtbar, zuordenbar, begrenzt und effizient, aber ein Workflow kann perfekt effizient sein und trotzdem nicht den Betrieb wert sein. Diese Entscheidung erfordert, den Agenten an dem menschlichen Prozess zu messen, den er ersetzt hat – das ist eine Produkt- und Analytics-Disziplin und keine FinOps-Disziplin. Was die Kostenplattform beiträgt, ist das Fundament: saubere Attribution und Kosten-Daten pro Workflow sind genau die Eingaben, gegen die die Ergebnismessung verknüpft wird.

Bauen Sie die fünf Stufen auf, und Sie können Ende-zu-Ende antworten: wer es ausgegeben hat, warum und ob es kontrolliert war. Das bedeutet, Amazon-Bedrock-Kosten zu managen, und es ist der Unterschied zwischen einer monatlichen Rechnungsprüfung und einem Betriebsmodell.

Legen Sie los, indem Sie die Guidance for Claude Code with Amazon Bedrock -Referenzarchitektur für die Stufen 1–3 bereitstellen, und konfigurieren Sie anschließend mithilfe der Dokumentation zu den cost attribution best practices Ihre Tagging-Strategie.

Über die Autoren