AWS AgentCore Runtime Instances: AI-агенты до 14 дней

6 августа 2026 года AWS объявила общую доступность Runtime Instances для Amazon Bedrock AgentCore. Компании получили управляемые EC2-инстансы для AI-агентов, которым нужны длительные сессии, GPU, доступ к операционной системе или совместная работа нескольких исполнителей.

Для бизнеса это важный этап развития технологии. Инфраструктура для AI-агентов превращается в самостоятельный контур со своими расходами, правами доступа, журналами действий и правилами эксплуатации.

Runtime Instances поддерживают сессии продолжительностью до 14 дней. Для сравнения, стандартный microVM-runtime рассчитан на сессии до восьми часов и быстрое масштабирование. Новый режим позволяет выбирать GPU-, memory- и compute-optimized конфигурации, размещать нескольких агентов на одном хосте и сохранять рабочую среду между этапами процесса.

AWS отвечает за подготовку инстансов, обновления, масштабирование и управление жизненным циклом среды. Команда может сосредоточиться на логике агентов, безопасности и экономике сценария.

Что AWS добавила в Bedrock AgentCore

Runtime Instances работают как capacity provider. Команда выбирает подходящие типы EC2 и подключает к ним агентов через общие AgentCore API.

Платформа поддерживает:

• Linux на ARM64 и x86_64;
• Python версий 3.11-3.14;
• нативный код;
• контейнерные образы;
• GPU-, memory- и compute-optimized инстансы;
• приостановку сессии во время простоя;
• повторный запуск сохранённой сессии.

Приостановка помогает сократить расходы, когда агент ожидает данные или согласование. После возобновления он продолжает работу в сохранённом окружении.

Один runtime может обслуживать нескольких агентов с разными зависимостями и артефактами. Общая сессия позволяет исполнителям обмениваться рабочим контекстом на одном хосте. Долговременную память можно хранить в AgentCore Memory, устойчивые данные - в Amazon EBS.

AWS также предлагает комбинированную архитектуру. Лёгкий агент-оркестратор работает в microVM, принимает задания и распределяет их между специализированными исполнителями на Runtime Instances. Такая схема подходит для компиляции кода, проверки безопасности, GUI-автоматизации и процессов, которым требуется сохранение состояния.

Какие бизнес-задачи выигрывают от постоянного runtime

Первый сценарий - процессы продолжительностью больше рабочего дня. Агент может собирать показатели из нескольких систем, проверять отклонения, ожидать согласование и готовить итоговый отчёт. Сессия до 14 дней сохраняет рабочее состояние между этапами и упрощает восстановление процесса после пауз.

Второй сценарий - ресурсоёмкие операции. GPU может потребоваться для запуска локальных моделей, обработки больших массивов документов, изображений или видео. Выбор конкретного семейства EC2 позволяет подобрать вычислительную мощность под нагрузку и рассчитать стоимость каждой операции.

Третий сценарий - работа группы агентов. Один исполнитель принимает запрос, второй обращается к корпоративным данным, третий проверяет результат, четвёртый готовит действие для сотрудника. Размещение на общем хосте сокращает задержки и упрощает передачу рабочего контекста.

Постоянный runtime также подходит для задач, где агенту нужны системные библиотеки, собственные контейнеры, браузерная автоматизация или доступ к операционной системе. Стандартного окружения для таких процессов бывает недостаточно.

Как руководителю выбрать режим развёртывания AI-агентов

Сначала оцените длительность операции. Serverless microVM подходит для коротких запросов и нерегулярной нагрузки. Runtime Instances стоит рассматривать для непрерывных задач, длительных согласований и тяжёлых вычислений.

Затем проверьте требования к среде. Выделенный runtime оправдан, если агенту нужны:

• доступ к операционной системе;
• специальные системные библиотеки;
• контейнеры;
• GPU;
• сохранение состояния между этапами;
• совместная работа нескольких исполнителей.

Агентам, которые обращаются к API и работают в стандартном Python-окружении, часто хватает более лёгкого режима.

Следующий критерий - профиль загрузки. Постоянная высокая утилизация позволяет прогнозировать расходы на инстанс. При редких коротких вызовах выделенная мощность может простаивать.

AWS взимает плату за EC2 и управление через AgentCore. Финансовая модель должна учитывать обе статьи. Для расчёта следует сопоставить стоимость инфраструктуры с числом завершённых операций и ценностью результата для бизнеса.

Отдельно проверьте географию размещения. На момент анонса Runtime Instances доступны в регионах США, Европы и Азиатско-Тихоокеанского региона, включая Франкфурт и Ирландию. Российским компаниям нужно заранее оценить требования к размещению данных, сетевой маршрут и задержку.

Какие метрики включить до запуска

Для пилота достаточно пяти показателей:

1. Стоимость одной завершённой операции. 2. Средняя длительность сессии и доля успешных восстановлений. 3. Загрузка CPU, оперативной памяти и GPU. 4. Количество ручных вмешательств. 5. Время от постановки задания до принятого результата.

Дополнительно фиксируйте расходы по каждому агенту и процессу. Общая сумма в облачном счёте слабо помогает управлять системой. Руководителю нужна связь между затратами и результатом: подготовленным отчётом, обработанным лидом, закрытым обращением или выпущенной единицей контента.

Метрики стоит собирать до автоматизации и после запуска пилота. Такой подход позволяет сравнить агентный процесс с текущей ручной схемой по стоимости, скорости и числу ошибок.

Риски постоянной агентной инфраструктуры

Длинная сессия повышает возможные расходы при ошибке. Зациклившийся агент способен тратить токены и вычислительные ресурсы несколько часов. Для каждого процесса нужны ограничения по времени, бюджету и количеству обращений к инструментам.

Система должна останавливать выполнение при повторяющихся действиях, превышении лимита или потере ожидаемого прогресса. Для критичных операций стоит предусмотреть ручное подтверждение.

Совместный runtime требует строгого разделения прав. Каждый агент получает доступ только к тем API, данным и командам, которые нужны для его роли.

Журналы должны сохранять:

• автора действия;
• использованный инструмент;
• входные параметры;
• полученный результат;
• время выполнения;
• решение сотрудника при ручном согласовании.

Подтверждение человека требуется для операций с деньгами, публикациями, персональными данными и настройками инфраструктуры.

Команде также нужно фиксировать версии промптов, инструментов, моделей и контейнеров. Обновление зависимости способно изменить поведение процесса. Перед релизом прогоняйте контрольный набор сценариев и сравнивайте результаты с предыдущей версией.

Облако или сервер в контуре компании

AWS берёт на себя значительную часть инфраструктурных задач и ускоряет запуск. Собственный сервер даёт компании больше контроля над размещением данных, сетевыми правилами и стоимостью постоянной нагрузки.

Выбор зависит от требований безопасности, компетенций команды и характера использования. Облачный runtime удобен для быстрого пилота и переменной нагрузки. Сервер в контуре компании подходит для процессов с чувствительными данными, внутренними системами и постоянным объёмом вычислений.

Для пилотного размещения AI-агентов на сервере клиента рекомендуем выделенный сервер Beget. Перед переносом рабочих процессов настройте резервное копирование, мониторинг, права доступа и порядок восстановления после сбоя.

Гибридная архитектура позволяет оставить оркестратор и чувствительные данные в контуре компании, а тяжёлым исполнителям выдавать облачные мощности под конкретные задания. Права доступа и измеримые операции должны определять устройство такой системы.

План пилота Runtime Instances

Выберите один процесс продолжительностью от нескольких часов до нескольких дней. Зафиксируйте входные данные, ожидаемый результат, точки согласования и условия остановки.

Затем разделите роли:

1. Оркестратор принимает задачу и управляет последовательностью. 2. Исполнители выполняют отдельные операции. 3. Проверяющий агент контролирует результат. 4. Сотрудник подтверждает спорные или критичные действия.

Каждому участнику назначьте минимальные права и отдельный бюджет. Настройте журналы, лимиты времени и автоматическую остановку при повторяющихся действиях.

На первой неделе запускайте агентный процесс параллельно с текущей ручной схемой. Сравнивайте скорость, стоимость, качество результата и количество вмешательств.

На второй неделе передайте агентам больше рутинных операций, сохранив ручной контроль для действий с высоким риском. Расширяйте охват после серии стабильных запусков и понятного расчёта экономического эффекта.

Что означает анонс AWS для рынка AI-агентов

Runtime Instances подтверждают переход рынка к производственной эксплуатации AI-агентов. Платформы получают длительные сессии, управляемый жизненный цикл, специализированное оборудование и поддержку многоагентных процессов.

Теперь компаниям предстоит сравнивать решения по качеству процессов, ограничениям, безопасности и прозрачности расходов. Возможности модели сами по себе мало говорят о готовности системы к работе с реальными бизнес-задачами.

Рабочая инфраструктура для AI-агентов включает роли, права доступа, журналы, регламенты, метрики и ответственных сотрудников. Начинать лучше с процесса, результат которого можно оценить за две недели.

AI SMM Office запускается примерно за 10 минут. После запуска компания получает отдел из четырёх AI-агентов в Telegram. Они готовят контент и выполняют маркетинговые задачи по заданным правилам. Такой пилот помогает проверить агентную модель на живом процессе и увидеть результат в ежедневной работе.

Источники: AWS: Runtime Instances GA, AWS News Blog: persistent compute for production AI agents. [agents/agent-command] [agent] run 2e860320-0db4-4a35-a2c2-8ade45480525 ended with stopReason=stop