AWS AgentCore Runtime obsługuje większe sesje i montowanie systemów plików

Amazon Web Services 12 listopada 2026 r. rozszerzyło możliwości nowej generacji Amazon Bedrock AgentCore Runtime o większe sesje agentów, rozliczanie według zakontraktowanego poziomu bazowego oraz dynamiczne montowanie systemów plików. AWS informuje, że aktualizacje zapewniają nawet 15-krotnie szybsze uruchamianie sesji przy zachowaniu izolacji sprzętowej.

Zaktualizowane środowisko wykonawcze jest dostępne w regionach AWS w Ameryce Północnej, Ameryce Południowej, Europie i regionie Azji i Pacyfiku. AgentCore Runtime to zarządzana warstwa obliczeniowa w ramach AgentCore — platformy AWS do tworzenia agentów wykorzystujących różne struktury i modele. Szersza oferta platformy obejmuje również uwierzytelnianie, kontrolę dostępu i obserwowalność.

Wydanie jest następstwem wprowadzenia AgentCore Runtime V2 18 września 2026 r., które przyniosło uruchamianie na podstawie migawek i odzyskiwanie pamięci. AWS zapowiadało wówczas, że wkrótce udostępni większe zasoby obliczeniowe i przestrzeń dyskową oraz ceny zakontraktowanego poziomu bazowego. Te możliwości stanowią teraz znaczną część aktualizacji, obok montowania systemów plików.

Większe sesje bez pul rozgrzanych instancji

Każda sesja może teraz korzystać z maksymalnie 8 vCPU i 32 GB pamięci oraz obsługiwać obrazy kontenerów o wielkości do 10 GB. Według AWS to czterokrotnie większa moc obliczeniowa niż w poprzedniej wersji, a sesje uruchamiają się w czasie krótszym niż dwie sekundy, niezależnie od rozmiaru obrazu i współbieżności. Eliminuje to potrzebę utrzymywania przez klientów własnych pul rozgrzanych instancji lub wstępnie skonfigurowanych klastrów w celu ograniczenia opóźnień przy zimnym starcie.

Mechanizm uruchamiania opiera się na przywracaniu migawek, a nie na ponownej inicjalizacji. AgentCore jednorazowo przygotowuje sprawne środowisko kontenera, zapisuje jego zainicjalizowany stan, a następnie przywraca migawkę dla każdej nowej instancji. Dzięki temu czynności takie jak wczytywanie artefaktów modelu i pobieranie statycznej konfiguracji nie są powtarzane przy każdym zimnym starcie.

Siwei Shen, wiceprezes ds. inżynierii w Coinbase, opisał efekty wdrożenia produkcyjnego: „Migracja do nowej generacji AgentCore Runtime skróciła czas zimnego startu naszych sesji agentów z niemal minuty do mniej niż pięciu sekund, nawet przy szczytowym ruchu. Wyeliminowała również opóźnienia uruchamiania przekraczające 30 sekund, a jednocześnie nasz tygodniowy wolumen agentów wzrósł ponad dwukrotnie”.

Mission Cloud poinformowało, że wstępne porównanie tego samego obciążenia zapytań w języku naturalnym w obu wersjach środowiska wykonawczego wykazało o 35% szybsze zimne starty żądań wnioskowania, o 77% szybsze uruchamianie kontroli stanu oraz o 17% niższy zmierzony koszt środowiska wykonawczego na wywołanie. Agent tej firmy wyszukuje informacje o nieruchomościach i sprzedaży bez konieczności poruszania się przez użytkowników po złożonych systemach danych.

Odzyskiwanie pamięci i rozliczanie według poziomu bazowego

AWS zmienia również sposób rozliczania pamięci w okresach bezczynności. Środowisko wykonawcze odzyskuje pamięć w ciągu kilku minut od jej zwolnienia przez agenta i skaluje bezczynnego agenta do zera. AWS twierdzi, że agenci prowadzący rozmowy wieloetapowe, z naturalnymi przerwami, mogą zużywać do 68% mniej pamięci na sesję. Rozwiązuje to problem wcześniejszego modelu, w którym opłaty naliczano według szczytowej alokacji pamięci dla sesji, nawet gdy pamięć nie była już używana.

W przypadku agentów działających nieprzerwanie ceny zakontraktowanego poziomu bazowego określają minimalną ilość pamięci na sesję, za którą naliczana jest opłata, i umożliwiają zwiększenie jej na żądanie do czterokrotności tego poziomu. AWS opisuje przewidywalną stawkę dla równomiernych obciążeń jako odpowiadającą stawkom AWS Lambda MicroVM. W przypadku nieregularnych obciążeń oraz takich, które mogą być skalowane do zera, nadal obowiązuje rozliczanie według zużycia.

Zuora poinformowało, że w wielu przypadkach nowe środowisko wykonawcze zmniejszyło ilość pamięci na wywołanie o około 60%, a jednocześnie pozwoliło obsługiwać większy ruch przy zachowaniu stałych opóźnień.

Pamięć masowa, izolacja i ograniczenia wdrożeniowe

Każda sesja nadal działa we własnej, izolowanej sprzętowo mikromaszynie wirtualnej Firecracker, z własną tożsamością, zasadami dostępu i ścieżką audytu. Agenci mogą teraz dynamicznie montować system plików i zapisywać w nim swoją pracę, na przykład w zasobniku Amazon S3 z obsługą FUSE. AWS informuje, że dane przez cały czas wykonywania zadania pozostają w granicach zaufania sesji i podlegają jednemu zestawowi zabezpieczeń, co rozszerza izolację poza środowisko obliczeniowe.

Możliwość ograniczania zakresu folderów pamięci masowej do poszczególnych sesji nie jest częścią ogłoszonej wersji. AWS informuje, że przed konferencją re:Invent dane uwierzytelniające oznaczone identyfikatorem sesji będą przypisywać każdą sesję do jej własnego folderu pamięci masowej, zapewniając bardziej szczegółową kontrolę nad funkcją montowania.

W aktualnej dokumentacji V2 opisano również różnice dotyczące wdrażania. V2 nadal wymaga włączenia, ponieważ domyślnie używana jest V1, chyba że platformVersion jest ustawione na V2; utworzenie lub zaktualizowanie środowiska wykonawczego V2 zajmuje kilka minut, podczas których AWS przygotowuje migawkę, a kontener musi zgłosić prawidłowy stan za pośrednictwem swojego /ping punktu końcowego w ciągu 120 sekund. Te czasy konfiguracji są niezależne od opóźnienia zimnego startu sesji.

Sesje mogą działać maksymalnie przez osiem godzin, ale są kończone po 15 minutach bezczynności, po osiągnięciu limitu czasu działania lub w przypadku nieprawidłowego stanu. Stan sesji jest nietrwały, a jej zakończenie powoduje zniszczenie mikromaszyny wirtualnej i wyczyszczenie pamięci.

W ramach tego wydania moc obliczeniowa sesji, rozliczanie pamięci i dane zadań zostają połączone w jednym zarządzanym modelu środowiska wykonawczego. Nadal brakuje w nim szczegółowej izolacji pamięci masowej: ograniczanie zakresu pamięci masowej do poszczególnych sesji to ostatni krok w rozszerzaniu gwarancji izolacji środowiska wykonawczego — od wykonywania zadań po zapisywanie pracy agentów.