Amazon Bedrock rechnet pro verarbeitetem Input- und Output-Token ab. Die Kosten hängen vom Modell, vom Preismodus und vom Nutzungsmuster der Workloads ab. On-Demand eignet sich für unvorhersehbare oder volumenarme Nutzung; Provisioned Throughput liefert garantierte Kapazität für gleichmäßige, volumenstarke Produktions-Workloads; Batch-Inferenz bringt bis zu 50 % Rabatt für Jobs ohne Echtzeitanforderung. Modellanpassung und Fine-Tuning verursachen separate Kosten für Training, Speicherung und Inferenz. Da sich KI-Kosten anders verhalten als klassische Compute-Ausgaben, brauchen CloudOps-Teams Transparenz auf Token-Ebene und automatisierte Budgetkontrollen, damit die Bedrock-Ausgaben planbar bleiben.
Klassische Cloud-Budgetierung beruhte auf vorhersehbaren Einheiten: Instance-Stunden, Speicher-Gigabyte, Netzwerk-Egress. Amazon Bedrock passt nicht in dieses Schema. Ihre Rechnung hängt davon ab, wie viel Ihre Nutzer tippen, wie ausführlich Ihre Prompts sind, welches Foundation Model Sie gewählt haben und wie oft Ihre Anwendung fehlgeschlagene Calls wiederholt. Eine einzige Architekturentscheidung – etwa Claude 3 Opus statt Claude 3 Haiku – kann die Kosten in der Skalierung um eine Größenordnung verschieben.
Das ist keine Kritik an Bedrock, sondern strukturelle Realität inferenzbasierter Preismodelle, mit der die meisten CloudOps- und FinOps-Teams bisher nicht umgehen mussten. Die Engineers, die Ihre KI-Features gebaut haben, verstehen Tokens. Die Personen, die Ihr Cloud-Budget freigeben, vermutlich nicht. Diese Lücke zu schließen, ist dringend: Laut dem State of FinOps Report 2026 der FinOps Foundation steuern inzwischen 98 % der Organisationen ihre KI-Ausgaben aktiv – vor zwei Jahren waren es nur 31 %. Kostentransparenz ist kein Nice-to-have. Sie ist die Voraussetzung dafür, überhaupt über KI-Wachstum sprechen zu können.
Dieser Guide erklärt, wie das Bedrock-Pricing funktioniert, wie Sie Kosten abschätzen, bevor sie auf der Rechnung stehen, und wie Sie Monitoring und Kontrollen aufbauen, mit denen sich KI-Ausgaben jederzeit begründen lassen.
Wie funktioniert das Pricing von Amazon Bedrock?
Amazon Bedrock rechnet Inferenz ab: das Senden eines Prompts an ein Foundation Model und das Empfangen einer Antwort. Die zentrale Abrechnungseinheit ist das Token – ein Textstück, das ungefähr vier Zeichen oder dreiviertel eines Wortes entspricht. Jede Anfrage besteht aus Input-Tokens (Ihr Prompt, die System Message und der bisherige Konversationsverlauf) und Output-Tokens (die Antwort des Modells). Beides wird abgerechnet, zu unterschiedlichen Sätzen.
Was Bedrock-Kosten schwerer prognostizierbar macht als Compute-Kosten: Tokens sind nicht fix. Wer eine Frage in zwei Sätzen stellt, verbraucht weit weniger Input-Tokens als jemand, der ein 3.000-Wörter-Dokument einfügt. Eine Anwendung, die das Modell um eine "kurze Zusammenfassung" bittet, erzeugt weniger Output-Tokens als eine, die eine ausführliche Analyse anfordert. Wenn sich diese Variabilität über Tausende täglicher Anfragen multipliziert, wird die Budgetprognose ohne saubere Instrumentierung tatsächlich schwierig.
Zwei weitere Faktoren verkomplizieren das Bild. Erstens kosten Output-Tokens bei vielen Modellen mehr als Input-Tokens, weil das Generieren von Text rechnerisch aufwendiger ist als das Verarbeiten. Das variiert je nach Anbieter: Manche Modelle bepreisen Input und Output gleich, andere verlangen für Output deutlich mehr. Zweitens hat die Modellauswahl einen drastischen Effekt auf die Token-Sätze. Ein leichtgewichtiges Modell kostet pro Million Tokens nur einen Bruchteil eines Frontier-Modells derselben Familie. Das richtige Modell für eine Klassifizierungsaufgabe ist oft das falsche für komplexe Reasoning-Aufgaben – und umgekehrt. Allein nach Leistungsfähigkeit auszuwählen, ohne die Kosten einzubeziehen, gehört zu den häufigsten Ursachen unnötiger Bedrock-Ausgaben.
Preismodelle und Tarifstrukturen von Amazon Bedrock
Bedrock bietet drei zentrale Preismodi: On-Demand, Provisioned Throughput und Batch-Inferenz. Jeder bedient ein anderes Workload-Profil. Die Trade-offs zu verstehen, ist die Grundlage für Kostenkontrolle und operative Zuverlässigkeit gleichermaßen.
Preismodus
Abrechnung
Commitment
Latenz
Geeignet für
On-Demand
Pro verarbeitetem Token
Keines
Variabel; Throttling-Risiko bei Lastspitzen
Sprunghafte, experimentelle oder volumenarme Workloads
Provisioned Throughput
Fester Stundensatz pro Model Unit
1 oder 6 Monate
Garantiert; kein Throttling
Volumenstarke, gleichmäßige Workloads; Pflicht für Custom Models
Batch-Inferenz
Pro Token (bis zu 50 % Rabatt vs. On-Demand)
Keines
Asynchron; nicht in Echtzeit
Dokumentenverarbeitung, nächtliche Jobs, asynchrone Anreicherungs-Pipelines
On-Demand-Pricing für Foundation Models
On-Demand ist der Standard. Sie zahlen pro 1.000 verarbeiteten Tokens, ohne Vorabverpflichtung und ohne Mindestumsatz. Ideal für Workloads, die explorativ, sprunghaft oder noch nicht planbar genug sind, um Kapazitätsreservierungen zu rechtfertigen.
Das operative Risiko bei On-Demand ist Throttling. AWS erzwingt Concurrency-Limits beim Zugriff auf Foundation Models, und in Spitzenzeiten können Anfragen in die Warteschlange rutschen oder fehlschlagen. Für interne Tools oder unkritische Anwendungen ist dieser Trade-off akzeptabel, für kundenseitige Features mit Latenzanforderungen nicht.
Die Token-Sätze unterscheiden sich erheblich nach Modellfamilie und Generation. In der Anthropic-Claude-Reihe auf Bedrock können leichtere Modelle pro Million Tokens etwa eine Größenordnung weniger kosten als Frontier-Modelle derselben Familie. Bei den meisten Modellen unterscheiden sich auch Input- und Output-Sätze; manche Anbieter bepreisen sie gleich. Das richtige Modell für die Aufgabe zu wählen – und nicht einfach das leistungsfähigste verfügbare – ist die wirkungsvollste Kostenentscheidung, die ein Team treffen kann. Prüfen Sie aktuelle Sätze immer auf der AWS Bedrock Pricing-Seite, bevor Sie sich auf eine Modellauswahlstrategie festlegen, da sich Sätze und verfügbare Modellversionen häufig ändern.*
Optionen für Provisioned Throughput
Provisioned Throughput funktioniert wie eine Reserved Instance für Inferenz. Sie kaufen Model Units, von denen jede einen bestimmten Token-Durchsatz pro Minute garantiert, und zahlen einen festen Stundensatz – unabhängig davon, ob Sie diese Kapazität nutzen. Commitments laufen über einen oder sechs Monate, längere Laufzeiten ergeben bessere Konditionen.
Ob sich Provisioned Throughput finanziell lohnt, hängt von der Auslastung ab. Läuft Ihr Workload während der Geschäftszeiten mit konstantem Volumen, kann der feste Stundensatz bei gleichem Durchsatz spürbare Einsparungen gegenüber On-Demand bringen. Aber das Commitment ist verbindlich. Ungenutzte provisionierte Kapazität kostet genauso viel wie voll ausgelastete. Teams, die für Lastspitzen provisionieren und im Schnitt bei 30 % Auslastung laufen, sparen kein Geld.
Provisioned Throughput ist außerdem die einzige Inferenzoption für Custom Models und feinabgestimmte Modelle. Wer ein domänenadaptiertes Foundation Model deployen will, ist unabhängig vom Volumenprofil auf Provisioned Throughput angewiesen.
Kosten für Modellanpassung und Fine-Tuning
Das Fine-Tuning eines Foundation Models auf Bedrock erzeugt drei separate Kostenposten: Training, Speicherung und Inferenz. Die Trainingskosten basieren auf den insgesamt verarbeiteten Tokens Ihres Datensatzes und der Anzahl der Trainings-Epochen. Nach dem Training liegt das Custom Model im Speicher und verursacht eine monatliche Gebühr. Das Bereitstellen des feinabgestimmten Modells erfordert Provisioned Throughput, mit mindestens einer Model Unit – auch ohne langfristiges Commitment.
Bevor Sie sich auf eine Anpassung festlegen, sollten Sie einen Proof of Concept auf einem reduzierten Datensatz fahren, um zu prüfen, ob die Leistungsverbesserung die zusätzliche Kostenstruktur rechtfertigt. Modell-Distillation – das Komprimieren der Fähigkeiten eines großen Modells in ein kleineres, schnelleres – kann die langfristigen Inferenzkosten senken. Distillierte Modelle bringen aber eigene Trainingskosten mit sich und benötigen für das Deployment ebenfalls Provisioned Throughput.
Amazon-Bedrock-Kosten berechnen und schätzen
Belastbare Kostenschätzung erfordert den Schritt von vagen Annahmen zu gemessenen Token-Volumina. Teams, die Bedrock-Ausgaben auf Basis der "Anzahl an API-Calls" prognostizieren, liegen daneben. Die Anzahl der Tokens pro Call und das Verhältnis von Input zu Output zählen weit mehr als die reine Call-Anzahl.
Berechnung der Input- und Output-Token-Kosten
Die Grundformel ist einfach: Die Monatskosten ergeben sich aus Input-Tokens mal Input-Token-Satz plus Output-Tokens mal Output-Token-Satz, jeweils pro Million Tokens. Die Herausforderung liegt darin, diese Token-Volumina präzise zu schätzen, bevor produktive Daten vorliegen.
Beginnen Sie bei der Prompt-Architektur Ihrer Anwendung. Ein System-Prompt mit 500 Tokens wird bei jedem einzelnen Request berechnet. Ein Setup mit Retrieval-Augmented Generation (RAG), das pro Query 2.000 Tokens Kontext einfügt, skaliert diese Kosten über jeden Aufruf. Nehmen Sie Ihre Prompt-Templates unter die Lupe und zählen Sie die Tokens vor dem Launch mit dem Bedrock-Tokenizer oder einem modellspezifischen Counter.
Für die Output-Schätzung analysieren Sie, was Ihre Anwendung das Modell produzieren lässt. Klassifizierungsaufgaben mit einer Antwort erzeugen weit weniger Output-Tokens als Konversationsantworten oder lange Inhalte. Erstellen Sie ein repräsentatives Sample an Anfragen, messen Sie die tatsächlichen Input- und Output-Token-Zahlen und nutzen Sie das als Baseline. Anschließend wenden Sie einen Multiplikator für das erwartete Anfragevolumen an.
Ein praktisches Beispiel: Eine Anwendung sendet täglich 100.000 Anfragen an ein Mid-Tier-Foundation-Model mit durchschnittlich 800 Input-Tokens und 400 Output-Tokens. Das ergibt 80 Millionen Input-Tokens und 40 Millionen Output-Tokens pro Tag. Je nach Modell und Output-Token-Satz reichen die Tagesausgaben von zweistelligen bis dreistelligen Dollarbeträgen und summieren sich auf monatlich fünfstellige Beträge. Die Output-Token-Kosten – beim selben Modell oft höher als die Input-Sätze – machen den Großteil dieser Summe aus.* Aktuelle Sätze für alle verfügbaren Foundation Models finden Sie auf der AWS Bedrock Pricing-Seite.
Tools und Methoden zur Kostenschätzung
AWS stellt in der Konsole einen Bedrock-Preisrechner und ein Token-Schätzungstool bereit – beides hilfreich für die initiale Modellierung. Für die laufende Sichtbarkeit zeigt der AWS Cost Explorer die Bedrock-Ausgaben, schlüsselt sie ohne Resource Tagging aber nicht nach Modell, Anwendung oder Team auf. Tags sind essenziell. Versehen Sie jeden Bedrock-Aufruf mit den Identifiern für Anwendung, Team und Umgebung, die Ihrer Kostenallokation entsprechen – bevor die Workloads in Produktion gehen.
DoiT Cloud Intelligence geht über Tagging und Dashboards hinaus. Die Plattform liefert Echtzeittransparenz über Ihre KI-Kosten quer durch die gesamte Bedrock-Nutzung – mit Analysen, die granular zeigen, wie Modellauswahl, Prompt-Muster und Nutzungsspitzen die Ausgaben treiben. Diese Sichtbarkeit verknüpft Kostendaten mit Engineering-Entscheidungen auf eine Weise, die statische Reports nicht leisten.
In Multi-Modell-Umgebungen, in denen unterschiedliche Anwendungen unterschiedliche Foundation Models nutzen, sollten Sie pro Modell separate Kostenbudgets und Alert-Schwellen festlegen. Eine Spitze bei den Kosten eines Frontier-Modells sieht ganz anders aus als eine bei einem leichtgewichtigen Modell – beides in eine einzige Budgetzeile zu packen, erschwert die Ursachenanalyse.
Strategien zur Bedrock-Kostenoptimierung für CloudOps-Teams
Optimierung in Bedrock ist kein einmaliges Audit, sondern eine operative Disziplin. KI-Workloads entwickeln sich schnell. Ein Prompt, der beim Launch effizient war, kann teuer werden, wenn Use Cases wachsen, Kontextfenster größer werden und Konversationsverläufe sich aufstauen. Teams, die Bedrock-Kosten im Griff haben, behandeln sie wie Compute-Right-Sizing: kontinuierlich, mit automatisierten Signalen, die Maßnahmen auslösen.
Right-Sizing der Modellauswahl für Workloads
Modell-Right-Sizing ist die wirkungsvollste verfügbare Optimierung – und die meisten Teams investieren zu wenig darin. Standardvorgehen ist, das leistungsfähigste Modell einer Familie zu wählen und es über alle Use Cases hinweg auszurollen. Der bessere Ansatz: Modellfähigkeit auf Aufgabenkomplexität abstimmen.
Klassifizieren Sie Ihre Use Cases nach dem, was sie tatsächlich brauchen. Einfache Extraktion, Klassifizierung und Zusammenfassung benötigen kein Frontier-Modell. Ein kleineres, günstigeres Modell erledigt das präzise – zu einem Bruchteil der Kosten. Reservieren Sie große Modelle für komplexes Reasoning, mehrstufige Problemlösung und Aufgaben, bei denen die Output-Qualität spürbar auf Geschäftsergebnisse durchschlägt.
Testen Sie das konsequent. Lassen Sie Ihre realen Workloads gegen eine abgestufte Modellauswahl laufen, messen Sie die Output-Qualität gegen Ihre Akzeptanzkriterien und berechnen Sie die Kostendifferenz. Häufig lässt sich eine Qualitätsschwelle von 90 % mit einem Modell erreichen, das 10- bis 20-mal weniger kostet als die Top-Tier-Alternative. Das ist kein marginaler Effizienzgewinn. In der Skalierung ist es eine Budget-Transformation.
Erwägen Sie außerdem Batch-Inferenz für Workloads, die keine Echtzeitantworten brauchen. Der Batch-Modus von Bedrock senkt die Token-Kosten bei unterstützten Modellen um bis zu 50 %. Dokumentenverarbeitung, nächtliche Analysejobs und asynchrone Anreicherungs-Pipelines sind starke Kandidaten. Der Trade-off ist Latenz: Batch-Jobs laufen asynchron und sind daher nicht für nutzerseitige Features geeignet, die sofortige Antworten erwarten.
Nutzungsmonitoring und Budgetkontrollen umsetzen
Bedrock ohne Telemetrie auf Token-Ebene zu überwachen, ist wie EC2 ohne CPU-Metriken zu monitoren. AWS CloudWatch zeigt Bedrock-Aufrufzahlen und Fehler. Ergänzen Sie eigene Metriken für den Token-Verbrauch pro Modell, pro Anwendung und pro Umgebung. Setzen Sie Alarme auf Token-Schwellen, die auslösen, bevor Kosten zum Problem werden – nicht erst, wenn die Rechnung kommt.
Prompt-Caching reduziert Input-Token-Kosten bei wiederholten oder statischen Inhalten. System-Prompts, Referenzdokumente und gemeinsam genutzter Kontext, die sich zwischen Requests nicht ändern, lassen sich cachen. Der gecachte Anteil wird zu einem reduzierten Satz abgerechnet, was bei Anwendungen, in denen derselbe System-Prompt in jedem Call vorkommt, echte Einsparungen bringt. Aktivieren Sie Prompt-Caching für alle Inhalte, die in dieses Muster passen.
Cross-Region-Inferenz leitet Anfragen an verfügbare Modellkapazität in anderen AWS-Regionen, wenn Ihre Primärregion gedrosselt oder ausgelastet ist. Das verbessert die Zuverlässigkeit unter Last, ohne dass separate Provisioned-Throughput-Commitments nötig sind. Prüfen Sie das für Produktions-Workloads mit geringer Throttling-Toleranz.
Budget-Kontrollen in AWS Budgets können Bedrock-Ausgaben melden, reagieren aber auf bereits entstandene Kosten. Die stärkere Kontrolle ist Rate-Limiting auf Anwendungsebene, das ausufernde Nutzung stoppt, bevor sie auf der Rechnung landet. Setzen Sie Token-Limits pro Nutzer, pro Session und pro Anwendung in Ihrer Anwendungsschicht und erzwingen Sie sie, bevor Anfragen die Bedrock-API erreichen. Das ist der Unterschied zwischen einem Monitoring-Signal und einem echten Guardrail.
DoiT Cloud Intelligence bietet automatisierte Anomalieerkennung für KI-Ausgaben und macht Abweichungen von erwarteten Kostenmustern in Echtzeit sichtbar. So erfahren CloudOps-Teams innerhalb von Stunden von Kostenproblemen – nicht erst zum Monatsabschluss.
Bedrock-Kosten planbar und begründbar machen
Unvorhersehbare KI-Ausgaben sind nicht nur ein finanzielles Problem, sondern ein Glaubwürdigkeitsproblem. Wenn Engineering-Verantwortliche nicht erklären können, warum die Bedrock-Kosten von einem Monat zum nächsten um 40 % gestiegen sind, entsteht Reibung mit dem Finanzbereich, KI-Investitionsentscheidungen verzögern sich, und der Business Case für den Ausbau von KI-Initiativen wird untergraben. Kostentransparenz ist kein Overhead. Sie ist die Grundlage dafür, überhaupt über KI-Wachstum sprechen zu können.
Teams, die das richtig aufziehen, behandeln Bedrock-Kostenmanagement als Engineering-Praxis – nicht als Finance-Funktion. Sie instrumentieren den Token-Verbrauch zur Build-Zeit, nicht erst nach der ersten unerwarteten Rechnung. Sie validieren die Modellauswahl vor dem Launch gegen Kosten-Qualitäts-Trade-offs. Sie bauen automatisierte Guardrails, die Ausgabenlimits ohne manuelles Eingreifen durchsetzen. Und sie tracken Kosten pro Outcome, nicht nur Kosten pro Call, sodass sie ROI in einer Sprache belegen können, die Engineers und Führungskräfte gleichermaßen verstehen.
Das ist die operative Reife, die Bedrock vom Kostenrisiko zur belastbaren Capability macht.
DoiT hilft CloudOps- und FinOps-Teams, die Lücke zwischen KI-Kostendaten und konkretem Handeln zu schließen. DoiT Cloud Intelligence macht Bedrock-Ausgaben in Echtzeit nach Modell, Anwendung und Team sichtbar – mit automatisierten Alerts und Empfehlungen, für deren Interpretation kein FinOps-Spezialist nötig ist. DoiT verfügt über die AWS Generative AI Competency und ist direkt über den AWS Marketplace verfügbar, sodass Teams Cloud Intelligence in ihren bestehenden AWS-Procurement-Workflow einbinden können, ohne eine neue Lieferantenbeziehung aufzubauen.
Entdecken Sie DoiT Cloud Intelligence für KI-Kostenmanagement und erleben Sie, wie der Blick auf Ihr Bedrock-Pricing von reaktiv zu vorausschauend wird.
Häufige Fragen zum Pricing von Amazon Bedrock
Was ist die günstigste Art, Amazon Bedrock zu nutzen?
Am günstigsten kombinieren Sie Modell-Right-Sizing mit Batch-Inferenz, wo immer möglich. Ein kleineres, aufgabengerechtes Modell statt eines Frontier-Modells kann die Token-Kosten um den Faktor 10 bis 20 senken. Batch-Inferenz für Workloads ohne Echtzeitanforderung bringt zusätzlich bis zu 50 % Einsparung. Prompt-Caching für wiederkehrende System-Prompts und Kontext senkt die Input-Token-Kosten weiter. Beginnen Sie damit zu prüfen, welche Use Cases tatsächlich ein großes Modell brauchen, und migrieren Sie alles andere auf das kleinste Modell, das Ihre Qualitätsanforderungen erfüllt.
Wie schneidet Provisioned Throughput von Amazon Bedrock im Vergleich zu On-Demand-Pricing ab?
On-Demand rechnet pro verarbeitetem Token ab, ohne Commitment. Provisioned Throughput reserviert dedizierte Kapazität zu einem festen Stundensatz, der unabhängig von der tatsächlichen Nutzung anfällt. Provisioned wird wirtschaftlich bei hoher, gleichbleibender Auslastung – typischerweise dann, wenn die On-Demand-Kosten den Stundensatz des Commitments übersteigen würden. Für Custom Models und feinabgestimmte Modelle ist Provisioned Throughput unabhängig vom Volumen erforderlich. On-Demand ist die richtige Default-Wahl für variable Workloads, frühe Anwendungen und alle Use Cases, deren Nutzungsmuster noch nicht planbar sind.
Wie wirken sich Input- und Output-Tokens auf die Bedrock-Kosten aus?
Input- und Output-Tokens werden separat bepreist, und Output-Tokens kosten pro Million typischerweise drei- bis fünfmal mehr als Input-Tokens. Das heißt: Wie viel das Modell pro Anfrage produzieren soll, hat einen überproportionalen Effekt auf Ihre Rechnung. Anwendungen, die ausführliche Erklärungen, lange Inhalte oder ausladende strukturierte Outputs anfordern, verschieben den Schwerpunkt stark auf Output-Token-Kosten. Prompts so zu gestalten, dass sie die Ausgabelänge ohne Qualitätsverlust begrenzen, ist eine direkte Form der Kostenkontrolle.
Berechnet Amazon Bedrock Kosten für fehlgeschlagene API-Calls?
Bedrock berechnet Tokens, die erfolgreich verarbeitet wurden. Anfragen, die vor Beginn der Inferenz scheitern – etwa durch Authentifizierungsfehler oder gedrosselte Requests –, erzeugen keine Token-Kosten. Wiederholungsversuche bei Calls, die bis in die Inferenz vordringen und dort scheitern (zum Beispiel durch Verstöße gegen die Kontextlänge), können jedoch teilweise abgerechnet werden. Retry-Raten und Fehlerursachen zu monitoren, gehört zu verantwortungsvollem Kostenmanagement.
Welche Tools helfen beim Tracken und Steuern von Amazon-Bedrock-Ausgaben?
Der AWS Cost Explorer zeigt Bedrock-Ausgaben auf Service-Ebene, und AWS Budgets kann auf Kostenschwellen alerten. CloudWatch erfasst Aufrufmetriken. Für Sichtbarkeit auf Token-Ebene ist anwendungsseitiges Logging der Input- und Output-Token-Zahlen pro Request unerlässlich. Resource Tagging nach Anwendung, Team und Umgebung ermöglicht die Kostenallokation. Plattformen wie DoiT Cloud Intelligence liefern Echtzeit-Analysen für KI-Kosten und automatisierte Anomalieerkennung über Ihre gesamte Bedrock-Nutzung hinweg.