Управляйте затратами в Amazon Bedrock по клиентам

<div> <p>Представьте сервис SaaS с генеративным ИИ, где десятки клиентов запускают модели одновременно, а счет за облако растет как снежный ком. Знакомо? AWS представила способ держать расходы под контролем — application inference profiles для Amazon Bedrock.</p> <h2>Гранулярная отчетность по каждому клиенту</h2> <p>Application inference profiles позволяют помечать каждый запрос к модели метками вроде <code>TenantID</code> или <code>ApplicationID</code>. Эти тэги идут вместе с API-вызовом, и вы сразу видите: вот расходы клиента А, а вот клиента Б. Никаких усреднённых цифр — только точные данные по каждому профилю.</p> <h2>Как устроено решение</h2> <p>AWS поставила готовый шаблон на GitHub. Он развёртывает две «учётные записи» с разными профилями. Всё это упаковано в CloudFormation: профили, лямбды для обработки запросов, API Gateway, CloudWatch-дашборды и уведомления через SNS. Запускаете скрипт <code>setup.py</code> — и система готова.</p> <h2>Дашборды и тревоги</h2> <p>CloudWatch строит графики по каждому профилю: стоимость токенов, запросы в минуту, затраты за пятиминутку. При превышении порогов SNS шлёт письмо администратору. Зеленый статус — всё в норме; жёлтый — внимание; красный — пора разбираться.</p> <h2>Почему это важно</h2> <p>Без такого подхода операции ловят только «чёрно‑белые» сигналы и реагируют слишком поздно. А тут — раннее предупреждение, чёткая привязка затрат и возможность гибко менять тэги для новых команд или проектов.</p> <h2>На что обратить внимание</h2> <p>API Gateway обрывает запросы дольше 30 секунд, а лямбды умеют ждать до 15 минут. Учитывайте лимиты размера заголовков и payload — не более 6 МБ при синхронном вызове. Если превысите — будете получать ошибки.</p> <h2>Что дальше?</h2> <p>Попробуйте запустить готовый пример из GitHub, настройте пороги под свои нужды и дайте обратную связь AWS в комментариях блога. Так вы сможете не просто следить за расходами, а реально управлять бюджетом сервиса.</p> </div>