Amazon Bedrock записывает IAM-идентичность каждого, кто вызывает инференс. Правок в API-запросах для этого не требуется: при обращении к модели через эндпоинт bedrock-runtime или bedrock-mantle сервис фиксирует полный IAM ARN вызывающего, включая имя сессии федеративного пользователя, и публикует его в отчёте CUR 2.0 в колонке line_item_iam_principal. В блоге AWS схема атрибуции описана именно так: идентичность попадает в биллинг сама, инструментировать клиент не нужно.
Механизм работает на уровне эндпоинта, ниже логики конкретного инструмента. Claude Code, Claude Desktop, OpenAI Codex, ChatGPT Work и OpenCode обращаются к Bedrock через один из двух эндпоинтов инференса, поэтому атрибуция для них выглядит одинаково. Идентичность настраивается один раз, и каждый новый инструмент, который маршрутизирует инференс через Bedrock, наследует видимость затрат по пользователям автоматически.
Ниже практическая сборка схемы: IAM Identity Center с внешним IdP, permission set, session-теги, запросы Athena к CUR 2.0 и уровни контроля лимитов. Границу обозначим сразу: стоимости отдельного запроса в CUR нет, и это меняет то, что можно пообещать финансовому отделу.
Как Bedrock атрибутирует расходы без изменений в коде
Атрибуция встроена в слой эндпоинта. Клиент отправляет обычный запрос на инференс, а Bedrock рядом с ним сохраняет ARN роли или пользователя, под которым этот запрос авторизован. Для федеративного пользователя ARN выглядит примерно так: arn:aws:sts::123456789012:assumed-role/AWSReservedSSO_BedrockDev_1a2b3c/ivan.petrov@example.com. Имя сессии в конце и есть тот самый признак, по которому расходы разделяются по людям.
Из этого следуют три практических вывода. Первый: одна и та же настройка работает для всех инструментов, потому что они не участвуют в атрибуции. Второй: если инструмент ходит под общей ролью или общим статическим ключом, в CUR вы увидите одну строку на всех, и никакая постобработка не вернёт разбивку по фамилиям. Третий: имя сессии должно быть стабильным и уникальным для человека, иначе строки в отчёте начнут склеиваться или, наоборот, дробиться на несколько principal.
Идентичность идёт вместе с организационными тегами в CUR 2.0 и Cost Explorer, данные при этом остаются внутри периметра AWS. Для согласования с безопасностью это весомый аргумент: не нужно вывозить телеметрию в сторонний SaaS, чтобы узнать, кто сжёг бюджет.
Четыре паттерна доступа и почему для AI-инструментов подходит федерация
AWS описывает четыре паттерна доступа к Bedrock: IAM-пользователи, роли на приложение, федеративные идентичности и LLM-шлюзы, проксирующие запросы. В разборе AWS для AI-инструментов разработки и продуктивности выбран паттерн федеративных идентичностей: каждый разработчик или работник знаний аутентифицируется лично и получает собственный principal.
| Паттерн | Что видно в биллинге | Где уместен |
|---|---|---|
| IAM-пользователи | Отдельный ARN на человека | Небольшие команды, но требует длинных статических ключей |
| Роль на приложение | Один principal на всех пользователей приложения | Сервисные сценарии без людей в контуре |
| Федеративные идентичности | ARN с именем сессии на каждого пользователя | Claude Code, Codex, OpenCode и другие рабочие инструменты |
| LLM-шлюз | Principal шлюза, разбивка по людям живёт в учёте шлюза | Централизованные квоты и блокировки на каждый вызов |
Главный минус общих креденшелов в том, что все затраты схлопываются в один principal, и пофамильная разбивка становится невозможной в принципе. Паттерны при этом комбинируются: федерация для людей, шлюз для сервисных и агентных сценариев, отдельная роль для CI/CD-прогонов.
Настройка IAM Identity Center и внешнего IdP для персональных principal
Схема собирается из четырёх шагов.
- Подключить внешний IdP к IAM Identity Center. Okta, Entra ID и Ping интегрируются по SAML или OIDC, после чего пользователи и группы приходят из корпоративного каталога, а не создаются руками в AWS.
- Создать permission set с доступом к Bedrock и назначить его на нужные группы. Права выдаются на уровне permission set, а не персональными политиками, иначе сопровождение быстро превращается в ручную работу.
- Проверить, что при входе пользователь получает ARN роли с именем сессии, содержащим его идентификатор из IdP. Это и есть ключ группировки в CUR.
- Настроить срок жизни сессии под рабочий день. Слишком короткая сессия означает частые переподключения инструментов, слишком длинная расширяет окно, в котором уволенный сотрудник сохраняет доступ.
Выдача прав отдельному человеку важна ещё и для контроля: Deny-политика или ограничение на дорогие модели применяются к конкретному principal, а не блокируют всю команду. Нативная схема контроля расходов по IAM-принципалам разобрана отдельно: там про principal-теги, Cost Explorer, CUR 2.0 с Athena и бюджеты с Deny-политикой при превышении порога.
Session-теги: команда и кост-центр как разрезы в CUR 2.0
Теги можно прикреплять к IAM-принципалам или передавать как session-теги при федерации. Они появляются в CUR 2.0 с префиксом iamPrincipal/ и в Cost Explorer как фильтруемые измерения, поэтому команда и кост-центр становятся полноценными осями отчёта, а не текстовыми пометками в таблице. AWS описывает оба способа, и выбор между ними простой: то, что не меняется у человека годами (кост-центр, продукт), удобнее вешать на principal, а то, что зависит от контекста входа (конкретный проект или команда в текущей сессии), передавать как session-тег.
Ограничение, которое ломает планы чаще всего: активация тегов не ретроактивна. Расходы, сделанные до включения тега, не пересчитаются, и в отчёте появится дыра за прошлые периоды. Набор тегов и их значения нужно заложить до первого продакшн-запуска инструментов, иначе первый же отчёт по кост-центрам будет наполовину пустым.
Конфигурация рабочих станций для Claude Code, Codex и других инструментов
Со стороны инструмента требуется одно: получать креденшелы пользователя из Identity Center, а не из статического ключа в переменной окружения. Практически это означает, что на машине настроен профиль входа через SSO, а инструмент использует стандартную цепочку поиска учётных данных AWS. Конкретные флаги и переменные отличаются от инструмента к инструменту, поэтому проверять их нужно по документации самого инструмента, а не по универсальному шаблону.
Что должно получиться на выходе: в биллинге появляются строки с ARN, в котором видно имя человека. Проверка занимает минуту: попросите двух сотрудников сделать по одному вызову и посмотрите на разные значения line_item_iam_principal в свежем экспорте. Если principal одинаковый, дальше настраивать отчёты бессмысленно, сначала нужно чинить идентичность.
Отдельная головная боль - фоновые и агентные процессы, которые работают дольше сессии. Им нужна либо отдельная роль с понятным именем, либо обновление креденшелов без смены имени сессии, иначе расходы начнут расползаться по нескольким principal у одного и того же человека.
Отчёты в CUR 2.0 и Athena: расходы по пользователям и кост-центрам
CUR 2.0 выгружается в S3 и читается через Athena или другой SQL-движок поверх тех же файлов. Ключевые колонки для задачи: line_item_iam_principal как идентификатор пользователя, стоимость использования, дата начала использования и код сервиса для фильтра по Bedrock. Использование в отчёте агрегировано по principal и типу использования за каждый интервал экспорта: один час при часовом экспорте и один день при дневном.
Быстрый путь без выгрузки - Cost Explorer с фильтром по session-тегам. Он годится для проверки гипотезы и разговора с руководителем, но не для регулярной финансовой отчётности: детализацию по людям и произвольные срезы удобнее строить в Athena.
Запрос Athena: стоимость по пользователям
Каркас запроса за период выглядит так:
SELECT
line_item_iam_principal AS principal,
round(sum(line_item_unblinded_cost), 2) AS cost_usd
FROM cur2_bedrock
WHERE product_servicecode = 'AmazonBedrock'
AND line_item_usage_start_date >= DATE '2026-10-01'
GROUP BY 1
ORDER BY cost_usd DESC
LIMIT 100;Имя таблицы и точное значение кода сервиса зависят от настроек экспорта в конкретном аккаунте, их стоит сверить перед запуском (SHOW COLUMNS по таблице покажет реальный набор колонок). Если в отчёте нужны только люди, добавьте фильтр по формату ARN или исключите роли сервисных процессов, иначе верхние строки займут CI/CD и агенты.
Запрос Athena: разбивка по кост-центрам и командам
Второй запрос группирует те же данные по тегу кост-центра:
SELECT
resource_tags_iamprincipal_cost_center AS cost_center,
count(DISTINCT line_item_iam_principal) AS users,
round(sum(line_item_unblinded_cost), 2) AS cost_usd
FROM cur2_bedrock
WHERE product_servicecode = 'AmazonBedrock'
AND line_item_usage_start_date >= DATE '2026-10-01'
GROUP BY 1
ORDER BY cost_usd DESC;Имя колонки тега собирается из ключа и настроек экспорта, поэтому проверьте его в описании таблицы. Третий запрос решает обратную задачу, сопоставляет пользователя с командой и показывает, кто остался без тега:
SELECT
line_item_iam_principal AS principal,
max(resource_tags_iamprincipal_team) AS team,
round(sum(line_item_unblinded_cost), 2) AS cost_usd
FROM cur2_bedrock
WHERE product_servicecode = 'AmazonBedrock'
GROUP BY 1
ORDER BY cost_usd DESC;Пустое значение в колонке команды - сигнал, что федерация настроена не полностью: кто-то ходит под ролью без тега или под общим ключом. Такие строки полезно выводить отдельным блоком, это самый быстрый способ найти дыры в схеме.
Контроль лимитов: от Budgets до блокировки на каждый вызов
Отчётность отвечает на вопрос «кто потратил», но не мешает потратить. Уровни контроля различаются скоростью реакции, и их стоит наслаивать, а не выбирать один.
| Уровень | Задержка реакции | Что даёт | Чего не делает |
|---|---|---|---|
| AWS Budgets | До суток | Оповещение и автоматические действия при выходе за порог | Не останавливает расход, который уже идёт |
| CloudWatch-алерт с Lambda | 1-5 минут | Быстрая реакция на всплеск, автоматическое сужение доступа | Работает постфактум, после первых дорогих вызовов |
| Счётчики в DynamoDB на аутентификации | Секунды | Учёт и отсечение до выдачи доступа к модели | Грубее, чем учёт на каждом вызове |
| LLM-шлюз | На каждый вызов | Блокировка и квота до расхода токенов | Добавляет компонент и точку отказа |
AWS Budgets с задержкой до суток годится для оповещения, а не для остановки: к моменту срабатывания счёт уже выставлен. Бюджет с budget actions, который навешивает Deny-политику на превысившего лимит, полезен как страховка от забытого эксперимента, но исходить из того, что он сработает мгновенно, нельзя.
Связка CloudWatch и Lambda даёт задержку в 1-5 минут: алерт по метрике или расписанию запускает функцию, которая считает расход и меняет доступ к дорогим моделям. Архитектура per-user FinOps с обновлением ограничений каждые 15 минут показывает рабочую реализацию такого цикла, включая tiered enforcement и стоимость запросов в Athena. Слабое место схемы в том, что она реактивна: между всплеском и реакцией успевает пройти несколько дорогих сессий.
Счётчики в DynamoDB на уровне аутентификации позволяют отказать в доступе до вызова модели: пользователь получает временные креденшелы только при положительном остатке квоты. Это дешевле и проще, чем шлюз, но точность ограничена моментом выдачи доступа: внутри одной сессии человек всё ещё может потратить больше запланированного.
LLM-шлюз как точка атрибуции и тормоза
Четвёртый паттерн доступа из разбора AWS - шлюз, который проксирует запросы к Bedrock. Он видит каждый вызов и может считать токены, применять квоты по пользователю и блокировать расход до того, как он случится. Для федеративной схемы это совместимый вариант: шлюз получает principal пользователя и применяет лимиты по нему, а не по общему ключу.
Компромисс очевиден: в архитектуре появляется ещё один компонент со своими таймаутами, масштабированием и режимом отказа. Сборка self-service LLM-шлюза на Bedrock и LiteLLM показывает, из чего складывается такая система и какие поля стоимости нужно заполнить, чтобы бюджеты вообще срабатывали. Если задачи ограничены отчётностью, шлюз не нужен; если нужны жёсткие лимиты на вызов, без него не обойтись.
Ограничения метода: что CUR 2.0 не покажет
Список короткий, но его нужно проговорить до запуска, а не после первого счёта.
- CUR не содержит стоимости отдельного запроса. В отчёте есть сумма за интервал по principal и типу использования, но не разбивка по конкретным промптам.
- Использование агрегировано по principal и типу использования за интервал экспорта: один час при часовом экспорте и один день при дневном. Пики внутри интервала не видны.
- Теги не применяются ретроактивно. Включили кост-центр в середине месяца, значит первая половина месяца останется без разреза.
- Атрибуция по IAM-принципалу не единственный механизм в Bedrock, но сравнение дополнительных механизмов в исходном разборе не раскрыто, и подменять его догадками не стоит.
Данные при этом не покидают периметр AWS, что снимает часть вопросов службы безопасности и упрощает согласование доступа к отчётам.
Когда нужны логи вызовов моделей
За пределы биллинга пора выходить в трёх случаях: нужно разобрать дорогой промпт, найти причину аномалии за конкретный час или восстановить картину инцидента по одному пользователю. Для этого служат логи вызовов моделей и тегирование метаданных запросов: они дают детализацию, которой в CUR нет по определению.
У этого контура своя цена: объём хранения, требования к сроку жизни логов и вопрос, не попадают ли в них персональные данные из промптов. Решение о включении логов стоит принимать вместе с безопасностью, а не как техническую мелочь.
Порядок внедрения: что сделать первым
Последовательность важнее полноты. Сначала Identity Center и внешний IdP с персональными principal: без этого остальные шаги не имеют смысла. Затем permission set с доступом к Bedrock и настройка рабочих станций, чтобы инструменты получали креденшелы через SSO. Затем session-теги и значения кост-центров, причём до первого продакшн-запуска, потому что задним числом они не применятся.
После этого включается отчётность: экспорт CUR 2.0 с нужными колонками, пара запросов в Athena и сверка с Cost Explorer. И только в конце наращиваются уровни контроля по возрастанию скорости реакции, от бюджета-оповещения до шлюза с блокировкой на каждый вызов, в том порядке, в котором растёт цена ошибки.
Настройка делается один раз, новые инструменты наследуют видимость затрат автоматически. Ограничения CUR при этом никуда не исчезают, поэтому разговор с финансовым отделом лучше вести заранее: пофамильный учёт будет, стоимости отдельного запроса не будет. Если планируете следить за новыми возможностями Bedrock в части контроля расходов, пригодятся обновления Bedrock и AgentCore за август 2026 с разбором ограничений и чек-листом перед изменениями в проде.