«С 3–4 недель до минут на приложение»: AWS описала паттерн из четырёх агентов для миграции 300+ приложений на Bedrock AgentCore

Когда этот паттерн вообще нужен

AWS сразу отсекает лишнее: миграцию и модернизацию серверных, сетевых, mainframe-,.NET- и прикладных нагрузок закрывает управляемый AWS Transform, базы данных — AWS Database Migration Service (AWS DMS). Собственные агенты нужны там, где требования остаются уникальными для организации.

В описанной программе совпали три условия. Первое: и источники миграционных входных данных, и системы, куда уходят результаты, были доступны только через MCP-инструменты, которые команда построила и поддерживала сама, — это внутренняя вики со стандартами безопасности, система тикетов, платформа совместной работы и внутренний provisioning API. Второе: сгенерированный код инфраструктуры должен был компоновать внутреннюю библиотеку модулей, которую проверяет и утверждает служба безопасности, — вручную это занимало 3–4 недели на приложение, что на портфеле из 300+ приложений превращается в годы инженерной работы. Третье: объём программы включал эксплуатацию после передачи, а это уже вне сервисов миграции.

Четыре агента и два маршрута

Паттерн разделён на маршрут миграции (от обследования до развёртывания) и маршрут эксплуатации (мониторинг после миграции). В маршруте миграции работают три агента: Intake Agent читает через MCP-инструменты архитектурные документы, опросники и записи о зависимостях, после чего определяет архитектуру целевого состояния. IaC Agent генерирует infrastructure as code, компонуя для каждого приложения утверждённые внутренние модули. Migration Intelligence and Governance Agent отвечает за автоматическую отчётность по портфелю, оценки по Well-Architected и управление внутри Jira, Confluence и Webex.

Четвёртый агент — SRE Agent — относится к маршруту эксплуатации: он обеспечивает мониторинг и автоматизированное устранение проблем после cutover.

Отдельно AWS перечисляет, что берут на себя управляемые сервисы: AWS DMS с генеративным ИИ-помощником для конвертации схемы и автоматического переключения при миграции баз данных, а AWS Transform — обследование, планирование волн, создание landing zone, конвертацию сети, выполнение rehost или replatform и модернизацию для mainframe, виртуализованных и.NET-нагрузок.

Как это собрано технически

Каждый агент — это Strands-агент, заданный фундаментальной моделью, системным промптом и набором инструментов; хостит их serverless-рантайм Amazon Bedrock AgentCore с изоляцией сессий и оркестрацией нескольких агентов, а рассуждения обеспечивают фундаментальные модели Amazon Bedrock. Инструменты агент вызывает через AgentCore Gateway — возможность AgentCore, превращающую ваши API, функции AWS Lambda и существующие сервисы в MCP-совместимые инструменты, а AgentCore Identity аутентифицирует каждый вызов через суженные роли AWS IAM и ваш провайдер идентичности.

Состояние сессий и общий контекст хранит AgentCore memory. Именно на этом держится бесшовная передача работы: когда Intake Agent завершает обследование, он записывает целевую архитектуру и карты зависимостей в память, а IaC Agent читает этот общий контекст и начинает генерацию кода без ручной передачи.

Человек и безопасность в контуре

Главный принцип, который AWS формулирует без оговорок: автоматизированные действия всех агентов набора требуют явного одобрения человеком до выполнения, ни один агент не действует на продакшн-системах автономно. Это относится и к обновлению страниц Confluence, и к созданию задач в Jira, и к тикетам ServiceNow для эскалаций. Авторы называют такое одобряемое архитектурное решение основным принципом дизайна всех четырёх агентов: агенты поддерживают решения человека, а не заменяют их.

Безопасность встроена по фазам, а не приделана сверху. IaC Agent вытягивает стандарты службы безопасности прямо из Confluence и применяет их к генерируемому коду через кастомные MCP-инструменты. Сгенерированная инфраструктура проверяется на соответствие требованиям landing zone до развёртывания. AgentCore Gateway координирует контекст и контроль безопасности между агентами, а тесты генерируются вместе с кодом и встраиваются в CI/CD, чтобы ловить несоответствия до продакшна. На уровне инференса Amazon Bedrock Guardrails применяет контент-фильтры, запрещённые темы, фильтры чувствительной информации и проверки контекстной обоснованности к каждому промпту и каждому ответу модели: агент действует только на выводе, прошедшем guardrail, а трассировки guardrail попадают в AgentCore Observability вместе с журналом вызовов инструментов.

Отдельная деталь про политики: у агента IaC работают два слоя, отвечающие на разные вопросы, — AgentCore Policy вычисляет правила Cedar и решает, вызовет ли агент инструмент вообще, а курируемый набор политик определяет, чему удовлетворяет сгенерированная инфраструктура. Ответ несёт версию набора политик, поэтому сгенерированный код фиксирует, какие правила его породили, а отменённые политики уезжают в отдельное поле со сроком действия и перестают применяться сами, без ручной уборки.

Что получилось и сколько это стоит

Заявленные результаты — из одной конкретной программы, и AWS это подчёркивает: разработка IaC сократилась с 3–4 недель на приложение до минут автоматической генерации; согласованность паттернов держится по всем волнам, ни одна волна не может отклониться от утверждённого базового набора IaC; соответствие требованиям безопасности проверяется автоматически при каждом развёртывании с полным журналом аудита и без ручных усилий; точность соответствия «архитектура — развёртывание» выросла, потому что агент интерпретирует диаграмму, а код реализует её как задумано; отчётность по портфелю из 300+ приложений доступна по запросу без ручной агрегации, а команды волн загружают документы и получают код и отчёты.

Стоимость предсказуема и сосредоточена в нескольких местах. Обычно доминируют токены фундаментальных моделей, потому что обследование и генерация IaC прогоняют документы, политики и архитектурный контекст через модель. Amazon Bedrock AgentCore тарифицируется по потреблению: рантайм — по секундам за CPU и память, причём CPU масштабируется до нуля, пока агент ждёт ответ модели или одобрения человека; Gateway, Memory, Policy и Guardrails считаются за единицу использования, а телеметрия Observability — по тарифам Amazon CloudWatch. Для портфеля из 300+ приложений агенты работают всю программу миграции, а не разовой задачей, поэтому это текущие расходы, следующие за активностью волн; объём токенов зависит от размера документов и числа вызовов инструментов сильнее, чем от числа приложений, так что пилотная волна даёт базу на приложение.

На стороне AWS Transform агенты оценки и миграции для виртуализованных, Windows- и mainframe-нагрузок доступны бесплатно, ресурсы, которые создаёт миграция, тарифицируются обычным порядком, а кастомные трансформации оцениваются за агентную минуту.

AWS также приводит список шагов очистки, чтобы после тестирования не остались лишние расходы: удалить агентов из рантайма AgentCore, затем цели и сам Gateway, удалить ресурсы памяти AgentCore с состоянием сессий и общим контекстом, удалить guardrail, определения Policy в AgentCore и IAM-роли агентов, удалить группы логов CloudWatch, куда писала Observability, а также экземпляры репликации и эндпоинты AWS DMS, созданные для тестовых миграций, и убедиться в консоли AgentCore, что активных сессий агентов не осталось.