O que é o AgentCore Gateway e por que rate limiting importa
O Amazon Bedrock AgentCore Gateway é um gateway de IA totalmente gerenciado e serverless que funciona como ponto de entrada único e seguro para tráfego de IA. Ele roteia requisições para ferramentas como busca web gerenciada, bases de conhecimento gerenciadas, servidores MCP, modelos de inferência (Modelos de Linguagem de Grande Escala — LLMs), agentes (A2A, agentes como ferramentas, etc.) e endpoints HTTP.
A AWS anunciou o suporte a rate limiting no AgentCore Gateway, oferecendo controle refinado sobre quanto tráfego cada usuário pode consumir. Com essa funcionalidade, é possível definir regras baseadas em OAuth ou Gerenciamento de Identidade e Acesso (IAM) para requisições por minuto, conexões simultâneas e throughput de tokens — garantindo que os serviços downstream permaneçam disponíveis mesmo durante picos de tráfego.
Tipos de métricas de rate limiting
O AgentCore Gateway suporta três tipos de alvos: alvos MCP, alvos de inferência e alvos de passagem HTTP. Para cada um desses alvos, as seguintes métricas de limite estão disponíveis:
- Limites de requisição (RPS/RPM): Medidos em requisições por segundo (RPS) ou requisições por minuto (RPM), aplicam-se a todos os tipos de alvo. Cada requisição conta como exatamente uma unidade, independentemente do tempo de conclusão — uma que termina em 50 milissegundos e outra que faz streaming por 90 segundos consomem a mesma unidade.
- Limites de token (TPM): Medidos em tokens por minuto (TPM), aplicam-se apenas a alvos de inferência. O gateway usa um tokenizador de uso geral para estimar os tokens de entrada antes de despachar a chamada e reconcilia o consumo real após o retorno da resposta, considerando tanto tokens de entrada quanto de saída.
- Limites de conexão (CPS): Medidos em conexões por segundo (CPS), aplicam-se a todos os tipos de alvo. Ao contrário dos limites de requisição, o CPS rastreia por quanto tempo cada requisição mantém uma conexão aberta — uma chamada de inferência em streaming que dura 100 segundos ocupa um slot de conexão durante todo esse período.
Estrutura de configuração: dimension keys e entries
Para o caso de uso apresentado, a AWS considera três grupos de usuários: Basic, Advanced e Beta. O AgentCore Identity gerencia a autenticação de entrada usando Tokens Web JSON (JWT) com o Microsoft Entra ID como provedor de identidade. A Policy no Amazon Bedrock AgentCore aplica controle de acesso baseado em papéis (RBAC), limitando o acesso de cada grupo a alvos e modelos específicos.
Uma configuração de rate limit é composta por duas partes: chaves de dimensão (dimension keys) e entradas (entries). As chaves de dimensão definem como o gateway agrupa o tráfego em buckets de limite. As entradas definem o throughput permitido para cada bucket.
Os exemplos neste artigo utilizam a Interface de Linha de Comando da AWS (AWS CLI) para criar as configurações. O gateway suporta as seguintes chaves de dimensão: targetName, toolName, qualifiedModelId, $.context.jwt.<claim>, $.context.iam.principal e $.context.iam.sourceIdentity.
As entradas suportam o valor curinga *, que dá a cada valor distinto seu próprio bucket independente na taxa configurada. Uma entrada nomeada tem precedência sobre o curinga — a correspondência mais específica sempre vence.
Tipos de rate limits e exemplos de configuração
O AgentCore Gateway aplica duas camadas de rate limiting: limites definidos pelo cliente e Cotas de Serviço. Os limites do cliente são avaliados primeiro; se a requisição passar, as cotas de serviço são verificadas.
Cotas gerenciadas pelo serviço
As cotas gerenciadas pelo serviço são os limites impostos por conta AWS pelo próprio serviço. Elas definem o teto que os limites definidos pelo cliente não podem ultrapassar. A taxa efetiva é o mínimo entre o limite definido pelo cliente e o limite gerenciado pelo serviço. É possível solicitar aumentos para algumas cotas pelo console de Cotas de Serviço.
Limites por usuário
Os limites por usuário usam $.context.jwt.<claim>, $.context.iam.principal e $.context.iam.sourceIdentity como chaves de dimensão para controlar quanto tráfego usuários individuais ou grupos inteiros podem consumir.
O exemplo abaixo atribui taxas de requisição diferentes por grupo de usuário, usando o claim role do JWT:
aws bedrock-agentcore-control create-gateway-rate-limit \
--gateway-identifier my-gateway-abc1234567 \
--dimension-keys '["$.context.jwt.role"]' \
--description "Per-role request and connection limit" \
--entries '[
{
"dimensions": {"$.context.jwt.role": "[\"Basic\"]"},
"requests": [{"rate": 100, "period": "minute"}],
"connections": [{"rate": 50, "period": "second"}]
},
{
"dimensions": {"$.context.jwt.role": "[\"Advanced\"]"},
"requests": [{"rate": 300, "period": "minute"}],
"connections": [{"rate": 150, "period": "second"}]
},
{
"dimensions": {"$.context.jwt.role": "[\"Advanced\", \"Beta\"]"},
"requests": [{"rate": 300, "period": "minute"}],
"connections": [{"rate": 200, "period": "second"}]
},
{
"dimensions": {"$.context.jwt.role": "*"},
"requests": [{"rate": 80, "period": "minute"}],
"connections": [{"rate": 10, "period": "second"}]
}
]'Nessa configuração, usuários Basic recebem 100 RPM e 50 CPS compartilhados entre todo o grupo. Se um único usuário Basic consumir 80 requisições em um minuto, restam apenas 20 para os demais. Para evitar que um único usuário esgote a cota do grupo, é recomendável adicionar também um limite por usuário individual usando o claim $.context.jwt.sub:
aws bedrock-agentcore-control create-gateway-rate-limit \
--gateway-identifier my-gateway-abc1234567 \
--dimension-keys '["$.context.jwt.role", "$.context.jwt.sub"]' \
--description "Per-user request and connection limit within each role" \
--entries '[
{
"dimensions": {"$.context.jwt.role": "[\"Basic\"]", "$.context.jwt.sub": "*"},
"requests": [{"rate": 20, "period": "minute"}],
"connections": [{"rate": 10, "period": "second"}]
},
{
"dimensions": {"$.context.jwt.role": "[\"Advanced\"]", "$.context.jwt.sub": "*"},
"requests": [{"rate": 60, "period": "minute"}],
"connections": [{"rate": 30, "period": "second"}]
},
{
"dimensions": {"$.context.jwt.role": "[\"Advanced\", \"Beta\"]", "$.context.jwt.sub": "*"},
"requests": [{"rate": 60, "period": "minute"}],
"connections": [{"rate": 50, "period": "second"}]
},
{
"dimensions": {"$.context.jwt.role": "*", "$.context.jwt.sub": "*"},
"requests": [{"rate": 20, "period": "minute"}],
"connections": [{"rate": 20, "period": "second"}]
}
]'Juntos, o limite por grupo e o limite por usuário criam um modelo de aplicação em duas camadas com semântica AND: uma requisição precisa passar pelos dois limites para prosseguir. Se qualquer um dos dois negar a requisição, o gateway retorna uma resposta de throttling.
Limites por alvo
Os limites por alvo usam targetName, qualifiedModelId ou toolName como chave de dimensão para controlar o throughput para alvos, modelos ou ferramentas específicos. Eles protegem a capacidade do backend e distribuem a carga entre os recursos disponíveis:
aws bedrock-agentcore-control create-gateway-rate-limit \
--gateway-identifier my-gateway-abc1234567 \
--dimension-keys '["targetName"]' \
--description "Per-target rate limit" \
--entries '[
{
"dimensions": {"targetName": "Booking"},
"requests": [{"rate": 20, "period": "second"}]
},
{
"dimensions": {"targetName": "Docs"},
"requests": [{"rate": 15, "period": "second"}]
},
{
"dimensions": {"targetName": "awsdocsagent"},
"requests": [{"rate": 10, "period": "second"}],
"connections": [{"rate": 60, "period": "second"}]
},
{
"dimensions": {"targetName": "BedrockMantle"},
"tokens": [{"rate": 100000, "period": "minute"}],
"connections": [{"rate": 250, "period": "second"}]
},
{
"dimensions": {"targetName": "CustomPlatform"},
"tokens": [{"rate": 50000, "period": "minute"}],
"connections": [{"rate": 100, "period": "second"}]
},
{
"dimensions": {"targetName": "*"},
"tokens": [{"rate": 10000, "period": "minute"}],
"requests": [{"rate": 10, "period": "second"}],
"connections": [{"rate": 50, "period": "second"}]
}
]'Limites combinados (alvo + usuário)
Os limites híbridos combinam dimensões de alvo e de usuário em uma única configuração, oferecendo o controle mais granular. O exemplo abaixo aplica limites de token por modelo, escopados por usuário dentro de seu grupo. O qualifiedModelId é o identificador totalmente qualificado do modelo para alvos de inferência (consulte a documentação):
aws bedrock-agentcore-control create-gateway-rate-limit \
--gateway-identifier my-gateway-abc1234567 \
--dimension-keys '["$.context.jwt.role", "qualifiedModelId", "$.context.jwt.sub"]' \
--description "Per-user per-role per-model TPM and access limit" \
--entries '[
{
"dimensions": {"$.context.jwt.role": "[\"Advanced\", \"Beta\"]", "qualifiedModelId": "anthropic.claude-fable-5", "$.context.jwt.sub": "*"},
"tokens": [{"rate": 80000, "period": "minute"}]
},
{
"dimensions": {"$.context.jwt.role": "[\"Basic\"]", "qualifiedModelId": "anthropic.claude-fable-5", "$.context.jwt.sub": "*"},
"requests": [{"rate": 0, "period": "second"}]
},
{
"dimensions": {"$.context.jwt.role": "[\"Advanced\"]", "qualifiedModelId": "anthropic.claude-fable-5", "$.context.jwt.sub": "*"},
"requests": [{"rate": 0, "period": "second"}]
},
... (repita para openai.gpt-5.6-luna e openai.gpt-5.6-terra)
{
"dimensions": {"$.context.jwt.role": "[\"Advanced\"]", "qualifiedModelId": "*", "$.context.jwt.sub": "*"},
"tokens": [{"rate": 40000, "period": "minute"}]
},
{
"dimensions": {"$.context.jwt.role": "[\"Basic\"]", "qualifiedModelId": "*", "$.context.jwt.sub": "*"},
"tokens": [{"rate": 20000, "period": "minute"}]
}
]'Nessa configuração, anthropic.claude-fable-5 é um modelo restrito. Apenas usuários com o papel ["Advanced", "Beta"] podem invocá-lo, recebendo 80.000 TPM por usuário para workloads de benchmarking. Usuários Basic e Advanced (sem Beta) são bloqueados com taxa zero. Para modelos geralmente disponíveis, usuários Basic recebem 20.000 TPM e Advanced recebem 40.000 TPM por usuário via entradas curinga. Para mais exemplos de configuração, veja os exemplos de API de rate limit.
Rate limiting para workloads agênticos
Em workloads agênticos, dois tipos de rate limits devem ser considerados:
- Limites sobre a invocação do agente: Protegem a frequência com que usuários ou outros serviços podem invocar o agente. São limites de RPM e CPS escopados ao próprio alvo do agente. Para controle mais granular, combine
targetNamecom dimensões de usuário como["targetName", "$.context.jwt.role"]. - Limites sobre os recursos consumidos pelo agente: Protegem os recursos downstream que o agente consome em cada invocação. O comportamento depende de como o agente se autentica com o gateway ao invocar esses recursos.
Se o agente realiza uma troca de token on-behalf-of (OBO) com base no JWT do usuário, as requisições downstream carregam a identidade original do usuário e todos os limites baseados em usuário se aplicam normalmente. Porém, se o agente usa um fluxo de client credentials (máquina a máquina), as requisições downstream carregam a identidade do próprio agente. Nesse caso, os limites baseados em usuário não se aplicarão e é necessário adicionar limites que identifiquem o agente em si — usando um claim como $.context.jwt.azp (authorized party).
Boas práticas de rate limiting
- Se você usa Policy no AgentCore para RBAC, entenda a ordem de avaliação: os rate limits são aplicados primeiro, e a Policy é avaliada depois. Para evitar que requisições de usuários bloqueados consumam o bucket de rate limit, crie uma entrada com taxa zero para esses usuários.
- O gateway avalia rate limits com mais chaves de dimensão primeiro (limites mais específicos têm prioridade). Dentro do mesmo número de dimensões, limites mais restritivos (menores) são avaliados primeiro. A avaliação encerra no primeiro bloqueio.
- O curinga
*só pode aparecer em posições finais. Se usado na posição N, todas as posições seguintes também devem ser*. Veja os exemplos para entender esse comportamento. - Evite usar claims JWT de alta cardinalidade como chaves de dimensão (ex:
$.context.jwt.jti,$.context.jwt.nonce). Prefira identificadores estáveis comosub,role,teamoutier. - O gateway usa semântica fail-open para avaliação de rate limits. Não confie exclusivamente nos rate limits como barreira de segurança. Use autenticação, autorização e regras do AWS WAF para aplicação de segurança.
- Habilite logs de aplicação no seu AgentCore Gateway para ter acesso aos logs de rate limiting. O gateway emite atributos de span OpenTelemetry (OTEL) para cada requisição onde os rate limits são avaliados.
- Sempre inclua uma entrada catch-all (
*) nas suas configurações. Sem ela, callers sem entrada explícita ignoram completamente os limites definidos pelo cliente e caem diretamente nas cotas gerenciadas pelo serviço. Para mais boas práticas, consulte a documentação do AgentCore Gateway.
Conclusão
O suporte a rate limiting no Amazon Bedrock AgentCore Gateway permite governar o tráfego de IA com múltiplas camadas: limites por usuário para garantir uso justo entre papéis, limites por alvo para proteger a capacidade dos serviços downstream, e limites multidimensionais que combinam usuário e alvo para controle ainda mais refinado.
Combinado com o AgentCore Identity para autenticação, a Policy no AgentCore para controle de acesso baseado em papéis e logging de aplicação para observabilidade, o rate limiting oferece as ferramentas necessárias para operar um gateway de IA em produção com confiança — garantindo uso justo, protegendo os serviços backend e mantendo a disponibilidade conforme os workloads escalam.
Para começar, explore os recursos disponíveis: referência completa da API para criar, atualizar e excluir rate limits; exemplos de API de rate limit com operações em lote, listagem e exclusão; cotas gerenciadas pelo serviço e como solicitar aumentos; AgentCore Identity para autenticação JWT; Policy no AgentCore para RBAC; e logging de aplicação para monitoramento em tempo real.
Fonte
Configure rate limits for AI traffic on AgentCore gateway (https://aws.amazon.com/blogs/machine-learning/configure-rate-limits-for-ai-traffic-on-agentcore-gateway/)
Leave a Reply