AWS Professional Services подробно рассказала о многоагентной системе, предназначенной для автоматизации крупных корпоративных облачных миграций, используя Amazon Bedrock AgentCore для координации поиска, генерации инфраструктурного кода, управления и операций после миграции.

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

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

Миграционный рабочий процесс, разделённый между специализированными агентами

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

Intake Agent автоматизирует обнаружение приложений, картирование зависимостей и определение целевой архитектуры. Затем IaC Agent генерирует инфраструктуру как код в соответствии с практиками и стандартами безопасности организации. Migration Intelligence and Governance Agent формирует отчёты по портфелю, оценки Well-Architected и информацию по управлению в таких инструментах, как Jira, Confluence и Webex.

После развертывания SRE Agent отслеживает мигрированные рабочие нагрузки, выявляет потенциальное ухудшение и поддерживает автоматизированное устранение. AWS также указывает смежные сервисы для конкретных задач миграции, включая AWS Database Migration Service для assisted schema conversion и переключения базы данных, а также AWS Transform для модернизации устаревших приложений.

Такое разделение отражает разные профили риска в миграционной программе. Поиск требует извлечения фактов из документов и существующих систем. Генерация кода требует соблюдения инфраструктурных стандартов. Управление требует видимости на уровне портфеля, а операции требуют доступа к живым системам и тщательно контролируемого устранения проблем. Рассмотрение этих задач как отдельных ролей агентов может сделать разрешения и оценку более управляемыми, чем наделение одного агента широкой властью.

Как Amazon Bedrock AgentCore вписывается в систему

Согласно AWS Machine Learning Blog, каждый агент определяется базовой моделью, системным промптом и набором инструментов. Amazon Bedrock AgentCore Runtime размещает агентов в бессерверной среде с изоляцией сессий и поддержкой многоагентной оркестрации.

Агенты получают доступ к внешним возможностям через инструменты Model Context Protocol. AgentCore Gateway может преобразовывать API, функции AWS Lambda и существующие сервисы в MCP-совместимые инструменты, позволяя фреймворку подключать миграционных агентов к корпоративным системам без перестройки каждой интеграции вокруг нового интерфейса.

Идентификация обрабатывается через AgentCore Identity, который, по словам AWS, аутентифицирует вызовы с использованием ограниченных ролей AWS Identity and Access Management и поставщика идентификации организации. Это центральная деталь для автоматизации инфраструктуры: практическая граница безопасности определяется не только инструкциями модели, но и тем, что каждый агент технически может читать, изменять или выполнять.

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

Данные, стоящие за заявлением о производительности

Самое сильное заявление об эффективности в анонсе исходит от самого поставщика. AWS объясняет сокращение разработки IaC с трёх-четырёх недель на приложение до минут в портфеле из более чем 300 приложений своими внутренними данными отслеживания проектов. В блоге не приводится полная методология сравнения до и после, детали сложности каждого приложения, объём человеческой проверки или доля сгенерированного кода, принятого без существенных изменений.

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

Доступные доказательства всё же показывают, что именно AWS представляет: работающую внутреннюю архитектуру, сочетающую специализированные AI-агенты, корпоративные инструменты и сервисы миграции AWS. Однако это ещё не доказывает широко повторяемую экономию времени по отраслям или портфелям приложений. Второй источник в этой группе — блог, контролируемый AWS, а предоставленный wire-материал не содержит дополнительного текста статьи или независимого репортажа.

Что это значит для команд, занимающихся облачными миграциями

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

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

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

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

На что смотреть дальше

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

Дополнительные сведения о точках человеческого утверждения в фреймворке также помогут понять его операционную зрелость. Примеры отклонённых или исправленных ответов агентов, audit trails из AgentCore Identity и политики, регулирующие автоматическое устранение, помогут командам оценить риск.

Наконец, наличие повторно используемых reference implementations, поддерживаемых моделей по регионам AWS и интеграций за пределами инструментов, упомянутых в блоге, покажет, останется ли это паттерном AWS Professional Services или превратится в широко применимую платформенную архитектуру. Принятие подхода миграционными партнёрами и данные от клиентов вне AWS дали бы более сильный рыночный сигнал, чем текущий внутренний результат.

Взгляд Creati.ai

AWS позиционирует AgentCore как инфраструктуру для скоординированных корпоративных AI-агентов, а облачная миграция — правдоподобный тестовый кейс, потому что работа повторяющаяся, но всё ещё зависит от экспертного суждения. Ценность архитектуры, вероятно, будет исходить не столько из автономного принятия решений, сколько из превращения разрозненных миграционных задач в контролируемые, поддающиеся проверке рабочие процессы.

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