1. November 2026 · 10 Min. Lesezeit

Bedrock Limits und ThrottlingException

Grafische Titelkarte zum Beitrag „Bedrock Limits und ThrottlingException“ mit einem stilisierten Motiv: ein Container-Symbol, dessen Pfeil an einer Sperre endet, daneben eine Uhr für die Wartezeit und ein Stapel Anfragen.
Grafik: HumanITy

Eine ThrottlingException (HTTP 429) heißt bei Amazon Bedrock: Dein Konto hat eine Quote überschritten. Für Claude zählt Bedrock vor allem Tokens pro Minute, je Modell und Region, Eingabe und Ausgabe zusammen, dazu ein Tageslimit über alle Modelle. Der häufigste Grund für Drosselung trotz wenig Last: Bedrock reserviert beim Start jeder Anfrage die Eingabe plus den vollen Wert von max_tokens, und Ausgabe-Token zählen bei Modellen wie Opus 5.5 zehnfach. Abhilfe in dieser Reihenfolge: Wiederholen mit exponentiellem Backoff und Jitter, max_tokens passend setzen, die Quote in Service Quotas prüfen und bei Bedarf erhöhen lassen. Stand der Quellen: 01.11.2026, nicht aus einem eigenen Lasttest.

Bedrock nutze ich in manchen Fällen selbst produktiv und habe es bei Kunden eingerichtet, jeweils dort, wo Verarbeitung in der EU verlangt ist; meine eigene Belegschaft läuft im Alltag über Claude mit AVV. Regionen, EU-Profil und Datenwege erkläre ich in Claude über AWS Bedrock: EU, DSGVO, Kosten; hier geht es darum, warum Bedrock bremst und was du dagegen tust.

Welche Bedrock-Quoten für Claude gelten

Auf dem Standard-Endpunkt bedrock-runtime gelten je Modell diese Quoten, laut AWS gemeinsam für InvokeModel, Converse und die übrigen Schnittstellen:

Quote Gilt für
Cross-Region-Tokens pro Minute je Modell und Region, für Aufrufe über ein Inferenzprofil wie eu.
Global-Tokens pro Minute je Modell und Region, für global.-Profile, eigene Quote
On-Demand-Tokens pro Minute je Modell und Region, für Aufrufe ohne Profil in einer Einzelregion
Cross-Model Max Tokens Per Day je Konto und Region, über alle Modelle
Anfragen pro Minute nur bei manchen Modellen

Die Standardwerte aus AWS' Referenztabelle am 01.11.2026: Opus 5.5 hat 30 Millionen Tokens pro Minute über Cross-Region und über global, Sonnet 5.5 hat 6 Millionen, Haiku 5.5 10 Millionen. Das Tageslimit liegt bei 700 Millionen Tokens und ist in der Tabelle als nicht anpassbar markiert. Eine Quote für Anfragen pro Minute führt die Tabelle für die 5.5-Modelle nicht. Zwei Einschränkungen schreibt AWS selbst dazu: Die Werte deines Kontos können niedriger sein, abhängig von Region, Kontoalter, Nutzung und Zahlungshistorie. Was für dich gilt, zeigt nur die Service-Quotas-Konsole. Und der zweite Endpunkt bedrock-mantle hat eigene Quoten, dort getrennt für Eingabe und Ausgabe.

Für Europa ist wichtig: Sonnet 5.5 und Haiku 5.5 gibt es dort nicht als Einzelregion, Opus 5.5 nur in London. Wer über das EU-Profil arbeitet, stößt also an die Cross-Region-Quote.

Warum Bedrock schon bei wenig Last drosselt

AWS beschreibt die Zählung so:

  1. Beim Start zieht Bedrock Eingabe-Token plus max_tokens von der Minuten- und Tagesquote ab. Reicht die Quote nicht, wird gedrosselt.
  2. Während der Antwort gleicht Bedrock an die tatsächlich erzeugten Token an.
  3. Am Ende zählen Eingabe-Token plus Cache-Schreibvorgänge plus Ausgabe-Token mal Faktor. Gelesene Cache-Token zählen nicht, der Rest wird zurückgegeben.

Der Faktor heißt bei AWS Burndown-Rate: 10 für Opus 5.5, Sonnet 5, Opus 5 und Fable 5.1, 15 für die Modelle der Version 4.8, 5 für Version 4.7 und älter. Für Sonnet 5.5 und Haiku 5.5 nennt die Seite am 01.11.2026 keinen eigenen Wert. Bezahlt wird nur, was tatsächlich verbraucht wurde; der Faktor betrifft nur die Quote.

AWS rechnet ein Beispiel mit Faktor 5 vor: 3.000 Eingabe-Token, 1.000 in den Cache geschrieben, 1.000 Ausgabe-Token. Mit max_tokens von 32.000 reserviert die Anfrage beim Start 36.000 Token, verbraucht am Ende aber nur 9.000. Mit max_tokens von 1.250 reserviert sie 5.250. Ein zu hoch gesetztes max_tokens blockiert also Quote, die du nie nutzt, und senkt die Zahl gleichzeitiger Anfragen. Die Empfehlung von AWS: max_tokens nahe an der echten Antwortlänge wählen und die Werte dafür aus CloudWatch ablesen.

ThrottlingException und die anderen Fehler

Fehler HTTP Bedeutung laut AWS
ThrottlingException 429 Kontoquote überschritten
ServiceUnavailableException 503 Kapazität knapp, nicht deine Quote
overloaded_error 529 Modell vorübergehend überlastet
ModelNotReadyException 429 Modell noch nicht bereit, das SDK versucht es bis zu fünfmal
ServiceQuotaExceededException 400 Anfrage überschreitet eine Dienstquote
ModelTimeoutException 408 Verarbeitung dauerte zu lange
AccessDeniedException 403 Rechte fehlen, keine Quotenfrage

Die Unterscheidung spart Zeit: Bei einer ThrottlingException hilft eine höhere Quote, bei 503 und 529 nicht. Für beide Kapazitätsfehler nennt AWS Wiederholen mit Backoff und Cross-Region-Inferenz; bei 503 zusätzlich eine andere Region.

Wiederholen mit Backoff und Jitter

Die AWS-SDKs wiederholen gedrosselte Anfragen selbst. Wie genau, hängt derzeit von einem Schalter ab: AWS beschreibt das neue Verhalten von 2026, das du bis zur Umstellung mit AWS_NEW_RETRIES_2026=true einschaltest; ohne den Schalter gelten laut AWS andere Wartezeiten und Vorgaben. Im neuen Standardmodus wartet das SDK exponentiell länger, mit zufälligem Anteil (Jitter), damit nicht alle Clients gleichzeitig wiederkommen. Für Drosselungsfehler liegt die Basis der Wartezeit bei einer Sekunde, keine Pause dauert länger als 20 Sekunden, und es gibt drei Versuche insgesamt. Einstellen lässt sich das über AWS_RETRY_MODE und AWS_MAX_ATTEMPTS oder retry_mode und max_attempts in ~/.aws/config. Den Modus adaptive empfiehlt AWS nur, wenn ein Client viel gegen eine einzige Ressource schickt und oft gedrosselt wird; er bremst dann auch die erste Anfrage.

Wiederholen verschiebt das Problem nur. Wenn die CloudWatch-Werte zeigen, dass du dauerhaft an der Quote bist, helfen weniger Verbrauch oder eine höhere Quote.

Cross-Region-Inferenz, global und das EU-Profil

Ein geografisches Profil wie eu.anthropic.claude-sonnet-5-5 verteilt Anfragen auf mehrere Regionen innerhalb der EU, ein globales Profil auf alle kommerziellen Regionen weltweit, laut AWS mit rund 10 Prozent Ersparnis. Für die Quote zählt jeweils die eigene Profil-Quote. Wer EU-Verarbeitung braucht, bleibt beim EU-Profil; das globale Profil ist dann keine Ausweichroute. Inferenzprofile unterstützen kein Provisioned Throughput. Laut ihren Modellkarten unterstützen Opus 5.5, Sonnet 5.5 und Haiku 5.5 am 01.11.2026 nur die Leistungsstufe Standard, nicht Priority, Flex oder Reserved.

Quote erhöhen

  1. Service-Quotas-Konsole öffnen, „AWS services“, dann „Amazon Bedrock“.
  2. Nach dem Modell suchen, zum Beispiel „Sonnet 5.5“, und den aktuellen Wert deines Kontos prüfen.
  3. Die Cross-Region-Quote für Tokens pro Minute wählen und eine Erhöhung beantragen.

AWS schreibt dazu: Erhöhungen werden nicht automatisch gewährt. Wer die Cross-Region-Quote beantragt, bekommt vom Support das Angebot, On-Demand- und Tagesquote gleich mit anzuheben. Vorrang haben Konten, die ihre bisherige Quote tatsächlich ausschöpfen, sonst kann der Antrag abgelehnt werden. Für Modelle im Status Legacy oder Deprecated gibt es keine Erhöhung. Bei Quoten, die das unterstützen, legst du in derselben Konsole einen CloudWatch-Alarm an, der vor dem Erreichen warnt.

Token-Deckel als Kostenbremse

Die Quoten von Bedrock gelten je Konto und Region, nicht je Person. Einen Deckel je Person hat Claude Desktop im Bedrock-Modus: inferenceMaxTokensPerWindow mit inferenceTokenWindowHours. Token aus dem Cache zählen dabei nicht mit, laut Anthropic begrenzt der Deckel also nicht die Rechnung. Wie du ihn setzt, steht in Claude Desktop über Bedrock einrichten. Für Budget-Alarm und Kosten je Abteilung siehe AWS Bedrock Kosten: Claude-Preise und Budget.

Claude Code über Bedrock: die Einstellungen

Claude Code nutzt auf Bedrock die Invoke-Schnittstelle, nicht Converse, und zählt damit gegen dieselben Quoten. Laut Doku:

  • CLAUDE_CODE_USE_BEDROCK=1 und AWS_REGION, für Frankfurt eu-central-1. In eu-Regionen nimmt Claude Code das Präfix eu.; ANTHROPIC_BEDROCK_REGION_PREFIX ändert die Vorgabe.
  • ANTHROPIC_MODEL festlegen. Ohne Angabe rechnet Claude Code laut Doku zum Opus-Preis.
  • CLAUDE_CODE_MAX_RETRIES setzt die Zahl der Wiederholungen, Vorgabe 10.
  • CLAUDE_CODE_RETRY_WATCHDOG=1 wiederholt 429- und 529-Fehler ohne Ende, gedacht für unbeaufsichtigte Läufe; CLAUDE_CODE_RETRY_WATCHDOG_MAX_WAIT_MS begrenzt die Wartezeit.
  • CLAUDE_CODE_MAX_OUTPUT_TOKENS setzt die Obergrenze für Ausgabe-Token der meisten Anfragen.

Die letzte Variable ist meine Folgerung aus beiden Dokus, kein gemessener Effekt: Weil Bedrock max_tokens beim Start reserviert, senkt ein kleinerer Wert die Reservierung je Anfrage. Zu knapp darf er nicht sein: Erreicht eine Antwort die Grenze, schneidet Claude Code sie laut Doku ab, und ein festes Denkbudget muss unter dem Wert bleiben. Senk ihn deshalb schrittweise und richte dich nach den echten Antwortlängen in CloudWatch. Meldet Claude Code „on-demand throughput isn't supported“, trägst du statt der Modell-ID ein Inferenzprofil ein. Die Installation selbst steht in Claude Code installieren: Windows, Mac, Linux.

Monitoring mit CloudWatch

Bedrock schreibt Metriken in den Namensraum AWS/Bedrock:

  • InvocationThrottles: gedrosselte Aufrufe. Wie viele du siehst, hängt laut AWS von den Wiederholungen im SDK ab.
  • InvocationClientErrors: Client-Fehler, laut AWS einschließlich Anfragen, die wegen einer Dienstquote abgelehnt wurden; die zählen nicht als Drosselung.
  • InputTokenCount, OutputTokenCount, CacheWriteInputTokenCount, CacheReadInputTokenCount: der Verbrauch.
  • EstimatedTPMQuotaUsage: geschätzter Quotenverbrauch. AWS warnt, dass die Drosselung auf der Reservierung beruht und die Schätzung nicht die einzige Grundlage sein soll.

Zwei Hinweise aus der Doku: Fehler, die vor der Modellzuordnung entstehen, fehlen in der Ansicht je ModelId; für die Summe also ohne Dimension abfragen. Und unter „Dashboards → Automatic dashboards → Bedrock“ zeigt „Token Counts by Model“ den Verbrauch je Modell. Welche Region eine Anfrage bedient hat, steht in CloudTrail im Feld additionalEventData.inferenceRegion.

Häufige Fragen

Was bedeutet ThrottlingException bei Bedrock?

Dein Konto hat eine Quote für das Modell überschritten, meist Tokens pro Minute. Die Anfrage wurde abgelehnt und lässt sich wiederholen; Backoff mit Jitter ist der erste Schritt.

Warum werde ich gedrosselt, obwohl ich wenig Token verbrauche?

Weil Bedrock beim Start Eingabe plus max_tokens reserviert und Ausgabe-Token bei Modellen wie Opus 5.5 zehnfach zählt. Ein großes max_tokens blockiert Quote, auch wenn die Antwort kurz bleibt.

Hilft das globale Profil gegen Drosselung?

Es hat eine eigene Quote und verteilt auf mehr Regionen. Die Anfragen können dann aber außerhalb der EU verarbeitet werden. Für EU-Anforderungen ist es keine Lösung.

Werden gedrosselte Anfragen berechnet?

AWS rechnet nach tatsächlichem Token-Verbrauch ab, nicht nach der Reservierung für die Quote. Gedrosselte Anfragen erscheinen auch nicht in der Metrik Invocations, die angenommene Anfragen zählt.

Wie du weitermachst

Prüf zuerst in Service Quotas die echten Werte deines Kontos, dann in CloudWatch InvocationThrottles und den Token-Verbrauch der letzten Tage. Liegt die Spitze nahe an der Quote, beantrag die Erhöhung; liegt sie weit darunter, ist meist max_tokens zu groß. Alles weitere zu Claude sammle ich auf der Seite Claude, Fragen dazu kannst du in meiner Community stellen.

Kevin Welter

Kevin Welter

Entwickler, IT-Architekt, Fachbuchautor (Kubernetes, Cloud-Infrastrukturen) und Speaker. Betreibt sein Business mit einer KI-Belegschaft aus vierzehn KI-Mitarbeitern und zeigt Selbstständigen in seiner Community, wie sie ihren ersten KI-Mitarbeiter einstellen.

Mehr über KI-Mitarbeiter

In einer Stunde läuft dein erster KI-Mitarbeiter

7 Tage kostenlos testen