Anthropic Claude Opus auf Bedrock braucht separates Use-Case-Agreement, nicht nur Häkchen

Anthropic Claude Opus auf Bedrock braucht separates Use-Case-Agreement

Kontext

Bei der Erstellung des Welle-1-Backend-Routing-Setups in Open WebUI VF gab es einen LiteLLM-Error:

litellm.APIConnectionError: BedrockException - anthropic.claude-opus-4-7 is not available for this account.

Annahme: „nur Haeckchen in Bedrock Console → Model Access setzen”. Falsch.

Realitaets-Check (2026-05-18)

aws bedrock get-foundation-model-availability --model-id anthropic.claude-opus-4-7 --region eu-central-1 zeigt:

agreementAvailability.status:   NOT_AVAILABLE   ← das ist der Blocker
authorizationStatus:            AUTHORIZED
entitlementAvailability:        AVAILABLE
regionAvailability:             AVAILABLE

Gleiches Bild fuer Opus 4.5 + Opus 4.6 — alle Opus-Versionen haengen am gleichen Anthropic-Use-Case-Agreement, nicht modellspezifisch.

Zum Vergleich Sonnet 4.6 (funktioniert sofort nach Modell-Access-Klick):

agreementAvailability.status:   AVAILABLE       ← Sonnet/Haiku haben kein extra Agreement

Was passiert beim „Häkchen setzen” in der Console

Wenn man in Bedrock Console → Model Access auf Claude Opus 4.7 klickt:

• Sonnet/Haiku-Modelle: einfach Check-Box, sofort approved
• Opus-Modelle: Anthropic-spezifisches Use-Case-Form mit Fragen zu Branche, Nutzer-Anzahl, Datenschutz-Hinweisen. Submit → Anthropic prueft manuell, typische Wartezeit 24-48h, dann agreementAvailability wechselt auf AVAILABLE

Konsequenz fuer Folgekunden

Wann immer ein Kunden-Setup Opus plant (Welle-1-Backend-Routing, Industriekunden mit komplexen Workflows, etc.):

1. Use-Case-Agreement-Approval ins Setup-Runbook — kann nicht „on-demand” wenn LLM gerade gebraucht wird, sondern muss tage-vorher beantragt sein
2. Standard Use-Case-Description als Vorlage:
   • „Multi-tenant chat assistant for German SME — accounting analysis, document workflows, mail draft preparation.”
   • „Hosted on AWS Fargate in eu-central-1, data stays in EU.”
   • „GDPR-compliant, data residency EU only, no training opt-in.”
   • Branche: „Professional services / SaaS”
   • Nutzer-Zahl: realistische Range pro Tenant + Erwartung in 12 Monaten
3. Stack-Code-Fallback — Backend-Routing-Code sollte einen Fallback haben, falls Opus nicht aktiviert: Sonnet macht den Job (vermutlich langsamer + weniger Genauigkeit, aber funktionsfaehig). Nicht: BedrockException ungefiltert an den User durchreichen
4. Multi-Version-Antrag: im Use-Case-Form alle Opus-Versionen ankreuzen die man perspektivisch nutzen will (4.5, 4.6, 4.7) — ein Antrag, mehrere Approvals

Praxis-Tipp Verifikation

Vor jedem Kunden-Live-Gang mit Opus-Anbindung:

for v in opus-4-5-20251101-v1 opus-4-6-v1 opus-4-7; do
  echo "=== anthropic.claude-$v ==="
  aws bedrock get-foundation-model-availability \
    --region eu-central-1 \
    --profile <kunden-profile> \
    --model-id "anthropic.claude-$v" 2>&1 | grep agreementAvailability -A1
done

Wenn alle drei NOT_AVAILABLE zeigen → Use-Case-Antrag steht aus, Live-Gang verschieben bis Approval.

Cross-Refs

• welle-1-perfektion — VF-Anwendungsfall der den Fall entdeckt hat
• _index — AWS-Org-Doku
• bedrock-eu-image-gen-limitation — verwandte EU-Bedrock-Doku (was geht, was nicht)