Amazon Bedrock записывает IAM-принципал, пользователя или роль, для каждого запроса на инференс. Запись идёт автоматически, менять вызовы модели не нужно. Это снимает главную проблему контроля затрат на генеративный AI: счёт раскладывается по конкретным людям, ролям и приложениям, а не выглядит одной строкой «Amazon Bedrock» в биллинге.
Схема, которая закрывает задачу только средствами AWS, делится на три части: атрибуция через теги на IAM-принципале, отчётность в Cost Explorer или CUR 2.0 и принудительное ограничение через AWS Budget с budget action, применяющим Deny-политику при пересечении порога (описание подхода в блоге AWS). Порядок принципиален: без тегов отчётность покажет только общий расход, а без данных отчётности порог бюджета придётся ставить наугад.
Для типового случая писать код не требуется. Кастомный контур на IAM Identity Center, Athena по логам инференса и Lambda даёт почти реальное время, но требует сопровождения кода. Это осознанный размен: точность до минут против операционной нагрузки на команду.
Зачем вообще атрибутировать расходы Bedrock по IAM-принципалам
Строка «Amazon Bedrock» за месяц сообщает, сколько потратил сервис, и молчит о том, кто именно потратил. Когда доступ к моделям есть у десятка разработчиков, у пары внутренних агентов и у аналитиков с ноутбуками, общий счёт невозможно ни объяснить финансовому отделу, ни разложить по командам, ни ограничить точечно: лимит придётся ставить сразу на всех.
Разбивка по принципалам закрывает три задачи. Показывает цену каждой команды и продукта. Ловит аномалии, например забытый агент, который крутит цикл с повторами и жжёт токены ночью. Даёт основание для лимита конкретному потребителю вместо общего стопа для всей компании.
Три части схемы: атрибуция, отчётность, ограничение
- Атрибуция. Principal-теги на IAM-роли, если у каждого человека или приложения своя роль. Session-теги, если роль одна на нескольких людей: они передаются в момент принятия роли и дают детализацию до сессии.
- Отчётность. Cost Explorer с фильтром по сервису и группировкой по тегу для ежедневного взгляда. CUR 2.0 в S3 с запросами через Athena, когда нужен line-item анализ и SQL.
- Ограничение. AWS Budget, ограниченный Amazon Bedrock и отфильтрованный по идентичности или значению тега, плюс budget action, который применяет Deny IAM-политику при пересечении порога.
Части связаны последовательно. Теги без активации как cost allocation tags в отчётность не попадут. Отчётность без тегов не покажет владельца расхода. Бюджет без данных о реальном потреблении превратится в случайное число, которое либо блокирует работу слишком рано, либо не срабатывает вовсе.
Что проверить в аккаунте до настройки
Проверка занимает несколько минут и экономит часы, если чего-то не хватает. Нужны:
- аккаунт AWS с включённым доступом к моделям Amazon Bedrock;
- права на тегирование IAM-принципала, активацию cost allocation tags, создание data exports, бюджетов и budget actions;
- доступ к Bedrock через IAM-роли или IAM-пользователей;
- настроенный AWS CLI с рабочими учётными данными;
- CUR 2.0 data export и S3-бакет, куда он складывается;
- Amazon Athena, если планируются SQL-запросы к экспорту (компонент опциональный).
Отдельный пункт, на котором чаще всего спотыкаются: доступ к AWS Billing Console управляется отдельно от большинства IAM-разрешений, и его наличие нужно подтвердить до того, как вы начнёте настройку. Права администратора в аккаунте сами по себе не гарантируют видимость биллинга.
Первый практический шаг: открыть Cost Explorer, отфильтровать Service по Amazon Bedrock и сгруппировать по доступной идентичности. Так видно, что уже фиксируется без всякой настройки, и где данных не хватает.
Атрибуция: как связать запросы Bedrock с конкретным IAM-пользователем
Выбор между двумя механизмами простой. Если у каждого человека или приложения своя роль, достаточно principal-тегов на роли. Если несколько людей работают через одну роль, по-пользовательская детализация добавляется session-тегами, которые передаются при принятии роли (AWS описывает оба сценария).
Principal-теги на роли: когда у каждого своя роль
Логика простая: роль это принципал, тег на роли это метка расходов этого принципала. Тегирование выполняется на IAM-принципале и требует соответствующих прав. Рабочий набор тегов выглядит примерно так:
owner= конкретный человек или команда-владелец;team= ml-platform, support, research;project= support-bot, doc-search, internal-copilot;cost_center= код из финансовой системы.
После активации этих ключей как cost allocation tags они появляются в Cost Explorer и в CUR 2.0, и расходы Bedrock можно фильтровать и группировать по любому из них. Дисциплина именования важнее количества тегов: если в одном месте написано ml-platform, а в другом ML Platform, отчёт расползётся на две строки, и половина расходов потеряется при группировке.
Session-теги: когда роль одна на нескольких людей
Session-теги передаются в момент принятия роли, поэтому детализация появляется на уровне сессии, а не роли целиком. Это единственный нативный способ развести пользователей внутри одной общей роли без создания роли на каждого. Цена решения: дисциплина передачи тегов ложится на процесс входа. Если вход настроен без тегов или кто-то ходит через обходной путь, в отчёте появится безымянная доля расходов, и разбирать её придётся вручную.
Активация cost allocation tags и необратимость ретроактивности
Порядок шагов такой: тегирование принципалов, затем активация ключей как cost allocation tags, затем ожидание, пока биллинговый конвейер подхватит данные и они появятся в отчётах. Пропуск второго шага самая частая причина фразы «теги стоят, а в отчёте пусто».
Ключевое ограничение: теги не применяются ретроактивно. Расходы, сделанные до тегирования, останутся без разбивки навсегда, восстанавливать их придётся по логам. Поэтому схему включают до того, как счёт станет заметным, а не после первого неприятного инвойса. Это же аргумент начинать с тегирования, а не с бюджета: бюджет на нетегированных данных регулирует только общую сумму.
Отчётность в Cost Explorer: быстрый взгляд без выгрузок
Cost Explorer закрывает ежедневный сценарий. Сервис фильтруется по Amazon Bedrock, группировка ставится по доступной идентичности или по активированному тегу, период выбирается по вкусу: день, неделя, месяц. Данные появляются только после активации cost allocation tags, до этого группировка по тегу просто не предложит нужный ключ.
Этого достаточно, чтобы проверить, кто выбивается из общего ритма, и грубо оценить порядок сумм перед тем, как ставить бюджет. Чего Cost Explorer не даст: детального line-item анализа, разбивки по типам токенов и произвольной SQL-логики. Практичное разделение такое: Cost Explorer остаётся инструментом ежедневного контроля, CUR подключается, когда нужны разрезы по токенам, регионам и моделям.
CUR 2.0 и Athena: детальный анализ расходов Bedrock
Порядок настройки: создать CUR 2.0 data export с включённой caller identity, направить его в S3-бакет, подключить Amazon Athena и работать с экспортом через SQL. Athena здесь опционален: без запросов можно скачивать файлы и разбирать их вручную, но на объёмах это быстро становится неудобным.
Главное ограничение формата: CUR агрегирует данные по часам и не содержит построчных запросов. Почасовые суммы по принципалу, модели и типу использования есть, журнала каждого вызова модели нет. Если нужна трассировка конкретного запроса, придётся смотреть логи приложения или Bedrock, а не биллинг.
Несколько значений product_servicecode
Расходы Bedrock в CUR могут проходить под несколькими значениями product_servicecode. Фильтр по одному значению даёт заниженную сумму, и расхождение с инвойсом потом ищут днями. Начинать стоит с исследовательского запроса: вывести все встречающиеся значения и суммы по ним.
SELECT product_servicecode,
SUM(line_item_unblended_cost) AS cost
FROM cur_bedrock
GROUP BY product_servicecode
ORDER BY cost DESC;Дальше в рабочий фильтр попадают все найденные значения сразу, а не первое из списка. Тот же запрос удобно повторять раз в квартал: набор кодов меняется по мере появления новых возможностей сервиса.
Четыре типа токенов и ставки in-Region vs cross-Region
В данных по Bedrock фигурируют четыре типа токенов: input, output, cache read и cache write. Каждый тарифицируется по своей ставке, поэтому формула «токены умножить на одну цену» не сходится с инвойсом никогда. Кэшированные токены связаны с механизмом prompt caching: как он устроен и почему входные токены при повторной отправке контекста стоят дешевле, разобрано в отдельном материале о prompt caching на Amazon Bedrock.
Вторая переменная, которую легко упустить, это регион. Ставки для in-Region и cross-Region запросов различаются, и один принципал может генерировать оба типа. Как менялся кросс-региональный инференс и что это значит для контроля расходов, мы разбирали в обзоре обновлений Bedrock и AgentCore за август 2026. Практический вывод для SQL: стоимость считается как сумма по типам токенов с учётом региона, иначе отчёт будет красивым, но неверным.
Принудительное ограничение через AWS Budgets и budget actions
Ограничение собирается из двух элементов: бюджет, ограниченный Amazon Bedrock и отфильтрованный по одной идентичности или значению тега, и budget action, который применяет Deny IAM-политику при пересечении порога (схема из блога AWS). Такая конструкция не требует прикладного кода: вся логика живёт в настройках бюджета и IAM.
Как собрать бюджет по Bedrock с фильтром по идентичности или тегу
Сначала бюджет ограничивается сервисом Amazon Bedrock, затем накладывается фильтр. Слишком широкий фильтр превращает персональный лимит в общий стоп для всех, кто пользуется тем же тегом. Слишком узкий оставляет лазейки: лимит стоит на одной роли, а тот же человек ходит через вторую.
Рабочий пример: отдельный бюджет на команду по значению тега team = support с месячным порогом, который выведен из данных Cost Explorer за прошлые периоды. Для сервисных аккаунтов и агентов разумнее отдельные бюджеты по project: у автоматики расход растёт скачками, и смешивать её с людьми в одном лимите неудобно.
Для применения Deny-политики budget action работает от имени IAM-роли, у которой есть права менять политики. Эту роль нужно создать и выдать ей минимально достаточные права заранее, иначе при пересечении порога действие просто не сработает, а узнаете вы об этом по счёту.
Deny-политика и её радиус поражения
Deny-политика на общей роли блокирует всех её пользователей, включая тех, кто лимит не превышал. Это главный риск схемы, и он проявляется в самый неудобный момент: один сотрудник выжег бюджет на эксперимент, доступ к модели пропал у всей команды.
Смягчение зависит от контекста. Отдельные роли на потребителей дают точечную блокировку, но увеличивают число сущностей в IAM. Session-теги и фильтр по ним позволяют держать общую роль, однако Deny-политика всё равно применяется к роли целиком, поэтому выигрыш частичный. Третий вариант: принять командную блокировку сознательно, если цена простоя ниже цены неожиданного счёта. Универсально правильного ответа здесь нет.
Ограничения нативного подхода: что он не умеет
Схему стоит внедрять с открытыми глазами, иначе ожидания руководства не сойдутся с реальностью.
- Бюджеты не работают в реальном времени. Данные обновляются до трёх раз в день, поэтому превышение фиксируется с задержкой. Всплеск за час до обновления успеет потратить заметную сумму.
- Теги не применяются ретроактивно. Расходы до тегирования останутся без разбивки, и восстановить их можно только по логам.
- CUR агрегирует данные по часам и не содержит построчных запросов. Журнала отдельных вызовов модели в биллинге нет.
- Deny-политика на общей роли блокирует всех её пользователей, а не только нарушителя лимита.
- Доступ к Billing Console управляется отдельно от большинства IAM-разрешений, это отдельная строка в чек-листе готовности.
Альтернатива с почти реальным временем существует: контур, где Athena считает дневной расход по логам инференса, а Lambda раз в 15 минут пересобирает IAM-политики и отключает дорогие модели по мере приближения к бюджету. Пример такой архитектуры разобран в материале о per-user AI FinOps для Amazon Bedrock на примере Jamf. Цена точности: код, который вы пишете и дальше сопровождаете.
Вывод без иллюзий: нативный подход закрывает типовой случай за часы настройки и ноль строк кода. Когда нужен контроль с точностью до минуты и точечное отключение конкретного пользователя, придётся строить кастомный контур и считать стоимость его поддержки.
Какой сценарий выбрать: сравнительная таблица
| Сценарий | Что нужно настроить | Когда подходит | Чего не умеет |
|---|---|---|---|
| Быстрая отчётность в Cost Explorer | Ничего, кроме доступа к консоли | Первая оценка расходов и ежедневный контроль | Нет line-item анализа и разбивки по типам токенов |
| Отчётность по командам с тегами | Principal- или session-теги, активация cost allocation tags | Разделение затрат между командами и продуктами | Не работает назад во времени, требует дисциплины входа |
| Детальный анализ через CUR 2.0 | CUR 2.0 data export с caller identity, S3, Athena | Разборы по токенам, регионам и моделям, сверка с инвойсом | Почасовая агрегация, нет журнала отдельных запросов |
| Принудительное ограничение через AWS Budgets | Бюджет по Bedrock с фильтром, budget action с Deny и роль для него | Жёсткий лимит на пользователя, команду или проект | Задержка до трёх обновлений в день, блокировка всей роли |
На практике нужна комбинация, а не один пункт из таблицы. Теги ставятся с первого дня работы с Bedrock, пока расходы малы. Cost Explorer используется для ежедневного контроля. CUR 2.0 подключается под конкретный вопрос, когда суммы перестают сходиться или нужен разбор по типам токенов. AWS Budgets ставится на те идентичности, где превышение бюджета действительно критично, с заранее выбранным ответом на вопрос «что будет, когда Deny сработает на всю команду».