AgentCore runtime — управляемый вычислительный слой Amazon Bedrock AgentCore, то есть полностью управляемая среда для развёртывания и запуска агентов без создания и поддержки инфраструктуры. В анонсе Amazon новая версия меняет три вещи: как runtime обращается с памятью, насколько предсказуемо стартует и по какому принципу считается счёт.
Коротко: память возвращается сразу после завершения сессии, а не удерживается на пиковом уровне. Время холодного старта не зависит от размера контейнера и уровня параллелизма агентов. Тарифицируется фактическое потребление ресурсов, а не простой CPU в ожидании ввода-вывода, и модель оплаты остаётся consumption-based.
Практический вывод для тех, кто держит в облаке десятки агентов: если агент простаивает большую часть времени, стартует с тяжёлым образом или работает при переменном параллелизме, обновление бьёт ровно по двум болям — нестабильной latency при масштабировании и оплате ресурсов, которые агент не использует.
Что такое AgentCore runtime и зачем Amazon его обновила
AgentCore runtime — одна из возможностей Amazon Bedrock AgentCore. Разработчик отдаёт код агента, а рантайм берёт на себя жизненный цикл: изоляцию сессий, масштабирование, идентификацию и наблюдаемость. Первая версия заложила serverless-основу с изоляцией сессий, масштабированием до нуля и оплатой только за фактическое использование. Контекст предыдущих релизов платформы разобран в материале об обновлениях Amazon Bedrock и AgentCore.
Причина обновления — накопленная практика. С момента запуска тысячи команд использовали runtime для production-агентов, и их запросы Amazon формулирует так: быстрее реагировать при росте нагрузки, точнее управлять распределением ресурсов и получить экономику, которая точно следует за фактическим использованием.
Второй фактор — смена профиля агентов. Чат-боты уступили место кодинг-агентам, которые работают минуты и часы и удерживают контекст на протяжении многих шагов. Следом появились ambient-агенты: они запускаются событиями, работают без присмотра, всё чаще запускаются другими агентами и «проявляются» только по завершении задачи или когда нужно решение человека. Для такого спектра нужен рантайм, который одновременно быстрый и не разорительный на длинных сессиях.
Ключевые изменения в двух словах
- Эластичное управление памятью. Память освобождается, как только сессия её отпускает, вместо удержания на пиковом уровне.
- Снапшоты среды. Среда готовится один раз, снимается снапшот, новые инстансы восстанавливаются из него.
- Стабильный холодный старт. Время запуска не зависит от размера контейнера и уровня параллелизма агентов.
- Тарификация фактической памяти. Счёт считается по реально используемым ресурсам, а не по всему образу контейнера.
- Масштабирование до нуля. Пока работы нет, ничего не запущено и тарифицировать нечего.
Модель оплаты остаётся consumption-based: постоянной платы за ёмкость, зарезервированную «на всякий случай», нет.
Эластичное управление памятью: как runtime перестал держать пик
Идея простая, эффект заметный. Прежняя схема удерживала память на пиковом уровне всю сессию. Новый рантайм стартует с компактного профиля, подгружает память по требованию и освобождает её, когда она остывает. Формулировка Amazon звучит так: память возвращается в тот момент, когда сессия её отпускает, а не держится на пике. Тот же тезис повторяется в разделе про экономику: память освобождается мгновенно после окончания сессии.
Почему удержание пиковой памяти было проблемой
Агенты редко потребляют память равномерно. Иллюстрация: на пике обработки большого документа агенту нужно 2 ГБ, но 80% времени ему хватает 200 МБ. Схема с удержанием пика означала, что вы платите за 2 ГБ весь сеанс, включая минуты, когда реально занято 200 МБ. Разрыв между пиком и средним уровнем особенно велик там, где память уходит на поиск по большой базе знаний, разбор вложений и работу code interpreter в песочнице.
Отдельный вопрос — что происходит между сессиями. Если контейнер продолжает держать память в ожидании следующего запроса, вы платите за тепло, а не за работу. Возврат памяти сразу после сессии сокращает именно этот участок.
Анонс описывает механику, но независимых замеров потребления памяти не публикует. Проверить выигрыш можно только замером на своей нагрузке: снимите профиль памяти агента и посмотрите, какую долю времени занято меньше половины пикового объёма.
Снапшоты и предсказуемый холодный старт: цифры и механика
Вместо повторной инициализации окружения при каждом холодном старте платформа один раз готовит среду, снимает снапшот и восстанавливает его для новых инстансов. Новая копия агента не проходит заново установку зависимостей, загрузку библиотек и настройку окружения: она поднимается из уже готового состояния.
Как снапшот ускоряет запуск
Классический холодный старт контейнера складывается из скачивания образа, распаковки слоёв, запуска процесса и прогрева приложения. Чем крупнее образ, тем дольше каждый шаг, и тем сильнее разброс по времени. Снапшот убирает повторную подготовку: среда инициализируется однократно, а дальше новые инстансы восстанавливаются из зафиксированного состояния. Для образов в проверенном диапазоне размеров это даёт ровное время запуска, а не растущее вместе с числом слоёв и зависимостей.
Amazon приводит замеры на пустом echo-агенте: P75 холодного старта около 2 секунд для образов от 200 МБ до 2 ГБ. У прежней версии latency росла вместе с размером образа, примерно с 5,4 до 30 секунд. Те же замеры показывают, что стабильность сохраняется при разном уровне параллелизма агентов.
Оговорки существенные. Во-первых, это цифры вендора, независимых проверок нет. Во-вторых, echo-агент ничего не делает: он возвращает ответ без вызовов моделей, инструментов и внешних API, поэтому 2 секунды описывают накладные расходы самого рантайма, а не полное время отклика вашего агента. Реальный сценарий добавит инициализацию инструментов, установку соединений и вызовы моделей — эти шаги в замер не входят. В-третьих, диапазон 200 МБ — 2 ГБ не покрывает тяжеловесные образы с локальными моделями.
Что означают P75 и почему это важно
P75 — 75-й процентиль времени холодного старта: 75% запусков укладываются в это значение, оставшиеся 25% оказываются медленнее. Для пользовательского опыта важнее хвост распределения, чем среднее: редкие медленные старты запоминаются сильнее, чем стабильно средние. Именно по этой причине метрика P75 честнее описывает предсказуемость, чем среднее по всем запускам.
Новая модель оплаты: за что именно платит пользователь
Оплата остаётся consumption-based, но тарифицируется фактически используемая память, а не весь образ контейнера. Два следствия Amazon формулирует прямо: нет постоянной платы за ёмкость, зарезервированную «на всякий случай», и нет оплаты простаивающего CPU, который ждёт ввода-вывода. Биллинг следует за потреблением ресурсов, а не за выделенным максимумом.
Дальше включается масштабирование до нуля. Пока агенту нечего делать, не запущено ничего и начислять нечего; когда приходит работа, платформа выделяет нужную ёмкость. Для парка из десятков агентов, которые простаивают большую часть суток, это меняет структуру расходов сильнее, чем любая скидка за объём.
В будущем Amazon обещает baseline-тарифы. Публичных ставок пока нет, поэтому пересчитать экономику в деньгах до их появления не получится: сравнивать можно только логику начислений, но не суммы.
Сравнение с традиционными serverless-решениями
Большинство serverless-платформ биллят память, выделенную под инстанс, на всё время его жизни, а не фактическое потребление, и не освобождают её так же агрессивно. AgentCore runtime опирается на два принципа: возврат памяти сразу по завершении сессии и полное масштабирование до нуля. Если ваш агент работает короткими всплесками, структура начислений окажется выгоднее; если агент загружен постоянно и равномерно, разница с классическим serverless-биллингом сгладится.
Кому и когда стоит использовать новый AgentCore runtime
Рантайм расширяет serverless-основу на весь спектр агентов: для интерактивных он остаётся быстрым и стабильным, для долго работающих и более автономных — durable и доступным по цене.
Интерактивные агенты. Там, где пользователь ждёт ответ в диалоге, стабильный холодный старт важнее пиковой производительности. Плавающие 15–30 секунд на старте ломают сценарий, 2 секунды — почти незаметны.
Долго работающие автономные агенты. Кодинг-агенты, которые держат контекст часами, и агенты, запускаемые событиями, выигрывают от того, что память не удерживается на пике между фазами работы.
Парк простаивающих агентов. Если у вас много агентов, которые активно работают пару часов в сутки, масштабирование до нуля превращает их содержание из постоянной статьи расходов в переменную.
Production при переменном параллелизме. Когда нагрузка растёт скачками, предсказуемый запуск снимает часть рисков по SLA. Как это выглядит в реальной архитектуре с наследованным кодом, памятью и Guardrails, видно на примере архитектуры AI-агентов monday.com на Amazon Bedrock.
Если вы сравниваете платформы, полезно посмотреть и на конкурентные managed-подходы: например, Managed Agents в Gemini API решают похожую задачу изоляции и контроля бюджета, но другими средствами.
Когда миграция не срочна
Если агентов немного, образы компактные, нагрузка предсказуема, а текущий P75 холодного старта вас устраивает, спешить не обязательно. У первой версии уже есть изоляция сессий и масштабирование до нуля, а новая тарификация станет по-настоящему интересной после публикации baseline-тарифов. Разумный план в этом случае — остаться на текущей версии, но снять метрики: P75 холодного старта, распределение потребления памяти, долю времени простоя. Эти цифры пригодятся, когда вы решите считать выгоду перехода.
Ограничения и что обещают в будущем
Ограничения на момент анонса выглядят так:
- нет поддержки x86;
- ограничен объём RAM, vCPU и хранилища на инстанс;
- нет suspend/resume сессий;
- нет scoped identity для автономных агентов.
Amazon обещает закрыть эти пункты в будущих релизах, туда же входят baseline-тарифы. Сроков вендор не называет, поэтому планировать переход можно только по факту доступности функций.
Для части сценариев ограничения окажутся блокирующими. Если агенту нужно переживать паузы между шагами с сохранением состояния, suspend/resume — не удобство, а требование. Если автономный агент запускается другими агентами, узкая идентичность нужна для разграничения прав. В таких случаях вариант один: строить логику поверх своей инфраструктуры и ждать обновлений, а не подгонять архитектуру под текущие лимиты.
Практические шаги для старта и миграции
- Снять baseline на текущей версии: P75 холодного старта, распределение потребления памяти, стоимость за неделю при вашем профиле нагрузки.
- Прочитать полный текст анонса и документацию Amazon Bedrock AgentCore по рантайму, сверив список доступных функций со своим сценарием.
- Собрать тестовый стенд из двух агентов: пустого echo-агента для замера накладных расходов рантайма и реального агента с инструментами и вызовами моделей.
- Сравнить P75 и хвост распределения холодного старта на обоих стендах, а не только среднее время.
- Проверить конфигурацию памяти и образа: переход может потребовать пересмотра профиля памяти и пересборки контейнера, если вы закладывали запас «на всякий случай».
- Сверить лимиты платформы со своими требованиями: архитектура, объём RAM, vCPU, хранилище, работа с идентичностью. Региональные и IAM-ограничения удобно проверять по чек-листу из разбора Claude Fable 5.1 в AWS для enterprise-сценариев.
- Переносить на новую версию один сервис, а не весь парк агентов, и сверять фактические затраты с прогнозом.
Главное, что стоит вынести из анонса: рантайм перестал быть заложником пикового профиля агента. Стабильный запуск и оплата по факту использования снимают две статьи расходов, которые обычно прячутся в облачном счёте. Начните с замера P75 холодного старта и профиля памяти на своём агенте: этих двух цифр достаточно, чтобы понять, принесёт обновление выигрыш именно вам или можно спокойно подождать следующего релиза.