Как Amazon Bedrock сам следит за своими лимитами: разбор Ops Alert для продакшена

Что нового

Amazon запустила Amazon Bedrock Ops Alert — готовое решение для автоматического мониторинга генеративных нагрузок на Bedrock. Оно собирает метрики, отслеживает лимиты, само подстраивает пороги алертов и при необходимости открывает тикеты в AWS Support.

Ключевые возможности:

• Три слоя мониторинга для генеративных сценариев на Bedrock:
  • критические ошибки (throttling, 4xx, 5xx);
  • использование лимитов по запросам в минуту (RPM) и токенам в минуту (TPM), плюс задержки;
  • аномалии по запросам, токенам и латентности на базе ML в Amazon CloudWatch.
• Автоматический пересчёт порогов алертов после изменения квот через Service Quotas API. Пример: при квоте 10 000 RPM и пороге 80% алерт сработает на 8 000 запросов в минуту.
• Автоматическое создание тикетов в AWS Support (нужен тариф Business или Enterprise):
  • отдельные сценарии для RPM‑проблем, TPM‑проблем и «непонятных» ограничений;
  • отдельный сценарий для инцидентов, не связанных с квотами (ошибки 5xx, резкий рост латентности).
• Защита от дубликатов тикетов: Ops Alert проверяет, есть ли активный тикет по тому же типу проблемы за последние 60 дней, и при необходимости просто дописывает обновление в уже открытый кейс.
• Контекстные уведомления по email: письма уходят через Amazon SNS и содержат ID тикета, ссылку в консоль AWS Support, метрики за последние 14 дней и оценку серьёзности (critical / warning).
• Автоматическая работа с глобальными нагрузками: решение учитывает сценарии кросс-регионального и глобального инференса в Bedrock и помогает не закручивать квоты «на глаз».

Ops Alert работает поверх стандартных сервисов AWS: Amazon CloudWatch, AWS Lambda, Amazon SNS, AWS Systems Manager Parameter Store, AWS Secrets Manager, AWS Service Quotas и AWS Support API. Деплой — через AWS CloudFormation.

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

Общая архитектура

Ops Alert — это CloudFormation‑шаблон, который разворачивает цепочку из Lambda‑функций, CloudWatch‑алармов и SNS‑топиков. Вся логика крутится вокруг трёх слоёв мониторинга и одного «композитного» аларма.

Базовый цикл такой:

1. Деплой стека:

   • Lambda Quota Calculator запрашивает текущие квоты Amazon Bedrock по RPM и TPM через Service Quotas API.
   • На основе заданных процентов (например, 80%) считает пороги для алертов.
   • Сохраняет пороги в AWS Systems Manager Parameter Store.
   • Сохраняет email‑контакты AI SRE‑команды в AWS Secrets Manager.

2. Сбор метрик:

   • Amazon Bedrock публикует в CloudWatch метрики: количество вызовов, количество токенов, ошибки, throttling, латентность.
   • Для генеративных сценариев Bedrock поддерживает кросс-региональный и глобальный инференс. Метрики учитывают реальные запросы, включая кэширование промптов и токены для записи в кэш.

3. Три слоя мониторинга:

   • Layer 1 — критические ошибки:
     • ClientErrors следит за InvocationClientErrors (проблемы на стороне клиента: превышение квоты, валидация, неверные параметры).
     • ServerErrors следит за InvocationServerErrors (ошибки на стороне сервиса Bedrock).
     • Throttles следит за InvocationThrottles (Bedrock явно ограничил скорость запросов).
   • Layer 2 — использование лимитов и латентность:
     • HighInvocationRate следит за Invocations и срабатывает, когда фактический RPM превышает заданный процент квоты.
     • HighTPMQuotaUsage следит за EstimatedTPMQuotaUsage — оценкой потребления TPM с учётом токенов записи в кэш и множителей на вывод.
     • HighLatency следит за InvocationLatency и реагирует на превышение порога по времени ответа.
   • Layer 3 — аномалии (CloudWatch ML):
     • InvocationAnomaly анализирует Invocations и ловит нетипичные всплески.
     • InputTokenAnomaly смотрит на InputTokenCount.
     • OutputTokenAnomaly — на OutputTokenCount.
     • LatencyAnomaly — на InvocationLatency.

   CloudWatch строит «нормальный» коридор значений по истории и реагирует только на рост метрик выше верхней границы. Падение нагрузки система считает нормальным и не тревожит команду.

4. Композитный аларм и обработка:

   • Все дочерние алармы входят в один composite alarm.
   • Как только хотя бы один из них переходит в состояние ALARM, composite alarm публикует сообщение в SNS‑топик Raw Alarm Topic.
   • SNS вызывает Lambda‑функцию notification processor.

5. Lambda‑обработчик алертов:

   • Опрашивает composite alarm, чтобы понять, какие именно дочерние алармы сработали.
   • Определяет серьёзность (critical / warning).
   • Запрашивает через Service Quotas API актуальные значения RPM и TPM.
   • Через CloudWatch получает:
     • текущие значения метрик;
     • пиковые RPM/TPM за последние 14 дней;
     • среднее количество токенов на запрос.
   • Читает пороги из Parameter Store и сравнивает пиковые значения с ними.
   • Определяет сценарий: проблема с квотой или инфраструктурная/сервисная ошибка.

6. Работа с AWS Support (опционально):

   • Если авто‑создание тикетов включено, Lambda:
     • классифицирует аларм как квотный или не квотный;
     • проверяет через Support API, есть ли активный тикет той же категории за последние 60 дней;
     • если есть — добавляет в него новое сообщение с деталями алерта и свежими метриками;
     • если нет — создаёт новый тикет.

   Для квотных сценариев тикет содержит уже посчитанные значения RPM/TPM и историю использования за 14 дней. Для не квотных — описание проблемы, метрики и контекст, который полезен для поиска причины.

7. Email‑уведомления:

   • После обработки тикета Lambda отправляет структурированное уведомление во второй SNS‑топик Formatted Notification Topic.
   • Подписчики получают письма в зависимости от настроек фильтрации: все события, только критические или только предупреждения.
   • Если тикет в AWS Support создан, письмо содержит его ID и прямую ссылку в консоль.

8. Автообновление порогов:

   • Amazon EventBridge по расписанию (по умолчанию раз в сутки) запускает Lambda Alarm Updater.
   • Она снова запрашивает квоты через Service Quotas API.
   • Пересчитывает пороги по тем же формулам и обновляет CloudWatch‑алармы.
   • Сохраняет новые пороги с таймстампами в Parameter Store — получается история изменений.

Формулы порогов

Пороги завязаны на реальные квоты Bedrock:

• RPM‑порог:

RPM_threshold = RPM_quota × (RequestsPerMinuteThresholdPercent / 100)

Пример: квота 10 000 RPM, порог 80% → алерт на 8 000 запросов в минуту.

• TPM‑порог:

TPM_threshold = TPM_quota × (TokensPerMinuteThresholdPercent / 100)

Пример: квота 6 250 000 TPM, порог 80% → алерт на 5 000 000 токенов в минуту.

Для проверки сценариев Lambda сравнивает пиковое TPM за 14 дней с этим порогом.

Классификация алармов и тикетов

Ops Alert делит события на четыре типа:

1. RPM‑специфичные:

   • HighInvocationRate, InvocationAnomaly.
   • Создаётся тикет типа Quota Request только на увеличение RPM.

2. TPM‑специфичные:

   • HighTPMQuotaUsage, InputTokenAnomaly, OutputTokenAnomaly.
   • Создаётся Quota Request только на увеличение TPM.

3. Неясные квотные:

   • Throttles, ClientErrors.
   • Запрашивается увеличение и RPM, и TPM, чтобы инженер поддержки мог разобраться, что именно упёрлось в лимит.

4. Не квотные:

   • ServerErrors, HighLatency, LatencyAnomaly.
   • Создаётся тикет типа Investigation Request, без просьбы поднять квоты. В тикете — контекст, метрики и условия срабатывания аларма.

Перед созданием квотного тикета система всегда смотрит на пиковую нагрузку за 14 дней. Это позволяет сформулировать запрос по делу: когда нагрузка действительно приблизилась к порогу, а не упала в него случайно.

Что это значит для вас

Кому это нужно

Ops Alert полезен, если вы:

• запускаете генеративные продукты на Bedrock в продакшене (чат‑боты, ассистенты, контент‑генерация, RAG‑сервисы);
• работаете с несколькими foundation‑моделями и регионами, включая кросс-региональный и глобальный инференс;
• уже упирались в лимиты RPM/TPM и вручную открывали тикеты в AWS Support;
• хотите сократить время реакции SRE‑команды и перестать узнавать о проблемах от бизнес‑пользователей.

Если вы только экспериментируете с Bedrock на небольших объёмах, выгода от Ops Alert будет минимальной. CloudWatch‑графиков и пары ручных алармов достаточно, пока трафик не растёт и квоты не меняются.

Где это помогает

1. Пики нагрузки и рост продукта

При масштабировании генеративного сервиса нагрузка растёт неравномерно. Без автоматизации команда:

• вручную смотрит на графики CloudWatch;
• оценивает, когда запросить увеличение квот;
• пересчитывает пороги для каждого аларма после одобрения квот.

Ops Alert делает это сам:

• отслеживает использование RPM и TPM относительно квот;
• заранее шлёт предупреждения, когда вы приближаетесь к 80% (или другому порогу);
• автоматически поднимает пороги после изменения квот.

2. Кросс-региональный и глобальный инференс

Bedrock позволяет:

• использовать кросс-региональный инференс в рамках географии — сервис сам выбирает оптимальный регион;
• включать глобальные профили инференса, которые отправляют запросы в любые коммерческие регионы AWS.

Глобальный инференс даёт:

• доступ к гораздо большему пулу ресурсов;
• снятие узких мест по отдельным регионам;
• около 10% экономии по сравнению с географическим кросс-региональным инференсом.

Ops Alert помогает не просто бесконечно поднимать квоты, а оптимизировать распределение нагрузки:

• вы видите, где реально упираетесь в лимиты;
• можете переключиться на глобальный инференс и снять пиковые нагрузки без лишних тикетов на квоты.

3. Оптимизация по токенам и стоимости

Bedrock поддерживает prompt caching:

• система кэширует части контекста;
• модель не пересчитывает одинаковые куски, что снижает стоимость и задержку.

Заявленные эффекты:

• до 90% экономии на стоимости токенов;
• до 85% снижения латентности ответа;
• прямое снижение потребления TPM.

Ops Alert отслеживает TPM через EstimatedTPMQuotaUsage, включая токены записи в кэш и множители на вывод. Это помогает понять, как кэширование и батч‑инференс реально влияют на нагрузку и когда квоты нужно увеличивать, а когда — просто лучше настроить промпты.

4. Сокращение ручной рутины для AI SRE

Без Ops Alert каждая новая модель и каждый новый регион — это:

• свои CloudWatch‑алармы;
• свои тикеты на квоты;
• свои пересчёты порогов после одобрения.

Ops Alert превращает это в масштабируемую схему:

• один стек CloudFormation разворачивает весь пайплайн мониторинга;
• новые модели и профили инференса попадают под существующие правила;
• тикеты в AWS Support формируются автоматически и с нужным контекстом.

Где это не поможет

• Если вы не используете Amazon Bedrock, Ops Alert вам не пригодится: решение заточено под его метрики и квоты.
• Если у вас нет Business или Enterprise Support, автоматическое создание тикетов работать не будет — останутся только алерты и письма.
• Если трафик небольшой и квоты далёки от предела, выгода от сложной схемы мониторинга будет меньше, чем стоимость настройки и поддержки.

Доступность для России

Amazon Bedrock и AWS Support официально работают в инфраструктуре AWS. Для команд, которые находятся в России и не имеют прямого доступа к AWS, продукт может быть недоступен без обходных схем. Если у вас нет аккаунта AWS с доступом к Bedrock и Support API, развернуть Ops Alert не получится.

Место на рынке

Ops Alert — это не отдельный SaaS‑мониторинг, а нативное решение внутри AWS‑экосистемы для генеративных нагрузок на Bedrock.

По сравнению с типичной схемой «CloudWatch + сторонний дашбординг + ручные тикеты» Ops Alert даёт:

• автоматический пересчёт порогов после изменения квот через Service Quotas API;
• интеграцию с AWS Support API для создания тикетов с полным контекстом;
• трёхслойную схему обнаружения проблем (ошибки, пороги, аномалии) без ручной настройки сложных правил.

Прямых численных сравнений с другими вендорами в материале нет, но можно выделить несколько конкретных отличий от типичных внешних APM/обсервабилити‑систем:

• внешние системы обычно не знают о квотах Bedrock и не могут автоматически подстраивать пороги под RPM/TPM‑лимиты;
• Ops Alert работает с конкретными метриками Bedrock (EstimatedTPMQuotaUsage, InvocationThrottles и т.д.) и заточен именно под генеративные сценарии;
• интеграция с AWS Support позволяет не просто «кричать» в Slack, а сразу запускать процесс увеличения квот или расследования инцидента.

Если вы уже используете сторонние инструменты (Datadog, New Relic, Grafana Cloud и т.п.), Ops Alert не заменяет их по общей наблюдаемости инфраструктуры. Он закрывает узкую, но болезненную зону — управление квотами и инцидентами вокруг Amazon Bedrock.

Как запустить

Исходный материал описывает архитектуру и компоненты, но не приводит конкретный CloudFormation‑шаблон или команды CLI. Общая схема запуска такая:

1. Подготовить аккаунт AWS с доступом к:

   • Amazon Bedrock;
   • Amazon CloudWatch;
   • AWS Lambda;
   • Amazon SNS;
   • AWS Systems Manager Parameter Store;
   • AWS Secrets Manager;
   • AWS Service Quotas API;
   • AWS Support API (нужен Business или Enterprise Support).

2. Развернуть CloudFormation‑стек Amazon Bedrock Ops Alert:

   • задать проценты порогов для RPM/TPM и латентности (например, 80%);
   • указать email‑адреса для уведомлений;
   • включить или отключить авто‑создание тикетов в AWS Support.

3. Проверить, что:

   • Lambda Quota Calculator отработала и записала пороги в Parameter Store;
   • CloudWatch‑алармы для трёх слоёв созданы и привязаны к метрикам Bedrock;
   • SNS‑топики Raw Alarm Topic и Formatted Notification Topic существуют, а email‑подписки подтверждены.

4. Сгенерировать тестовую нагрузку на Bedrock, чтобы:

   • спровоцировать throttling или высокий RPM/TPM;
   • увидеть, как срабатывают алармы и приходят письма;
   • убедиться, что тикет в AWS Support создаётся корректно (если функция включена).

5. Настроить расписание EventBridge для Alarm Updater, чтобы пороги автоматически подстраивались под новые квоты.

Если вы строите серьёзный генеративный продукт на Amazon Bedrock, Ops Alert закрывает сразу несколько рутинных задач AI SRE‑команды: от пересчёта порогов до общения с AWS Support. Для команд, которые пока только пробуют Bedrock, это скорее задел на будущее, чем необходимость прямо сейчас.

---

Читайте также

• Azure Monitor: единый центр наблюдения за ресурсами в Azure
• Codex выходит за пределы кода: как ИИ‑ассистент превращается в офисный инструмент
• OpenAI GPT‑5.5, GPT‑5.4 и Codex стали доступны в Amazon Bedrock: что это даёт разработчикам