Amazon Web Services опубликовала референсную архитектуру мультиаккаунтного AI-агента: данные остаются в своих AWS-аккаунтах, а агент получает единый способ запрашивать их через Amazon Bedrock AgentCore Gateway и Model Context Protocol (MCP). Центральный платформенный аккаунт запускает агента на AgentCore Runtime и выполняет инференс LLM через Amazon Bedrock, а бизнес-подразделения (line-of-business, LOB) публикуют свои данные и инструменты как MCP-серверы в собственных аккаунтах. Описание архитектуры AWS приводит в блоге Machine Learning.
Ключевой принцип: наружу уходит результат конкретного запроса, а не сырой датасет. Запрос «покажи продажи за квартал» возвращает агрегированное число, но не всю таблицу продаж. Предпосылка простая: предприятия хотят, чтобы агенты рассуждали над данными, разбросанными по десяткам аккаунтов, и при этом эти данные никуда не копировались и не централизовались.
Сразу оговорю границы: речь о референсной архитектуре, а не о готовом продукте. AWS показывает схему, набор сервисов и логику связей, а сборку под свои аккаунты каждая команда делает сама. Разбор ниже опирается на вводную часть публикации AWS и на общие свойства сервисов; там, где автор материала деталей не раскрыл, я это отмечаю прямо.
Что такое мультиаккаунтный AI-агент на AWS и зачем он нужен
Схема отвечает на конкретную корпоративную проблему: данные лежат в десятках AWS-аккаунтов, а бизнес хочет задавать вопросы одному агенту и получать сводные ответы по всем источникам. Копировать всё в один аккаунт дорого, долго и политически сложно: у каждого набора данных есть владелец, свой цикл изменений и свои требования к доступу.
Архитектура раскладывается на три слоя. Центральный платформенный аккаунт запускает агента. Распределённые LOB-аккаунты держат данные и публикуют инструменты. AgentCore Gateway связывает первые два слоя: агент подключается к шлюзу, а не к отдельным MCP-серверам подразделений. Ниже разберу каждый слой подробнее, начну с главного вопроса: почему данные вообще не свозят в одно место.
Почему данные не копируются в центральный аккаунт
Команды держат данные у себя по трём причинам: понятное владение, изоляция периметра и независимые циклы развёртывания. Как только данные уезжают в аккаунт-агрегатор, появляется копия. Её нужно синхронизировать, защищать по тем же правилам, что и оригинал, и заново согласовывать с владельцем при каждом изменении схемы. Комплаенс-требования не исчезают, а удваиваются.
Агент работает иначе. Он не тянет датасет к себе, а вызывает инструмент на стороне владельца. MCP-сервер сам решает, что вернуть: агрегат, выборку по фильтру, одну строку справочника. Сырые данные при этом не покидают аккаунт LOB: за периметр уходит только результат выполнения вызова.
| Запрос к агенту | Что возвращает MCP-сервер | Что остаётся в аккаунте LOB |
|---|---|---|
| Продажи за квартал по региону | Агрегированное число | Строки продаж и записи по клиентам |
| Остаток товара на складе | Текущее значение остатка | Полная складская таблица и история движения |
| Число активных договоров | Счётчик на дату | Реестр договоров с реквизитами сторон |
Таблица выше - иллюстрация принципа «результат вместо датасета», а не описание конкретных инструментов из примера AWS. Логика в том, что фильтрация, проверка прав на уровне записи и агрегация выполняются внутри периметра владельца данных.
Три слоя архитектуры: платформенный аккаунт, LOB-аккаунты и AgentCore Gateway
- Платформенный аккаунт. Здесь работает агент на AgentCore Runtime, а инференс LLM идёт через Amazon Bedrock. Платформенная команда держит под контролем список доступных базовых моделей, применяет Amazon Bedrock Guardrails и видит расходы через единую границу биллинга, без необходимости управлять квотами моделей в десятках LOB-аккаунтов.
- LOB-аккаунты. Подразделения публикуют свои данные и инструменты как MCP-серверы в собственных аккаунтах. Владелец данных сам решает, какие операции доступны и что именно возвращается в ответе.
- AgentCore Gateway. Слой интеграции и единая конечная точка для обнаружения и вызова инструментов среди зарегистрированных подразделений. Агент обращается только к шлюзу платформенного аккаунта.
AgentCore Runtime стоит описать отдельно: это бессерверная среда, не привязанная к конкретному фреймворку, с изоляцией сессий в выделенных микровиртуальных машинах, оплатой по потреблению и встроенной аутентификацией. Для LOB-команд это означает, что не нужно поднимать собственный хостинг под MCP-сервер и отдельно решать задачу изоляции запросов друг от друга.
При росте нагрузки схему расширяют: инференс распределяют по нескольким выделенным inference-аккаунтам, а AgentCore Gateway ставят впереди как Inference Gateway. Такой шлюз маршрутизирует трафик между провайдерами моделей, выбирает провайдера под конкретный запрос и применяет лимиты скорости для каждой команды. Это уже про масштаб и справедливое распределение бюджета между подразделениями.
В опубликованном примере фигурирует один агент. Тот же паттерн выдерживает несколько агентов в платформенном аккаунте: Gateway для них общий, а политики доступа разводятся по ролям.
Как работает кросс-аккаунтная интеграция MCP через AgentCore Gateway
Основная сложность здесь не в протоколе, а в доверии между аккаунтами. Аккаунт, который вызывает инструмент, не владеет ни данными, ни сервером, который их отдаёт. Поэтому вызов строится в два независимых шага: сначала подразделение публикует MCP-сервер у себя, затем регистрирует его в шлюзе платформенного аккаунта и настраивает разрешения.
Публикация MCP-сервера в аккаунте LOB
Команда LOB разворачивает MCP-сервер на AgentCore Runtime в своём аккаунте. Сервер инкапсулирует доступ к данным и инструментам и отдаёт наружу только результат вызова. Проверки прав на уровне записи, фильтрация чувствительных полей и агрегация остаются внутри периметра владельца, платформенная команда в них не вмешивается.
Для команд, которые уже возились с внешними и локальными MCP-серверами, механика знакомая: наружу выставляются инструменты, а не схема базы. Разбор MCP-моста между облачным агентом и локальными серверами показывает ту же логику на примере подключения к машине разработчика, включая вопросы изоляции процессов и ограничения доступа.
Регистрация MCP-сервера в AgentCore Gateway
Gateway платформенного аккаунта выступает единой точкой обнаружения и вызова инструментов. Команда LOB регистрирует свой MCP-сервер, указывая endpoint и необходимые разрешения. Дальше агент обращается к шлюзу, а шлюз маршрутизирует вызов к нужному серверу в нужном аккаунте. Прямых связей между LOB-аккаунтами при этом не возникает, что заметно упрощает аудит: все маршруты проходят через одну точку.
Ограничение по фактуре: вводная часть материала AWS не раскрывает формат манифеста регистрации, состав полей и пошаговую настройку IAM-доверия между аккаунтами. Общий смысл понятен (роль в LOB-аккаунте доверяет роли в платформенном аккаунте, шлюз вызывает endpoint от имени агента), но конкретные шаблоны политик придётся собирать по документации и проверять на стенде. Исходное описание архитектуры служит здесь точкой отсчёта, а не готовым чек-листом.
Настройка аутентификации и авторизации между аккаунтами
Аутентификацию между сервисами закрывает AgentCore Identity, а внешним провайдером идентификации в примере выступает Okta. Используется стандартная для машинного взаимодействия схема OAuth 2.0 M2M: агент получает токен и предъявляет его шлюзу при вызове серверов подразделений. Шлюз проверяет токен и передаёт дальше уже авторизованный вызов.
Авторизацию разбирает Policy in Amazon Bedrock AgentCore. Политики описываются на языке Cedar и учитывают атрибуты пользователя из JWT, то есть роль, подразделение и уровень доступа. Пример, который логически следует из такой схемы: пользователь с ролью «аналитик» может вызывать только инструменты чтения, а «менеджер» получает доступ и к операциям записи. Это уже не пример из публикации AWS, а демонстрация того, как атрибуты токена превращаются в конкретные ограничения на вызов инструмента.
Безопасность и гранулярная авторизация в мультиаккаунтной среде
Мультиаккаунтная схема хороша тем, что границы доверия здесь совпадают с границами аккаунтов. Данные не покидают аккаунт LOB, наружу возвращается результат запроса, а доступ к инструментам ограничивается на нескольких уровнях. Защита складывается из трёх независимых механизмов, и каждый закрывает свой класс риска.
Аутентификация с AgentCore Identity и Okta
AgentCore Identity отвечает за машинную аутентификацию по OAuth 2.0 M2M, Okta играет роль внешнего identity provider. Агент получает токен, предъявляет его шлюзу, шлюз проверяет подпись и срок действия, и только после этого вызов уходит в MCP-сервер подразделения. Для машинного взаимодействия такая схема привычна: короткоживущий токен вместо долгоживущих статических ключей, единая точка выпуска и отзыва.
Обратная сторона тоже очевидна: без настроенного провайдера идентификации (Okta или аналогичного) схема не заработает, а значит, в проект добавляется внешняя зависимость и связанные с ней требования к эксплуатации.
Гранулярная авторизация с Policy in AgentCore (Cedar)
Policy in Amazon Bedrock AgentCore позволяет ограничивать доступ не грубым «есть доступ к агенту или нет», а по атрибутам: какая роль у пользователя, из какого он подразделения, какой у него уровень допуска. Политики на Cedar описывают правила вида «инструмент с прогнозом продаж доступен отделу продаж, инструмент с зарплатными данными недоступен никому, кроме HR и финансов».
Практическая ценность в том, что принцип наименьших привилегий получается выразить декларативно и хранить в одном месте, вместо того чтобы раскидывать проверки по коду каждого MCP-сервера. Кейс AvioBook на Amazon Bedrock AgentCore показывает, как похожая изоляция данных через JWT-атрибуты и шлюз работает в боевой системе, включая ограничения proof-of-concept.
Честная оговорка: это набор инструментов, а не абсолютная защита. Если в токене нет нужных claim, если политика написана слишком широко или если MCP-сервер возвращает больше данных, чем требует запрос, никакой Cedar это не исправит. Политики нужно проектировать вместе с контрактами инструментов.
Защита данных на уровне LLM с Amazon Bedrock Guardrails
Amazon Bedrock Guardrails применяются в платформенном аккаунте централизованно для всех агентов. Они фильтруют запросы и ответы модели: можно ограничить нежелательные темы, вырезать персональные данные и блокировать вредоносный контент до того, как он попадёт пользователю в чат.
Плюс централизации в том, что политики фильтрации задаются один раз на платформе, а не согласуются отдельно с каждым подразделением. Минус в том же: слишком строгие фильтры на уровне платформы начинают резать легитимные запросы LOB-команд, и настраивать их приходится итеративно.
Наблюдаемость и оценка качества агента
Здесь начинается самая слабо документированная часть схемы. Вводная публикация AWS не раскрывает, как именно в этой архитектуре настраиваются логи, трассировка и оценка ответов. Ниже - рабочая логика для распределённой среды и стандартные сервисы AWS, которые такую задачу закрывают.
Сбор логов и трассировка запросов между аккаунтами
Главное требование в мультиаккаунтной схеме: идентификатор запроса должен доходить от агента через шлюз до MCP-сервера в чужом аккаунте и возвращаться обратно с тем же значением. Без сквозного идентификатора разбор инцидента превращается в переписку между командами в чате: непонятно, где потерялись две секунды и на каком шаге отвалился вызов.
Стандартный набор AWS для этой задачи - Amazon CloudWatch для логов и метрик и AWS X-Ray для трассировки распределённых вызовов. Цепочка для наблюдения выглядит так: агент на AgentCore Runtime, шлюз, MCP-сервер в аккаунте LOB, обратный ответ. Практический разбор наблюдаемости агентных запросов через CloudWatch, X-Ray и OpenTelemetry показывает, как это устроено на уровне вызовов и почему без трассировки оценка качества превращается в гадание.
Оценка качества ответов агента
Оценивать агента в мультиаккаунтной среде сложнее, чем в одном аккаунте: один и тот же вопрос может уходить в разные подразделения и получать ответы разной свежести и полноты. Полезный минимум - фиксировать, какой MCP-сервер и какой аккаунт участвовали в обработке запроса, иначе невозможно понять, кто именно дал сбойный результат.
Отдельно стоит проверять поведение после изменений в политиках: ужесточение правил в Cedar или новый фильтр в Guardrails легко ломает сценарий, который до этого работал. Конкретные метрики и методики оценки AWS в этом материале не приводит, поэтому набор проверок придётся определять под свой домен: для финансов это сверка агрегатов с эталонным отчётом, для инвентаризации - контроль расхождений с учётной системой.
Управление затратами в мультиаккаунтной архитектуре
Экономика здесь устроена удобно для платформенной команды: инференс LLM идёт в платформенном аккаунте через Amazon Bedrock, и расходы на модели собираются в одной границе биллинга. Не нужно выбивать квоты базовых моделей в каждом LOB-аккаунте и потом сводить счета из десятков мест.
AgentCore Runtime оплачивается по потреблению, то есть платят за фактические вызовы, а не за простаивающие мощности. Платформенная команда контролирует, какие базовые модели доступны агентам, и может ограничивать набор: дорогая модель остаётся для сложных запросов, массовые обращения уходят на более дешёвые варианты. При схеме с Inference Gateway добавляются лимиты скорости для каждой команды, что превращает бюджет в управляемый параметр, а не в сюрприз в конце месяца.
Кросс-аккаунтные вызовы добавляют расходы на трафик и на работу MCP-серверов в подразделениях. Конкретных цифр по этому паттерну AWS в опубликованном материале не приводит, поэтому считать нужно по своим объёмам запросов. Обзор обновлений Amazon Bedrock и AgentCore за август 2026 полезен тем, что там разобраны механизмы контроля расходов и временные политики, которые напрямую влияют на смету агентных проектов.
Ограничения и подводные камни подхода
Решение не разворачивается «из коробки» и требует зрелых процессов. Что стоит взвесить до старта:
- Сложность кросс-аккаунтной настройки. Роли, доверительные отношения и разрешения нужно согласовать для каждого LOB-аккаунта. В схеме на три аккаунта это терпимо, в схеме на тридцать - отдельный проект с регламентом.
- Зависимость от провайдера идентификации. Без Okta или аналогичного сервиса схема с OAuth 2.0 M2M не собирается, а внешний identity provider добавляет свою зону отказа.
- Шлюз как единая точка. Все вызовы инструментов идут через AgentCore Gateway платформенного аккаунта. Это удобно для аудита и одновременно означает, что деградация шлюза затрагивает всех агентов и все подразделения.
- Дополнительные сетевые хопы. Каждый вызов проходит цепочку агент, шлюз, MCP-сервер в чужом аккаунте и обратно. Для интерактивного диалога это заметно, и бюджеты задержек нужно закладывать заранее.
- Согласованность политик. Правила доступа живут в платформенном аккаунте, а логика фильтрации данных - в LOB-аккаунтах. Если команды трактуют «доступ к записи» по-разному, разграничение перестаёт работать.
Отдельно упомяну ограничение материала: опубликованный текст AWS раскрывает вводную часть архитектуры, а детали настройки кросс-аккаунтного доступа, наблюдаемости и оценки качества в нём не разобраны. Схему стоит воспринимать как каркас, который предстоит наполнить решениями под свой контур.
Кому подходит мультиаккаунтный AI-агент на AWS
Архитектура оправдывает себя в крупных организациях с несколькими бизнес-подразделениями, где данные нельзя двигать по требованиям комплаенса, где у каждого набора данных есть владелец и где подразделения выпускают обновления независимо друг от друга. Типичный потребитель - компания с десятками AWS-аккаунтов, собственным identity provider и командой платформы, которая готова поддерживать общий шлюз.
Для небольшой команды в одном-двух аккаунтах схема избыточна. Прямое подключение MCP-сервера к агенту в том же аккаунте или более простые интеграции дадут тот же результат с меньшими накладными расходами. Централизованное хранилище с понятными правами доступа тоже остаётся рабочим вариантом, если данные допустимо копировать.
Практический шаг для тех, кто решил пробовать: стартуйте с одного-двух LOB-аккаунтов, оставьте инференс в платформенном аккаунте и опишите роли и JWT-claims до регистрации первого MCP-сервера в Gateway. Переписывать политики доступа задним числом дороже, чем спроектировать их на входе.