AWS zamknie starą przestrzeń nazw bedrock-agentcore usługi AWS Agent Registry 30 października 2026 r. Do tego dnia klienci muszą sami przenieść istniejące rejestry i rekordy: AWS nie robi tego automatycznie, a dane pozostawione w starej przestrzeni zostaną utracone. Migracja dotyczy wyłącznie AWS Agent Registry. AWS opisuje termin, skutki i dostępne metody migracji.

Wybierz metodę pasującą do sposobu pracy z rejestrem

AWS udostępnia narzędzie, które pobiera dane, przekształca je do nowego schematu i ładuje do nowych rejestrów na tym samym koncie AWS i w tym samym regionie. Sposób przeprowadzenia migracji zależy przede wszystkim od tego, czy przenosisz dane jednorazowo, potrzebujesz procesu zarządzanego, czy rekordy są nadal zapisywane przez działający system.

MetodaKiedy pasujeSposób migracji i przełączenia
Jednorazowa migracja lokalna lub przez AWS CloudShellGdy wystarczy pojedyncze uruchomienie narzędziaPełne przeniesienie danych z terminala lub AWS CloudShell, bez wdrażania infrastruktury migracyjnej
Zarządzane zadania AWS GlueGdy migracja ma działać bez nadzoru lub wymagać dodatkowego ładowania przy przełączeniuPełne ładowanie, a następnie ładowanie przyrostowe w momencie przełączenia
Tryb active-activeGdy produkcyjny rejestr nadal otrzymuje zapisyPo pełnej migracji aplikacja zapisuje dane w obu przestrzeniach nazw; po walidacji odczyty i zapisy przechodzą do agent-registry

W przypadku spokojnego, jednorazowego przeniesienia wystarczy lokalne uruchomienie lub CloudShell. AWS Glue odpowiada na potrzebę migracji zarządzanej i ładowania przyrostowego, a active-active pozwala utrzymać zapisy podczas przygotowania przełączenia. AWS opisuje te trzy warianty w przewodniku migracji.

Zaplanuj zmiany w aplikacji i integracjach

Samo przeniesienie rekordów nie wystarczy. Zmieniają się endpointy, uprawnienia IAM, ARN-y, klienci SDK, przestrzeń nazw CLI, schemat API oraz odwołania używane przez monitoring i reguły zdarzeń. AWS wskazuje, że zmiany schematu są niekompatybilne wstecz: kod budujący żądania do Registry lub odczytujący odpowiedzi trzeba dostosować.

Najważniejsze mapowania obejmują:

  • Endpointy: bedrock-agentcore.{region}.amazonaws.com zmienia się na agent-registry.{region}.api.aws, a bedrock-agentcore-control.{region}.amazonaws.com na agent-registry-control.{region}.api.aws.
  • IAM: prefiks akcji bedrock-agentcore:* zmienia się na agent-registry:*, a podmiot usługi bedrock-agentcore.amazonaws.com na agent-registry.amazonaws.com.
  • Klienci i CLI: BedrockAgentCoreClient oraz BedrockAgentCoreControlClient zastępują odpowiednio AgentRegistryClient i AgentRegistryControlClient; komendy przechodzą z aws bedrock-agentcore na aws agent-registry.
  • Monitoring i zdarzenia: przestrzeń nazw CloudWatch zmienia się z AWS/BedrockAgentCore na AWS/AgentRegistry. Reguły EventBridge dopasowujące źródło aws.bedrock-agentcore lub zmienione typy szczegółów trzeba dostosować do aws.agent-registry; zdarzenia nadal korzystają z domyślnej magistrali zdarzeń.

Zmienia się także model danych API. Nowe rekordy wymagają pól name i recordType; inlineContent staje się data, a schemaVersion i protocolVersion zastępuje dataSchemaVersion. Zmienia się również struktura deskryptorów, a pole synchronizacji source trafia do deskryptorów. Zaktualizuj więc zarówno kod aplikacji, jak i integracje, które korzystają z tych wartości.

Polityka BedrockAgentCoreFullAccess nie otrzymuje automatycznie uprawnień agent-registry:*; AWS wskazuje AgentRegistryFullAccess jako politykę dla dostępu do Registry. Nie usuwaj jednak wszystkich uprawnień z prefiksem bedrock-agentcore: zasoby workload identity i dostawcy poświadczeń OAuth nadal z niego korzystają. Szczegóły mapowań AWS opisuje w dokumentacji migracji.

Przed ładowaniem sprawdź role synchronizujące rekordy

Jeśli rekordy są synchronizowane z użyciem poświadczeń roli IAM, jej polityka zaufania musi akceptować agent-registry.amazonaws.com przed załadowaniem danych na żywo. Narzędzie migracyjne AWS nie wykrywa tej zależności. Wymóg ten nie dotyczy rekordów uwierzytelnianych przez OAuth ani rekordów bez autoryzacji.

Jeżeli zmigrowany rekord otrzyma status CREATE_FAILED, AWS opisuje następującą naprawę: zaktualizuj politykę zaufania, usuń nieudany rekord w nowym Registry i ponownie uruchom jego ładowanie. Sprawdzenie zaufania przed migracją pozwala uniknąć tego dodatkowego cyklu w przypadku rekordów synchronizowanych przez IAM.

Przeprowadź walidację przed przełączeniem

Po załadowaniu porównaj liczbę rejestrów i liczbę rekordów w każdym z nich. AWS zaleca też sprawdzenie próbek przekształconych deskryptorów, aktualizację integracji oraz testy odczytu i zapisu w agent-registry. W trybie active-active wykonaj walidację przed skierowaniem odczytów i zapisów do nowej przestrzeni nazw.

AWS zamknie bedrock-agentcore dla AWS Agent Registry 30 października 2026 r.; wtedy zakończy się dostęp do odczytu i zapisu, a pozostawione tam dane zostaną utracone. AWS wskazuje, że zmiana nie obejmuje usług Identity, Gateway, Runtime ani Policy.