Am 01.08.2026 lieferte Bedrock waehrend eines Laufs ServiceUnavailableException.
Botocore versuchte es dreimal in fuenf Sekunden und gab auf, die
Web-Source-Selektion fiel ersatzlos aus. Im Bericht war davon nichts zu sehen,
der Lauf galt als vollstaendig. Gemessen sind es zwei betroffene Aufrufe bei
rund 340, also 0,6 Prozent, aber jeder Vorfall kostet einen ganzen
Pipeline-Schritt.
Der Fehler ist auch keiner unserer Quote. ServiceUnavailableException ist ein
503, AWS hat also gerade keine Kapazitaet fuer das Modell. Unsere Meldung
sagte trotzdem "Rate-Limit", weil der Code beide Faelle in einen Topf warf.
Aendert sich damit:
1. Geduldiges Wiederholen. Kapazitaets- (503), Kontingent- (429) und
Verbindungsfehler werden nach 5, 15 und 30 Sekunden erneut versucht. Diese
Dellen dauern typischerweise unter einer Minute, unsere bisherigen fuenf
Sekunden lagen genau im ungeguenstigsten Fenster. Stufen ueber
BEDROCK_RETRY_WAITS einstellbar.
2. Zwei Bremsen gegen lange Laeufe. Gewartet wird nur, wenn die Wartezeit ins
Zeitbudget des Aufrufs passt (die Wartezeit zaehlt gegen dasselbe
asyncio-Budget, und die Haiku-Planungsaufrufe haben nur 120 Sekunden), und
nur solange das Wartebudget des Refreshs reicht (BEDROCK_RETRY_BUDGET_S,
Vorgabe 120 Sekunden). Ein Lauf kann sich dadurch um hoechstens zwei
Minuten verlaengern.
3. Ursachen werden getrennt benannt. Im Log steht jetzt "hat keine freie
Kapazitaet" oder "meldet ausgeschoepftes Kontingent" statt pauschal
"Rate-Limit". Nach aussen bleibt beides die Kategorie rate_limit, damit die
Retry-Steuerung des Orchestrators unveraendert greift.
4. Stoerungen werden sichtbar. Waehrend einer Wartezeit meldet die Oberflaeche
"KI-Dienst hat keine freie Kapazitaet, neuer Versuch in 15 Sekunden", sonst
sieht die stehende Anzeige wie ein Haenger aus. Nach dem Lauf steht eine
Zusammenfassung im Refresh-Protokoll, auch wenn der Lauf sonst glatt
durchlief.
5. botocore laeuft im Modus 'adaptive' statt 'standard'. Es bremst sich bei
Drosselung selbst ein und deckt die Sekunden ab, unsere Schleife die
Zehnersekunden.
Zeitliche Wirkung, gemessen am EU-Lauf der Ceuta-Lage (252 Sekunden, 15
Bedrock-Aufrufe): im stoerungsfreien Fall null, im betroffenen Lauf rund eine
Minute mehr. Bei 0,6 Prozent Fehlerrate je Aufruf trifft das etwa jeden
elften Lauf, im Mittel ueber alle Laeufe rund zwei Prozent.
Gegenprobe mit einem echten Bedrock-Aufruf ueber den geaenderten Pfad: Antwort,
Verbrauch und Kosten unveraendert, keine Stoerung protokolliert.
Neu sind 23 Pruefungen, insgesamt laufen 179 ohne Netzzugriff und ohne Kosten.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
