AgentCore Runtime V2 AWS: szybszy start i elastyczna pamięć

W skrócie

Stan na 23.09.2026.

AWS oficjalnie udostępnił nową generację Amazon Bedrock AgentCore Runtime, określaną w dokumentacji jako platform version V2.
V2 uruchamia środowisko agenta ze snapshotu, odzyskuje nieużywaną pamięć w trakcie sesji i ma zapewniać bardziej przewidywalne zimne starty.
Migracja wymaga testów aplikacji: snapshot zmienia zasady inicjalizacji, obsługi sekretów, losowości i połączeń sieciowych.

Co się wydarzyło

18 września 2026 roku AWS ogłosił dostępność nowej generacji AgentCore Runtime — zarządzanej warstwy wykonawczej dla agentów i narzędzi AI w Amazon Bedrock AgentCore. Producent opisuje ją jako serverlessowe środowisko oparte na microVM, bez wcześniejszego rezerwowania infrastruktury i ze skalowaniem do zera (oficjalny komunikat AWS).

Najważniejsza zmiana dotyczy sposobu przygotowania instancji. W V2 AgentCore inicjalizuje środowisko raz, tworzy jego snapshot, a kolejne instancje odtwarza z tego obrazu zamiast wykonywać pełny start od początku. AWS podaje, że w swoich testach osiągnął zimny start P75 na poziomie 1,9–2,0 sekundy dla obrazów kontenerowych od 200 MB do 2 GB. Dla V1 wskazany zakres wynosił 5,4–30 sekund (oficjalny komunikat AWS).

Druga zmiana to elastyczne zarządzanie pamięcią. Sesja zaczyna z niewielkim profilem, dostaje dodatkową pamięć wtedy, gdy jej potrzebuje, a nieużywane zasoby są odzyskiwane w trakcie działania. Według AWS rozliczenie ma dzięki temu lepiej odpowiadać rzeczywistemu zużyciu zamiast wartości szczytowej utrzymywanej do końca sesji (oficjalny komunikat AWS).

V2 jest dostępne w regionach us-east-1, us-east-2, us-west-2, eu-west-1 oraz ap-northeast-1. Przy tworzeniu lub aktualizacji runtime'u trzeba ustawić platformVersion na V2; bez wskazania wersji nowe środowisko nadal domyślnie korzysta z V1 (dokumentacja platform versions).

Jak działa V2 i gdzie są pułapki

Snapshot obejmuje stan procesu przygotowany przed rozpoczęciem obsługi żądań. To dobra wiadomość dla ciężkich importów, ładowania statycznej konfiguracji czy przygotowania klientów SDK: taką pracę można wykonać raz podczas startu i odziedziczyć w odtwarzanych instancjach. Dokumentacja AWS wymaga, aby inicjalizacja zakończyła się w ciągu 120 sekund; dopiero potem środowisko powinno zgłosić gotowość (przewodnik optymalizacji V2).

Ta sama właściwość tworzy jednak ryzyko. Wszystko, co musi być świeże lub unikalne dla żądania, powinno powstawać w handlerze, nie podczas startu. AWS wymienia między innymi krótkotrwałe dane uwierzytelniające, identyfikatory, znaczniki czasu i losowe wartości. Jeżeli zostaną utworzone przed snapshotem, wiele odtworzonych instancji może odziedziczyć ten sam stan (przewodnik optymalizacji V2).

Szczególnej uwagi wymagają biblioteki kryptograficzne. Dla własnych kontenerów AWS zaleca wersje bezpieczne dla snapshotów, które ponownie inicjalizują źródło losowości po odtworzeniu; w Amazon Linux 2023 wskazany jest pakiet openssl-snapsafe-libs. W bezpośrednich wdrożeniach kodu obrazy zarządzane przez usługę mają już odpowiednio przygotowane biblioteki (przewodnik optymalizacji V2).

Podobna zasada dotyczy sieci. Klienta API można przygotować podczas startu, ale otwarte połączenie nie przetrwa odtworzenia snapshotu. Pierwsze wywołanie musi umieć zestawić je ponownie. Nie należy też traktować nazwy hosta ani PID jako unikalnego identyfikatora instancji, ponieważ wartości zapisane w snapshocie mogą być wspólne dla wielu odtworzeń (przewodnik optymalizacji V2).

Dokumentacja wskazuje jeszcze dwa ograniczenia wdrożeniowe. Łączny rozmiar zmiennych środowiskowych w V2 jest obecnie mniejszy niż w V1: 1,5 KB dla bezpośredniego wdrożenia kodu i 2,5 KB dla kontenera, wobec 4 KB w V1. Ponadto CloudFormation i AWS CDK nie obsługują jeszcze ustawiania platformVersion, więc w części zespołów migracja będzie wymagała dodatkowego kroku poza istniejącym IaC (dokumentacja platform versions).

Dlaczego to ważne dla firmy

W zastosowaniach interaktywnych opóźnienie pierwszej odpowiedzi wpływa na to, czy użytkownik postrzega agenta jako narzędzie dostępne od ręki, czy jako proces oczekujący w kolejce. Wynik P75 podany przez AWS nie jest gwarancją dla każdej aplikacji, ale pokazuje kierunek: cięższy obraz kontenera nie musi automatycznie oznaczać wielokrotnie dłuższego zimnego startu. Rzeczywisty rezultat trzeba potwierdzić na własnym kodzie i ruchu.

Elastyczna pamięć może być istotna dla agentów o nierównym profilu pracy. Agent może przez większość sesji zużywać niewiele zasobów, a większej ilości potrzebować tylko podczas przetwarzania dokumentu albo uruchomienia narzędzia. Odzyskiwanie pamięci w trakcie sesji daje szansę na lepsze powiązanie kosztu z faktyczną pracą, ale AWS nie publikuje w komunikacie uniwersalnej oszczędności procentowej. Dlatego decyzja wymaga pomiaru całego scenariusza, a nie przeniesienia wyniku z materiału producenta.

Z perspektywy ryzyka największą zmianą nie jest sam czas startu, lecz nowy model cyklu życia procesu. Kod poprawny w V1 może po snapshotowaniu przechowywać przeterminowany token, powielać identyfikator albo zakładać istnienie połączenia, którego już nie ma. To problemy możliwe do wykrycia przed produkcją, jeżeli migracja obejmuje testy odtworzenia, uwierzytelniania i równoległych sesji.

Co zrobić w tym tygodniu

Sprawdź region i wersję. Potwierdź, czy używany region obsługuje V2 i czy runtime ma jawnie ustawione platformVersion: V2. Nie zakładaj, że aktualizacja nastąpi automatycznie.
Zapisz punkt odniesienia. Zmierz czas pierwszej odpowiedzi, czas kolejnych wywołań, pamięć oraz koszt na reprezentatywnym zestawie zadań w V1.
Przejrzyj inicjalizację. Oddziel dane stałe od wartości zależnych od żądania. Sekrety krótkotrwałe, czas, identyfikatory i losowość przenieś do handlera.
Sprawdź biblioteki kryptograficzne. Jeżeli używasz własnego kontenera, zweryfikuj, czy stos kryptograficzny jest bezpieczny po odtworzeniu snapshotu.
Przetestuj połączenia. Uruchom scenariusze obejmujące bazy danych, kolejki i zewnętrzne API. Klienci powinni umieć ponownie zestawić połączenie po restore.
Zaplanuj rollback. Wdrażaj V2 na osobnym runtime lub endpointcie, zachowując możliwość powrotu do V1 do czasu zakończenia porównania.

W praktyce warto zacząć od jednego procesu, dla którego sukces da się zmierzyć w czasie, jakości wykonania i koszcie. Dopiero po takim pilotażu można ocenić, czy krótszy start i elastyczna pamięć przynoszą wartość większą niż koszt migracji. Jeśli potrzebujesz pomocy w zaplanowaniu pomiarów i bezpiecznego wdrożenia, zobacz konsultacje Tensor Deep.

Podsumowanie

AgentCore Runtime V2 jest oficjalnie dostępny od 18 września 2026 roku. AWS zmienił sposób uruchamiania środowiska na odtwarzanie ze snapshotu i wprowadził elastyczne zarządzanie pamięcią. Producent raportuje zimny start P75 1,9–2,0 sekundy dla obrazów 200 MB–2 GB, ale wynik konkretnego agenta zależy od jego kodu, zależności i integracji (oficjalny komunikat AWS).

Najrozsądniejsza ścieżka to kontrolowany pilotaż: pomiar V1, przegląd inicjalizacji pod kątem snapshotu, testy bezpieczeństwa i połączeń, a następnie porównanie kosztu całego zadania. V2 może usunąć ważną barierę wydajnościową, ale wymaga świadomego przygotowania aplikacji.

FAQ

Czy AgentCore Runtime V2 jest oficjalnie dostępny?

Tak. AWS ogłosił dostępność nowej generacji 18 września 2026 roku. Włącza się ją przez ustawienie platformVersion na V2, a lista obsługiwanych regionów znajduje się w komunikacie i dokumentacji AWS (oficjalny komunikat AWS).

Czy każda aplikacja osiągnie zimny start poniżej dwóch sekund?

Nie ma takiej gwarancji. AWS podaje wynik P75 1,9–2,0 sekundy z własnych testów dla obrazów 200 MB–2 GB. Zespół powinien powtórzyć pomiar na własnym obrazie, konfiguracji i obciążeniu.

Czy migracja wymaga zmian w kodzie?

Może ich wymagać. Najważniejsze obszary to inicjalizacja danych zależnych od żądania, odświeżanie poświadczeń, generowanie losowości, obsługa połączeń po odtworzeniu oraz biblioteki kryptograficzne w prywatnych kontenerach (przewodnik optymalizacji V2).

Źródła

Ten artykuł został przygotowany z użyciem narzędzi AI i zweryfikowany na podstawie oficjalnych źródeł AWS wymienionych powyżej.