# ADR: Escalando Agentes em Produção com AgentCore Runtime Quotas

Em julho de 2026, a AWS elevou os limites padrão do AgentCore Runtime para 5.000 sessões ativas simultâneas em us-east-1/us-west-2 e 200 interações por segundo em todas as regiões. Este ADR documenta o contexto que forçou essa decisão de design, as opções arquiteturais que considerei para sistemas agênticos em escala financeira, e as consequências operacionais que você precisa planejar antes de colocar agentes em produção.

- URL: https://fernando.moretes.com/blog/adr-escalando-agentes-em-producao-com-agentcore-runtime-quotas-amazon-bedro

- Markdown: https://fernando.moretes.com/blog/adr-escalando-agentes-em-producao-com-agentcore-runtime-quotas-amazon-bedro/article.md?lang=pt

- Published: 2026-07-02T09:03:27.108Z

- Category: IA & Agentes

- Tags: bedrock-agentcore, agentic-ai, quota-management, financial-grade, aws-well-architected, session-scaling, observability, enterprise-ai

- Reading time: 9 min

- Source: [Amazon Bedrock AgentCore increases default runtime quota limits](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-bedrock-agentcore-increases-default-runtime-quota-limits/)

---

Cotas padrão dobradas não são apenas uma boa notícia de produto — elas são um sinal de que a AWS está apostando que workloads agênticos vão para produção em escala. Este ADR trata do que muda na arquitetura quando o teto sobe, e do que ainda pode te derrubar.

## Contexto e Forças: Por Que Isso Importa Agora

Desde o lançamento do Amazon Bedrock AgentCore, tenho acompanhado de perto como equipes de engenharia financeira tentam encaixar agentes de IA em fluxos de trabalho que exigem auditabilidade, latência controlada e isolamento de falhas. O problema recorrente não era a capacidade do modelo — era a infraestrutura de runtime. Limites conservadores de sessão forçavam arquiteturas de contorno: filas SQS para serializar chamadas de agente, Step Functions para gerenciar ciclos de vida de sessão fora da plataforma, e lógica de retry manual que duplicava o que o próprio AgentCore deveria fornecer.

O anúncio de 1º de julho de 2026 muda esse cálculo. Com 5.000 sessões ativas simultâneas em us-east-1 e us-west-2, e 2.500 nas demais regiões suportadas, o AgentCore passa a ser viável como runtime primário para casos de uso que antes exigiam soluções híbridas. Os 200 agent interactions per second e os 25 new sessions per second como padrão — sem necessidade de solicitação de aumento — eliminam uma categoria inteira de atrito operacional no onboarding de novos workloads.

Mas elevar o teto padrão não resolve os problemas de design que surgem quando você realmente usa essa capacidade. Em ambientes financeiros, cada sessão de agente carrega contexto sensível: dados de cliente, estado de transação, histórico de decisão. A escala horizontal de sessões amplifica a superfície de ataque, a complexidade de observabilidade e os riscos de custo. O sinal técnico aqui não é 'use mais agentes' — é 'agora você precisa de uma arquitetura de controle de sessão séria'.

## Novos Limites Padrão do AgentCore Runtime (Julho 2026)

- **5,000** — Sessões ativas simultâneas (us-east-1, us-west-2). Padrão sem solicitação de aumento de cota
- **2,500** — Sessões ativas simultâneas (demais regiões suportadas). Disponível em todas as regiões onde AgentCore está disponível
- **200/s** — Interações de agente por segundo (todas as regiões). Novo padrão regional uniforme
- **25/s** — Novas sessões criadas por segundo (todas as regiões). Taxa de criação de sessão — gargalo crítico em bursts

## As Forças Arquiteturais que Esse Anúncio Expõe

Quando você lê '5.000 sessões simultâneas', a primeira reação de engenharia é: 'ótimo, posso escalar'. A segunda reação — a que importa — deveria ser: 'o que acontece quando eu chego em 4.800 sessões e um burst de 300 usuários simultâneos tenta criar novas sessões a 25/s?'

O limite de **25 novas sessões por segundo** é o gargalo real nessa arquitetura. Em um sistema financeiro com picos de mercado — abertura de bolsa, janelas de liquidação, eventos de crédito — a taxa de criação de sessão pode exceder esse limite mesmo com headroom abundante no pool de sessões ativas. Isso exige um padrão de **session pre-warming**: criar sessões antecipadamente e mantê-las em um pool gerenciado, reutilizando-as para requisições entrantes em vez de criar uma nova sessão por interação de usuário.

O segundo vetor de pressão é o isolamento de contexto. Com 5.000 sessões ativas, cada uma potencialmente carregando contexto de cliente em memória de runtime, a questão de **onde o estado de sessão vive** torna-se crítica. O AgentCore gerencia o estado de sessão internamente, mas para fins de auditoria regulatória em ambientes financeiros, você precisa de uma trilha de auditoria externa e imutável. Isso significa integrar o AgentCore com DynamoDB (para estado de sessão projetado com TTL e partition key por `customerId#sessionId`) e S3 com Object Lock para logs de decisão de agente.

O terceiro vetor é custo. A 200 interações/s sustentadas, com cada interação invocando um modelo Bedrock (Claude, Titan, ou outro), os custos de token podem escalar não-linearmente. Sem circuit breakers por sessão e sem limites de token por interação configurados explicitamente, um agente mal instruído pode consumir orçamento de uma semana em horas.

## Opções Arquiteturais para Sessões de Agente em Escala

### Opção A: Sessão por Requisição (Stateless Pattern)

**Pros**
- Simples de implementar; sem gerenciamento de pool
- Isolamento completo entre requisições

**Cons**
- Consome o limite de 25 novas sessões/s rapidamente sob burst
- Overhead de criação de sessão adiciona latência P99 significativa
- Sem reutilização de contexto entre interações do mesmo usuário

**Verdict:** Aceitável apenas para workloads de baixo volume e baixa frequência

### Opção B: Session Pool com Pre-warming via Lambda Scheduled

**Pros**
- Absorve bursts sem atingir o limite de criação de sessão
- Latência de primeira interação controlada (sessão já ativa)
- Permite associação de contexto de usuário a sessões pré-aquecidas

**Cons**
- Complexidade de gerenciamento de pool; risco de sessões órfãs
- Custo de sessões ativas não utilizadas durante períodos de baixo tráfego
- Requer lógica de afinidade de sessão e limpeza com TTL no DynamoDB

**Verdict:** Recomendado para sistemas financeiros com padrões de tráfego previsíveis

### Opção C: Orquestração via Step Functions com AgentCore como Worker

**Pros**
- Controle explícito de ciclo de vida de sessão com estado auditável
- Retry/idempotência nativos do Step Functions; integração com CloudWatch Alarms
- Separação clara entre orquestração de negócio e execução de agente

**Cons**
- Latência adicional por hop de Step Functions (50-200ms por transição de estado)
- Custo de transições de estado em workflows de alta frequência
- Complexidade de design de máquina de estados para fluxos de agente longos

**Verdict:** Ideal para workflows de aprovação, compliance e processos de negócio de longa duração

### Opção D: Multi-região Ativo-Ativo com Roteamento por Latência

**Pros**
- Usa o pool de 5.000 sessões de us-east-1 e us-west-2 em paralelo
- Resiliência regional; sem single point of failure de runtime

**Cons**
- Estado de sessão não é replicado entre regiões pelo AgentCore nativamente
- Complexidade de consistência de contexto e afinidade de sessão cross-region
- Custo de dados cross-region e latência de sincronização de estado

**Verdict:** Válido apenas para requisitos de RTO < 1min; exige design cuidadoso de consistência

## A Decisão: Session Pool com Controle de Admissão e Auditoria Externa

Para sistemas financeiros operando com AgentCore em produção, a decisão que defendo é a **Opção B com elementos da Opção C**: um pool de sessões pré-aquecidas gerenciado por Lambda com controle de admissão, combinado com orquestração via Step Functions para fluxos que exigem aprovação ou auditoria regulatória.

O raciocínio é direto: o limite de 25 novas sessões/s é o único gargalo que não pode ser resolvido com mais capacidade de runtime — ele é um limite de taxa de API, não de capacidade de computação. Pre-warming transforma esse limite de um gargalo de burst em um parâmetro de planejamento de capacidade. Com um Lambda agendado a cada 5 minutos verificando o pool e criando sessões até um target configurável (digamos, 200 sessões prontas), você absorve bursts de até 200 usuários simultâneos sem tocar no limite de criação.

Para o controle de admissão, uso um DynamoDB com partition key `poolId` e sort key `sessionId`, com um atributo `status` (AVAILABLE | IN_USE | DRAINING) e TTL de 30 minutos. Uma Lambda de dispatcher faz um `UpdateItem` condicional com `ConditionExpression: attribute_exists(sessionId) AND #status = :available` — isso garante que dois dispatchers concorrentes nunca atribuam a mesma sessão. A idempotência é garantida pelo `correlationId` da requisição original, armazenado como atributo da sessão.

Para auditoria, cada interação de agente — entrada, saída, ferramentas invocadas, tokens consumidos — é publicada em um stream Kinesis Data Firehose com destino S3 com Object Lock (COMPLIANCE mode, 7 anos para regulação financeira brasileira). O KMS key policy restringe `kms:Decrypt` a roles de auditoria com condição `aws:PrincipalTag/Role: AuditReader`, impedindo que a aplicação principal acesse seus próprios logs de auditoria.

## Arquitetura de Session Pool com Controle de Admissão para AgentCore

Fluxo de ciclo de vida de sessão AgentCore em ambiente financeiro: pre-warming, despacho com controle de admissão, execução de agente, auditoria imutável e drenagem de sessão.

### 🌐 Entrada / Ingress

- API Gateway REST + WAF (edge)
- Lambda Dispatcher Conditional UpdateItem (compute)

### 🗄️ Pool de Sessões / Session Pool

- DynamoDB poolId | sessionId status + TTL 30min (data)
- Lambda Warmer EventBridge 5min Cria sessões até target (compute)

### 🤖 AgentCore Runtime

- AgentCore Runtime 5k sessões / us-east-1 200 interactions/s (ai)
- Bedrock Model Claude / Titan Token budget enforced (ai)

### 🔐 Auditoria & Segurança / Audit & Security

- Kinesis Firehose Interação → S3 (messaging)
- S3 Object Lock COMPLIANCE 7 anos KMS AuditReader only (storage)
- CloudWatch SLO: sessions/quota Alarm: >80% pool used (security)

### 🔄 Fluxos Regulatórios / Regulatory Flows

- Step Functions Aprovação / Compliance Workflow de longa duração (compute)

### Fluxos

- apigw -> dispatcher: requisição + correlationId
- dispatcher -> dynamo: UpdateItem condicional
status: AVAILABLE→IN_USE
- warmer -> agentcore: CreateSession (pré-aquecimento)
- warmer -> dynamo: Registra sessionId no pool
- dispatcher -> agentcore: InvokeAgent (sessionId alocado)
- agentcore -> bedrock: Invocação de modelo
com token budget
- agentcore -> firehose: Evento de interação
(input/output/tools/tokens)
- firehose -> s3audit: Parquet + KMS encrypt
- dispatcher -> sfn: Fluxos de aprovação
(async)
- agentcore -> cw: Métricas: sessions_active
interactions_per_sec

## Observabilidade: O Que Monitorar Quando Sessões Escalam

Com 5.000 sessões potencialmente ativas, a observabilidade não pode ser reativa — você precisa de SLOs definidos antes de ir para produção. Os três sinais que instrumentalizo em qualquer deployment AgentCore em escala financeira são:

**1. Pool Utilization Ratio**: `sessions_in_use / pool_target`. Alarme em 80% — não em 100%. A 80%, o warmer Lambda deve ser acionado imediatamente para criar sessões adicionais. Se você esperar 100%, já está rejeitando requisições. No CloudWatch, isso é uma métrica customizada publicada pelo dispatcher com dimensões `PoolId` e `Region`, com um alarm action que invoca o warmer via SNS.

**2. Session Creation Lag**: tempo entre a requisição de nova sessão e a sessão estar disponível para uso. Em condições normais com pre-warming, isso deve ser zero (sessão já disponível no pool). Se começar a subir, indica que o warmer não está mantendo o ritmo — ou que o limite de 25 sessões/s está sendo atingido. Um CloudWatch Metric Math de `p99(session_allocation_latency)` acima de 500ms deve disparar um alarme de capacidade.

**3. Token Budget Exhaustion Rate**: percentual de interações que atingiram o limite de tokens configurado por sessão. Em sistemas financeiros, um agente que esgota seu budget de tokens provavelmente está em um loop ou recebeu um prompt adversarial. Esse sinal deve acionar tanto um alarme operacional quanto um evento de segurança — com correlação ao `sessionId` e `customerId` para investigação.

Para correlação distribuída, injeto o `correlationId` da requisição original como atributo de sessão AgentCore e como campo em todos os eventos Firehose. Isso permite rastrear uma interação de usuário desde o API Gateway até o log de auditoria S3, passando por todas as invocações de modelo — essencial para investigações de compliance.

> **Consequências: O Que Pode Dar Errado com Sessões em Escala:** **Sessões órfãs acumulam custo silenciosamente.** Se o dispatcher falhar após alocar uma sessão mas antes de marcar `IN_USE`, a sessão fica presa como `AVAILABLE` mas com contexto contaminado. Implemente um Lambda de reconciliação que varre sessões com `last_activity > 15min` e status `IN_USE`, drena-as e cria substitutas. Sem isso, você vai acumular sessões com contexto stale que causam respostas incorretas e cobranças desnecessárias.

**O limite de 25 sessões/s é por conta AWS, não por região.** Se você opera múltiplos ambientes (dev, staging, prod) na mesma conta em us-east-1, todos compartilham esse limite. Separe ambientes em contas AWS distintas com AWS Organizations — não é opcional em ambientes financeiros regulados.

**Burst de criação de sessão pode mascarar um ataque.** Um aumento súbito na taxa de criação de sessão pode ser tráfego legítimo ou uma tentativa de exaustão de recursos. Configure um WAF rate rule no API Gateway com limite de 10 requisições de criação de sessão por IP por segundo, e uma regra de AWS Shield Advanced para padrões anômalos. O custo de uma sessão AgentCore criada por um atacante é seu custo — não o dele.

## Implicações Regulatórias e de Governança para Mercados Financeiros

O aumento de cotas do AgentCore chega em um momento em que reguladores financeiros globais — incluindo o Banco Central do Brasil com suas diretrizes de IA para instituições financeiras, e o DORA na Europa — estão formalizando requisitos para sistemas de IA em produção. Escalar agentes para 5.000 sessões simultâneas sem uma estratégia de governança correspondente é um risco regulatório, não apenas técnico.

Os três requisitos de governança que todo deployment AgentCore em ambiente financeiro deve endereçar são: **explicabilidade de decisão**, **controle de acesso granular** e **testabilidade adversarial**.

Para explicabilidade, o registro de cada interação de agente no Firehose/S3 não é suficiente — você precisa registrar *por que* o agente tomou cada decisão: quais ferramentas considerou, quais descartou, qual foi o raciocínio intermediário. Isso requer configurar o AgentCore com `enableTrace: true` e capturar os trace events, não apenas o output final. Em uma auditoria do BACEN, 'o modelo decidiu' não é uma resposta aceitável.

Para controle de acesso, cada sessão AgentCore deve ser associada a uma identidade de usuário final verificada — não apenas à role IAM da aplicação. Isso significa propagar o `sub` do token JWT do usuário como atributo de sessão e usar esse atributo em políticas de autorização de ferramenta dentro do agente. Um agente que pode invocar qualquer ferramenta para qualquer usuário é uma violação do princípio de menor privilégio no nível de runtime.

Para testabilidade adversarial, com 200 interações/s disponíveis, você tem capacidade para rodar testes de red team automatizados em ambiente de staging sem impactar produção. Implemente um pipeline de CI/CD que executa um conjunto de prompts adversariais conhecidos contra cada nova versão de instrução de agente antes do deploy — e bloqueie o deploy se a taxa de resposta inadequada exceder um threshold definido.

## AgentCore em Escala: Lentes do Well-Architected

- **security**: Propague identidade de usuário final como atributo de sessão AgentCore. Use KMS CMK com key policy restritiva para logs de auditoria. Configure WAF rate limiting em criação de sessão. Separe ambientes em contas AWS distintas.
- **reliability**: Implemente session pool pre-warming para absorver bursts sem atingir o limite de 25 sessões/s. Reconciliação periódica de sessões órfãs. Circuit breaker por sessão para evitar loops de agente. Multi-AZ para DynamoDB de controle de pool.
- **performance**: Pool utilization ratio como SLO primário (target < 80%). Alarm em p99 de session allocation latency > 500ms. Token budget por sessão para evitar interações de longa duração que bloqueiam capacidade.

## Anti-Padrões Comuns ao Escalar AgentCore

- Criar uma nova sessão AgentCore para cada requisição HTTP sem pool — esgota o limite de 25 sessões/s em qualquer burst moderado e adiciona latência desnecessária de criação de sessão ao P99.
- Usar a mesma conta AWS para dev, staging e prod com AgentCore — todos os ambientes compartilham as cotas de runtime, e um teste de carga em staging pode degradar produção.
- Não configurar token budget por sessão — um agente em loop ou com prompt adversarial pode consumir orçamento de modelo em minutos, sem alarme até o fim do ciclo de billing.
- Registrar apenas o output final do agente sem os trace events — em uma auditoria regulatória, você não consegue reconstituir o raciocínio do agente e a resposta 'o modelo decidiu' não é aceitável.
- Não implementar lógica de drenagem de sessão durante deploys de nova versão de instrução — sessões ativas com a versão anterior continuam respondendo com comportamento desatualizado durante o rollout.

> **Nota do Arquiteto:** Na prática, o que me preocupa nesse anúncio não é o aumento de cota em si — é que ele vai encorajar equipes a colocar agentes em produção sem ter resolvido o problema de governança de sessão primeiro. Já vi isso acontecer com Lambda concurrency e com Kinesis shards: a capacidade cresce antes da maturidade operacional, e o resultado são incidentes de custo e de dados que custam muito mais do que o tempo que teria sido necessário para desenhar o controle de admissão corretamente. Minha recomendação concreta: antes de usar mais de 500 sessões simultâneas em produção, implemente o pool com DynamoDB, o alarme de utilização em 80%, e o trace logging no Firehose — nessa ordem, sem pular etapas. A lição aprendida é que em sistemas financeiros, a capacidade de escalar é um risco até que você tenha a observabilidade para entender o que está acontecendo nessa escala.

## Veredicto: Use a Capacidade, Mas Governe Antes de Escalar

O aumento de cotas padrão do AgentCore é uma mudança genuinamente significativa para quem está construindo sistemas agênticos em produção — elimina uma categoria de atrito operacional e torna o AgentCore viável como runtime primário para workloads de escala financeira. Mas a decisão arquitetural correta não é 'escale para 5.000 sessões' — é 'implemente controle de admissão, auditoria imutável e observabilidade de pool antes de usar mais do que 10% dessa capacidade'. O limite de 25 novas sessões/s é o gargalo real; o session pre-warming com DynamoDB resolve isso. A separação de ambientes em contas AWS distintas é não-negociável em contextos regulados. E o trace logging com enableTrace: true é o que separa um sistema auditável de um sistema que apenas funciona. Para equipes financeiras: este é o momento de construir a fundação de governança de sessão — não de simplesmente aumentar o target do pool.

**Rating:** Adote com Governança / Adopt with Govern

## Referências

- [Amazon Bedrock AgentCore increases default runtime quota limits (AWS What's New, Jul 1 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/amazon-bedrock-agentcore-increases-default-runtime-quota-limits/)
- [AgentCore Runtime Release Notes — Increased Default Service Quotas (June 2026)](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/release-notes.html)
- [Quotas for Amazon Bedrock AgentCore](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/bedrock-agentcore-limits.html)
- [AgentCore Developer Guide](https://docs.aws.amazon.com/bedrock-agentcore/)
- [AgentCore Supported Regions](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-regions.html)
- [Amazon Bedrock AgentCore Product Page](https://aws.amazon.com/bedrock/agentcore/)
- [Amazon Bedrock AgentCore now available in four additional AWS Regions (AWS What's New, Jun 2026)](https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-bedrock-agentcore-four-additional-regions/)
- [AWS Well-Architected Framework — Machine Learning Lens](https://docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html)