AWS Bedrock AccessDenied: model oznaczony jako legacy albo nieaktywny (upgrade to an active model)

Ten runbook dotyczy błędów dostępu do modelu na Bedrock (nie throttlingu). Gdzie wybór modelu mieści się w architekturze agenta, opisaliśmy w artykule Amazon Bedrock AgentCore: architektura i cennik. W sprawie projektu warstwy modeli w produkcji umów konsultację.

Objawy

Błąd pojawia się w jednej z poniższych postaci. Najpierw ustal, którą, bo naprawa się różni.

# 1. Model oznaczony jako legacy po okresie bezczynności
AccessDeniedException: Access denied. This model is marked by provider as legacy
and you have not been actively using the model in the last 30 days.
Please upgrade to an active model on Amazon Bedrock.

# 2. Brak dostępu do modelu / przypięta przestarzała wersja
AccessDeniedException when calling the InvokeModel operation:
You don't have access to the model with the specified model ID.
# np. przy przypiętym "anthropic.claude-3-5-sonnet-20241022-v2:0"

Widoczny wpływ:

• Działający wcześniej agent lub aplikacja nagle zwraca AccessDenied przy każdym wywołaniu modelu
• Błąd pojawia się po dłuższej przerwie w używaniu konkretnego modelu (reguła 30 dni)
• Błąd pojawia się po ogłoszeniu wycofania modelu przez AWS lub po przypięciu konkretnej, starej wersji modelu

Przyczyna

Ten sam kod błędu (AccessDeniedException) ma tu dwie odrębne przyczyny związane z cyklem życia modelu, nie z uprawnieniami IAM.

1. Reguła 30 dni bezczynności dla modeli legacy. AWS oznacza część wersji modeli jako “legacy”. Jeśli konto nie wywoływało danego modelu przez około 30 dni, dostęp jest cofany, a kolejne wywołanie zwraca AccessDenied z komunikatem “marked by provider as legacy… upgrade to an active model”. Naprawa polega na przejściu na aktualną, aktywną wersję modelu (lub, gdzie to możliwe, ponownym wystąpieniu o dostęp).
2. Brak przyznanego dostępu albo przypięcie przestarzałej wersji. Konto nigdy nie miało (albo utraciło) dostęp do konkretnego ID modelu, lub kod przypina wycofywaną wersję (anthropic.claude-3-5-sonnet-20241022-v2:0) zastępowaną nowszym snapshotem albo profilem inferencji.

Warto znać jeden niuans: nowsze modele Anthropic na Bedrock coraz częściej udostępniane są przez profile inferencji (cross-region), a nie przez samo ID modelu. Przypięcie samego, starego ID modelu bywa więc źródłem problemu.

Częste przyczyny:

• Przerwa w używaniu modelu legacy dłuższa niż 30 dni
• Przypięcie konkretnej, wycofywanej wersji modelu zamiast aktualnego ID lub profilu inferencji
• Brak przyznanego dostępu do modelu na koncie lub w regionie
• Wywołanie po ogłoszeniu wycofania modelu przez AWS

Naprawa

Krok 1: Sprawdź, które modele są aktywne

Wypisz dostępne modele fundamentalne i potwierdź ich status oraz aktualne ID.

# Lista aktywnych modeli fundamentalnych w regionie
aws bedrock list-foundation-models \
  --region eu-central-1 \
  --query 'modelSummaries[].{Id:modelId, Name:modelName, Lifecycle:modelLifecycle.status}'

# Szczegóły konkretnego modelu (potwierdź status cyklu życia)
aws bedrock get-foundation-model \
  --model-identifier anthropic.claude-3-5-sonnet-20241022-v2:0 \
  --region eu-central-1

Jeśli status modelu to LEGACY (lub model nie występuje na liście aktywnych), to przypadek z cyklu życia (krok 2). Jeśli model jest aktywny, ale nadal dostajesz AccessDenied, sprawdź dostęp do modelu (krok 3).

Krok 2: Przejdź na aktywny model lub profil inferencji

Zastąp przestarzałe ID modelu aktualną, aktywną wersją. Dla nowszych modeli Anthropic użyj profilu inferencji zamiast samego ID.

# Antywzorzec: przypięte, wycofywane ID modelu
model_id = "anthropic.claude-3-5-sonnet-20241022-v2:0"   # legacy

# Lepiej: aktualne, aktywne ID modelu (lub jego profil inferencji cross-region)
# Zweryfikuj aktualny identyfikator w `list-foundation-models` / dokumentacji AWS
model_id = "anthropic.claude-sonnet-5"          # aktualny aktywny model
# lub przez profil inferencji cross-region:
# model_id = "eu.anthropic.claude-sonnet-5"

• Nie przypinaj samego, starego ID modelu na sztywno w kodzie produkcyjnym
• Trzymaj identyfikator modelu w konfiguracji, nie w kodzie, aby dało się go zmienić bez wdrożenia
• Rozważ fallback na drugi aktywny model, gdy główny zwróci AccessDenied

Krok 3: Potwierdź lub ponownie przyznaj dostęp do modelu

Jeśli model jest aktywny, ale wywołanie nadal kończy się AccessDenied, sprawdź dostęp do modelu na koncie i w regionie (konsola Bedrock → Model access). W razie potrzeby wystąp ponownie o dostęp do właściwej, aktywnej wersji.

Krok 4: Zapobieganie

• Nie pozwól, by model legacy stał bezczynnie ponad 30 dni, jeśli musi pozostać dostępny, albo z góry zaplanuj przejście na aktywny model
• Monitoruj ogłoszenia AWS o cyklu życia modeli i wycofaniach
• Trzymaj co najmniej jeden aktywny model “rozgrzany” jako ścieżkę awaryjną

Weryfikacja

Potwierdź, że wywołanie aktywnego modelu zwraca 200.

# Wywołanie aktywnego modelu / profilu inferencji: oczekuj 200 i odpowiedzi modelu
aws bedrock-runtime invoke-model \
  --model-id anthropic.claude-sonnet-5 \
  --body '{"anthropic_version":"bedrock-2023-05-31","max_tokens":16,"messages":[{"role":"user","content":"ping"}]}' \
  --cli-binary-format raw-in-base64-out \
  --region eu-central-1 \
  /dev/stdout

Oczekiwane: wywołanie zwraca odpowiedź modelu bez AccessDenied. Jeśli błąd nadal występuje przy aktywnym modelu, wróć do kroku 3 (dostęp do modelu).

Powiązane

• Bedrock InvokeModel ThrottlingException 429 - powiązana klasa błędów Bedrock (throttling, nie dostęp)
• Bedrock: zbyt wiele tokenów na dobę - druga kwotowa klasa błędów Bedrock
• Amazon Bedrock AgentCore: architektura, komponenty i cennik - gdzie wybór modelu mieści się w stosie agenta
• Uruchamianie LLM na AWS: Bedrock vs SageMaker vs self-hosting na EKS - dobór i wersjonowanie modeli
• Dokumentacja AWS o cyklu życia modeli Bedrock