Блог AWS по машинному обучению 28 октября 2026 года опубликовал разбор корпоративной платформы для AI-агентов, собранной на Amazon Bedrock AgentCore (Building an Agentic AI Platform on Amazon Bedrock AgentCore). Главный тезис публикации неудобен для индустрии: модель и вызовы инструментов давно не главный блокер вывода агента в продакшен.
Узкое место - всё, что вокруг. Сколько команд может строить в безопасной среде одновременно. Кто владеет каждой моделью и каждым инструментом. Как AgentOps и обработка ошибок остаются внутри заранее заданного контура. Как платформенная, продуктовая и финансовая команды видят стоимость и здоровье сервисов по аккаунтам. Ответ AWS - федеративная модель: центральная Platform-команда владеет операционной моделью, control plane, общими шлюзами, шаблонами, политиками и CI/CD-гейтами, а Workstream-команды получают изолированные ячейки и владеют своими агентами.
Сразу о статусе фактов, чтобы не смешивать цитаты и домыслы. Доступный текст публикации подтверждает операционную модель, paved road, отдельные inference- и tool-шлюзы, guardrails, allow-list моделей и регионов, per-Workstream квоты и бюджеты, атрибуцию затрат и пайплайн оценки, который гейтит агента перед продакшеном. Детали вроде конкретных SCP-политик, CloudWatch OAM, Cost and Usage Report, порядка вывода ресурсов и привязки к eu-west-1 в доступном фрагменте не раскрыты. Ниже они помечены как требования к проверке, а не как выдержки из поста.
Зачем нужна мультиаккаунтная платформа для агентов на AgentCore
Amazon Bedrock AgentCore - набор модульных сервисов для сборки, развёртывания и эксплуатации агентов: runtime, gateway, identity, memory, policy, registry, evaluations. Сам по себе он даёт строительные блоки. Корпоративные контракты поверх них добавляет Enterprise Agentic AI Platform Blueprint: владение, границы аккаунтов, доставку ПО, наблюдаемость, управление затратами и вывод из эксплуатации, и всё это как развёртываемую инфраструктуру как код.
Разница принципиальная. Модульный сервис отвечает на вопрос «можно ли вызвать модель». Blueprint отвечает на вопрос «кто именно вызвал, в каком аккаунте, в рамках какого бюджета, с какими guardrails и что будет, когда команда уйдёт». Второй набор вопросов обычно всплывает, когда агентов становится десять и больше.
Почему контроли дрейфуют, когда каждая команда собирает их сама
Workstream-команды постоянно меняют промпты, набор инструментов, доступ к данным и поведение приложения. Контроли при этом должны оставаться согласованными. Когда каждая команда собирает их самостоятельно, результат предсказуем: контроли дрейфуют, общие сервисы превращаются в узкое место, а аудит владения упирается в вопрос «чьи это ключи и кто это настроил».
Дрейф редко выглядит как авария. Сначала одна команда ослабляет фильтр, потому что он мешает тестировать. Вторая копирует её конфиг как рабочий образец. Через квартал у пяти команд пять разных наборов guardrails, и никто не может доказать, что в проде нет обхода. Федеративная модель бьёт по причине, а не по симптому: контроли живут в одном месте, команды меняют только то, что им действительно нужно менять.
Что даёт «paved road» Workstream-команде
В публикации paved road описан конкретным списком. Команда получает:
- одобренные модели и инструменты;
- короткоживущую идентичность рабочей нагрузки;
- изолированные runtime и memory;
- автоматизированную оценку;
- откат;
- телеметрию;
- атрибуцию затрат.
Это контракт, а не меню. Команда не выбирает, нужна ли ей атрибуция затрат: без неё платформа не покажет, кто сжёг бюджет. Пункты работают только вместе. Изолированный runtime без телеметрии прячет проблемы, телеметрия без квот не спасает общую ёмкость, квоты без allow-list моделей не мешают вызвать неподходящую модель из неподходящего региона.
Операционная модель: Platform-команда и Workstream-команды
В посте AWS роли разведены явно. Platform team управляет платформой. Workstream teams - доменные или продуктовые команды, которые строят и владеют агентами на платформе. Вся остальная архитектура отвечает на один вопрос: как этот стык не разваливается при росте числа команд.
Кто чем владеет: матрица ответственности
Матрица ниже собрана из того, что публикация относит к платформе и к Workstream. Строки про вывод ресурсов и наблюдаемость - интерпретация корпоративных контрактов blueprint, а не дословная цитата.
| Область | Platform-команда | Workstream-команда |
|---|---|---|
| Control plane и шаблоны | Владеет | Использует |
| Inference- и tool-шлюзы | Владеет и обновляет | Обойти не может |
| Guardrails и allow-list моделей и регионов | Задаёт | Запрашивает изменения |
| Квоты и бюджеты | Задаёт лимиты | Планирует расход внутри лимита |
| CI/CD-гейты | Владеет пайплайном | Проходит гейты при каждом релизе |
| Промпты и поведение агента | Не владеет | Владеет |
| Инструменты | Держит каталог одобренных | Подключает только из каталога |
| Доступ к данным | Задаёт контур | Настраивает внутри контура |
| Наблюдаемость и атрибуция затрат | Собирает по аккаунтам | Видит свои метрики и счёт |
| Вывод из эксплуатации | Задаёт порядок | Запускает вывод своей ячейки |
Разделение обязанностей держится на одном ограничении: ни одна сторона не может в одиночку снять контроль и выпустить релиз. Platform не пишет промпты за команду, Workstream не правит guardrails под себя. Аудировать такую схему проще, потому что у каждого изменения есть один владелец.
Архитектура: control plane и изолированные ячейки Workstream
Публикация перечисляет компоненты без экзотики: операционная модель, control plane, ячейки на каждую Workstream, отдельные inference- и tool-шлюзы и CI/CD-пайплайн оценки, который гейтит агента перед продакшеном. Каждая ячейка несёт Runtime, Memory и Tool Gateway (источник).
Изоляция runtime и memory внутри ячейки
Runtime и memory входят в paved road и ограничивают радиус поражения. Агент одной команды не видит память другой, сбой в ячейке не роняет соседей, а короткоживущая идентичность рабочей нагрузки означает, что унести долгоживущий креденшел из конфига не получится. Границы аккаунтов добавляют второй слой: даже при ошибке в конфигурации ячейка не выходит за пределы своего аккаунта.
Практический смысл изоляции виден на инциденте. Если один агент начал генерировать мусор в память, пострадает его ячейка, а не общий каталог команды. Откат в такой схеме локальный, а не платформенный.
Почему шлюзы вынесены на уровень платформы
Централизованные шлюзы удерживают guardrails, allow-list моделей и регионов, квоты и атрибуцию затрат согласованными между всеми командами. Отдайте шлюз командам, и через пару месяцев у вас будет пять реализаций контроля и ни одной гарантии, что они эквивалентны. Логика та же, что в разборе типичных провалов агентских пилотов: демо ломается не о модель, а об отсутствие архитектуры безопасности и единого AI Gateway.
Inference-шлюз с guardrails: модели, регионы, квоты и атрибуция затрат
Правило из публикации звучит как аксиома: каждый недоверенный inference-запрос проходит через одобренный inference-шлюз. Шлюз делает пять вещей одновременно.
- Применяет guardrails организации. AWS приводит в пример Amazon Bedrock Guardrails и допускает стороннего провайдера.
- Ограничивает модели и регионы AWS, доступные конкретной Workstream-команде.
- Держит per-Workstream rate limits, token-квоты и бюджеты.
- Несёт идентичность рабочей нагрузки.
- Испускает данные атрибуции.
Третий пункт закрывает проблему шумного соседа: одна команда не может выесть общую ёмкость. Четвёртый отвечает на вопрос, кто отправил запрос, даже если у команды десяток агентов. Пятый превращает расходы из абстракции в строку отчёта.
Allow-list моделей и регионов: как это работает на практике
Ограничения задаются на уровне Workstream-команды: у одной доступ к модели в одном регионе, у другой - к другой модели в другом. Запрос вне allow-list отклоняется шлюзом до вызова Bedrock. Конкретный синтаксис политик зависит от реализации шлюза, в публикации он не детализирован, поэтому ниже иллюстрация формата, а не выдержка из кода AWS.
{
"workstream": "payments-agents",
"models": [
{ "model_id": "approved-model-id", "region": "approved-region" }
],
"limits": {
"requests_per_minute": 120,
"tokens_per_day": 4000000
}
}Региональный список стоит держать в голове, если платформа разрешает кросс-региональный инференс: в обзоре обновлений Bedrock и AgentCore за август 2026 разобрано, как он устроен и какие ограничения несёт, включая контроль расходов. Чем шире географию моделей разрешает шлюз, тем аккуратнее нужно формулировать allow-list, иначе запрос уедет в регион, который вы не планировали использовать.
Квоты, токен-лимиты и бюджеты против «шумного соседа»
Это три разных механизма, и подменять один другим нельзя. Rate limits ограничивают скорость: запросы в минуту. Token-квоты ограничивают объём обработки. Бюджеты ограничивают деньги. Всплеск за минуту не остановит месячный бюджет, а медленный рост расходов не остановит rate limit. Платформе нужны все три, и все привязаны к Workstream-команде.
Есть практический нюанс: лимиты должны быть видны команде до того, как она упрётся в них в проде. Лимит, о котором узнают из ошибки 429 в пятницу вечером, команда обойдёт своим шлюзом. Лимит, который виден в телеметрии и обсуждён на старте, команда планирует.
Tool Gateway и MCP: доступ только к одобренным инструментам через AWS_IAM и SigV4
Правило из публикации короткое: агенты должны обнаруживать и вызывать только одобренные инструменты через аутентифицированный Model (tool) Gateway. Всё остальное - следствия. Неодобренный инструмент агент не видит. Одобренный вызов проходит аутентификацию на шлюзе и оставляет след с субъектом и временем.
Формулировка в доступном фрагменте обрывается на словах об аутентифицированном Model (tool) Gateway, поэтому внутренний механизм в этом тексте не раскрыт. В описании темы указаны AWS_IAM и SigV4 как способ аутентификации MCP-доступа; в доступном фрагменте поста это не подтверждено, так что сверяйте схему с документацией AgentCore Gateway под свою версию.
Как аутентификация AWS_IAM и SigV4 закрывает неодобренные вызовы
Логика подписи запроса простая. Клиент подписывает вызов своим ключом, шлюз проверяет подпись и права IAM-роли, и только после этого запрос уходит к инструменту. Анонимный вызов отваливается на входе, вызов с чужими правами тоже. Второй эффект - атрибуция: у каждого обращения к инструменту есть субъект, роль и время.
Для MCP это значит, что агент работает не с произвольным списком серверов, а с каталогом, который открыл ему шлюз. Похожий контур с MCP-инструментами в Gateway и передачей прав через токен мы разбирали в материале про аналитику авиарейсов на AgentCore у AvioBook. Там изоляция доступа к данным держится на JWT и Cognito, а инструменты вызываются только через шлюз.
CI/CD-пайплайн: как гейтится каждый релиз агента
Публикация заявляет CI/CD-пайплайн оценки, который гейтит агента перед продакшеном. По описанию референса порядок шагов такой: сборка и синтез инфраструктуры, проверка политик, деплой в nonproduction, оценка на реальном Runtime, ручное ревью, откат как штатная процедура. Конкретные шаги развёртывания и результаты прогонов в доступном фрагменте не приведены, поэтому список описывает контур процесса, а не отчёт об испытаниях.
Оценка идёт на реальном Runtime, и это ключевое решение. Синтез инфраструктуры доказывает, что политика описана. Runtime доказывает, что она применяется. Между этими двумя утверждениями лежит весь риск дрейфа.
Парные проверки «разрешённый вызов успешен, запрещённый отклонён»
Парность означает, что для каждого контроля проверяются два сценария. Позитивный: разрешённая модель и разрешённый инструмент действительно отвечают. Негативный: запрос к модели вне allow-list, к неодобренному инструменту, из запрещённого региона или сверх квоты действительно отклоняется.
Одна негативная проверка не доказывает ничего, кроме того, что сломался позитивный путь. Комбинация ловит расхождение декларации и поведения: политика на бумаге запрещает, а шлюз пропускает, потому что правило не доехало до окружения.
Ручное ревью и откат как обязательные шаги
Автоматические гейты проверяют то, что умеют проверять. Ручное ревью остаётся точкой, где человек утверждает изменение и берёт на себя ответственность за смысл, а не за синтаксис. Похожая логика лежит в методологии Agent-Ops 0.4.0: агент предлагает действия, человек утверждает, применяет их детерминированный исполнитель.
Откат должен быть описан до промоушена. Процедура, которую изобретают в момент инцидента, обычно включает ручное переключение того, что уже сломано.
SCP, разделение обязанностей и границы аккаунтов
Границы аккаунтов входят в корпоративные контракты blueprint. Разделение обязанностей держит всю модель: Platform владеет контролями, Workstream владеет агентом, ни одна сторона не снимает контроль в одиночку. SCP в описании референса указаны как дополнительный слой ограничений на уровне организации. Конкретных политик в доступном фрагменте поста нет, поэтому здесь только роли и логика, а сами политики придётся писать под свою организацию.
Короткоживущая идентичность рабочей нагрузки
Короткоживущая идентичность входит в paved road и напрямую связана с SCP. У агента нет долгоживущего креденшела, который можно унести из конфига, а организация сверху отрезает лишние действия на уровне аккаунта. Даже если в аккаунте появится слишком широкое разрешение, SCP не даст использовать его за пределами разрешённого набора сервисов.
Проверка на практике простая: попробуйте отозвать доступ у выведенной из эксплуатации ячейки. Если для этого нужно руками искать ключи в пяти местах, идентичность недостаточно короткоживущая.
Наблюдаемость и атрибуция затрат: CloudWatch OAM и Cost and Usage Report
Публикация ставит вопрос прямо: как платформенная, продуктовая и финансовая команды видят стоимость и здоровье сервисов по аккаунтам. В описании референса ответ строится на CloudWatch OAM для свода метрик между аккаунтами и Cost and Usage Report для разнесения затрат. В доступном фрагменте поста эта конкретика не подтверждена, так что ниже схема, которую нужно проверять по своей реализации.
Как атрибуция затрат связана с inference-шлюзом
Inference-шлюз несёт идентичность рабочей нагрузки и испускает данные атрибуции. Это и есть источник привязки: запрос к модели сопоставляется с Workstream, а не с безымянным аккаунтом. Дальше данные атрибуции складываются с CUR и дают сумму по команде, которую можно сверить с её бюджетом.
Без такой привязки мультиаккаунтная схема превращает счёт в общий котёл, а разбор «кто потратил» занимает недели. Проверка зрелости: возьмите любой счёт за месяц и попробуйте разложить его по Workstream-командам без ручной сверки. Если не получается, атрибуция не настроена, сколько бы дашбордов ни висело.
Вывод из эксплуатации: порядок зависимостей до нулевого остатка
Retirement входит в корпоративные контракты blueprint наравне с владением и наблюдаемостью. По описанию референса ресурсы выводятся в строгом порядке зависимостей до нулевого остатка. Порядок критичен, потому что удаление в произвольной последовательности оставляет висящие зависимости: правило маршрутизации без цели, роль с доверием к несуществующему сервису, ключ шифрования под удалённым хранилищем.
Нулевой остаток - проверяемое состояние. Пока в аккаунте живёт ресурс от выведенной ячейки, он стоит денег и остаётся поверхностью атаки. Конкретный список ресурсов и порядок их удаления в доступном фрагменте не приведены, его придётся составлять под свой стек и проверять автоматически, а не по памяти дежурного.
Ограничения референса и что проверять при адаптации
Blueprint - открытый референс, а не готовый продукт. В описании темы названы два ограничения: привязка к eu-west-1 и необходимость собственных проверок при замене компонентов. Ни то, ни другое в доступном фрагменте поста не подтверждено, но оба пункта логично вытекают из устройства: allow-list регионов, парные проверки на реальном Runtime и контракты под конкретные сервисы ломаются при смене компонента.
Заменили inference-шлюз - прогоняйте парные проверки заново. Поставили сторонние guardrails - убедитесь, что негативные сценарии по-прежнему отклоняются, а позитивные не деградировали. Сменили tool-шлюз - проверьте, что агент видит только одобренные инструменты и что вызовы аутентифицируются и атрибутируются. Привязка к одному региону означает и другое: при работе в других регионах allow-list, квоты и данные атрибуции придётся собирать заново, а не копировать.
Чек-лист перед адаптацией blueprint под свою организацию
- Определены ли владельцы каждой модели и каждого инструмента, и совпадает ли это с тем, что видит аудит?
- Задан ли allow-list моделей и регионов отдельно для каждой Workstream-команды?
- Есть ли per-Workstream rate limits, token-квоты и бюджеты, и видит ли команда свои лимиты заранее?
- Проходит ли каждый релиз парные проверки на реальном Runtime: разрешённый вызов успешен, запрещённый отклонён?
- Предусмотрены ли ручное ревью и описанный откат до промоушена в продакшен?
- Видит ли финансовая команда затраты по Workstream, а платформа - здоровье сервисов по аккаунтам?
- Описан ли вывод из эксплуатации до нулевого остатка с автоматической проверкой остатка?
- Какие компоненты вы заменяете и какие проверки для них написаны заново?
Начинать стоит с двух вещей: списка владельцев моделей и инструментов и одной негативной проверки, которая реально отклоняет вызов на живом Runtime. Эти два артефакта показывают, есть ли у платформы контракт или пока только диаграмма.