Amazon Bedrock ajoute une attribution détaillée des coûts d’inference par utilisateurs et applications

AWS 17 апреля 2026 года запустила для Amazon Bedrock функцию granular cost attribution — детальный учет расходов на inference. Теперь расходы можно автоматически привязывать к конкретному пользователю, приложению, IAM-роли или tenant-у, не меняя существующие сценарии вызова моделей.

Как это работает

Bedrock начал передавать в AWS Billing данные о том, какой IAM principal отправил запрос к модели. Это может быть обычный IAM-пользователь, роль приложения, временная федеративная сессия через Okta или Entra ID, а также Bedrock API key, если он связан с IAM-идентичностью. В отчете CUR 2.

0 появляется поле line_item_iam_principal, а по line_item_usage_type можно понять, какая модель использовалась, в каком регионе и на какие токены ушли деньги — входные или выходные. Поверх этого AWS предлагает подключать cost allocation tags. Их можно вешать напрямую на IAM-пользователей и роли либо передавать как session tags при федеративной авторизации и AssumeRole.

После активации в биллинге такие теги попадают и в CUR 2.0, и в Cost Explorer, где расходы уже можно собирать по команде, проекту, cost center или tenant-у. Сама функция доступна в коммерческих регионах без доплаты, но для нее нужно включить экспорт IAM principal в CUR 2.

0 и дождаться появления тегов в течение 24–48 часов.

«Понимание того, кто именно тратит деньги на inference, — первый шаг к

chargeback, прогнозированию и оптимизации».

Четыре сценария учета AWS описывает четыре типовых схемы, в которых

новая атрибуция особенно полезна. Логика одна: кто вызывает Bedrock, тот и становится единицей учета. Но способ разметки зависит от того, работает ли с моделями человек, сервис, корпоративная SSO-сессия или общий LLM-шлюз.

Разница важна, потому что именно от этого зависит, где будут храниться идентификатор вызывающей стороны и теги для последующей агрегации затрат в отчетах и алертах. IAM users и API keys — подходит для небольших команд и прототипов: можно видеть траты каждого разработчика отдельно. IAM roles для приложений — удобно для продакшн-сервисов: расходы делятся по backend-ам, батч-джобам и проектам.

Federated users через IdP — корпоративные пользователи видны по session name и тегам из SAML или OIDC. LLM gateway или proxy — для SaaS и внутренних AI-платформ, где нужен разрез по пользователям и tenant-ам, а не одна общая строка на весь шлюз. Самый нетривиальный вариант — gateway.

Если прокси ходит в Bedrock под одной ролью, биллинг увидит только эту роль и потеряет детализацию. AWS предлагает решать это через AssumeRole на каждого пользователя или tenant-а с передачей role-session-name и тегов. Полученные креденшалы можно кешировать до часа, поэтому модель не требует вызывать STS на каждый запрос.

По умолчанию лимит STS для AssumeRole — 500 вызовов в секунду на аккаунт, и это важно учитывать в high-throughput системах.

Практический эффект для команд

Для FinOps и AI-платформ это закрывает давнюю дыру: раньше Bedrock-расходы часто видели только на уровне аккаунта или одного сервисного пользователя, а дальше приходилось строить собственный слой логирования и разносить затраты вручную. Теперь AWS дает нативный механизм chargeback и showback через те же IAM-идентичности и теги, которые компании уже используют для доступа и governance. Отдельный плюс — можно быстро понять, кто тянет дорогие модели вроде Opus, кто сидит на более легких конфигурациях, и где бюджет съедают именно output tokens.

Для engineering-команд ценность не только в финансах. Если у каждого микросервиса своя роль, а у сотрудников — своя федеративная сессия, то один и тот же механизм одновременно усиливает безопасность и прозрачность. В multi-tenant SaaS это особенно полезно: можно сравнивать стоимость обслуживания клиентов, строить внутренние тарифы и ставить алерты в Cost Explorer по тегам.

По сути AWS превращает идентичность вызова модели в полноценную финансовую метку, с которой уже можно строить отчеты без отдельного data pipeline.

Что это значит

Amazon Bedrock становится заметно удобнее для компаний, которые масштабируют GenAI не на десятки демо-запросов, а на реальные команды, сервисы и клиентов. Чем больше у бизнеса AI-трафика, тем важнее видеть не просто общий счет, а конкретного источника расходов.