Как отследить затраты на Amazon Bedrock по пользователям через Athena и CUDOS
AWS показала, как настроить детальный учёт расходов на Bedrock через Cost and Usage Reports 2.0 с IAM-идентификацией. Теперь можно видеть, кто именно из команды сколько потратил на вызовы моделей, анализировать через SQL в Athena или готовые дашборды CUDOS. Включение отслеживания IAM-принципалов увеличивает размер отчётов, но даёт полную прозрачность.
Если строишь коммерческий AI-сервис на Bedrock или управляешь большой командой разработчиков, прозрачность затрат — это не опция, а необходимость. Теперь можно честно биллить клиентов или распределять внутренние расходы без самописных решений.
AWS выпустила вторую часть гайда по контролю расходов на Amazon Bedrock. Главное нововведение — поддержка детализации затрат до уровня IAM-пользователя в Cost and Usage Reports 2.0. Раньше видели только общие цифры по сервису, теперь каждый вызов модели привязан к конкретному разработчику или приложению.
Настраиваешь CUR 2.0 с включением caller identity allocation data — в отчётах появляется колонка line_item_iam_principal с ARN того, кто делал запрос. Дальше подключаешь Amazon Athena и пишешь SQL-запросы: кто, какую модель, сколько токенов, сколько денег. Или разворачиваешь готовые дашборды CUDOS через CloudFormation.
Важный нюанс: IAM-детализация раздувает размер отчётов. Одна строка использования превращается в N строк — по одной на каждого пользователя. Для высоконагруженных проектов с десятками разработчиков стоит настроить S3 Lifecycle-политики для старых файлов. Первый отчёт генерируется до 24 часов.
AWS предлагает автоматизацию через Claude Code или Kiro-CLI: клонируешь репозиторий, запускаешь агента, и он сам развернёт окружение и выполнит первый тестовый запрос. Или настраиваешь вручную через консоль — шаги детально расписаны в документации.
Автор: Юлия Тарасова · Источник: aws.amazon.com
Разработчикам. Можно отслеживать расходы на модели в проде по каждому сервису и разработчику, оптимизировать вызовы дорогих моделей, настраивать алерты на аномальные траты через SQL-запросы в Athena.
Бизнесу. Полная прозрачность расходов на AI внутри компании: видно, какие команды и проекты сколько тратят, можно внедрить chargeback и распределять затраты по центрам ответственности, интегрировать с BI-системами для финансовой отчётности.
Инвесторам. AWS усиливает enterprise-функции Bedrock — прозрачность затрат критична для корпоративного внедрения AI. Компании, работающие с мультитенантными AI-приложениями и нуждающиеся в детальном учёте, получают инструмент для контроля unit-экономики.
- Сделать SaaS-платформу на Bedrock с точным биллингом по пользователям — теперь можно честно делить затраты между клиентами без собственной прослойки учёта.
- Построить внутренний chargeback-процесс: каждая команда видит свои расходы на AI, можно вводить лимиты и оптимизировать использование моделей.
- Разработать инструмент мониторинга AI-расходов для enterprise: дашборды с аномалиями, алертами на превышение бюджета, рекомендациями по оптимизации — интеграция с Athena и CUDOS уже готова.
- Консалтинг по оптимизации AI-затрат: помогать компаниям настраивать CUR 2.0, строить отчётность, находить узкие места в использовании дорогих моделей.
- Маркетплейс готовых SQL-запросов и дашбордов для Bedrock-аналитики — многие enterprise-команды платят за экономию времени на настройке.
- Это не прорыв, а базовая enterprise-функция — большинство AI-провайдеров давно дают детализацию по пользователям. AWS просто догоняет.
- Увеличение размера CUR-файлов может неприятно удивить затратами на хранение и обработку в S3 и Athena при высоких нагрузках.
- Сложность настройки для небольших команд: нужны IAM-права, понимание CUR, знание SQL — порог входа выше, чем у простых дашбордов в UI.
- Задержка до 24 часов на первый отчёт — для быстрых экспериментов и оптимизации в реальном времени не подходит.
Это не инновация, а базовая enterprise-гигиена, которой не хватало Bedrock с запуска. Для больших команд и B2B-сервисов — must have: без прозрачности затрат невозможно масштабироваться и честно биллить клиентов. Для стартапов и экспериментаторов — оверкилл: настраивать CUR, IAM, Athena ради пары запросов в день смысла нет.
Главный подвох — раздутие отчётов. Если у вас 50 разработчиков молотят модели весь день, размер CUR может вырасти в разы. AWS молчит про реальные цифры, но S3 и Athena-запросы — это тоже деньги. Плюс задержка до суток на первый отчёт убивает идею оперативной оптимизации. В итоге это инструмент для месячной аналитики и аудита, а не для реалтайм-контроля бюджета.
Инструменты из статьи
Агентный кодинг в терминале от Anthropic: сам пишет, тестирует и правит код...
Доступ из РФ →
Комментарии