A AWS anunciou uma melhoria importante no IAM Identity Center: agora é possível habilitar o suporte multi-Region com apenas um clique ao criar uma nova instância de organização. Antes dessa mudança, o processo exigia várias etapas manuais — como criar uma chave KMS (Key Management Service) gerenciada pelo cliente, configurar políticas de chave e adicionar as Regiões uma a uma. Com a atualização, esse fluxo foi significativamente simplificado.
As três opções de configuração de instância
Ao criar uma nova instância do IAM Identity Center em Regiões compatíveis, a AWS agora oferece três opções de configuração:
Instância single-Region: configuração padrão, limitada a uma única Região.
Instância multi-Region: a opção de um clique. Ela cria automaticamente uma chave KMS multi-Region gerenciada pelo cliente na conta do usuário e replica a instância para uma Região adicional.
Instância customizada: permite configurar as definições de Região individualmente, incluindo a possibilidade de usar uma chave KMS gerenciada pelo cliente já existente na conta.
Por que isso importa: resiliência no acesso
O principal benefício da configuração multi-Region é a resiliência. Com essa opção habilitada, os colaboradores de uma organização continuam conseguindo acessar suas contas AWS mesmo que o IAM Identity Center enfrente alguma interrupção na Região primária. Ou seja, a continuidade do acesso a contas e aplicações fica muito mais garantida em cenários de falha regional.
Disponibilidade e custos
As opções de configuração de instância estão disponíveis em 17 Regiões AWS comerciais habilitadas por padrão para instâncias de organização do IAM Identity Center. Vale destacar que o próprio IAM Identity Center não tem custo adicional, mas as cobranças padrão do AWS KMS se aplicam à chave gerenciada pelo cliente criada pela opção multi-Region.
Como começar
Para quem quer explorar essa novidade, a AWS disponibiliza recursos de documentação para apoiar a jornada:
A AWS anunciou que o Amazon Timestream para InfluxDB agora oferece suporte nativo a backup e restauração de dados. A novidade permite que equipes criem e gerenciem suas próprias cópias de segurança, além de restaurar dados sob demanda — tudo isso de forma controlada e sem depender de soluções externas.
Como funciona o backup
O recurso oferece duas modalidades principais de backup:
Backup sob demanda (one-time): ideal para ser executado antes de migrações arriscadas ou mudanças de configuração que possam impactar os dados.
Backup automatizado recorrente: é possível configurar agendamentos com frequências variadas — por hora, diariamente, semanalmente, mensalmente ou com intervalos personalizados — cada um com seu próprio período de retenção.
Cada recurso suporta até quatro configurações de backup automatizado simultaneamente, o que dá bastante flexibilidade para cenários com diferentes requisitos de proteção.
O primeiro backup realizado captura uma cópia completa do banco de dados. Os backups subsequentes são incrementais, o que reduz o impacto no desempenho durante a execução contínua.
Como funciona a restauração
Na hora de restaurar, há duas opções disponíveis:
Criar um novo recurso que herda automaticamente as configurações do recurso de origem.
Substituir um recurso existente pelo conteúdo do backup.
Vale destacar que, se o recurso de origem utilizar uma Chave Gerenciada pelo Cliente (KMS), os backups associados utilizarão essa mesma chave automaticamente — mantendo a consistência da estratégia de criptografia.
Compatibilidade e disponibilidade
O recurso está disponível para os dois motores suportados pelo serviço: InfluxDB 2 e InfluxDB 3. O acesso pode ser feito por três caminhos:
Console de Gerenciamento da AWS (AWS Management Console)
Interface de Linha de Comando da AWS (AWS CLI)
API do Timestream para InfluxDB
O backup e restauração gerenciados pelo cliente estão disponíveis em todas as regiões da AWS onde o Amazon Timestream para InfluxDB já está presente.
Por que isso importa
Antes desse recurso, equipes que utilizavam o Timestream para InfluxDB precisavam recorrer a estratégias manuais ou externas para proteger seus dados de séries temporais. Agora, com backup e restauração nativos, o controle da estratégia de proteção de dados fica diretamente nas mãos de quem opera o serviço — sem gambiarras.
A AWS anunciou que o Gerenciador de Endereços IP (IPAM) da Amazon Virtual Private Cloud (VPC) passou a oferecer suporte a duas novas capacidades voltadas para segurança de roteamento: o monitoramento de proteção de rotas BGP e o gerenciamento de Infraestrutura de Chave Pública de Recursos delegada (RPKI) para prefixos Traga Seu Próprio IP (BYOIP). A atualização foi publicada em 7 de agosto de 2026.
O problema que essa novidade resolve
Antes desse recurso, quem utilizava prefixos BYOIP na AWS precisava realizar manualmente uma série de tarefas trabalhosas: criar e renovar as Autorizações de Origem de Rota (ROA) diretamente no Registro Regional de Internet (RIR) correspondente, validar a propriedade dos prefixos via registros WHOIS ou DNS, e ainda depender de ferramentas de terceiros para monitorar a segurança das rotas. Com a nova funcionalidade, boa parte desse trabalho passa a ser automatizado e centralizado dentro do próprio IPAM.
O que os administradores de rede ganham
Monitoramento de proteção de rotas BGP
Com o monitoramento BGP integrado ao IPAM, os administradores de rede conseguem, a partir de um único painel, visualizar:
O status de validade RPKI de todos os prefixos BYOIP, em todas as contas e regiões da organização;
A robustez das ROAs configuradas, diferenciando entre configurações estritas e permissivas;
A detecção de sobreposição de rotas, que pode indicar tentativas de sequestro de prefixos (route hijacking);
Prefixos com ROAs inválidas ou ausentes, permitindo ação corretiva antes que problemas ocorram.
RPKI Delegado
Com o RPKI Delegado, o processo de integração com o RIR — seja ele ARIN, RIPE, APNIC ou LACNIC — é realizado uma única vez. A partir daí, o IPAM assume automaticamente as seguintes responsabilidades:
Criação das ROAs durante o provisionamento de novos prefixos BYOIP;
Renovação automática das ROAs antes do vencimento;
Gerenciamento das ROAs para prefixos utilizados em ambientes on-premises.
Disponibilidade
O recurso está disponível no Amazon VPC IPAM em todas as regiões comerciais da AWS, com exceção das regiões AWS GovCloud (US) e das regiões da China (Beijing, operada pela Sinnet, e Ningxia, operada pela NWCD).
Quando uma organização começa a escalar o uso de agentes de codificação como o Codex, a pergunta da liderança muda de natureza. Não basta mais saber se a ferramenta ajuda um desenvolvedor individualmente. O desafio passa a ser: como entender a adoção, controlar o consumo, manter a confiabilidade e expandir o acesso de forma responsável?
Para responder a essa pergunta, a AWS publicou um padrão de referência que combina as métricas OpenTelemetry (OTel) emitidas pelo Codex com o Amazon CloudWatch, usando autenticação via AWS IAM Identity Center. O resultado é uma visibilidade nativa AWS do uso do Codex, sem precisar adicionar nenhum proxy centralizado ao caminho de inferência dos modelos. Toda a implementação está documentada no repositório de orientação do Codex na AWS.
Como a arquitetura funciona
A lógica central do padrão é simples e elegante: o desenvolvedor continua usando o Codex localmente, sem nenhuma mudança perceptível no seu fluxo de trabalho. O que acontece nos bastidores é o seguinte:
O Codex emite métricas OTel para um coletor que escuta apenas em 127.0.0.1 (ou seja, somente na máquina local).
Esse coletor enriquece as métricas com atributos organizacionais — como user.id, user.email, departamento, time, centro de custo e organização.
O coletor então agrupa as métricas em lotes e as envia ao endpoint regional do CloudWatch usando o protocolo OpenTelemetry Protocol (OTLP), autenticado com AWS Signature Version 4 (SigV4).
Esse design garante que o coletor nunca interfere no caminho de inferência do Amazon Bedrock. Não há criação de serviços centralizados como um Amazon Elastic Container Service (ECS), balanceador de carga, Virtual Private Cloud (VPC) ou endpoint público de ingestão. O que é implantado é apenas um dashboard no CloudWatch.
Transformando telemetria em decisões de negócio
O dashboard CodexOnBedrock incluído no padrão de referência exibe totais acumulados em 24 horas para usuários ativos, turnos de conversa, requisições de API e uso de tokens. Também oferece visões segmentadas por modelo, tipo de token, usuário, departamento, time, centro de custo, organização e origem da sessão.
Esses sinais ajudam líderes de tecnologia a distinguir adoção ampla de experimentação isolada. Por exemplo, um aumento de usuários ativos em vários times indica uma necessidade de capacitação diferente de um alto consumo concentrado em um grupo pequeno. A tabela abaixo, presente no artigo original, resume as perguntas executivas que o padrão ajuda a responder:
A adoção do Codex está crescendo? → Usuários ativos, threads, turnos e requisições de API informam se é hora de expandir o piloto ou focar no onboarding.
Onde o consumo está concentrado? → Tokens por usuário, modelo, departamento, time e centro de custo orientam showback, revisão de uso ou ajuste de capacitação.
Os times estão usando capacidades agênticas? → Volume de chamadas de ferramentas e origem da sessão indicam onde guias de workflow ou investimentos em sistema podem ajudar.
A experiência do desenvolvedor é confiável? → Status de API, duração de requisições e duração de turno ponta a ponta sinalizam se há algo a investigar em acesso ao modelo, rede ou comportamento do cliente.
Qual foi o custo do serviço? → AWS Cost and Usage Reports (CUR) 2.0 com dados de principal IAM fornecem relatórios financeiros e alocação de custos em nível de faturamento.
Um ponto importante destacado no artigo: as métricas OTel do CloudWatch mostram volume de uso e comportamento operacional, mas não são um ledger de faturamento. Estimativas de preço de tabela podem divergir dos custos reais por conta de mudanças de preço, descontos, créditos e ajustes de cobrança. Para o gasto realizado, a recomendação é usar o CUR 2.0 ou os relatórios de gestão de custos do Amazon Bedrock.
Implementando o padrão de referência
O quickstart de acesso nativo AWS contém todos os comandos e templates necessários. A implementação se divide em cinco etapas:
1. Habilitar as capacidades OTel do CloudWatch
O primeiro passo é ativar o enriquecimento OTel e as tags de recurso para telemetria na região desejada:
A operação start-otel-enrichment habilita o enriquecimento e o acesso via Prometheus Query Language (PromQL) para métricas fornecidas pela AWS. A operação start-telemetry-enrichment habilita o enriquecimento com tags de recurso. A documentação OTel do CloudWatch descreve a ingestão nativa via OTLP e as consultas PromQL em detalhes. Antes de alterar qualquer configuração, é importante confirmar quais configurações de nível de conta já estão ativas.
2. Implantar o dashboard e compilar o coletor
Após clonar o repositório, o dashboard é implantado e o binário do coletor é obtido com:
O stack do AWS CloudFormation implanta o dashboard CodexOnBedrock. Como o coletor roda nas estações de trabalho dos desenvolvedores, essa etapa não cria infraestrutura centralizada de computação ou rede para o coletor.
3. Gerar a configuração por desenvolvedor
A configuração do coletor é gerada a partir do perfil AWS autenticado do desenvolvedor:
Com o flag --auto-lookup, o script pode ler atributos organizacionais diretamente do identity store do IAM Identity Center. Valores explícitos via linha de comando podem sobrescrever os valores descobertos. Se um atributo opcional não estiver disponível, o bloco de configuração correspondente deve ser omitido — nunca envie strings de placeholder como dimensões, pois isso cria séries de baixo valor e compromete a qualidade dos relatórios.
4. Configurar o Codex e conceder acesso com privilégio mínimo
O exportador de métricas do Codex deve ser apontado para o coletor local. É necessário incluir o caminho completo /v1/metrics porque o Codex não o adiciona automaticamente:
O coletor encaminha as métricas para o endpoint regional de métricas OTLP do CloudWatch, como https://monitoring.us-west-2.amazonaws.com/v1/metrics. O SigV4 é o método de autenticação recomendado para credenciais AWS de curta duração. A identidade de publicação requer apenas a permissão cloudwatch:PutMetricData — nenhuma permissão de log-group ou ECS é necessária para esse caminho de métricas.
A configuração log_user_prompt = false deve ser mantida. Esse padrão foi projetado para medir sinais operacionais e de adoção, não para coletar código-fonte ou conteúdo de prompts.
5. Validar o fluxo completo
Inicie o coletor com a configuração gerada, execute uma tarefa no Codex e abra o dashboard CodexOnBedrock no console do CloudWatch. Também é possível usar o CloudWatch Query Studio ou o script check-otel-pipeline.sh do repositório para confirmar que a métrica codex.turn.token_usage está chegando.
As métricas do Codex são enviadas periodicamente e ao encerramento limpo do processo. O runbook de referência documenta um intervalo de 60 segundos e sugere OTEL_METRIC_EXPORT_INTERVAL=1000 como salvaguarda opcional para caminhos de erro que possam pular o flush de saída. Se nenhuma métrica aparecer, também é importante verificar se a configuração gerenciada não definiu [analytics] enabled = false, pois essa configuração desabilita o pipeline de métricas do Codex.
Operando com governança em mente
As mesmas dimensões que tornam o dashboard útil podem criar preocupações de privacidade e governança se expostas de forma muito ampla. Algumas recomendações do padrão de referência:
Use visões agregadas por time, departamento e centro de custo para relatórios executivos.
Restrinja dashboards por usuário a funções aprovadas de sistemas, operações, segurança ou finanças, alinhando o acesso com as políticas de monitoramento de funcionários e retenção de dados.
Controle a cardinalidade das métricas à medida que escala: padronize nomes e valores de atributos, omita campos que não suportem uma decisão definida e evite adicionar nomes de projetos ou identificadores efêmeros sem um plano de retenção e consulta.
Do ponto de vista de custos, as métricas OTel do CloudWatch usam precificação por gigabyte ingerido, e as consultas PromQL são cobradas por amostras escaneadas. É recomendado revisar a documentação de preços do CloudWatch OTel e os preços do Amazon CloudWatch antes de uma implantação ampla.
Vale destacar uma limitação importante: esse padrão fornece visibilidade e controles suaves. É possível usar alarmes do CloudWatch e notificações do Amazon Simple Notification Service (SNS) para alertar quando um usuário ou time ultrapassa um limite de uso definido. No entanto, como o IAM Identity Center emite credenciais temporárias diretamente, esse caminho de telemetria local não consegue bloquear sincronamente uma requisição ao Amazon Bedrock com base em um orçamento de tokens. Se for necessário controle rígido, a recomendação é usar um gateway no caminho da requisição com controles de orçamento.
Estratégia de implantação em fases
O artigo original recomenda uma abordagem gradual:
Fase 1: Comece com um único grupo de engenharia cujos líderes e desenvolvedores concordam com o propósito da telemetria. Valide que a atribuição de identidade está correta, que o dashboard responde perguntas reais de operação e que os controles de acesso refletem a política de governança.
Fase 2: Adicione um conjunto pequeno de dimensões organizacionais controladas e defina alertas para condições que exigem ação.
Fase 3: Expanda via configuração gerenciada de workstations somente após o ciclo de vida do coletor, as atualizações de identidade e o processo de suporte estarem repetíveis.
Fase 4: Combine a telemetria de uso do CloudWatch com os relatórios do CUR 2.0 para que os líderes possam revisar adoção e comportamento operacional ao lado dos custos reais de faturamento.
Limpeza do ambiente
Para remover o padrão de monitoramento, basta parar o coletor nas estações de trabalho e excluir o stack do dashboard:
Se nenhuma outra carga de trabalho depender dos recursos de enriquecimento no nível de conta, é possível avaliar a desativação com aws cloudwatch stop-otel-enrichment e aws observabilityadmin stop-telemetry-enrichment. Confirme as dependências antes, pois essas configurações podem suportar outros casos de uso de observabilidade do CloudWatch na conta.
Conclusão
Escalar o Codex não é apenas uma decisão de acesso — é uma decisão de modelo operacional que conecta capacitação de desenvolvedores, confiabilidade de sistemas, governança e responsabilidade financeira. Ao combinar métricas OTel do Codex, atributos do IAM Identity Center, um coletor local e o Amazon CloudWatch, as organizações conseguem construir visibilidade orientada a decisões sem inserir um novo serviço centralizado no caminho de inferência.
O CloudWatch mostra como o Codex está sendo usado. O CUR 2.0 fornece a fonte da verdade financeira. Juntos, eles suportam um caminho estruturado do piloto à adoção governada. Use o quickstart de acesso nativo AWS do Codex para iniciar um piloto e, em seguida, adapte as dimensões, o modelo de acesso e a cadência de relatórios às decisões que a sua organização precisa tomar.
O desafio: inferência de IA dentro de uma única região AWS
Uma organização global com sede nos Estados Unidos chegou à AWS com uma exigência aparentemente simples: permitir que seus engenheiros usassem o Claude Code com uma restrição clara de residência de dados. O processamento das inferências do Amazon Bedrock precisava ocorrer em Londres (região eu-west-2), não apenas ser chamado a partir de Londres. O time de compliance havia traçado uma linha dura: prompts, respostas e todo processamento intermediário deveriam permanecer dentro de uma única região AWS.
A AWS explorou dois caminhos para resolver esse problema e documentou os detalhes — incluindo limitações, configurações e como verificar a conformidade via AWS CloudTrail. Vale reforçar um ponto importante antes de tudo: para a maioria das cargas de trabalho no Amazon Bedrock, a inferência entre regiões (cross-Region inference, ou CRIS) é a escolha padrão recomendada, pois distribui a carga, aumenta a capacidade disponível e dá acesso mais rápido a modelos novos. Os padrões descritos aqui se aplicam apenas quando o requisito de compliance exige uma região específica — não apenas uma geografia como “em algum lugar na UE”.
Dois endpoints, dois caminhos
O Amazon Bedrock expõe os modelos Claude por meio de dois endpoints distintos. A escolha entre eles determina como a residência de dados é garantida — e em quais regiões isso é possível.
Classic Amazon Bedrock (bedrock-runtime)
É a API de invocação original do Amazon Bedrock. O Claude Code a utiliza quando a variável de ambiente CLAUDE_CODE_USE_BEDROCK=1 está definida. Para manter as requisições em uma única região, é necessário criar um application inference profile apontando para o modelo base da região desejada — os perfis de inferência definidos pelo sistema são cross-region por padrão.
Mantle (bedrock-mantle)
É um endpoint mais recente do Amazon Bedrock que serve os modelos Claude no formato nativo da API da Anthropic. O Claude Code o utiliza quando CLAUDE_CODE_USE_MANTLE=1 está definido. O roteamento para uma única região é nativo: basta definir AWS_REGION e o Mantle resolve o endpoint para aquela região diretamente, sem necessidade de criar perfis de inferência adicionais.
Cada endpoint tem sua própria disponibilidade regional e linha de modelos:
Classic Amazon Bedrock: suporte a inferência in-region apenas em eu-west-2 (Londres), para os modelos anthropic.claude-opus-4-6-v1 e anthropic.claude-sonnet-4-6.
Mantle: suporte in-region em 7 regiões (Irlanda, Estocolmo, Tóquio, Melbourne, US East N. Virginia, US East Ohio e US West Oregon), com acesso aos modelos anthropic.claude-sonnet-5, anthropic.claude-opus-4-8 e anthropic.claude-haiku-4-5.
A escolha da região define o caminho. Para Londres (eu-west-2), somente o Caminho 2 (classic Amazon Bedrock) funciona. Para as sete regiões suportadas pelo Mantle, o Caminho 1 é mais simples e dá acesso a modelos mais recentes. Para outras regiões, nenhum dos dois padrões se aplica hoje.
Caminho 1: Mantle para regiões suportadas
Se o requisito de compliance aponta para uma das sete regiões com suporte nativo no Mantle, essa é a opção mais direta. Não é necessário criar nenhum recurso adicional na AWS além da política de Gerenciamento de Identidade e Acesso (IAM). A configuração resume-se a três variáveis de ambiente:
# Route Claude Code through the Mantle endpoint
# Ireland, an in-Region Mantle Region
export CLAUDE_CODE_USE_MANTLE=1
export AWS_REGION=eu-west-1
# Pin the model family aliases to Mantle model IDs
export ANTHROPIC_DEFAULT_OPUS_MODEL='anthropic.claude-opus-4-8'
export ANTHROPIC_DEFAULT_SONNET_MODEL='anthropic.claude-sonnet-5'
export ANTHROPIC_DEFAULT_HAIKU_MODEL='anthropic.claude-haiku-4-5'
O Claude Code não possui credenciais próprias — ele assina as chamadas ao Amazon Bedrock com as credenciais AWS já presentes no ambiente do desenvolvedor. A política de IAM (Gerenciamento de Identidade e Acesso da AWS) abaixo deve ser anexada ao principal IAM que os desenvolvedores utilizam (a role assumida via IAM Identity Center, por exemplo). Ela restringe chamadas Mantle apenas à região alvo:
A condição aws:RequestedRegion rejeita qualquer chamada Mantle feita fora do endpoint da Irlanda — mesmo que o desenvolvedor configure AWS_REGION incorretamente, o IAM bloqueia a chamada. Um detalhe importante: no Mantle, o recurso da política é um projeto, não um modelo. Isso significa que a política de identidade controla apenas a região. Para restringir também os modelos permitidos, é necessário usar uma política de controle de serviço (SCP).
Caminho 2: Application inference profile para regiões não cobertas pelo Mantle
O requisito de compliance do cliente era especificamente Londres, e o Mantle não oferece roteamento in-region para eu-west-2 — o endpoint EU do Mantle roteia por toda a geografia europeia, podendo processar em Frankfurt, Irlanda ou Paris. O classic Amazon Bedrock é a única opção para London.
Há ainda uma restrição adicional: conforme os model cards do Claude Opus 4.6 e do Claude Sonnet 4.6, eu-west-2 é atualmente a única região onde esses modelos oferecem inferência in-region no classic Amazon Bedrock. As versões Opus 4.7 e 4.8 são Geo-only nesse endpoint.
O problema é que esses modelos não podem ser chamados diretamente pelo seu model ID — o Amazon Bedrock exige que sejam invocados por meio de um inference profile. Os perfis definidos pelo sistema são cross-region (prefixos eu. e global.), o que contradiz o requisito. A solução é criar um application inference profile apontando para o ARN (Nome de Recurso da Amazon) do modelo base na região desejada:
Cada comando retorna um inferenceProfileArn no formato arn:aws:bedrock:eu-west-2:<account-id>:application-inference-profile/<id>. Esses ARNs são usados como identificadores de modelo no Claude Code. Application inference profiles também habilitam rastreamento de custo e uso por perfil na fatura AWS.
A configuração de ambiente fica assim:
# Route Claude Code through classic Bedrock in London
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_REGION=eu-west-2
# Map the model aliases to the London application inference profiles
export ANTHROPIC_DEFAULT_OPUS_MODEL='arn:aws:bedrock:eu-west-2::application-inference-profile/'
export ANTHROPIC_DEFAULT_SONNET_MODEL='arn:aws:bedrock:eu-west-2::application-inference-profile/'
Para implantações em equipe, a recomendação é definir essas variáveis em um arquivo de configuração gerenciado em vez do shell individual de cada engenheiro, garantindo consistência e controle centralizado.
A política IAM para esse caminho inclui os ARNs dos perfis de inferência e dos modelos base, além das ações necessárias:
Uma vantagem desse caminho em relação ao Mantle: o ARN do modelo base no resource da política permite restringir região e modelos em uma única política de identidade, sem precisar de SCP.
Verificando a conformidade com AWS CloudTrail
Toda chamada do Claude Code ao Amazon Bedrock deve aparecer no AWS CloudTrail da região alvo — e em nenhuma outra. A forma de consultar depende do caminho utilizado, pois os dois endpoints registram eventos de maneiras distintas.
Caminho 2 (classic Amazon Bedrock)
As invocações de modelo são registradas como InvokeModel na event source bedrock.amazonaws.com. Para consultar:
O Mantle registra inferências como CreateInference na event source bedrock-mantle.amazonaws.com, e esse é um evento de dados do CloudTrail. Antes de verificar qualquer coisa, é necessário habilitar os data events do bedrock-mantle com um advanced event selector em uma trail ou event data store. Após habilitar o logging, a consulta é feita no AWS CloudTrail Lake:
SELECT eventName, awsRegion, element_at(requestParameters, 'model') AS model
FROM
WHERE eventSource = 'bedrock-mantle.amazonaws.com'
AND eventName = 'CreateInference'
Independentemente do caminho, três verificações confirmam a conformidade: (1) o campo awsRegion de todos os eventos deve corresponder à região alvo; (2) a mesma consulta executada em todas as outras regiões deve retornar zero resultados; (3) qualquer evento com errorCode: AccessDenied deve ser rastreável a um teste intencional.
Comparativo entre os dois caminhos
Caminho 1 (Mantle): 7 regiões suportadas, modelos mais recentes (Sonnet 5, Opus 4.8, Haiku 4.5), zero recursos AWS adicionais a criar, 3 variáveis de ambiente.
Caminho 2 (classic Amazon Bedrock): apenas Londres disponível, modelos Opus 4.6 e Sonnet 4.6, criação de 2 application inference profiles, 4 variáveis de ambiente.
Antes de definir qual caminho seguir, a recomendação é verificar o status in-region atual nos model cards do Amazon Bedrock, pois a disponibilidade muda à medida que novos modelos chegam às regiões.
Limpeza e próximos passos
Para remover os application inference profiles criados no Caminho 2:
Application inference profiles não geram custo por si só — o custo vem das invocações de modelo. Remover perfis não utilizados mantém a conta organizada e reduz a superfície de invocação acidental. O Caminho 1 não requer limpeza além de desanexar a política IAM.
O Claude Code pode executar os dois endpoints na mesma sessão: defina CLAUDE_CODE_USE_BEDROCK=1 e CLAUDE_CODE_USE_MANTLE=1 juntos, e os model IDs no formato Mantle roteiam para o Mantle enquanto os demais vão para o classic Invoke — útil em migrações ou quando diferentes famílias de modelos estão em endpoints distintos.
Para implantação do Claude Code em escala empresarial com federação OIDC, integração com IAM Identity Center e observabilidade, consulte o repositório Claude Apps Gateway.
Agentes de Inteligência Artificial (IA) estão ficando cada vez mais autônomos, e as empresas estão rodando mais deles. O problema é que a confiança e a segurança não acompanharam esse ritmo. De acordo com a McKinsey, cerca de 80% das organizações já enfrentaram comportamentos de risco vindos de agentes de IA. Não por acaso, preocupações com segurança e risco lideram a lista de barreiras para escalar IA agêntica.
O que torna isso complicado é que a maioria dos mecanismos de controle existentes foi projetada para software previsível. Agentes decidem seu próprio caminho à medida que executam tarefas — e cada passo pode parecer legítimo individualmente, enquanto o conjunto das ações passa completamente despercebido.
Considere três exemplos concretos que ilustram bem o problema:
Um agente consulta a conta de um cliente e transfere dinheiro para um número de conta diferente — porque cada chamada foi avaliada isoladamente e aprovada.
Um agente realiza uma série de pedidos, cada um abaixo do limite de aprovação — porque nada estava somando o total contra o orçamento da sessão.
Um agente encontra uma ferramenta com falha e fica tentando novamente a noite toda, consumindo todo o orçamento de tokens — porque nada limitou o quanto ele poderia consumir.
Cada requisição era legítima. O problema aparece apenas no padrão — e o próprio agente é a última coisa em que você deveria confiar para detectar isso.
Amazon Bedrock AgentCore: segurança na camada de infraestrutura
A AWS desenvolveu o Amazon Bedrock AgentCore para dar às equipes o que elas precisam para construir, conectar e otimizar agentes em escala, sem precisar montar a infraestrutura por conta própria. Um princípio guia o serviço desde o início: controles de segurança pertencem à camada de infraestrutura, aplicados de forma consistente em todos os agentes — e não no código da aplicação, onde cada equipe os implementa de maneira diferente.
O gateway do AgentCore é onde essa ideia se concretiza. Trata-se de um ponto de entrada totalmente gerenciado e serverless para o tráfego de IA, roteando requisições para servidores Protocolo de Contexto de Modelo (MCP), Modelos de Linguagem de Grande Escala (LLMs), agentes e bases de conhecimento. Como toda chamada passa por ele, o gateway é o lugar natural para aplicar limites que valem independentemente de como um agente se comporta.
A AWS anunciou agora dois avanços importantes nesse trabalho: políticas temporais, alimentadas pelo Dogwood — uma nova linguagem de políticas open source criada especificamente para agentes de IA — e rate limiting no gateway.
Políticas temporais: controle sobre sequências de ações
As políticas do AgentCore já ofereciam controle determinístico sobre o comportamento dos agentes, verificando cada ação antes de ser executada para avaliar quem pode chamar qual ferramenta e sob quais condições. Essas verificações são stateless por design — cada requisição é julgada por seus próprios méritos, de forma rápida e verificável.
Mas à medida que os agentes assumem tarefas mais longas com menos supervisão, surge uma nova pergunta: as ações tomadas em conjunto somam algo que deveria ser permitido? Essa visão só é possível quando se observa a sequência de ações, não apenas as individuais.
As políticas temporais estendem as políticas do AgentCore para preencher essa lacuna. Em vez de julgar uma requisição de forma isolada, o motor de políticas também analisa o que o agente já fez naquela sessão e então permite ou nega a chamada com base nessa sequência de ações.
Na prática, isso significa que:
Uma transferência para o número de conta errado pode ser bloqueada por uma política que exige que o valor passado em uma chamada corresponda ao que uma chamada anterior retornou.
Uma política pode somar o que um agente gastou em uma sessão e bloquear a próxima compra assim que o orçamento for atingido — mesmo que essa compra esteja abaixo do limite individual.
É possível exigir que as etapas aconteçam em uma ordem definida, ou que uma ação significativa precise de aprovação humana registrada.
Permissões podem ser reduzidas automaticamente quando uma pessoa não está mais engajada na sessão.
Um ponto crucial: as políticas temporais são aplicadas na camada do gateway, fora do código do próprio agente. O agente não vê a lógica da política e não consegue raciocinar ao redor dela, independentemente de como é instruído ou de quais defeitos carrega. Para líderes de segurança que precisam aprovar sistemas autônomos, essa é a distinção que importa. É a diferença entre confiar que um agente vai se comportar e saber que o limite vale ao longo de todas as suas ações. As decisões são determinísticas, negam por padrão e são registradas com todo o contexto por trás delas.
Dogwood: a linguagem de políticas por trás das políticas temporais
Alimentando as políticas temporais está o Dogwood, uma nova linguagem de políticas criada especificamente para agentes de IA. Construído sobre a fundação do Cedar, o Dogwood foi projetado para lidar com uma nova dimensão de controle de agentes: avaliar se uma sequência de ações de um agente está em conformidade com uma política à medida que ela se desenrola.
O Dogwood incorpora o Cedar e adiciona construções temporais para governança de agentes, incluindo rate limits, janelas de tempo, etapas de pré-requisito e gatilhos de escalação. Ele está disponível como especificação open source e implementação de referência sob a licença Apache 2.0. Isso dá visibilidade total a como as políticas são avaliadas e permite que o ecossistema mais amplo construa ferramentas de suporte.
Rate limiting: controle sobre o que os agentes consomem
O custo de IA é uma questão de governança por si só, e com agentes ele começa por quão rapidamente eles consomem tokens e chamadas. Um agente executa quantas etapas julgar necessárias — então o custo de uma tarefa depende de como ele escolhe trabalhar, e não de uma taxa predeterminada. Sem limites, um loop de retry ou uma sessão incomumente pesada consome no ritmo que o agente decidir. Essa imprevisibilidade é uma restrição real para aprovação.
Disponível agora, é possível definir esses tetos diretamente no gateway do AgentCore. O rate limiting permite que equipes limitem o consumo por usuário em todas as ferramentas, modelos e agentes por trás do gateway, usando as identidades que já gerenciam via OAuth ou Gerenciamento de Identidade e Acesso (IAM). Os limites podem cobrir:
Requisições: quantas chamadas alguém faz, por segundo ou por minuto.
Tokens: quantos tokens um modelo processa para eles.
Conexões: por quanto tempo mantêm conexões abertas.
Ter as três métricas importa porque agentes geram custos de formas diferentes. Um loop de retry aparece como volume de requisições; uma tarefa com raciocínio intenso aparece como tokens; uma longa sessão de pesquisa aparece como uma conexão mantida aberta enquanto muito pouco tráfego se move. Qualquer medida única deixa uma brecha para esgotar um serviço sem acionar um limite.
Os limites se aplicam em janelas de por segundo e por minuto, o que contém o modo de falha que as equipes realmente enfrentam: um agente consumindo em uma taxa que ninguém pretendia, descoberto depois do fato. Os rate limits entram em vigor assim que configurados, sem alterações no código do agente. A alocação de capacidade passa a ser algo que as equipes de plataforma configuram, não constroem. Diferentes usuários, equipes, ferramentas e modelos podem ter tetos distintos, sem nenhuma lógica de throttling escrita em nenhum deles.
Para onde isso está indo
Os modelos continuam melhorando, e esse progresso é o que torna os agentes dignos de serem implantados. Mas também eleva o que está em jogo — um agente mais capaz toma ações mais consequentes com menos supervisão. O que uma empresa ganha com modelos melhores depende de conseguir rodar esses agentes com a mesma disciplina que aplica a tudo mais em produção.
Confiar em um agente não é realmente um julgamento sobre o modelo. É um julgamento sobre o sistema dentro do qual o modelo opera — e se esse sistema aguenta quando um agente se comporta de forma inesperada. Construir esse sistema é uma disciplina jovem, e a AWS indica que as perguntas dos clientes hoje são visivelmente mais sofisticadas do que as de um ano atrás.
Cada controle que sai do código da aplicação e vai para a plataforma é uma coisa a menos que precisa ser reconstruída, revisada e aprovada separadamente para cada agente. Quanto mais confiavelmente uma plataforma consegue delimitar o que os agentes fazem e quanto consomem, mais autonomia se pode conceder sem hesitação.
A AWS anunciou a disponibilidade geral das Runtime Instances, um novo recurso dentro do Amazon Bedrock AgentCore. A proposta é simples: permitir que equipes executem agentes de Inteligência Artificial (IA) em instâncias do Amazon EC2 próprias, sem precisar se preocupar com o gerenciamento da infraestrutura por baixo.
O AgentCore Runtime já existia com uma abordagem baseada em microVMs — ideal para sessões mais curtas e com inicialização rápida. As Runtime Instances chegam como uma opção complementar, voltada para cenários mais exigentes.
Para que serve e quando usar
Nem todo agente de IA tem o mesmo perfil de uso. Alguns precisam rodar por longos períodos, consumir muita memória ou até mesmo depender de hardware especializado, como GPUs. É exatamente para esses casos que as Runtime Instances foram projetadas.
Com esse novo recurso, as equipes têm acesso à amplitude de tipos de instâncias EC2 disponíveis na AWS, incluindo:
Instâncias com aceleração por GPU
Instâncias otimizadas para memória
Instâncias otimizadas para computação
Enquanto a opção serverless com microVMs suporta sessões de até 8 horas, as Runtime Instances ampliam esse limite para sessões de até 14 dias — um salto significativo para agentes que precisam de continuidade e persistência.
Como funciona na prática
A configuração pode ser feita pelo Console de Gerenciamento da AWS, pela Interface de Linha de Comando (CLI), pelos Kits de Desenvolvimento de Software (SDKs) ou por APIs. O fluxo básico consiste em criar um capacity provider (provedor de capacidade), especificando os tipos de instâncias EC2 que os agentes vão precisar, e depois associar os agentes a esse provedor.
Um ponto importante: é possível escolher o tipo de computação mais adequado para cada agente individualmente, ou até usar uma combinação de opções — tudo isso sem alterar a forma como os agentes são implantados ou invocados. O AgentCore cuida do provisionamento, da aplicação de patches, do escalonamento e do gerenciamento do ciclo de vida das instâncias.
Disponibilidade por região
As Runtime Instances já estão disponíveis nas seguintes regiões da AWS:
Leste dos EUA (Norte da Virgínia)
Leste dos EUA (Ohio)
Oeste dos EUA (Oregon)
Ásia-Pacífico (Mumbai)
Ásia-Pacífico (Singapura)
Ásia-Pacífico (Sydney)
Ásia-Pacífico (Tóquio)
Europa (Frankfurt)
Europa (Irlanda)
Modelo de cobrança
Em relação aos custos, a AWS cobra pelo gerenciamento da computação provisionada, somado aos custos normais das instâncias Amazon EC2 utilizadas. Para entender os detalhes de precificação, a AWS disponibiliza uma página de preços do AgentCore.
Onde aprender mais
Para quem quiser se aprofundar, a AWS publicou um post detalhado no AWS News Blog explicando o funcionamento do recurso. A documentação oficial do AgentCore também está disponível com guias técnicos para quem quiser começar a usar as Runtime Instances.
O problema: dados de IA isolados do restante da telemetria de segurança
Quando uma equipe de segurança investiga um incidente envolvendo sistemas de Inteligência Artificial (IA), ela precisa cruzar dados de comportamento do modelo com informações de identidade, rede e aplicação. O desafio é que, até então, os eventos de intervenção do Amazon Bedrock Guardrails ficavam disponíveis apenas no Amazon CloudWatch — separados do restante da telemetria de segurança centralizada no Amazon Security Lake.
A AWS publicou uma solução que resolve exatamente isso: um pipeline automatizado que captura eventos de intervenção do Amazon Bedrock, os transforma em registros compatíveis com o Open Cybersecurity Schema Framework (OCSF) e os entrega ao Security Lake como uma fonte personalizada. A partir daí, analistas do Centro de Operações de Segurança (SOC) podem consultar violações de guardrails lado a lado com dados de AWS Identity and Access Management (IAM), logs de fluxo do Amazon Virtual Private Cloud (Amazon VPC) e outras fontes — tudo via Amazon Athena.
Por que isso importa para segurança?
Quando um guardrail bloqueia uma tentativa de injeção de prompt ou redige informações sensíveis, esse evento tem valor investigativo comparável a uma tentativa de login mal-sucedida ou a um alerta de intrusão de rede. Ignorar essa telemetria ou mantê-la isolada significa perder correlações críticas.
Considere o cenário de uma organização financeira que utiliza o Amazon Bedrock em múltiplas unidades de negócio. Cada unidade aplica guardrails para bloquear conteúdo prejudicial, prevenir consultas fora do escopo, redigir Informações de Identificação Pessoal (PII) como números de conta, e detectar injeções de prompt. A equipe de segurança precisa responder a perguntas como:
Quais contas de usuário disparam mais intervenções de guardrail — e essas mesmas contas têm atividade IAM suspeita?
Tentativas de injeção de prompt estão correlacionadas com endereços IP que também aparecem nos logs de fluxo do VPC?
Qual é a tendência de violações em toda a organização comparada aos últimos 30 dias?
Com os eventos roteados para o Security Lake, uma única query no Athena cobre as três perguntas.
Visão geral da solução
A arquitetura do pipeline captura logs de invocação de modelos do Amazon Bedrock que contêm dados de rastreamento de guardrails, filtra apenas os eventos onde houve intervenção efetiva e os transforma em registros Detection Finding do OCSF (class_uid 2004). Os arquivos resultantes são gravados no Amazon Simple Storage Service (Amazon S3) do Security Lake no formato Apache Parquet comprimido com Zstandard (zstd).
A mesma infraestrutura — filtro de assinatura, transformação via AWS Lambda, gravação em Parquet e particionamento no S3 — suporta múltiplos tipos de evento apenas alterando o padrão de filtro e o mapeamento OCSF:
Uma aplicação chama o Amazon Bedrock via API InvokeModel ou Converse com um guardrail configurado.
O Amazon Bedrock avalia o guardrail e registra a invocação — incluindo os dados de rastreamento do guardrail — em um grupo de logs do CloudWatch Logs via logging de invocação de modelos.
Um filtro de assinatura identifica as entradas de log onde a ação do guardrail foi INTERVENED (conteúdo bloqueado ou mascarado).
O filtro entrega os registros correspondentes para uma função AWS Lambda responsável pela transformação OCSF.
A função Lambda transforma cada evento em um registro Detection Finding OCSF (class_uid 2004), agrupa os registros e os converte para o formato Parquet comprimido com zstd.
O arquivo Parquet é gravado no bucket S3 do Security Lake usando o caminho de partição obrigatório: ext/BedrockGuardrails/region=/accountId=/eventDay=/.
Os campos dos eventos de intervenção do Amazon Bedrock Guardrails são mapeados para atributos do Detection Finding OCSF (class_uid 2004) da seguinte forma:
class_uid: estático — 2004 (Detection Finding)
category_uid: estático — 2 (Findings)
severity_id: derivado do tipo de política — 3 (Médio) para conteúdo/tópico; 4 (Alto) para injeção de prompt
activity_id: estático — 1 (Create)
time: timestamp do log de invocação
cloud.provider: estático — AWS
cloud.region: região do log de invocação
cloud.account.uid: accountId do log de invocação
actor.user.uid: ARN de identidade do log de invocação
finding_info.title: derivado do tipo de política (ex: ContentPolicy Intervention)
finding_info.desc: ação/tópico do rastreamento do guardrail (ex: Blocked: HATE content detected on INPUT)
Um guardrail do Amazon Bedrock existente (ou criado durante a implantação)
Logging de invocação de modelos habilitado no Amazon Bedrock (com dados de rastreamento de guardrail ativados)
O primeiro passo é clonar o repositório:
git clone https://github.com/aws-samples/sample-bedrock-guardrails-security-lake.git
cd sample-bedrock-guardrails-security-lake
A implementação de referência implanta três stacks do CloudFormation: SecurityLakeSourceStack, TransformPipelineStack e MonitoringStack. Os comandos abaixo implantam as stacks na ordem correta de dependência:
O logging de invocação de modelos captura os dados de rastreamento do guardrail. É necessário ativar o logging completo de requisição e resposta para um grupo de logs do CloudWatch Logs, configurando textDataDeliveryEnabled para capturar os corpos de texto — que incluem a saída de rastreamento do guardrail quando ele está associado à invocação.
Registrar fonte personalizada no Security Lake
O BedrockGuardrails deve ser registrado como uma fonte personalizada no Security Lake usando a classe de evento DETECTION_FINDING. O Security Lake cria o prefixo S3 e o papel IAM para a fonte. A stack configura o papel do crawler do AWS Glue para descoberta de partições.
Esse filtro captura apenas os eventos onde o guardrail bloqueou ou modificou conteúdo — não os eventos de passagem bem-sucedida. Isso reduz o número de invocações do Lambda e, consequentemente, os custos.
Consultando violações no Athena
Após a implantação, as violações de guardrail geralmente aparecem nas tabelas do Security Lake em 5 a 10 minutos, dependendo do agendamento do crawler do AWS Glue. A partir daí, é possível executar queries de correlação entre serviços.
O exemplo abaixo identifica usuários que disparam tanto intervenções de injeção de prompt quanto atividade IAM incomum:
WITH guardrail_violators AS (
SELECT actor.user.uid AS user_arn,
COUNT(*) AS violation_count
FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_bedrockguardrails"
WHERE eventDay >= '20260701'
AND unmapped.guardrail_policy_type = 'PromptAttack'
GROUP BY actor.user.uid
),
iam_failures AS (
SELECT actor.user.uid AS user_arn,
COUNT(*) AS failure_count
FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_cloud_trail_mgmt_2_0"
WHERE eventDay >= '20260701'
AND status_id = 2
GROUP BY actor.user.uid
)
SELECT g.user_arn,
g.violation_count,
i.failure_count
FROM guardrail_violators g
JOIN iam_failures i ON g.user_arn = i.user_arn
ORDER BY g.violation_count DESC;
Também é possível acompanhar a tendência de violações por tipo de política ao longo do tempo para estabelecer baselines e detectar picos. A query abaixo mostra a tendência de 30 dias:
SELECT eventDay,
unmapped.guardrail_policy_type AS policy_type,
COUNT(*) AS violation_count
FROM "amazon_security_lake_glue_db_us_east_1"."amazon_security_lake_table_us_east_1_bedrockguardrails"
WHERE eventDay >= '20260623'
GROUP BY eventDay, unmapped.guardrail_policy_type
ORDER BY eventDay, violation_count DESC;
O mapeamento OCSF foi validado contra a versão 1.3.0 do schema, e o crawler do AWS Glue do Security Lake detecta corretamente os arquivos Parquet particionados para consulta.
Considerações de escala e múltiplas contas
Em volumes baixos de intervenção (dezenas de eventos por hora), gravações diretas via Lambda produzem arquivos Parquet de tamanho aceitável. Para volumes maiores, a AWS recomenda usar o Amazon Data Firehose com sua conversão nativa para Parquet e intervalo de buffer de 5 minutos — gerando arquivos maiores e menos numerosos, o que otimiza o desempenho de queries no Athena.
Para ambientes multi-conta, o esquema de particionamento (accountId=<account>) já suporta esse cenário nativamente. O pipeline de filtro e transformação deve ser implantado em cada conta de workload onde o logging de invocação de modelos estiver habilitado. Cada pipeline grava de forma cross-account no bucket do Security Lake do administrador delegado. A distribuição pode ser feita via CloudFormation StackSets em toda a organização.
Alternativa para quem ainda não usa o Security Lake
Para organizações que ainda não adotaram o Security Lake, é possível consultar eventos de intervenção de guardrails diretamente no CloudWatch Logs Insights usando o mesmo grupo de logs do filtro de assinatura. O CloudWatch Logs Insights suporta queries entre múltiplos grupos de logs, permitindo correlacionar eventos de guardrails com outras fontes do CloudWatch sem a etapa de transformação OCSF.
O Security Lake agrega valor quando é necessário fazer joins com fontes fora do CloudWatch em uma única camada de query — como logs de fluxo do VPC, logs DNS do Amazon Route 53 e findings de terceiros.
Limpeza do ambiente
Para evitar cobranças contínuas, as stacks devem ser destruídas na ordem inversa de dependência:
A integração entre o Amazon Bedrock Guardrails e o Amazon Security Lake representa um avanço importante para equipes de segurança que operam ambientes de IA na AWS. Ao transformar eventos de intervenção em registros OCSF padronizados e entregá-los ao Security Lake, a telemetria de IA deixa de ser um silo isolado e passa a fazer parte da análise unificada de segurança.
Analistas de SOC ganham a capacidade de correlacionar eventos de intervenção de IA com dados de IAM, rede e aplicação em uma única query — algo que antes exigiria múltiplas ferramentas e integrações manuais. A implementação de referência está disponível para clone e adaptação conforme a configuração de guardrails de cada organização.
O problema com controles de acesso tradicionais em agentes de IA
Antes dos agentes de IA, era geralmente suficiente que os controles de acesso tratassem cada ação como um evento independente. As aplicações dependiam de lógica de negócio determinística para garantir que as ações acontecessem na ordem correta e que os dados estivessem atualizados.
Agentes de IA se comportam de forma fundamentalmente diferente. Eles decidem em tempo de execução quais ferramentas chamar, com quais argumentos e em qual ordem. Essa flexibilidade, combinada com modelos cada vez mais inteligentes, torna os agentes ao mesmo tempo poderosos e difíceis de controlar.
Uma chamada de ferramenta pode parecer segura quando analisada isoladamente, mas ser prejudicial no contexto da chamada anterior — por exemplo, após ler de uma fonte de dados não confiável. A questão então passa a ser: como aplicar regras de autorização que levem em conta o histórico de sessão do agente, de uma forma que o próprio agente não consiga burlar?
O que são políticas temporais no AgentCore
As políticas temporais no Amazon Bedrock AgentCore permitem definir regras com estado (stateful) que determinam a autorização para os destinos do AgentCore Gateway, avaliando a requisição atual no contexto de eventos anteriores na trajetória do agente. Como essas políticas são executadas no perímetro do AgentCore Gateway, fora do próprio código do agente, o agente não pode interceptá-las nem manipulá-las.
Por que agentes precisam de políticas com estado
Os controles de acesso existentes no AgentCore Policy aplicam regras determinísticas e sem estado (stateless) a cada requisição individual. Esses controles são necessários, mas frequentemente insuficientes para agentes. Considere os seguintes cenários onde controles stateless falham em capturar problemas críticos:
Um agente chama uma ferramenta de consulta de cliente, alucina um número de conta diferente do retornado, e passa esse valor para uma ferramenta de transferência de fundos — movendo dinheiro para a conta errada.
Um agente descontrolado executa dezenas de operações em loop porque nada rastreia que a exposição acumulada já ultrapassou o limite de risco.
Um agente aprova e nega o mesmo sinistro de seguro em segundos.
Cada chamada de ferramenta individual nesses cenários passaria numa verificação de política stateless. O problema só fica aparente quando se observa a trajetória do agente — a sequência ordenada de ações em uma sessão. As políticas temporais estendem o AgentCore Policy com essa camada de aplicação consciente da trajetória, executando no gateway, fora do código do agente, de modo que não podem ser contornadas independentemente do que o agente faça, como foi instruído ou quais bugs existam no código.
Casos de uso comuns
Integridade de saída entre ferramentas encadeadas: exige que um argumento passado para a chamada atual corresponda exatamente à saída de uma chamada anterior, impedindo que o agente alucine ou substitua valores entre etapas.
Sequenciamento de chamadas de ferramentas: exige que uma ferramenta seja chamada antes de outra para verificar a aderência a procedimentos operacionais padrão (SOP).
Aprovação humana antes de ações privilegiadas: bloqueia chamadas destrutivas ou sensíveis até que um evento de aprovação humana explícita seja registrado na trajetória.
Atualidade dos dados: exige que uma consulta de dados tenha sido concluída dentro de um intervalo de tempo antes que uma ação dependente seja autorizada, evitando decisões baseadas em informações desatualizadas.
Como as políticas temporais funcionam
As políticas temporais se baseiam no mecanismo de políticas já usado para controle de acesso stateless. Elas introduzem o conceito de trajetórias de agentes — sequências delimitadas de ações identificadas por um principal e um ID de sessão. Os agentes nunca veem a lógica das políticas, nunca tocam no armazenamento de estado e não podem alterar os controles. Assim como nas demais funcionalidades do AgentCore Policy, as políticas temporais negam por padrão e a proibição tem precedência sobre a permissão.
Quando o gateway recebe uma chamada de ferramenta, o mecanismo de políticas: consulta o estado da trajetória para ações, entradas e saídas relevantes; avalia cada política temporal contra a requisição atual no contexto de seu escopo histórico; e retorna uma decisão determinística de ALLOW ou DENY, registrando o contexto completo da decisão.
Cada requisição avaliada por uma política temporal deve carregar um cabeçalho x-amzn-bedrock-agentcore-policy-session-id, que identifica a sessão à qual a requisição pertence. O limite pode refletir qualquer unidade de trabalho que faça sentido para a aplicação — uma conversa de usuário, uma tarefa com múltiplas etapas ou um fluxo de trabalho de longa duração.
Uma sessão nunca é definida apenas pelo seu ID. O AgentCore combina o ID de sessão com a identidade do usuário final para produzir uma sessão única — o que significa que duas identidades diferentes podem apresentar o mesmo ID de sessão e ainda assim serem tratadas como sessões completamente separadas. Dentro de uma sessão ativa, as trajetórias de agentes têm uma janela máxima de retrospecto de 24 horas. Qualquer evento de trajetória mais antigo que isso é automaticamente excluído.
Uma regra adicional governa a relação entre sessões e as próprias políticas: sempre que uma mudança é feita nas políticas de um mecanismo de políticas, as sessões existentes são invalidadas, garantindo que cada sessão seja avaliada contra o conjunto atual de políticas.
Aplicando políticas temporais a um agente de gestão de portfólios
Para tornar esses conceitos concretos, a AWS apresenta um exemplo hipotético de um agente de banco privado que ajuda assessores de investimento a gerenciar portfólios de clientes. O agente recupera perfis de clientes, carrega posições de portfólio, busca preços de mercado em tempo real, realiza análises e executa operações em nome do assessor.
No cenário, as seguintes ferramentas MCP (Protocolo de Contexto de Modelo) são expostas através do AgentCore Gateway: get_client_profile, load_portfolio, get_market_price, execute_trade e rebalance_portfolio. Há três perfis de assessores: juniores (autoridade limitada de negociação), seniores (autoridade total) e oficiais de compliance (acesso somente leitura).
Para autenticação, o exemplo utiliza o Amazon Cognito com tokens JWT (JSON Web Token) para autenticação de entrada no AgentCore Gateway. Consulte a documentação do AgentCore Gateway para aprender como configurar a autenticação.
As políticas temporais utilizam o Dogwood, uma nova linguagem de governança open source projetada para agentes e suas ferramentas. O Dogwood suporta a avaliação de políticas Cedar existentes e adiciona suporte a condições temporais. Por ser compatível com Cedar, os clientes podem continuar usando suas políticas atuais sem precisar migrar. Para mais detalhes sobre o Dogwood, consulte a documentação da linguagem ou este post do blog.
Fluxo de requisição pelo gateway e pela política
Quando o agente de portfólio inicia uma chamada de ferramenta, o seguinte ocorre: a requisição chega ao AgentCore Gateway; o assessor já está autenticado via AgentCore Identity; a requisição carrega o ID de trajetória da sessão atual; o mecanismo de políticas recupera o estado acumulado da trajetória; cada política temporal avalia a requisição atual contra esse histórico; se todas as políticas permitirem, a requisição segue para a ferramenta MCP; se qualquer política proibir, a requisição é negada e a negação é registrada; em caso de execução bem-sucedida, a ação e seu resultado são anexados ao estado da trajetória para avaliações futuras.
Figura 1: Fluxo de requisição pelo AgentCore Gateway e Policy — Imagem original — fonte: Aws
Os sete padrões de política aplicados ao exemplo
A equipe de compliance do exemplo exige os seguintes controles temporais antes que o agente entre em produção:
Política 1: Sequenciamento de fluxo de trabalho
O agente deve executar get_client_profile, depois load_portfolio, antes que qualquer operação seja executada. Sem o perfil do cliente, o agente não tem contexto verificado sobre quais portfólios pertencem a esse cliente, qual é a tolerância ao risco ou quais restrições de conta se aplicam.
permit (principal, action == AgentCore::Action::"FinTarget___load_portfolio", resource == AgentCore::Gateway::)
when temporal {
formerly within 5m (AgentCore::Action::"FinTarget___get_client_profile"::response{eventResource: resource})
};
permit (principal, action == AgentCore::Action::"FinTarget___rebalance_portfolio", resource == AgentCore::Gateway::)
when temporal {
formerly within 5m (AgentCore::Action::"FinTarget___load_portfolio"::response{eventResource: resource})
};
Política 2: Integridade de saída para entrada
O portfolio_id passado para execute_trade deve corresponder exatamente a um dos IDs retornados por get_client_profile. O agente não pode fabricar ou substituir um ID diferente. Isso impede que um atacante use injeção de prompt para direcionar o agente a operar contra o portfólio de outro cliente.
Uma chamada a get_market_price deve ter sido concluída nos últimos 30 segundos antes que execute_trade seja autorizado. Em mercados voláteis, mesmo uma cotação de 60 segundos atrás pode representar uma variação de preço significativa.
permit (
principal,
action == AgentCore::Action::"execute_trade",
resource
)
when temporal {
formerly within 30s (
AgentCore::Action::"get_market_price"::response{eventResource: resource}
)
};
Política 4: Limite de orçamento acumulado por trajetória
O valor total de operações em uma única sessão não pode ultrapassar $60.000. Um agente comprometido executando dezenas de pequenas operações que individualmente parecem normais ainda pode acumular uma exposição catastrófica.
permit (
principal,
action == AgentCore::Action::"execute_trade",
resource
)
when temporal {
exists (total: Long).
((sum amount for (amount: Long), (t: Timepoint).
where (formerly within 24h (
AgentCore::Action::"get_market_price"::request{input.cost: amount, eventResource: resource}
&& tp(t)))) == total
&& total < 60000)
};
Política 5: Aprovação humana para operações de grande valor (consumo único)
Qualquer operação acima de $25.000 exige a aprovação explícita do assessor. Cada aprovação é consumida por uma única operação. Uma segunda operação de grande valor exige uma nova aprovação, impedindo que o agente interprete uma única aprovação como permissão abrangente para múltiplas operações.
permit (
principal,
action == AgentCore::Action::"execute_trade",
resource
)
when {
context.input.cost < 25000 ||
temporal {
!(AgentCore::Action::"execute_trade"::response{eventResource: resource})
since within 24h (
AgentCore::Action::"approve_trade"::response{
input.status: "approved",
eventResource: resource}
)
}
};
Política 6: Exclusão mútua
O agente não pode comprar e depois vender o mesmo ativo na mesma trajetória se a venda resultar em prejuízo. A contradição em si é o sinal de que algo deu errado e a sessão deve ser revisada.
Após 15 minutos sem interação do assessor, o agente perde acesso a operações de escrita (execute_trade, rebalance_portfolio). O assessor pode se reengajar a qualquer momento para restaurar o acesso completo. Isso garante que uma operação autônoma prolongada não acumule riscos sem controle.
O modelo de cobrança é baseado nas requisições de autorização realizadas durante a execução do agente. Cada vez que um agente chama uma ferramenta pelo AgentCore Gateway, o Policy verifica a ação contra as regras definidas. As primeiras 100 políticas temporais por mecanismo de políticas estão incluídas no preço existente por requisição de autorização. Consulte a página de preços do AgentCore para mais detalhes.
Limpeza dos recursos
Para evitar cobranças contínuas, os recursos criados devem ser removidos na seguinte ordem: primeiro excluir as políticas temporais do mecanismo de políticas, depois desanexar o mecanismo de políticas do gateway e, por fim, excluir o mecanismo de políticas. Um mecanismo de políticas não pode ser excluído enquanto ainda contiver políticas ou permanecer anexado a um gateway.
Para listar e excluir as políticas, repita o comando de exclusão para cada uma das sete políticas:
As políticas temporais trazem autorização stateful e consciente de trajetória para sistemas de IA agêntica. Os sete padrões demonstrados — sequenciamento de fluxo de trabalho, integridade de saída para entrada, atualidade de dados, limites de orçamento acumulado, aprovações humanas no loop, exclusão mútua e decaimento progressivo de confiança — se generalizam para qualquer domínio onde agentes interagem com ferramentas sensíveis em tempo de execução.
Como a aplicação acontece no perímetro do AgentCore Gateway, fora do próprio raciocínio do agente, essas proteções permanecem à prova de adulteração independentemente do comportamento do modelo. Isso oferece uma forma declarativa e auditável de aplicar limites operacionais sem restringir a flexibilidade que torna os agentes valiosos. Para começar, consulte a documentação do AgentCore.
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:
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:
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:
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):
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.
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 targetName com 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 como sub, role, team ou tier.
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.
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.
