Claude-Störung: Runbook für 429, 529 und EU-Fallback

TL;DR

Eine Claude-Störung zeigt sich als 529 (Überlast), 500 oder 504. Ein 429 ist meist Ihr eigenes Limit. Beides mit Backoff und Jitter wiederholen, einen 429 wegen Ausgabengrenze aber nie. Für personenbezogene Daten wechseln Sie zwischen Bedrock-EU-Geo-Profil und Vertex-Multi-Region eu. Die Anthropic API taugt nicht als EU-Fallback: Sie hat keine EU-Inferenz.

Welcher Claude-Fehler bedeutet was?

Es gibt drei Gruppen. 529, 500 und 504 bedeuten: Der Anbieter hat ein Problem, also wiederholen und umschalten. 429 heißt: Sie haben ein Limit erreicht, entweder ein Rate Limit mit retry-after oder eine Ausgabengrenze, bei der jeder Retry sinnlos ist. 400, 401, 403 und 413 sind eigene Fehler, die ein Fallback nur verdeckt.

Die Fehlerseite der Claude API beschreibt 529 overloaded_error als vorübergehende Überlast, die bei hohem Verkehr über alle Nutzer hinweg auftreten kann. Sie warnt außerdem: Wenn Ihre eigene Nutzung sprunghaft steigt, können Beschleunigungslimits 429 auslösen. Bedrock und Vertex verpacken dieselben Modelle in eigene Fehlerbegriffe. Wer Bereitschaft hat, braucht deshalb eine Tabelle und nicht drei Browser-Tabs.

Code	Wo	Bedeutung	Maßnahme
429 rate_limit_error	Claude API	RPM-, ITPM- oder OTPM-Limit erreicht	retry-after abwarten, dann wiederholen
429 mit enforced_spend_limit_reached	Claude API	Monatliche Tier-Ausgabengrenze erreicht	Nicht wiederholen. Tier anheben oder umschalten
400 invalid_request_error	Claude API	Fehlerhafte Anfrage oder selbst gesetztes Ausgabenlimit	Anfrage korrigieren oder Limit erhöhen
500 api_error / 504 timeout_error	Claude API	Interner Fehler oder Timeout	Mit Backoff wiederholen, lange Jobs streamen
529 overloaded_error	Claude API, Bedrock	Kapazität beim Anbieter, nicht Ihr Kontingent	Mit Jitter wiederholen, dann umschalten
429 ThrottlingException	Bedrock	Kontingent des AWS-Kontos überschritten	Backoff, Kontingenterhöhung oder zweite Route
503 ServiceUnavailable	Bedrock	Hohe Nachfrage in der Region	Backoff, Cross-Region-Inferenz
429 “Resource exhausted, please try again later.”	Vertex	Geteilte Pay-as-you-go-Kapazität erschöpft	Exponentieller Backoff, dann umschalten

Zwei Details verändern das Runbook. Die Seite zu Rate Limits stellt klar: Der 429 wegen Ausgabengrenze hat keinen retry-after-Header und schlägt bis 00:00 UTC am Ersten des Folgemonats fehl. Die Grenzen liegen bei 500 USD (Start), 1.000 USD (Build) und 200.000 USD (Scale). Und die Bedrock-Fehlerreferenz sagt ausdrücklich, dass ein 503 nichts mit Ihren Kontingenten zu tun hat. Die melden sich mit 429. Lesen Sie also erst den Statuscode, bevor Sie ein Ticket eröffnen.

Wie wiederholen Sie 429- und 529-Fehler richtig?

Lassen Sie das SDK wiederholen, keine selbst gebaute Schleife. Die Anthropic SDKs wiederholen Verbindungsfehler, 408, 409, 429 und alle 5xx (also auch 529) standardmäßig zweimal mit kurzem exponentiellem Backoff und beachten retry-after. Für Batch-Jobs erhöhen Sie max_retries maßvoll, für Dialoganwendungen bleiben Sie niedrig.

Die Python-SDK-Doku nennt die Standardwerte: 2 Wiederholungen und 10 Minuten Timeout pro Anfrage. Ein zu kleines Limit lösen Retries nicht. Rate Limits arbeiten mit einem Token-Bucket, und Anthropic weist darauf hin, dass 60 RPM als 1 Anfrage pro Sekunde durchgesetzt werden können. 20 parallele Aufrufe können also gedrosselt werden, obwohl die Minutensumme passt. Im Start-Tier erlauben Sonnet 5 und Opus 5.5 jeweils 1.000 RPM, 2.000.000 Input-Token und 400.000 Output-Token pro Minute. Gecachte Lesezugriffe zählen bei den meisten Modellen nicht zum ITPM-Limit. Prompt Caching ist damit die billigste Kapazitätserhöhung.

import anthropic

# Dialogpfad: schnell scheitern, damit die Fallback-Route übernimmt
interactive = anthropic.Anthropic(max_retries=2, timeout=60.0)

# Batch-Pfad: mehr Geduld
batch = anthropic.Anthropic(max_retries=6)

try:
    msg = interactive.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        messages=[{"role": "user", "content": "Fasse dieses Ticket zusammen."}],
    )
    print(msg._request_id)
except anthropic.RateLimitError as e:
    # Ausgabengrenze: kein retry-after, Wiederholen bringt nichts
    print(e.status_code, e.response.headers.get("retry-after"))

AWS empfiehlt für 429, 500, 503 und 529 auf Bedrock exponentiellen Backoff mit zufälligem Jitter und warnt vor synchronen Retries vieler Clients, weil sie die Erholung bremsen. Googles Seite zu Fehler 429 rät für Vertex dasselbe. Eine Falle auf AWS: NAT-Gateways, VPC-Interface-Endpunkte und Network Load Balancer kappen inaktive TCP-Verbindungen nach 350 Sekunden, Linux sendet Keep-alives aber erst nach 7.200 Sekunden. Lange Streaming-Aufrufe sterben dann still und sehen aus wie eine Störung. Abhilfe: tcp_keepalive=True in der boto3-Konfiguration und ein Kernel-Keep-alive unter 350 Sekunden.

Welcher Fallback hält Claude in der EU?

Bedrock mit dem Geo-Inferenzprofil eu. und Vertex mit der Multi-Region eu. Beide bedienen aktuelle Claude-Modelle, beide verarbeiten in EU-Regionen, beide kosten 10 % mehr als ihre globalen Routen. Die Anthropic API ist kein EU-Fallback: inference_geo kennt nur us und global, das Workspace-Geo nur die USA.

Das überrascht viele Teams. Die Seite zur Datenresidenz nennt genau zwei Inferenz-Geos. Ein Fallback auf api.anthropic.com bringt personenbezogene Daten aus der EU heraus, und zwar genau in dem Moment, in dem niemand an die DSGVO denkt. Globale Routen auf Bedrock und Vertex tun dasselbe. Googles erster Tipp gegen 429 lautet: “Nutzen Sie den globalen Endpunkt.” Für EU-Daten ignorieren Sie diesen Tipp.

Route	Modell-ID	Residenz	Dokumentierte Kapazität
Bedrock EU-Geo-Profil	eu.anthropic.claude-opus-5-5, eu.anthropic.claude-sonnet-5	EU-Regionen	Standard 2 Mio. Input-TPM, auf Antrag bis 5 Mio. Input- und 500.000 Output-TPM
Vertex Multi-Region eu	claude-opus-5-5, claude-sonnet-5	EU-Multi-Region	Opus 5.5: 1.000 QPM, 10 Mio. Input-TPM. Sonnet 5: 1.250 QPM, 12,5 Mio. Input-TPM
Bedrock global, Vertex global	Präfix global., region="global"	Weltweit	Vertex Opus 5.5 global: 2.000 QPM
Claude API	claude-opus-5-5	nur global oder us	Tier-Limits wie oben

Die beiden EU-Routen fallen unabhängig voneinander aus, weil sie auf verschiedenen Clouds mit eigenen Kontingenten laufen. Zwei Hinweise aus der AWS-Doku zur Cross-Region-Inferenz: Ihre SCPs müssen alle Zielregionen des Profils erlauben, sonst bricht das Geo-Profil selbst. Und CloudTrail protokolliert jede Anfrage in der Quellregion, das Feld additionalEventData.inferenceRegion zeigt, wo sie lief. Dieses Feld gehört in die Nachweise für Ihren Datenschutzbeauftragten. Die Einrichtung beider Routen beschreiben wir in Claude auf AWS Bedrock in Frankfurt und Claude auf Vertex AI in Europa.

Verwechseln Sie das nicht mit dem Anthropic-Parameter fallbacks. Laut der Seite zu Refusals und Fallback löst ihn nur eine Ablehnung durch einen Sicherheitsklassifikator aus. Rate Limit, Überlast oder Serverfehler kommen unverändert zurück. Auf Bedrock und Google Cloud gibt es ihn gar nicht. Er ist ein Werkzeug gegen Ablehnungen, nicht gegen Ausfälle.

Im Client ist der Fallback eine kurze Schleife über zwei Clients:

import anthropic
from anthropic import AnthropicBedrock, AnthropicVertex

ROUTES = [
    (AnthropicBedrock(aws_region="eu-central-1", max_retries=2), "eu.anthropic.claude-sonnet-5"),
    (AnthropicVertex(project_id="mein-eu-projekt", region="eu", max_retries=2), "claude-sonnet-5"),
]
FAILOVER = (anthropic.RateLimitError, anthropic.InternalServerError, anthropic.APIConnectionError)

def ask(messages, max_tokens=1024):
    last = None
    for client, model in ROUTES:
        try:
            return client.messages.create(model=model, max_tokens=max_tokens, messages=messages)
        except FAILOVER as e:  # 429, 5xx inkl. 529, Netzwerk
            last = e
    raise last

400, 401 und 403 fehlen in FAILOVER mit Absicht. Eine kaputte Anfrage scheitert auf beiden Clouds, und ein Authentifizierungsfehler auf einer Cloud ist ein Konfigurationsproblem, das Sie sehen wollen.

Mit einem Gateway wandert dieselbe Logik in die Konfiguration. LiteLLM wechselt zur nächsten Modellgruppe, sobald num_retries aufgebraucht ist. Die Fallback-Doku nennt ausdrücklich 429 und 500 als abgedeckt. LiteLLM übersetzt die Location eu in aiplatform.eu.rep.googleapis.com. Die Grundinstallation steht in unserem Artikel zum LiteLLM-EU-Gateway.

model_list:
  - model_name: claude-eu
    litellm_params:
      model: bedrock/eu.anthropic.claude-sonnet-5
      aws_region_name: eu-central-1
  - model_name: claude-eu-vertex
    litellm_params:
      model: vertex_ai/claude-sonnet-5
      vertex_ai_project: mein-eu-projekt
      vertex_ai_location: eu

litellm_settings:
  num_retries: 2
  allowed_fails: 3
  cooldown_time: 30
  fallbacks: [{"claude-eu": ["claude-eu-vertex"]}]

allowed_fails und cooldown_time sind die Beispielwerte aus der Doku und ein brauchbarer Start. Jede Zeile im Spend-Log speichert attempted_fallbacks und original_model_group, Sie können also später zählen, wie viele Anfragen die Ersatzroute bedient hat. Seit LiteLLM v1.85.0 wird mock_testing_fallbacks aus Proxy-Anfragen entfernt. Testen Sie den Fallback, indem Sie die Primärroute in Staging bewusst brechen, etwa mit falscher Region oder entzogener IAM-Berechtigung.

Wie sieht das Störungs-Runbook Schritt für Schritt aus?

Erkennen Sie die Störung über Ihre eigene Fehlerquote, bestätigen Sie sie auf der richtigen Statusseite, schalten Sie bewusst um und notieren Sie Request-IDs von Anfang an. Die meiste Zeit geht bei Claude-Störungen auf der falschen Statusseite verloren oder mit Retries gegen eine Ausgabengrenze. Das Runbook unten passt auf einen Bildschirm.

status.claude.com führt claude.ai, Claude Console, Claude API, Claude Code, Claude Cowork und Claude for Government. Bedrock und Vertex stehen dort nicht. Im September 2026 verzeichnete die Seite 13 Vorfälle, 8 davon mit der Komponente Claude API, meist erhöhte Fehlerraten für einzelne Modelle. Ein Vorfall dort beweist nicht, dass Bedrock ausfällt, und ein Bedrock-Problem taucht dort nicht auf. Abonnieren Sie in der Bereitschaft alle drei: die Claude-Statusseite (E-Mail, SMS, Slack, Teams, Webhook oder Atom), das AWS Health Dashboard und Google Cloud Service Health.

1. Alarm. Bereitschaft auslösen, wenn die Quote aus 5xx und 429 bei Claude-Aufrufen 5 Minuten über Ihrem Schwellwert liegt, getrennt nach Anbieter und Modell.
2. Einordnen. Statuscode und Body lesen. Ausgabengrenze (enforced_spend_limit_reached) oder 4xx: Retries stoppen, an den Budgetverantwortlichen eskalieren. 429-Drosselung, 503, 529: Anbieter oder Kapazität.
3. Eingrenzen. status.claude.com, AWS Health und Google Cloud Service Health prüfen. Festhalten, ob ein Modell, eine Route oder alles betroffen ist.
4. Umschalten. Hat das Gateway nicht schon gewechselt, Verkehr auf die andere EU-Route legen. Nie auf eine globale Route oder api.anthropic.com, solange personenbezogene Daten im Spiel sind.
5. Last abwerfen. Batch-Jobs pausieren, Parallelität senken, unkritische Funktionen auf ein kleineres Modell derselben EU-Route legen.
6. Kommunizieren. Erste interne Meldung nach spätestens 15 Minuten: Auswirkung, aktive Route, Zeitpunkt des nächsten Updates. Danach alle 30 Minuten. Kunden informieren Sie nur, wenn das Umschalten nicht geklappt hat.
7. Belege sichern. request-id fehlgeschlagener Claude-API-Aufrufe, AWS-Request-IDs und Zeitstempel aufheben. AWS verlangt für ein 529-Ticket Request-ID, Modell-ID, Region und Zeitpunkt.
8. Zurückschalten. Erst wenn die Primärroute 30 Minuten sauber läuft, sonst pendelt der Verkehr.
9. Post-Mortem. Innerhalb von 5 Arbeitstagen: Zeitlinie, Anzahl Anfragen über die Ersatzroute, Kostendifferenz und eine konkrete Änderung an Kontingenten, Alarmen oder Konfiguration.

Die Intervalle von 15 und 30 Minuten sind unsere Empfehlung, keine Vorgabe der Anbieter.

Selbst betreiben oder auslagern?

Selbst betreiben lohnt sich, wenn Sie bereits eine Rufbereitschaft rund um die Uhr und Konten bei AWS und Google Cloud haben. Den Fallback zu bauen dauert wenige Tage. Teuer ist der Betrieb: Kontingentprüfungen, Übungen, Modell-ID-Wechsel und Post-Mortems. Auslagern sollten Sie, wenn Claude geschäftskritisch ist, nachts aber niemand erreichbar ist.

Was der Eigenbetrieb konkret bedeutet:

Aufgabe	Wer	Wie oft
Bereitschaft für Claude-Routen	Plattform- oder SRE-Team	24/7, wenn Kunden Claude direkt nutzen
Kontingente prüfen, Erhöhungen bei AWS und Google beantragen	Plattformverantwortliche	Bei jedem Modellstart, mindestens quartalsweise
Umschaltübung in Staging	Plattform-Engineer	Quartalsweise (unsere Empfehlung)
Modell-IDs auf beiden Clouds angleichen	Plattform-Engineer	Bei jedem Release (Opus 5.5 kam am 22. September 2026 auf Vertex)
Post-Mortem und Statuskommunikation	Incident Commander	Pro Vorfall

Unsere Schätzung, keine belegte Zahl: 2 bis 4 Personentage für Aufbau und Test der Zwei-Cloud-Route, danach etwa ein halber Tag pro Monat für Übungen, Kontingente und Modellwechsel, dazu die Bereitschaftszulage. Ohne Nachtbereitschaft sind die eigentlichen Kosten die Bereitschaft, nicht der Code.

Einen Managed-Service-Anbieter zu beauftragen ist sinnvoll, wenn Claude in einem Kundenprozess steckt und Ihnen die Nachtabdeckung fehlt, oder wenn Sie nur für den Fallback eine zweite Cloud eröffnen müssten. Wenig Sinn ergibt es für interne Werkzeuge, bei denen zwei Stunden Ausfall lästig, aber nicht teuer sind. Ebenso wenig, wenn der Anbieter den Verkehr über eigene Konten leiten würde, denn dann ändert sich, wer die Daten verarbeitet.

Was Sie von einem Anbieter für dieses Thema verlangen sollten:

• SLA mit realistischem Umfang. Reaktionszeiten je Schweregrad für Erkennung und Umschaltung. Kapazität, die AWS oder Google nicht zusagen, kann auch der Dienstleister nicht zusagen. Google nimmt Pay-as-you-go-429 aus der SLA-Fehlerquote heraus.
• AVV und Unterauftragsverarbeiter. Ein AVV nach Art. 28 DSGVO und eine Liste der Unterauftragsverarbeiter mit AWS und Google samt exakten Regionen. Prüfen Sie, dass in der Konfiguration keine globale Route und kein Fallback auf die Anthropic API steht.
• Zugriffsmodell. Betrieb in Ihren eigenen AWS- und Google-Cloud-Konten über Rollen mit minimalen Rechten, Lesezugriff auf Logs, keine Kopie von Prompts in Systeme des Dienstleisters.
• Exit. Gateway-Konfiguration, Alarmregeln und Runbook liegen in Ihrem Repository. Schlüssel und Kontingente bleiben in Ihren Konten, damit Sie innerhalb eines Tages übernehmen können.

Die Preise samt 10 % Aufschlag für beide EU-Routen stehen in unserem Claude-API-Kostenvergleich.

FAQ

Ist ein Claude-Fehler 529 meine Schuld?

Nein. Ein 529 overloaded_error bedeutet, dass dem Anbieter vorübergehend Kapazität fehlt. Ihr Kontingent meldet sich mit 429. Wiederholen Sie mit Backoff und Jitter und schalten Sie auf die zweite EU-Route, wenn 529 länger als ein paar Minuten anhält.

Was ist der Unterschied zwischen 429 und 529 bei Claude?

Ein 429 heißt: Sie haben ein Limit erreicht, also Rate Limit, Beschleunigungslimit oder Ausgabengrenze. Ein 529 heißt: Anthropic oder der Cloud-Anbieter ist für alle überlastet. Ein Rate-Limit-429 löst sich nach retry-after. Ein 429 wegen Ausgabengrenze erst im Folgemonat oder mit höherem Tier.

Kostet der EU-Fallback mehr als eine globale Route?

Ja. Regionale und Multi-Region-Endpunkte auf Bedrock und Vertex kosten bei aktuellen Modellen 10 % mehr als globale Endpunkte. US-only-Inferenz auf der Claude API kostet das 1,1-Fache. Während einer Störung rechnet die Ersatzroute zu ihren eigenen Preisen ab, planen Sie beide ein.

Kann ich auf die Anthropic API ausweichen und trotzdem DSGVO-konform in der EU bleiben?

Nein. Die Claude API kennt für inference_geo nur us und global, das Workspace-Geo nur die USA. Für EU-Residenz besteht das Fallback-Paar aus Bedrock mit eu.-Profil und Vertex mit Multi-Region eu.

Hilft der Anthropic-Parameter fallbacks bei einer Störung?

Nein. Er wiederholt eine Anfrage nur, wenn ein Sicherheitsklassifikator sie ablehnt. Rate Limits, Überlast und Serverfehler kommen unverändert zurück, und auf Bedrock oder Google Cloud ist der Parameter nicht verfügbar.

Wo sehe ich, ob Claude gerade gestört ist?

Auf status.claude.com für Claude API, claude.ai und Claude Code. Bedrock und Vertex stehen dort nicht, prüfen Sie deshalb auch das AWS Health Dashboard und Google Cloud Service Health. Ihre eigenen Fehlerquoten sind schneller als jede Statusseite.

Wie viele Retries sollte ich einstellen?

Für Dialoganwendungen den SDK-Standard von 2, damit die Fallback-Route schnell übernimmt. Für Batch-Jobs, die warten können, max_retries erhöhen. Einen 429 wegen Ausgabengrenze nie wiederholen, ebenso wenig 400, 401 oder 403.

Quellen

1. Anthropic Docs: API-Fehler (1. Oktober 2026)
2. Anthropic Docs: Rate Limits (1. Oktober 2026)
3. Anthropic Docs: Python SDK (1. Oktober 2026)
4. Anthropic Docs: Datenresidenz (1. Oktober 2026)
5. Anthropic Docs: Refusals and fallback (1. Oktober 2026)
6. Anthropic Docs: Claude in Amazon Bedrock (1. Oktober 2026)
7. Anthropic Docs: Claude auf Google Cloud (1. Oktober 2026)
8. AWS: Bedrock API-Fehlercodes (1. Oktober 2026)
9. AWS: Cross-Region Inference (1. Oktober 2026)
10. AWS: Geographic Cross-Region Inference (1. Oktober 2026)
11. AWS: Modellkarte Claude Opus 5.5 (1. Oktober 2026)
12. Google Cloud: Fehlercode 429 (1. Oktober 2026)
13. Google Cloud: Claude Opus 5.5 (1. Oktober 2026)
14. Google Cloud: Claude Sonnet 5 (1. Oktober 2026)
15. LiteLLM Docs: Fallbacks (1. Oktober 2026)
16. Claude-Statusseite (1. Oktober 2026)