ainews
AWS запустил гибкие лимиты запросов для AI-трафика в AgentCore gateway
Amazon Bedrock AgentCore gateway теперь умеет ограничивать AI-трафик на уровне пользователей: запросы в минуту, токены, одновременные соединения. Можно раздавать разные лимиты разным группам (Basic/Advanced/Beta) через JWT или IAM, защищая модели и инструменты от перегрузок и контролируя расходы.
Потому что без rate limiting AI-платформа в проде — это русская рулетка с расходами и стабильностью. Теперь AWS даёт инструмент из коробки, что снижает порог входа для enterprise.
Что произошло
AWS анонсировал поддержку rate limiting в Amazon Bedrock AgentCore gateway — serverless-шлюзе для AI-трафика. Теперь можно детально ограничивать нагрузку на уровне отдельных пользователей или групп.
Три типа лимитов:
- Requests per minute/second (RPM/RPS) — количество запросов в минуту или секунду для любых целей (MCP-серверы, HTTP-эндпоинты, модели)
- Tokens per minute (TPM) — только для инференс-запросов к LLM, учитываются входные и выходные токены
- Connections per second (CPS) — сколько одновременных активных соединений может держать пользователь (важно для стриминговых вызовов)
Лимиты настраиваются через dimension keys (targetName, toolName, qualifiedModelId, JWT-клеймы, IAM-принципалы) и entries с приоритетом: явное имя бьёт wildcard.
Пример из документации: группа Basic получает 10 RPS на целевые сервисы, Advanced — 100 RPS на высоконагруженный MCP-сервер Booking, Beta — повышенные лимиты на экспериментальные модели. Аутентификация через JWT (Microsoft Entra ID), авторизация через политики Bedrock.
Автор: Анна Мельникова · Источник: aws.amazon.com
Разработчикам. Можно программно защитить свои AI-инструменты и модели от перегрузок, раздавать квоты через IAM или JWT, не переписывая логику в каждом сервисе. Dimension keys позволяют гибко группировать трафик по целям, моделям, пользователям.
Бизнесу. Контроль расходов на AI: ограничивайте доступ к дорогим моделям для разных команд, защищайте инфраструктуру от спайков, тестируйте новые модели на ограниченной аудитории (Beta-группы) без риска для прода.
Инвесторам. AWS укрепляет позиции в enterprise AI: rate limiting — критичная функция для продакшена, особенно при multi-tenant AI-сервисах. Снижает барьер входа для компаний, которые боятся неконтролируемых расходов на LLM.
- Строить multi-tenant AI-платформы на Bedrock с гибкими тарифами: Basic/Pro/Enterprise — лимиты из коробки, без самописного биллинга
- Продавать AI-агентов как SaaS с гарантированным QoS: каждому клиенту — свой rate bucket, защита от noisy neighbor
- Безопасно тестировать новые модели на ограниченной группе пользователей, постепенно открывая доступ по мере стабилизации
- Защитить внутренние AI-инструменты от случайных DDoS или неоптимизированных циклов запросов от разработчиков
- Интеграция с корпоративным IAM/OAuth: раздавать квоты на основе роли или подразделения, не изобретая велосипед
- Это AWS-специфичная фича, привязка к Bedrock и AgentCore — vendor lock-in, сложно мигрировать на другие облака
- Нет детальной информации о точности токенизации для лимитов TPM (используется general-purpose tokenizer, а не нативный токенизатор модели — могут быть расхождения)
- Документация пока техническая, нет ready-made шаблонов для популярных кейсов — придётся разбираться самим
- Неясно, как биллинг AWS учитывает лимиты: если пользователь упёрся в лимит, платишь ли ты за отброшенные запросы или только за обработанные?
Долго ждали. Rate limiting — это база для любого AI-сервиса в проде, и то, что AWS делает его нативной частью AgentCore, сильно упрощает жизнь. Теперь не нужно городить свой rate limiter перед Bedrock или молиться, чтобы никто не запустил бесконечный цикл запросов к дорогой модели.
Но есть нюансы. Во-первых, это работает только внутри экосистемы AWS Bedrock — если у вас гибридная инфраструктура или мультиоблако, придётся дублировать логику. Во-вторых, детали биллинга туманны: неясно, считаются ли отброшенные запросы в счёт, и насколько точен их general-purpose токенизатор для TPM-лимитов (у каждой модели свой токенизатор, расхождения могут быть). В целом — отличный шаг для enterprise, но проверяйте цифры в реальной нагрузке, прежде чем полагаться на это в критичных системах.
Комментарии