AWS AgentCore Runtime додає більші сеанси та монтування файлових систем

Amazon Web Services 12 листопада 2026 року розширила можливості нового покоління Amazon Bedrock AgentCore Runtime: збільшила сеанси агентів, запровадила тарифікацію за гарантованим базовим обсягом і додала динамічне монтування файлових систем. За даними AWS, оновлення дають змогу запускати сеанси до 15 разів швидше, зберігаючи апаратну ізоляцію.

Оновлена версія середовища виконання доступна в регіонах AWS у Північній і Південній Америці, Європі та Азійсько-Тихоокеанському регіоні. AgentCore Runtime — це керований обчислювальний рівень платформи AgentCore від AWS, призначеної для створення агентів на основі різних фреймворків і моделей; ширша платформа також охоплює автентифікацію, контроль доступу та спостережуваність.

Цей випуск з’явився після представлення AgentCore Runtime V2 18 вересня 2026 року, у якому було реалізовано запуск на основі знімків стану та вивільнення пам’яті. Тоді AWS повідомила, що збільшені обчислювальні ресурси й обсяг сховища, а також ціноутворення з гарантованим базовим рівнем з’являться незабаром. Тепер ці можливості становлять значну частину оновлення, до якого також додали монтування файлових систем.

Більші сеанси без пулів попередньо запущених середовищ

Тепер для кожного сеансу можна використовувати до 8 vCPU та 32 ГБ пам’яті, а також образи контейнерів розміром до 10 ГБ. За даними AWS, обчислювальна потужність у чотири рази перевищує показник попередньої версії, а сеанси запускаються менш ніж за дві секунди незалежно від розміру образу чи кількості одночасних запусків. Це усуває потребу в керованих клієнтами пулах попередньо запущених середовищ або заздалегідь підготовлених кластерах для подолання затримок холодного запуску.

Для запуску відновлюють знімок стану, а не повторюють ініціалізацію. AgentCore один раз готує працездатне середовище контейнера, фіксує його ініціалізований стан, а потім відновлює цей знімок для кожного нового екземпляра. Завдяки цьому такі завдання, як завантаження артефактів моделі й отримання статичної конфігурації, не доводиться повторювати під час кожного холодного запуску.

Віцепрезидент із розробки в Coinbase Сівей Шень описав результат у промисловому середовищі: «Перехід на нове покоління AgentCore Runtime скоротив холодний запуск сеансів наших агентів із майже хвилини до менш ніж п’яти секунд, навіть у періоди пікового навантаження. Також зникли затримки запуску тривалістю понад 30 секунд, а тижневий обсяг роботи агентів більш ніж подвоївся».

Mission Cloud повідомила, що початкове порівняння однакового навантаження запитами природною мовою на обох версіях середовища виконання показало: холодний запуск для запитів на виведення результатів став на 35% швидшим, запуск перевірки працездатності — на 77% швидшим, а виміряна вартість виконання на один виклик знизилася на 17%. Агент отримує дані про нерухомість і продажі, не змушуючи користувачів працювати зі складними системами даних.

Вивільнення пам’яті та тарифікація за базовим рівнем

AWS також змінює принцип тарифікації за пам’ять у періоди простою. Коли агент вивільняє пам’ять, середовище виконання звільняє її протягом кількох хвилин і зменшує ресурси неактивного агента до нуля. За даними AWS, агенти з кількома послідовними зверненнями та природними паузами можуть споживати до 68% менше пам’яті на сеанс. Це розв’язує проблему попередньої моделі, у якій оплату нараховували за піковий обсяг пам’яті, виділений для сеансу, навіть після того, як пам’ять більше не використовувалася.

Для агентів, що працюють постійно, тарифікація з гарантованим базовим рівнем встановлює мінімальний обсяг пам’яті на сеанс, за який стягується плата, і дає змогу за потреби збільшувати його до чотирикратного значення. За описом AWS, передбачувана ставка для стабільних робочих навантажень відповідає тарифам AWS Lambda MicroVM; для навантажень із різкими стрибками та масштабуванням до нуля зберігається оплата за фактичне споживання.

Zuora повідомила, що в багатьох випадках нова версія середовища виконання скоротила обсяг пам’яті на один виклик приблизно на 60%, даючи змогу обробляти більше трафіку зі стабільною затримкою.

Сховище, ізоляція та обмеження розгортання

Кожен сеанс і надалі працює у власній апаратно ізольованій мікровіртуальній машині Firecracker, маючи окремі ідентифікатор, політику доступу та журнал аудиту. Тепер агенти можуть динамічно монтувати файлову систему й зберігати в ній результати роботи, наприклад у сегменті Amazon S3 із підтримкою FUSE. За даними AWS, протягом усього завдання дані залишаються в межах довіри сеансу й підпорядковуються єдиному набору засобів контролю, тож ізоляція охоплює не лише обчислювальне середовище.

Оголошена доступність поки не передбачає обмеження доступу до папки сховища окремо для кожного сеансу. AWS повідомляє, що до re:Invent облікові дані з позначкою сеансу прив’язуватимуть кожен сеанс до власної папки сховища, додаючи детальніший контроль до можливості монтування.

У поточній документації V2 також описано відмінності в розгортанні. V2 потрібно вмикати окремо, оскільки за замовчуванням використовується V1, якщо не platformVersion встановлено значення V2; створення середовища виконання V2 або його оновлення триває кілька хвилин, поки AWS готує знімок стану, а контейнер має повідомити про справний стан через свій /ping кінцевий вузол протягом 120 секунд. Цей час налаштування не пов’язаний із затримкою холодного запуску сеансу.

Сеанси можуть тривати до восьми годин, але завершуються після 15 хвилин бездіяльності, після досягнення граничної тривалості або в разі несправності. Стан сеансу є тимчасовим: після його завершення мікровіртуальна машина знищується, а пам’ять очищується.

У цьому випуску обчислювальні ресурси сеансу, тарифікація за пам’ять і дані завдань об’єднано в одну модель керованого середовища виконання. Поки що бракує лише детальної ізоляції сховища: обмеження доступу до сховища для кожного сеансу — це останній крок до поширення гарантій ізоляції середовища виконання з процесу виконання на збережені результати роботи агентів.