AWS выложила шаблон data lake для Bedrock: видно каждый промпт, токен и его цену

Знакомая история: в конце месяца приходит счёт за Bedrock, сумма выросла, а ответить на вопрос «кто и почему» нельзя. Агрегат виден, содержимого вызовов нет. Непонятно, какой промпт ушёл, что вернула модель и сколько токенов она съела. AWS предлагает готовое решение: центральное озеро данных для всех вызовов Bedrock в организации. Шаблоны CloudFormation, код Lambda и SQL-запросы лежат в репозитории AWS Sample Bedrock Invocation Data Lake.

Что есть из коробки и чего не хватает

У Bedrock есть model invocation logging. Он пишет полный след запросов и ответов в S3 или CloudWatch. Но включается он отдельно в каждом аккаунте, и данные остаются там же. Если аккаунтов десяток, получается десяток изолированных островов. Сравнить команды, найти расточительный промпт или разобрать всплеск расходов по ним трудно.

Как устроен пайплайн

Путь каждого вызова состоит из пяти этапов:

• Bedrock в аккаунте-источнике пишет лог в группу CloudWatch.
• Subscription filter работает как постоянное правило пересылки: каждое новое событие уходит в CloudWatch Logs destination в центральном аккаунте. Источники не получают прав на центральный пайплайн, они только отдают события.
• Небольшая Lambda распаковывает пакеты CloudWatch, которые приходят сжатыми и закодированными. Она отбрасывает служебный шум вроде сообщения «Permissions are correctly set» и поднимает вложенное поле с идентичностью вызывающего на верхний уровень.
• Amazon Data Firehose буферизует записи, конвертирует JSON в Parquet и кладёт в S3 по датам (year/month/day).
• Таблица Glue объясняет Athena, как читать эти файлы, и дальше работает обычный SQL.

В итоге в одной таблице у каждого вызова есть промпт, ответ, число входных и выходных токенов, модель, причина остановки, аккаунт, время и IAM-роль. Это уже не «мы потратили X токенов», а «вот что было в каждом вызове».

Что с этим делать на практике

Вот несколько сценариев из поста:

• Отладка. Достаёте точный промпт и ответ конкретного вызова без раскопок в сырых логах.
• Эффективность. Сравниваете input и output токены по командам и моделям и находите, где токены уходят впустую.
• Промпт-инжиниринг. Ищете ответы с stop_reason = max_tokens: их обрезало, значит, промпт или конфиг стоит доработать.
• Стоимость. Таблица джойнится с AWS Cost and Usage Report 2.0 по IAM ARN, и появляются расходы по командам и дням, а также цена самых неэффективных вызовов.

Для наглядности есть дашборд в Quick Sight, он ставится командой cid-cmd deploy. В него можно добавить метаданные организации, например названия команд.

Авторы связывают всё это с tokenomics: по их словам, на конференции FinOps Foundation в 2026 году её объявили отдельным доменом FinOps. Логика проста: токены нельзя оптимизировать, пока их не измерили. Озеро даёт именно эту базу.

Ограничения и подводные камни

Главный риск — безопасность. Вы складываете полные промпты и ответы всех команд в один бакет, а в них может быть PII. Бакет шифруется через KMS, но доступ к нему и к результатам Athena нужно ограничить IAM-политиками самостоятельно.

Есть и операционные нюансы:

• Логирование Bedrock — настройка уровня аккаунта, а не ресурс CloudFormation. Её нужно включить отдельным API-вызовом в каждом источнике, и только с доставкой в CloudWatch.
• Данные появляются не мгновенно: Firehose сбрасывает буфер примерно через минуту, иногда дольше. Для расследований это нормально, для алертов в реальном времени — нет.
• Представление в Athena создаётся вручную: сохранённый запрос нужно выполнить один раз.
• Джойн со стоимостью идёт по IAM ARN. Если все команды ходят в Bedrock под одной ролью, разбивка по ним получится условной. Это наш вывод, в посте он напрямую не обсуждается.
• При удалении сначала опустошите бакеты, а Athena workgroup удалите вручную.

Вывод

Если у вас Bedrock в нескольких аккаунтах и вы не можете сказать, какая команда сжигает больше токенов, шаблон стоит развернуть. Совет авторов: не пытайтесь охватить всё сразу. Начните с одного-двух аккаунтов, освойте запросы к таблице и только потом расширяйте на организацию. Заодно проверьте IAM-политики и бакет, пока данных там ещё немного.