Один вызов вместо ручной пересборки: AWS показала Quick Resource Migrator для переноса ресурсов Amazon Quick между аккаунтами

Проблема, которую решает перенос

Amazon Quick AWS описывает как агентного ИИ-компаньона для работы: в нём собирают агентов, которые рассуждают над данными, вызывают коннекторы действий (action connectors) и доводят многошаговые задачи до конца. Строительные блоки такого решения перечислены прямо: чат-агенты с пользовательскими инструкциями, стартовыми промптами и приветственным сообщением; коннекторы для Slack, Jira и других интеграций; базы знаний, заземлённые на собственных документах; и Space, который связывает всё это вместе.

Большинство компаний держат отдельные аккаунты AWS для разработки и продакшена, иногда с прослойкой QA. Когда агент, коннекторы и базы знаний прошли проверку в аккаунте разработки, перенести их в следующий аккаунт одним нажатием нельзя: команды пересобирают каждую сущность руками — заново создают агента с теми же инструкциями и стартовыми промптами, повторно подключают к нему коннекторы, заново выдают права на ресурсы и заново готовят S3-бакет, его политику и источник данных под каждой базой знаний.

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

Ресурсы Amazon Quick программируемы

Ключевая предпосылка решения — то, что ресурсы Amazon Quick управляются программно. Spaces, агенты, коннекторы действий, базы знаний и flows доступны через Amazon Quick API, который является частью поверхности Amazon Quick Sight API и даёт полный жизненный цикл ресурса: создание, чтение, обновление, удаление и перечисление.

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

Как устроен Quick Resource Migrator

Quick Resource Migrator — пример MCP-сервера, размещённого на рантайме Amazon Bedrock AgentCore. Он переносит выбранный набор ресурсов между аккаунтами одним вызовом инструмента: выбор идёт по типу ресурса — агент, коннектор, база знаний, flow или space, — а внутри типа по идентификатору, по имени или по всем сразу.

Перенос работает как upsert: ресурс, которого в целевом аккаунте ещё нет, создаётся, а существующий обновляется на месте. Каждое обновление защищено версионированной резервной копией, которая записывается в Amazon S3 до изменения, поэтому у каждого ресурса остаётся полная история, доступная для просмотра и отката. Отдельно предусмотрен предпросмотр только для чтения: он заранее сообщает, что именно прогон создаст или обновит, и потому годится как этап согласования изменений перед публикацией.

Полный исходный код примера AWS выложила в репозитории aws-samples.

Что переносится и как

Чат-агенты воссоздаются вместе с их пользовательскими инструкциями, идентичностью, тоном, стартовыми промптами и приветственным сообщением, а их коннекторы действий подключаются заново — с переносом в целевой аккаунт. При переносе space его агенты автоматически привязываются к нему.

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

База знаний регистрируется в целевом аккаунте, её источник данных создаётся заново, права копируются, а для баз знаний на Amazon S3 мигратор дополнительно готовит целевой бакет и его политику — отдельный результат переноса; сами документы (объекты S3) при этом не копируются.

Flows воссоздаются из своего определения, но поскольку идентификаторы flow в разных аккаунтах различаются, сопоставление идёт по имени: одноимённый flow в целевом аккаунте обновляется, иначе создаётся новый. Сам Space воссоздаётся и связывается заново со своими агентами, коннекторами и базами знаний, причём ARN ресурсов переотображаются на целевой аккаунт — поэтому связанные ресурсы нужно переносить первыми, чтобы целевые ARN уже существовали.

Пять принципов, на которых он построен

Верность правам доступа: они не зашиты в код — сервер вызывает у каждого ресурса-источника API Describe*Permissions и повторяет идентичный список действий в целевом аккаунте, переотображая principals на зарегистрированных пользователей цели.

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

Минимальные права и изоляция: роль в аккаунте-источнике — только на чтение, роль в целевом аккаунте несёт лишь нужные миграции действия, а рантайм аутентифицирует вызывающих через JWT от Amazon Cognito и умеет работать в режиме сети VPC.

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

Ресурсо-ориентированный выбор и предсказуемость действий описаны в самой публикации как отдельные принципы: переносится один тип ресурса за раз, а любой прогон только добавляет или обновляет — удаление против целевого аккаунта не выдаётся вообще.

Три аккаунта и отсутствие долгоживущих ключей

Архитектурно решение построено на модели из трёх аккаунтов: центральный аккаунт-раннер хостит MCP-сервер на рантайме Amazon Bedrock AgentCore, сервер принимает read-only роль в аккаунте-источнике и read-write роль в целевом аккаунте через AWS Security Token Service (AWS STS), поэтому долгоживущие учётные данные нигде не хранятся.

Рантайм AgentCore, согласно официальной документации AWS, — это безопасная бессерверная среда исполнения, специально рассчитанная на развёртывание и масштабирование динамических ИИ-агентов и инструментов. В этой схеме Amazon Cognito в аккаунте-раннере выдаёт JWT по client-credentials grant со scope invoke; роль исполнения AgentCore имеет доступ к журналам Amazon CloudWatch и право sts:AssumeRole в роли источника и цели; бакет резервных копий хранит зашифрованные версионированные снимки целевых ресурсов.

Сам перенос идёт фиксированной последовательностью: разрешить ресурсы по типу и селектору, описать источник, воссоздать коннекторы, затем базы знаний (с созданием целевого бакета вида knowledge-base-<env>-<account>, политики, источника данных и самой базы знаний), затем агентов с подключёнными коннекторами, затем flows по имени и, наконец, spaces со связанными ресурсами — после чего вернуть структурированный отчёт о созданном, обновлённом и выданном.

Инструменты и развёртывание

Сервер выставляет пять инструментов. preview_migration работает только на чтение: он принимает идентификатор аккаунта-источника, тип ресурса, селектор и регион и возвращает инвентарь того, что было бы перенесено, без каких-либо изменений; при передаче целевого аккаунта ответ добавляет сопоставление источник-цель с пометкой CREATE или UPDATE для каждого ресурса.

migrate_resources выполняет полный перенос create-or-update и возвращает отчёт обо всём созданном, обновлённом и выданном вместе с ошибками; благодаря идемпотентности его можно запускать повторно, например на каждый релиз. list_backups и get_backup позволяют просмотреть полную историю версий любого перенесённого ресурса, а restore_backup заново применяет сохранённую версию к целевому ресурсу — и перед этим сам снимает свежую резервную копию, поэтому откат тоже обратим.

Развёртывание описано как три стека AWS CloudFormation: кросс-аккаунтные IAM-роли, сеть VPC и рантайм AgentCore с аутентификацией Cognito, который хостит MCP-сервер, после чего рантайм регистрируется в Amazon Quick как коннектор действий. Через этот же коннектор мигратором можно управлять из Amazon Quick на естественном языке, а из готового промпта app-builder собирается Quick App — интерфейс на тех же MCP-инструментах, где выбирают аккаунты и ресурсы, смотрят предпросмотр, запускают перенос и просматривают историю прошлых миграций.

Что это меняет

AWS формулирует итог так: кросс-аккаунтный перенос — базовая ожидаемая возможность корпоративного ПО, и до сих пор именно её не хватало Amazon Quick. Quick Resource Migrator превращает медленную, ручную и трудно аудируемую задачу в быструю, повторяемую и управляемую: один вызов инструмента воссоздаёт агентов, коннекторы и базы знаний в целевом аккаунте и верно копирует права — идемпотентно, так что это можно делать на каждом релизе.

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