Author: Make.com Service User

O desafio de observar agentes de IA fora da AWS

Quando você constrói agentes de inteligência artificial com frameworks como Strands Agents, LangGraph ou CrewAI, a observabilidade sobre o comportamento desses agentes é indispensável. Isso vale independentemente de onde eles estejam rodando: no Amazon EKS, no Amazon ECS, no AWS Lambda, em servidores on-premises ou em outros provedores de nuvem como Google Cloud Platform (GCP) ou Microsoft Azure.

O Amazon Bedrock AgentCore é a plataforma da AWS para construir, conectar e otimizar agentes em escala, com suporte a qualquer framework ou modelo. Dentro dela, o Amazon Bedrock AgentCore Observability oferece rastreamento nativo, monitoramento e análises que ferramentas locais de monitoramento de nuvem não entregam por padrão. O ponto de atenção: nativamente, o recurso suporta apenas agentes implantados no runtime do AgentCore dentro da AWS. Para agentes rodando em outros ambientes, é necessária configuração adicional para enviar a telemetria ao dashboard.

A AWS publicou um guia completo mostrando exatamente como fazer essa configuração. A seguir, apresentamos os principais conceitos e passos para colocar isso em prática.

Como a solução funciona

A abordagem utiliza o AWS Distro for OpenTelemetry (ADOT) — a Distribuição AWS para OpenTelemetry — rodando em processo junto com a aplicação do agente. O ADOT instrumenta automaticamente o framework do agente, captura spans seguindo as convenções semânticas de IA generativa e exporta a telemetria diretamente para o endpoint OTLP (Protocolo de Telemetria OpenTelemetry) do Amazon CloudWatch, usando autenticação SigV4 com credenciais do IAM (Gerenciamento de Identidade e Acesso).

São três componentes centrais para enviar telemetria de um agente externo ao painel do AgentCore Observability:

• Auto-instrumentação ADOT: cuida de toda a complexidade de exportar telemetria de ambientes fora da AWS.
• Credenciais IAM: utilizadas pelo ADOT para autenticar com o CloudWatch e encaminhar traces, métricas e logs ao dashboard.
• Variáveis de ambiente: contêm configurações específicas do OpenTelemetry para roteamento e autenticação.

Do ponto de vista de serviços AWS envolvidos, o Amazon CloudWatch serve como base para ingestão e armazenamento da telemetria. O AgentCore Observability adiciona dashboards especializados para agentes de IA. O ADOT fornece a capacidade de instrumentação multiplataforma. E o IAM garante a autenticação segura entre os ambientes externos e a AWS.

A observabilidade é um pilar fundamental de IA responsável. Ao rotear a telemetria para o AgentCore Observability, é possível enxergar as cadeias de raciocínio do agente, invocações de ferramentas e saídas do modelo. Isso permite detectar alucinações, monitorar respostas inadequadas, acompanhar o uso de tokens para governança de custos e auditar o comportamento dos agentes em diferentes ambientes — algo especialmente crítico para agentes rodando fora da AWS, onde problemas poderiam passar despercebidos sem uma observabilidade centralizada.

Pré-requisitos

Antes de começar, é necessário garantir que você tem:

• Uma conta AWS com acesso ao Amazon Bedrock configurado (o walkthrough usa o Claude Haiku). Verifique os modelos suportados por região da AWS.
• O CloudWatch Transaction Search habilitado na conta (configuração única).
• Python 3.10 ou superior instalado no ambiente não-AWS.
• Credenciais de usuário IAM (access key ID e secret access key) com permissões para: bedrock:InvokeModel, operações de logs no CloudWatch, operações do X-Ray e cloudwatch:PutMetricData.
• Acesso HTTPS de saída para endpoints da AWS a partir do seu ambiente.

Para habilitar o CloudWatch Transaction Search (uma vez por conta), execute:

aws xray update-trace-segment-destination --destination CloudWatchLogs --region us-east-1

Para verificar se está ativo:

aws xray get-trace-segment-destination --region us-east-1
# Expected: {"Destination": "CloudWatchLogs", "Status": "ACTIVE"}

Passo a passo de configuração

Passo 1: Instalar as dependências

No ambiente não-AWS (servidor on-premises, VM no GCP, VM no Azure ou qualquer máquina com acesso à internet):

pip install "aws-opentelemetry-distro>=0.10.0" boto3 "strands-agents[otel]"

O pacote aws-opentelemetry-distro inclui a auto-instrumentação ADOT com exportadores OTLP específicos para AWS e o aws_configurator, que cuida da autenticação SigV4. O pacote strands-agents[otel] fornece a emissão de traces OpenTelemetry a partir do framework Strands.

Passo 2: Configurar credenciais AWS

export AWS_ACCESS_KEY_ID=<your-access-key-id>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
export AWS_REGION=us-east-1

Nota de segurança: Para ambientes de produção, a AWS recomenda usar o IAM Roles Anywhere em vez de chaves de acesso de longa duração. Com esse recurso, workloads on-premises podem obter credenciais temporárias usando certificados X.509.

Passo 3: Definir variáveis de ambiente do OpenTelemetry

Essas variáveis configuram o ADOT para rotear a telemetria ao dashboard do AgentCore Observability:

export AGENT_OBSERVABILITY_ENABLED=true
export OTEL_PYTHON_DISTRO=aws_distro
export OTEL_PYTHON_CONFIGURATOR=aws_configurator
export OTEL_RESOURCE_ATTRIBUTES="service.name=my-external-agent,aws.log.group.names=/aws/bedrock-agentcore/runtimes/my-external-agent"
export OTEL_EXPORTER_OTLP_LOGS_HEADERS="x-aws-log-group=/aws/bedrock-agentcore/runtimes/my-external-agent,x-aws-log-stream=runtime-logs,x-aws-metric-namespace=bedrock-agentcore"
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_TRACES_EXPORTER=otlp

Pontos importantes sobre essa configuração:

• AGENT_OBSERVABILITY_ENABLED=true ativa o processamento de telemetria específico para IA generativa no ADOT.
• OTEL_PYTHON_DISTRO=aws_distro e OTEL_PYTHON_CONFIGURATOR=aws_configurator ativam a configuração OpenTelemetry específica para AWS, incluindo a assinatura SigV4 para o endpoint OTLP do CloudWatch.
• OTEL_RESOURCE_ATTRIBUTES com aws.log.group.names instrui o CloudWatch a indexar a telemetria no dashboard do AgentCore Observability. Sem isso, os traces vão para os logs genéricos do Amazon CloudWatch.
• OTEL_EXPORTER_OTLP_LOGS_HEADERS com x-aws-metric-namespace=bedrock-agentcore roteia métricas no formato de métrica embarcada para o namespace correto do CloudWatch.

Passo 4: Criar a aplicação do agente

Crie um arquivo chamado agent_test.py com um agente Strands:

from strands import Agent
from strands.models.bedrock import BedrockModel
from opentelemetry import baggage
from opentelemetry.context import attach
import time

# Configure the Bedrock model
model = BedrockModel(
    model_id="us.anthropic.claude-haiku-4-5-20251001-v1:0",
    region_name="us-east-1"
)

# Create the agent
agent = Agent(
    model=model,
    system_prompt="You are a helpful travel assistant."
)

# Set session ID for AgentCore session tracking
# All agent calls after attach() share same session ID for multiple requests/responses
session_id = f"external-session-{int(time.time())}"
ctx = baggage.set_baggage("session.id", session_id)
attach(ctx)

# Run the agent
response = agent("What are the top 3 things to do in Tokyo?")
print(response)

Passo 5: Executar com auto-instrumentação ADOT

O comando opentelemetry-instrument envolve o processo Python com o ADOT, instrumentando automaticamente as chamadas ao Amazon Bedrock e as operações do framework Strands:

opentelemetry-instrument python3.12 agent_test.py

A resposta do agente aparece no terminal. Em segundo plano, o ADOT captura traces, spans e logs, exportando tudo para o CloudWatch. A telemetria fica disponível no dashboard em dois a três minutos após a execução.

Validação a partir do Google Cloud Platform

Para confirmar que a solução funciona a partir de um provedor de nuvem de terceiros, a AWS testou a mesma configuração a partir do Google Cloud Shell — um terminal baseado em navegador rodando na infraestrutura do GCP.

A configuração no Google Cloud Shell segue exatamente o mesmo padrão: instalação das dependências, definição das credenciais AWS como variáveis de ambiente e configuração das variáveis ADOT, desta vez com nomes de serviço identificando o ambiente GCP (por exemplo, gcp-hosted-agent):

# Create a virtual environment
python3.12 -m venv venv
source venv/bin/activate

# Install dependencies
pip install "aws-opentelemetry-distro" boto3 "strands-agents[otel]"

# Set AWS credentials
export AWS_ACCESS_KEY_ID=<your-access-key-id>
export AWS_SECRET_ACCESS_KEY=<your-secret-access-key>
export AWS_REGION=us-east-1

# Set ADOT environment variables
export AGENT_OBSERVABILITY_ENABLED=true
export OTEL_PYTHON_DISTRO=aws_distro
export OTEL_PYTHON_CONFIGURATOR=aws_configurator
export OTEL_RESOURCE_ATTRIBUTES="service.name=gcp-hosted-agent,aws.log.group.names=/aws/bedrock-agentcore/runtimes/gcp-hosted-agent"
export OTEL_EXPORTER_OTLP_LOGS_HEADERS="x-aws-log-group=/aws/bedrock-agentcore/runtimes/gcp-hosted-agent,x-aws-log-stream=runtime-logs,x-aws-metric-namespace=bedrock-agentcore"
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_TRACES_EXPORTER=otlp

cat > agent_test.py << 'EOF'
from strands import Agent
from strands.models.bedrock import BedrockModel
from opentelemetry import baggage
from opentelemetry.context import attach
import time

model = BedrockModel(
    model_id="us.anthropic.claude-haiku-4-5-20251001-v1:0",
    region_name="us-east-1"
)
agent = Agent(model=model, system_prompt="You are a helpful assistant.")

# Set session ID for AgentCore session tracking
# All agent calls after attach() share same session ID for multiple requests/responses
session_id = f"gcp-session-{int(time.time())}"
ctx = baggage.set_baggage("session.id", session_id)
attach(ctx)

response = agent("What are the top 3 things to do in Paris?")
print(response)
EOF

opentelemetry-instrument python3.12 agent_test.py

Em dois a três minutos, o agente gcp-hosted-agent aparece no dashboard do AgentCore Observability ao lado de agentes rodando no runtime do AgentCore ou em outros ambientes. A telemetria é idêntica à produzida por agentes hospedados no runtime do AgentCore: sessões, traces, métricas de span, uso de tokens e latência — tudo em uma visão unificada, independentemente de onde o agente roda.

Comparação: ambientes não-AWS vs. runtime do AgentCore

Embora este guia use o Strands Agents, o mesmo padrão baseado em ADOT se aplica a outros frameworks compatíveis com OpenTelemetry. A tabela abaixo resume as principais diferenças entre as duas abordagens:

• Telemetria suportada: Em ambientes não-AWS, as variáveis OTEL precisam ser configuradas manualmente. No runtime do AgentCore, a configuração é automática e embutida.
• Gerenciamento de credenciais: Em ambientes externos, usa-se access key/secret do IAM ou o IAM Roles Anywhere. No runtime do AgentCore, a role IAM é atribuída automaticamente.
• Melhor para: A abordagem manual é ideal para agentes on-premises, no GCP, no Azure ou em qualquer ambiente não-AWS. O runtime do AgentCore é ideal para agentes implantados na AWS com AgentCore.

Ambientes validados

A AWS testou a abordagem de auto-instrumentação ADOT em dois ambientes não-AWS:

• On-premises (simulado): servidor standalone rodando fora da AWS — agente Strands reportando telemetria (sessões, traces, spans) no AgentCore Observability com sucesso.
• Google Cloud Shell (GCP): terminal baseado em navegador rodando no Google Cloud Platform — agente Strands reportando telemetria com sucesso.

Boas práticas

Com base nos testes realizados, a AWS recomenda:

• Use nomes descritivos: o service.name em OTEL_RESOURCE_ATTRIBUTES se torna o nome do agente no dashboard. Use nomes que identifiquem o ambiente, como prod-onprem-support-agent ou staging-gcp-research-agent.
• Valide as credenciais antes de rodar o agente: execute python -c "import boto3; print(boto3.client('sts').get_caller_identity())". Se falhar, o ADOT também falhará silenciosamente.
• Use Python 3.10 ou superior: o ADOT exige Python 3.10+. Python 3.12 é recomendado para melhor compatibilidade.
• Defina session IDs para conversas multi-turno: use a API de baggage do OpenTelemetry para propagar IDs de sessão:

  from opentelemetry import baggage
  from opentelemetry.context import attach
  ctx = baggage.set_baggage("session.id", "my-session-123")
  attach(ctx)

• Rotacione as credenciais regularmente: para produção, evite chaves de acesso de longa duração. Considere o IAM Roles Anywhere para workloads on-premises, ou use a federação de identidade do seu provedor de nuvem para assumir roles IAM da AWS.

Limpeza dos recursos

Para remover os recursos criados durante o walkthrough:

# Delete the IAM access key (if created for testing)
aws iam delete-access-key --user-name <your-user> --access-key-id <your-key-id>

# Optionally delete the auto-created CloudWatch log groups
aws logs delete-log-group --log-group-name /aws/bedrock-agentcore/runtimes/my-external-agent --region us-east-1
aws logs delete-log-group --log-group-name /aws/bedrock-agentcore/runtimes/gcp-hosted-agent --region us-east-1

O walkthrough utiliza Amazon Bedrock, Amazon CloudWatch e AWS X-Ray, que geram custos. Consulte as páginas de preços de cada serviço para detalhes.

Conclusão

O Amazon Bedrock AgentCore Observability não se limita a agentes rodando no runtime do AgentCore ou dentro da AWS. Com a auto-instrumentação ADOT, credenciais IAM e as variáveis de ambiente OpenTelemetry corretas, é possível enviar telemetria de qualquer ambiente com acesso à internet — on-premises, GCP, Azure ou qualquer outro lugar — para o mesmo dashboard centralizado.

A configuração exige apenas um pip install e um conjunto de variáveis de ambiente. A telemetria resultante é idêntica à produzida por agentes hospedados no runtime do AgentCore: sessões, traces, métricas de span e uso de tokens em uma visão unificada.

Para começar, clone o código de exemplo no GitHub e siga as instruções do README. Para agentes já rodando na AWS mas fora do runtime do AgentCore (EKS, ECS, Lambda), consulte o tutorial de AgentCore Observability para agentes hospedados no EKS. Para agentes no runtime do AgentCore, a observabilidade é configurada automaticamente — veja como adicionar observabilidade aos seus recursos do AgentCore.

Fonte

Monitor on-premises and multi-cloud AI agents with AgentCore Observability (https://aws.amazon.com/blogs/machine-learning/monitor-on-premises-and-multi-cloud-ai-agents-with-agentcore-observability/)

O problema que o RPA tradicional não resolve

Grandes empresas de setores como saúde, manufatura, varejo e serviços financeiros compartilham um desafio comum: sistemas legados críticos que só expõem interfaces HTML geradas por middleware server-side, sem Interfaces de Programação de Aplicações (APIs) modernas. Automatizar esses sistemas com Automação Robótica de Processos (RPA) tradicional funciona até certo ponto, mas escalar com confiabilidade é outra história.

O cenário típico envolve operadores navegando manualmente por fluxos de múltiplas telas, inserindo dados, validando regras de negócio e submetendo alterações — tudo isso repetido milhares de vezes por ano. Uma seguradora, por exemplo, pode processar dezenas de milhares de modificações em apólices anualmente, com equipes dedicadas a navegar interfaces complexas geradas por sistemas criados há décadas. Os custos com erros manuais e horas consumidas são significativos.

Os bots de RPA baseados em regras quebram quando a interface renderiza de forma diferente do esperado, quando há autenticação multifator (MFA) ou Single Sign-On (SSO) proprietário, ou quando surgem exceções que exigem raciocínio contextual. É exatamente essa lacuna que o Amazon Bedrock AgentCore Browser Tool se propõe a preencher.

O que é o AgentCore Browser Tool

O Amazon Bedrock AgentCore runtime oferece um serviço de navegador totalmente gerenciado na nuvem. Cada sessão de automação roda em um ambiente isolado com CPU, memória e sistema de arquivos próprios. Quando a sessão termina, o ambiente é encerrado e o estado é sanitizado.

A conexão com o navegador acontece via Playwright sobre o Protocolo Chrome DevTools (CDP) baseado em WebSocket (WSS), o que permite ao agente de IA controlar programaticamente qualquer aplicação web — incluindo interfaces JavaScript pesadas, formulários dinâmicos e fluxos de múltiplas etapas — independentemente da tecnologia por trás do sistema legado. O serviço roda uma instância gerenciada do Chromium na nuvem, exigindo apenas que a aplicação alvo esteja acessível via HTTP ou HTTPS.

Três capacidades do Browser Tool merecem destaque especial por atacar diretamente os problemas clássicos de automação legada:

• Perfis de navegador persistentes: o estado de autenticação é mantido entre sessões. O operador faz login uma vez — inclusive via live-view para fluxos com MFA — e as sessões seguintes já retomam autenticadas, eliminando a necessidade de repetir fluxos de SSO.
• Configuração de proxy: o tráfego pode ser roteado por infraestrutura de proxy corporativa com roteamento por domínio e credenciais armazenadas no AWS Secrets Manager, tornando sistemas internos acessíveis mesmo em redes restritas.
• Gravação de sessão: cliques, entradas em formulários e navegação são capturados e armazenados no Amazon S3, formando uma trilha de auditoria completa e reproduzível. Combinado com o AWS CloudTrail, isso atende aos requisitos de conformidade de setores regulados como financeiro e saúde.

Orquestração com Strands Agents e modelos de fundação

O componente de inteligência da solução vem da combinação entre o Amazon Bedrock e o Strands Agents. Em vez de seguir um script fixo, o agente opera em um ciclo ReAct (Raciocínio + Ação): captura um screenshot, analisa visualmente o estado da página usando um modelo de fundação com capacidade de visão, decide qual ação executar, executa via Playwright, observa o resultado e repete.

Essa abordagem é o que diferencia a solução do RPA tradicional. O modelo vê a página, raciocina sobre o que está na tela e determina o próximo passo — seja um clique, preenchimento de campo, scroll ou pausa para confirmação humana. Se um diálogo inesperado aparecer ou um campo validar de forma diferente do previsto, o modelo raciocina sobre o novo estado em vez de falhar.

Na prática, uma instrução em linguagem natural como “abra a apólice #12345, atualize o valor de cobertura para R$ 500.000 e submeta para aprovação” é suficiente para disparar um fluxo completo de automação. O modelo navega visualmente até a apólice correta, identifica os campos pelo screenshot, preenche as alterações em múltiplas telas, lida com prompts de validação inesperados e submete para aprovação — sem que nenhum humano precise mapear cada seletor CSS ou manter scripts frágeis.

Arquitetura da implementação de referência

A AWS publicou uma implementação de referência completa de um trabalhador digital baseado em IA, construída com AgentCore Browser Tool e Strands Agents. O código-fonte completo está disponível no GitHub.

A arquitetura é composta por um conjunto enxuto de componentes com responsabilidades bem delimitadas:

• Uma interface de chat React como Single Page Application (SPA) para o operador
• Um proxy com terminação TLS que resolve uma limitação específica do navegador
• Um worker Python executando Strands Agents no Amazon Bedrock AgentCore runtime
• O ambiente de navegador gerenciado pelo AgentCore Browser Tool

O fluxo completo funciona assim: a interface é carregada via Amazon CloudFront a partir de um bucket privado no S3. O operador se autentica pelo Amazon Cognito via OpenID Connect (OIDC), que emite um JSON Web Token (JWT). O navegador abre uma conexão WebSocket através de um Application Load Balancer (ALB) que termina o TLS. O ALB encaminha para um proxy NGINX rodando como tarefa do AWS Fargate em sub-rede privada. O proxy injeta o JWT no cabeçalho de autorização e encaminha ao AgentCore runtime, que valida o token e roteia para o container do agente. O agente chama o modelo de fundação no Amazon Bedrock para analisar screenshots e decidir as próximas ações, enquanto controla o navegador Chrome isolado via CDP. Transcrições e screenshots de sessão são armazenados no S3 com URLs pré-assinadas transmitidas ao chat do operador — os bytes da imagem não trafegam pelo WebSocket, apenas a URL de curta duração.

A infraestrutura de suporte inclui o Amazon ECR para hospedar as imagens de container e o Amazon CloudWatch para logging de auditoria e observabilidade.

Integração humana no loop

O operador acompanha a automação em tempo real. O agente transmite rastros de raciocínio e screenshots para a interface de chat à medida que avança. Quando o modelo determina que precisa de confirmação humana antes de uma ação crítica — como submeter uma modificação de apólice ou confirmar uma alteração de beneficiário — ele chama a ferramenta handoff_to_user, que pausa a automação e apresenta ao operador uma pergunta junto com o screenshot atual.

A sessão do navegador permanece ativa enquanto o agente aguarda resposta (até 300 segundos por padrão). O operador pode aprovar, rejeitar, fornecer instruções adicionais ou pedir ao agente que tente uma abordagem diferente. Após a resposta, o modelo retoma o ciclo ReAct com o input recebido. Se o operador não responder dentro do tempo limite, o modelo decide se tenta novamente, tenta uma abordagem alternativa ou aborta de forma controlada.

Decisões de design que afetam a confiabilidade em produção

A implementação de referência destaca duas escolhas técnicas relevantes para quem pretende levar a solução para produção:

Isolamento de event loop: o agente de navegador roda junto com um servidor WebSocket que transmite atualizações ao operador. O modelo de threading da ferramenta de navegador interfere no event loop do servidor, causando quedas de conexão após cerca de 15 segundos. A implementação de referência sobrescreve esse comportamento para que as operações do navegador rodem em seu próprio loop isolado, mantendo a conexão do operador estável durante toda a sessão.

Localizadores semânticos em vez de seletores CSS: bots de RPA tradicionais quebram quando elementos de UI mudam de posição ou são renomeados. A ferramenta semantic_action adota uma abordagem diferente: o modelo descreve o que vê (“clique no botão rotulado Enviar”) e a ferramenta mapeia isso para a API de Locator semântico do Playwright usando correspondência fuzzy sem distinção de maiúsculas/minúsculas. Isso torna a automação resiliente às variações de UI comuns em aplicações legadas.

Como implantar e testar

A solução completa é implantada com um único stack Terraform. Os pré-requisitos são: uma conta AWS com acesso a modelos de fundação com capacidade de visão no Amazon Bedrock, AWS Command Line Interface (AWS CLI) v2 configurado, Docker 24+, Terraform 1.5+, Node 20+ com Yarn e Python 3.12.

Os comandos de implantação são:

git clone <repo-url> && cd <repo>
cp deployment/terraform/stacks/all/terraform.tfvars.sample \
   deployment/terraform/stacks/all/terraform.tfvars
# Edite terraform.tfvars - defina aws_region, project_name, cognito_domain_prefix
terraform -chdir=deployment/terraform/stacks/all init
terraform -chdir=deployment/terraform/stacks/all apply

O stack provisiona o Cognito User Pool, distribuição CloudFront, repositórios ECR, serviço de proxy ECS, AgentCore runtime com autorizador JWT e armazenamento de sessão no S3. Os provisioners do Terraform constroem e publicam as imagens de container, compilam a interface React, sincronizam com o S3 e invalidam o CloudFront — tudo em uma única execução. O primeiro apply leva aproximadamente 20 a 30 minutos, a maior parte em propagação do CloudFront e builds de imagem.

Após a implantação, o Terraform exibe a URL do CloudFront. Para testar, basta abrir no navegador, fazer login com um usuário Cognito e enviar um prompt como:

"Open https://httpbin.org/forms/post, fill the customer name with John Smith, pick medium pizza, check bacon topping, and submit the form."

O rastro de raciocínio deve aparecer no chat, screenshots surgem a cada etapa e um prompt de confirmação humana aparece antes do envio final. Cenários adicionais de teste estão disponíveis no README do repositório.

Para encerrar a infraestrutura e evitar cobranças contínuas:

terraform -chdir=deployment/terraform/stacks/all destroy

Próximos passos e extensões possíveis

A implementação de referência foi projetada com espaço para crescer. Se o fluxo precisar de contexto entre sessões, o Amazon Bedrock AgentCore memory oferece memória gerenciada de curto e longo prazo. Para integrar APIs REST existentes como ferramentas que o agente possa chamar junto com as ações de navegador, o Amazon Bedrock AgentCore Gateway resolve isso sem a necessidade de criar Strands tools customizadas. Para portais que exigem comportamento de navegador personalizado, extensões do Chrome podem ser carregadas nas sessões do AgentCore Browser Tool no momento da criação.

O código-fonte completo da implementação está disponível no GitHub.

Fonte

Automate legacy web applications with Amazon Bedrock AgentCore Browser Tool (https://aws.amazon.com/blogs/machine-learning/automate-legacy-web-applications-with-amazon-bedrock-agentcore-browser-tool/)

Claude Opus 5 chega ao AWS GovCloud (US)

A AWS anunciou que o Claude Opus 5 — o modelo mais avançado da linha Opus da Anthropic até o momento — está agora disponível nas regiões do AWS GovCloud (US). A novidade é especialmente relevante para equipes que trabalham em ambientes de alta conformidade regulatória, já que o modelo chega com suporte nativo à Retenção Zero de Dados (ZDR) habilitada por padrão.

O acesso ao Claude Opus 5 está disponível pelo endpoint bedrock-runtime nas duas regiões do AWS GovCloud (US), e também pelo endpoint bedrock-mantle na região AWS GovCloud (US-West).

O que o Claude Opus 5 oferece

Codificação em nível de produção

O Claude Opus 5 traz avanços significativos em codificação. Segundo a AWS, o modelo é capaz de compreender e navegar por bases de código complexas com a fluência de um engenheiro experiente, além de produzir código em qualidade de produção — adaptando sua estratégia conforme avança no problema.

Agentes de longa duração

Uma das capacidades que se destaca é a execução de agentes autônomos por períodos prolongados — inclusive durante horas ou ao longo de uma noite inteira. Esses agentes conseguem contornar obstáculos, se recuperar de erros e alcançar seus objetivos sem intervenção constante, o que abre caminho para automações mais robustas em fluxos de trabalho corporativos.

Raciocínio aprofundado em documentos e análises complexas

O modelo também apresenta melhorias expressivas no processamento de documentos extensos e na precisão de análises complexas. Os maiores ganhos foram observados justamente em tarefas corporativas com grande volume de documentos — um cenário bastante comum em ambientes governamentais e regulados.

Governança de dados com ZDR no Amazon Bedrock

No Amazon Bedrock, o Claude Opus 5 é oferecido com a Retenção Zero de Dados (ZDR) habilitada por padrão. Isso significa que as equipes têm acesso à inteligência de ponta do Opus sem abrir mão dos requisitos de governança de dados. O serviço mantém os dados dentro da infraestrutura da AWS, com residência regional dos dados, e oferece acesso centralizado por meio de funcionalidades gerenciadas pela própria AWS, como Guardrails e Knowledge Bases.

Saiba mais

Para aprofundar o tema, a AWS disponibiliza a documentação oficial do Amazon Bedrock sobre o modelo, além das informações de disponibilidade por região.

Fonte

Claude Opus 5 is now available in AWS GovCloud (US) (https://aws.amazon.com/about-aws/whats-new/2026/07/claude-opus-5-aws-govcloud/)

O desafio do processo de due diligence em F&A

Equipes de fusões e aquisições (F&A) enfrentam uma pressão constante: analisar múltiplos alvos de aquisição com profundidade e velocidade ao mesmo tempo. Na prática, analistas passam semanas coletando dados de bases financeiras, pesquisas de mercado, registros regulatórios e repositórios internos — e depois reconciliam tudo manualmente.

O problema se agrava quando as equipes repetem trabalho. Modelos de valuation, pesquisas setoriais e análises competitivas são recriados do zero para cada novo negócio, sem aproveitar o conhecimento acumulado em transações anteriores. Por outro lado, times jurídicos e de conformidade exigem que as conclusões geradas por IA sejam rastreáveis e embasadas em fontes verificáveis — o que freou historicamente a adoção de automação nessa área.

Quatro pressões combinadas — ciclos lentos, dados fragmentados, esforço duplicado e exigências de governança — criam uma abertura clara para que agentes de IA transformem a forma como a due diligence funciona.

Como agentes de IA mudam a equação

A AWS demonstra, em um post técnico recente, como o Amazon Bedrock AgentCore pode orquestrar agentes autônomos que tratam cada uma dessas pressões de forma integrada:

• Coleta de dados: agentes consultam múltiplas fontes simultaneamente e sintetizam os resultados em avaliações preliminares, eliminando o ciclo repetitivo de busca e resumo manual.
• Priorização inteligente: o sistema avalia oportunidades com base em critérios estratégicos e direciona os alvos mais promissores para os especialistas certos, indicando exatamente quais dimensões merecem análise mais profunda.
• Memória institucional: cada análise concluída enriquece uma camada de memória compartilhada, de modo que negócios futuros se beneficiem de pesquisas anteriores, premissas de valuation e lições de integração já registradas.
• Governança nativa: cada afirmação emitida pelo agente é ancorada em uma citação verificável, e trilhas de auditoria são geradas automaticamente a cada invocação.

Duas rotas de implementação

A AWS apresenta dois caminhos para implementar essa solução, adequados a necessidades organizacionais distintas.

Opção 1: Amazon Quick (solução integrada)

O Amazon Quick oferece capacidades de IA prontas para uso, voltadas a fluxos de inteligência de negócios e pesquisa. É o caminho mais rápido para produção quando os requisitos se encaixam em padrões de análise convencionais. O serviço inclui geração de relatórios exportáveis (Amazon Quick Research), automação de tarefas repetitivas com fluxos pré-construídos (Amazon Quick Flows) e busca unificada em fontes conectadas (Amazon Quick Index).

Essa opção é indicada para quem quer implantar rapidamente, prefere serviços totalmente gerenciados e não precisa de customizações profundas. Para detalhes e arquitetura de referência, a AWS disponibilizou o anúncio do Amazon Quick. Também é possível estender o Quick com agentes customizados do AgentCore para requisitos específicos, como modelos proprietários de valuation — o post Construindo Gestão Inteligente de Contratos com Quick e AgentCore mostra como combinar os dois.

Opção 2: Arquitetura customizada com Amazon Bedrock AgentCore

O Amazon Bedrock AgentCore oferece controle granular sobre o comportamento dos agentes, memória e coordenação. Essa abordagem é indicada para equipes de F&A com metodologias proprietárias, requisitos complexos de coordenação entre múltiplos agentes, integrações com sistemas internos especializados ou necessidade de controle total sobre a seleção de modelos.

O restante do post técnico da AWS explora essa arquitetura customizada em detalhe, usando um cenário de due diligence no setor de transporte e logística como contexto.

Arquitetura de referência

Para equipes que optam pelo caminho customizado, a arquitetura de referência proposta pela AWS mostra como todas as peças se encaixam de ponta a ponta.

O sistema usa o AgentCore Runtime para coordenar um fluxo de due diligence com múltiplos agentes especializados, por meio do Strands Agents SDK. Um agente supervisor coordena quatro especialistas, cada um responsável por uma fase distinta do processo:

• Agente de Triagem de Alvos: identifica candidatos à aquisição convertendo consultas em linguagem natural para SQL e executando-as contra o Amazon Aurora PostgreSQL. Uma consulta como “empresas de logística mid-market com receita entre 100M e 500M USD e margem de EBITDA acima de 12%” é traduzida automaticamente em uma query parametrizada, e os resultados são enriquecidos com contexto narrativo da base de conhecimento.
• Agente de Análise Financeira: realiza análise de valuation usando fontes estruturadas e não estruturadas. Aplica metodologias padrão como Fluxo de Caixa Descontado (DCF) e análise de empresas comparáveis, buscando múltiplos de mercado via ferramenta integrada ao AgentCore Gateway. Sinaliza projeções da gestão que divergem do desempenho histórico.
• Agente de Fit Estratégico: avalia riscos de integração, sinergias e alinhamento organizacional. Recupera contexto de transações anteriores armazenadas na memória do AgentCore (usando um namespace dedicado prior_deals) e compara o perfil do alvo atual com aquisições já concluídas.
• Agente de Validação de Conformidade: audita respostas contra o checklist de governança de F&A. Invoca um avaliador customizado de verificação de citações (implementado como função AWS Lambda) que examina cada afirmação factual e sinaliza assertivas sem fonte de suporte.

Componentes-chave da arquitetura

A solução combina dados estruturados e não estruturados para ancorar as respostas dos agentes em fontes verificadas:

• Amazon Aurora PostgreSQL Serverless v2: armazena dados financeiros e operacionais estruturados. O Agente de Triagem gera SQL a partir de linguagem natural e executa as consultas via RDS Data API.
• Amazon Bedrock Knowledge Bases: a capacidade de Geração Aumentada por Recuperação (RAG) totalmente gerenciada do Bedrock indexa documentos de due diligence, incluindo memorandos de informações confidenciais (CIMs), demonstrações financeiras e checklists de governança.
• AgentCore Gateway: permite que os agentes interajam com segurança com ferramentas externas via integrações compatíveis com o Protocolo de Contexto de Modelo (MCP). Políticas Cedar impõem controles de acesso determinísticos sobre o uso das ferramentas.
• AgentCore Memory: mantém estado contextual e conhecimento institucional reutilizável entre interações. A memória de sessão preserva a continuidade da conversa, enquanto o namespace de longo prazo prior_deals armazena lições de aquisições concluídas.
• AgentCore Evaluations: usa avaliadores baseados em Lambda para validar automaticamente a qualidade dos outputs, precisão de citações e critérios específicos do domínio.
• Amazon Bedrock Guardrails: aplica controles de segurança e resposta em todo o fluxo, no nível do supervisor.
• Observabilidade: cada invocação gera um stream de logs no Amazon CloudWatch e um trace no AWS X-Ray que captura toda a hierarquia de chamadas do supervisor aos especialistas e ferramentas.

Segurança como parte da arquitetura

Due diligence de F&A envolve alguns dos dados mais sensíveis que uma empresa manipula: financeiros não divulgados, termos de negócio e planos de integração. Por isso, a segurança é tratada como componente de primeira classe na arquitetura:

• Todas as permissões de Gerenciamento de Identidade e Acesso (IAM) são escopadas para um Nome de Recurso da Amazon (ARN) específico, sem uso de wildcards.
• O AgentCore Gateway aplica uma política Cedar com negação padrão (default-deny) e autorização baseada em atributos: a ferramenta de dados de mercado só executa quando o código de setor solicitado corresponde a um vertical aprovado.
• A camada de banco de dados fica em sub-redes privadas isoladas da internet, atrás de endpoints de Nuvem Privada Virtual (VPC).
• Os datastores são criptografados em repouso com o Serviço de Gerenciamento de Chaves (KMS), e o Amazon Bedrock Guardrails filtra todas as respostas do supervisor para conteúdo prejudicial e conselhos financeiros personalizados.

Implantando e executando o exemplo

A implementação de referência completa está disponível no repositório M&A Due Diligence Multi-Agent Sample no GitHub. O repositório inclui dados sintéticos (sem empresas reais, dados financeiros ou informações pessoais identificáveis), implantação com um único comando e um notebook Jupyter de guia passo a passo. O custo estimado para um ciclo completo de implantação, execução e limpeza é inferior a USD 5,00.

Pré-requisitos

Antes de implantar, é necessário ter:

• Uma conta AWS com acesso aos modelos do Amazon Bedrock habilitado para Anthropic Claude e Amazon Nova. Para disponibilidade por região, consulte Modelos suportados por região da AWS no Amazon Bedrock.
• AWS Command Line Interface (AWS CLI) v2.15 ou superior.
• Python 3.11 ou superior.
• Node.js 20 ou superior.
• AWS Cloud Development Kit (AWS CDK) v2 (npm install -g aws-cdk).

Não é necessário ter o Docker instalado localmente. A imagem de contêiner do agente é construída no AWS CodeBuild. A implantação é suportada nas regiões: us-east-1, us-west-2, ap-southeast-2 e eu-central-1.

Passo 1: Implantar o stack

Clone o repositório e execute o script de implantação. A primeira implantação leva entre 20 e 25 minutos:

# macOS / Linux
git clone https://github.com/aws-samples/sample-ma-due-diligence-agentcore.git
cd sample-ma-due-diligence-agentcore
./deploy.sh

# Windows
git clone https://github.com/aws-samples/sample-ma-due-diligence-agentcore.git
cd sample-ma-due-diligence-agentcore
.\deploy.ps1

O script verifica a região e o acesso ao modelo, cria um ambiente virtual, executa cdk deploy --all, popula os dados sintéticos e roda um smoke test pós-implantação. Também instala o projeto em modo editável, registrando a ferramenta de linha de comando mna usada nos próximos passos.

Passo 2: Invocar os agentes

Use o CLI mna para enviar prompts a especialistas individuais ou deixar o supervisor rotear entre eles:

# Deixar o supervisor orquestrar entre os especialistas
mna invoke supervisor "Screen the mid-market logistics targets with revenue 100M-500M, then run a DCF on the top hit." --session-id walkthrough-session-00000000-0001

# Triagem de Alvos: text-to-SQL no Aurora + enriquecimento narrativo da KB
mna invoke target_screening "Screen the target pipeline for transportation companies with revenue between 100M and 500M USD, EBITDA margin above 12%, and fleet size above 200. Surface the top three and tell me what the CIM says about the leader's growth trajectory." --session-id walkthrough-session-00000000-0001

# Análise Financeira: recuperação da KB + ferramenta de dados de mercado via Gateway
mna invoke financial_analysis "Run a DCF on Example Corp using the CIM in the knowledge base. Flag any management projection that diverges from historical performance by more than 20% and pull comparable multiples for transportation-logistics mid-market." --session-id walkthrough-session-00000000-0001

# Fit Estratégico: recuperação de longo prazo na memória do AgentCore
mna invoke strategic_fit "Compare Example Corp' integration profile against our three most recent completed acquisitions. Identify the top three integration risks and cite the source memos." --session-id walkthrough-session-00000000-0001

Cada invocação imprime um trace_id no rodapé. Use mna trace <trace_id> para inspecionar o trace completo do X-Ray para aquela chamada.

Passo 3: Validar outputs com o avaliador

O subcomando mna evaluate executa o avaliador de verificação de citações contra o output de um especialista:

# Capturar uma resposta em formato JSON
mna --json invoke financial_analysis "Run a DCF on Example Corp using the CIM." --session-id blog-demo-session-00000000-000002 > run.json

# Extrair texto de resposta e citações
python -c "import json,pathlib;d=json.loads(pathlib.Path('run.json').read_text());pathlib.Path('response.txt').write_text(d['text'])"
python -c "import json,pathlib; d=json.loads(pathlib.Path('run.json').read_text()); pathlib.Path('citations.json').write_text(json.dumps(d['citations']))"

# Executar o avaliador de verificação de citações
mna evaluate --response-file response.txt --citations-file citations.json

O avaliador retorna um resultado estruturado de aprovação ou falha, com contagens de afirmações totais, suportadas e sem suporte. O código de saída é 0 em caso de aprovação e 1 em caso de falha, tornando-o compatível com pipelines de Integração Contínua (CI).

Passo 4: Explorar o notebook

Para uma tour guiada célula a célula do mesmo fluxo:

jupyter lab notebooks/walkthrough.ipynb

Limpeza dos recursos

Para evitar cobranças contínuas, destrua todos os recursos implantados ao terminar:

# macOS / Linux
./cleanup.sh

# Windows
.\cleanup.ps1

O script de limpeza executa cdk destroy --all --force e depois roda uma varredura de verificação em busca de recursos órfãos: buckets S3 com prefixo mna-*, repositórios ECR com prefixo mna-*, Amazon Bedrock Knowledge Bases com mna no nome, runtimes, memórias e gateways do AgentCore, e stacks do AWS CloudFormation iniciando com Mna. Para mais detalhes sobre limpeza de recursos do CDK, consulte a documentação do AWS CDK.

Próximos passos e extensões

A AWS sugere alguns caminhos para estender essa arquitetura:

• Adicionar um front-end de produção: o Full-Stack Starter Template for AgentCore (FAST) oferece uma interface React, autenticação via Amazon Cognito e distribuição pelo Amazon CloudFront, integrada diretamente ao AgentCore Runtime.
• Construir agentes especialistas adicionais: o arquivo CONTRIBUTING.md do repositório documenta o layout de arquivos, o padrão Strands e o processo de registro no supervisor para adicionar novos agentes — como um agente de registros regulatórios ou de pontuação ESG.
• Explorar orquestração avançada: o Strands Agents SDK suporta múltiplas abordagens de coordenação, incluindo agents-as-tools, swarms e grafos de agentes. A documentação de padrões de colaboração multi-agente cobre cada abordagem em detalhe.
• Conectar fontes de dados adicionais: o AgentCore Gateway suporta APIs HTTP, servidores MCP e alvos do Amazon API Gateway além da única ferramenta Lambda demonstrada no exemplo.

Conclusão

A AWS demonstrou como construir um sistema multi-agente no Amazon Bedrock AgentCore capaz de automatizar a due diligence de F&A no setor de transporte e logística. A arquitetura coordena agentes especializados para triagem de alvos, análise financeira, avaliação de fit estratégico e validação de conformidade — reduzindo semanas de trabalho analítico para horas.

Os padrões apresentados se estendem naturalmente a outros domínios de due diligence, incluindo saúde, serviços financeiros e aquisições de tecnologia. Para começar, basta clonar o repositório de exemplo, implantar o stack na sua conta AWS e experimentar modificar um agente especialista ou adicionar um novo.

Fonte

Accelerating M&A due diligence with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/accelerating-ma-due-diligence-with-amazon-bedrock-agentcore/)

IA dentro dos aplicativos que sua equipe já usa

Os dados corporativos vivem espalhados por dezenas de sistemas — mas o trabalho do dia a dia acontece no Microsoft 365. Pensando nisso, a AWS anunciou a disponibilidade geral das extensões do Amazon Quick para Word, Excel, PowerPoint e Outlook. A proposta é direta: em vez de pedir que as equipes adotem uma nova ferramenta, o assistente de IA agêntico chega diretamente dentro dos aplicativos que já estão abertos toda manhã.

As extensões estão disponíveis agora para clientes Amazon Quick nos planos Plus, Profissional e Enterprise, sem necessidade de licenciamento adicional. Elas funcionam tanto nas versões desktop quanto na versão web do Microsoft 365.

Por que isso importa: a camada de inteligência conectada

O diferencial do Amazon Quick não está apenas no modelo de IA em si, mas na amplitude dos dados conectados que o agente traz para cada interação. A maioria das organizações já opera com uma combinação de infraestrutura AWS, dashboards do Amazon QuickSight, pipelines do Salesforce, projetos no Jira, conversas no Slack e repositórios no SharePoint. O Quick conecta tudo isso às ferramentas de produtividade do cotidiano.

Na prática, isso significa que tarefas que antes exigiam dias de trabalho — como compilar uma resposta a uma proposta de cliente a partir de bases de conhecimento internas, propostas anteriores e dados ao vivo — podem ser concluídas em horas. Apresentações personalizadas que combinam fontes de dados estruturados e documentos não estruturados passam a ser montadas em uma hora, em vez de um ou dois dias.

Agêntico, não apenas um chat

Um ponto importante: essas extensões não são um chatbot colado ao Office. Elas são agênticas — o assistente não apenas responde perguntas, ele age diretamente dentro dos documentos, planilhas, apresentações e e-mails. O agente enxerga o contexto do que está aberto e trabalha sobre ele.

No Word, por exemplo, o Quick vive como um painel lateral persistente. O usuário abre pelo menu da faixa de opções, faz uma pergunta ou dá uma instrução, e o agente age dentro do documento — sem troca de abas, sem copiar e colar entre sistemas. Cada alteração feita pelo agente é registrada como um histórico de auditoria com comparação visual do antes e depois. O histórico de conversas também é preservado entre sessões.

Instalação e autenticação simplificadas

As extensões não exigem instalação no lado do cliente — elas rodam inteiramente na nuvem. Um administrador pode distribuí-las para usuários e grupos via centro de administração do Microsoft 365, usando um manifesto padrão, o mesmo mecanismo utilizado para qualquer suplemento do Microsoft 365. Alternativamente, o próprio usuário pode instalar pelo repositório de suplementos do Microsoft, buscando por “Quick” e clicando em Adicionar. As atualizações são entregues automaticamente — a equipe implanta uma vez e todos recebem as versões mais recentes sem intervenção de TI.

A exceção é o Outlook: como a maioria das organizações restringe permissões da API do Graph, a extensão do Outlook geralmente requer aprovação de administrador para funcionalidade completa.

O modelo de autenticação usa credenciais nativas do Quick e não exige um aplicativo Entra, o que reduz as dependências para a equipe de TI. Usuários nos planos Free ou Plus podem entrar com credenciais corporativas ou via login social (Google, Apple).

As extensões estão disponíveis em sete Regiões AWS: Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon), Europa (Irlanda), Europa (Londres), Europa (Frankfurt), Ásia-Pacífico (Sydney) e Ásia-Pacífico (Tóquio). Os dados permanecem dentro da região selecionada, e a infraestrutura de backend opera em isolamento completo, sem saída pública de dados.

Para começar, basta ter uma aplicação Quick ativa. As extensões se conectam ao ambiente Quick já configurado, herdando bases de conhecimento, fontes de dados e integrações existentes — incluindo Salesforce, Jira, Slack, SharePoint e outros — sem configuração adicional.

Microsoft Excel: de números a decisões

A extensão para Excel opera dentro do contexto dos dados que o usuário já está trabalhando. Ela cuida da recuperação e formatação em uma única etapa, eliminando a necessidade de alternar entre sistemas para chegar a uma resposta.

Quando é preciso trazer dados externos, a extensão busca em armazenamento em nuvem, data warehouses, QuickSight, Salesforce ou SharePoint. Em seguida, identifica inconsistências, corrige problemas de formatação e transforma tudo em formatos prontos para análise. É possível validar a análise contra métricas reais de negócio armazenadas no QuickSight, mantendo as planilhas conectadas a dados ao vivo durante todo o processo.

Um fluxo típico no Excel inclui pedir ao agente que analise a planilha atual e sinalize anomalias mês a mês acima de 10%, trazer receita do primeiro trimestre por região de um dashboard do QuickSight para uma nova aba, solicitar explicação de uma fórmula complexa com rastreamento de dependências, e gerar um gráfico comparando valores reais e previstos.

Microsoft Word: escreva com contexto corporativo

A extensão para Word funciona como um co-editor que entende tanto o documento quanto as fontes de dados conectadas. Ela respeita a estrutura existente do documento — fontes, estilos de título e padrões organizacionais — e, ao adicionar ou modificar uma seção, o resultado mantém a consistência com o que já está lá.

Cada edição é capturada como um snapshot de antes e depois, renderizado como comparação visual no painel de chat. Cada alteração inclui uma referência selecionável de volta à seção afetada, criando um registro completo do trabalho do agente. Esse histórico de auditoria é especialmente valioso em ambientes colaborativos onde múltiplas pessoas contribuem para o mesmo documento.

A extensão também permite gerar tabelas e visualizações a partir de dashboards do QuickSight, construir resumos executivos que referenciam métricas do pipeline do Salesforce ou incluir atualizações de status de projetos do Jira — tudo diretamente no documento, sem copiar e colar de outros sistemas.

Microsoft Outlook: e-mails informados pelos dados da empresa

A extensão para Outlook entende automaticamente o contexto do e-mail ou reunião em revisão. Assunto, remetente, destinatários, histórico do thread e timestamps são incluídos em cada interação, mantendo as respostas do agente relevantes ao contexto — sem precisar explicar o que está sendo analisado ou colar informações de fundo.

O agente rascunha respostas, responder-a-todos e novas mensagens com plena consciência do thread. Ele entende limites de conversa entre clientes de e-mail como Outlook, Gmail e Apple Mail, e preserva a estrutura correta do thread nas respostas. É possível adicionar destinatários nos campos Para, CC ou CCO, incluir anexos e agendar envios — tudo pelo painel lateral, sem sair da caixa de entrada.

Além da composição, a extensão ajuda a manter o controle da caixa de entrada: sinalizar, categorizar e mover mensagens; resumir threads longos e extrair itens de ação. O Outlook passa a ser uma superfície de fluxo de trabalho inteligente conectada a contas do Salesforce, métricas do QuickSight e tickets do Jira.

Microsoft PowerPoint: apresentações respaldadas por dados reais

A extensão para PowerPoint gera slides programaticamente e suporta fluxos de trabalho criativos em múltiplas etapas, muito além da geração por prompt único. As apresentações são construídas de forma iterativa, refinando design e conteúdo ao longo de várias interações com o agente.

O Quick utiliza os masters de slides, layouts, fontes e esquemas de cores da empresa, garantindo que os slides gerados estejam alinhados ao sistema de design já utilizado pela equipe. Não é preciso escolher entre assistência de IA e os templates corporativos — o agente trabalha dentro das diretrizes de marca desde o início.

A extensão conecta apresentações aos dados da empresa: gera gráficos e resumos executivos que referenciam dashboards do QuickSight ou métricas do Salesforce. Quando uma análise foi construída no Excel, a extensão do PowerPoint pode gerar uma apresentação para o conselho que entende o que a análise revelou e estrutura a narrativa de acordo. O contexto flui dos dados para a apresentação porque ambas as extensões utilizam as mesmas fontes de dados conectadas.

Como começar

As extensões do Amazon Quick para Microsoft 365 estão em disponibilidade geral. Quem já é cliente Quick pode instalar as extensões pela página de downloads do Quick. Quem ainda não usa o serviço pode iniciar uma avaliação gratuita, instalar as extensões e começar a usar o Quick no Word, Excel, PowerPoint e Outlook. Para mais detalhes técnicos, a documentação oficial do Amazon Quick traz todas as informações sobre novas capacidades e atualizações.

Fonte

Amazon Quick for Microsoft 365: Agentic AI where you work (https://aws.amazon.com/blogs/machine-learning/amazon-quick-for-microsoft-365-agentic-ai-where-you-work/)

O problema: cache KV isolado por réplica custa caro

Rodar inferência de Modelos de Linguagem de Grande Escala (LLMs — Large Language Models) em escala impõe um dilema clássico: ou você paga por instâncias GPU superdimensionadas para acomodar um cache KV crescente, ou aceita um tempo até o primeiro token (TTFT — Time to First Token) alto porque prompts idênticos são reprocessados em cada requisição.

Para equipes que operam um catálogo amplo de modelos de fundação disponíveis publicamente — como Qwen, Llama e DeepSeek — distribuídos em endpoints por linha de negócio, pipelines de Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation) ou aplicações de diálogo de múltiplos turnos, esse dilema se traduz diretamente em custo de infraestrutura mais alto e experiência do usuário degradada.

A causa raiz é simples. Durante a geração, o vLLM armazena as chaves e valores de atenção de cada token já processado em um cache KV, evitando recomputação a cada passo. O prefix caching estende isso reutilizando o cache entre requisições que compartilham os mesmos tokens iniciais — como um system prompt comum. Em instâncias econômicas como a ml.g6e.4xlarge (48 GB por GPU), depois de alocar pesos do modelo e runtime, a memória restante para prefix caching é limitada. Com modelos maiores ou maior concorrência, a situação piora: taxas de acerto caem, system prompts idênticos são reprocessados em toda requisição, e réplicas vLLM em escala horizontal mantêm caches isolados entre si. Rotear para uma réplica diferente equivale a um cold start funcional.

A solução: cache KV em três camadas com Curvine

A AWS descreveu uma arquitetura de cache KV em camadas no Amazon SageMaker HyperPod que estende a hierarquia de cache além da memória GPU e CPU para um pool compartilhado e distribuído de NVMe. A solução combina duas capacidades do HyperPod — Cache KV Gerenciado em Camadas e Roteamento Inteligente — com o Curvine, um sistema de arquivos de cache distribuído leve, como camada L2 compartilhada.

Em um deployment de teste, a arquitetura alcançou até 100% de taxa de acerto de cache entre Pods, melhora de até 2,7x no TTFT e latência de leitura L2 entre nós de aproximadamente 56 ms para um prompt de cerca de 1.900 tokens.

As três camadas da hierarquia

L0 – Cache GPU (HBM). É a camada nativa de atenção paginada do vLLM, que mantém os blocos KV mais quentes com a menor latência de acesso. A capacidade é limitada ao que sobra da memória GPU depois dos pesos do modelo. Em uma GPU de 48 GB, um modelo de 7B em bf16 usa cerca de 14 GB para pesos, deixando mais de 30 GB para blocos KV — headroom confortável. Já um modelo de 32B usa cerca de 64 GB de pesos e nem cabe em uma GPU de 48 GB; mesmo com sharding, sobra muito menos memória para KV, e o cache enche rapidamente sob concorrência.

L1 – Offload para memória CPU. Quando blocos GPU são despejados, o LMCache os captura na DRAM do host antes que sejam perdidos. Esse processo roda dentro de cada Pod de inferência e é gerenciado automaticamente pelo Inference Operator do SageMaker HyperPod quando se configura enableL1Cache: true no CRD InferenceEndpointConfig. É rápido, local ao Pod e dimensionado pelo parâmetro InstanceMemoryAllocationPercentage — recomenda-se começar com 20%.

L2 – Pool NVMe distribuído e compartilhado. É aqui que acontece a reutilização entre réplicas. O Curvine agrega os drives NVMe locais das instâncias G6e/P5 em um único namespace, que um cliente FUSE (um driver em espaço de usuário que apresenta o pool como um diretório comum) monta como um PVC (PersistentVolumeClaim) ReadWriteMany em cada Pod de inferência. O LMCache lê e escreve via conector fs://, então o pool distribuído parece um diretório local. Como todos os Pods montam o mesmo namespace, um bloco KV escrito por uma réplica é imediatamente legível pelas demais.

O Curvine em si é direto de operar: um nó Primário (chamado “Master” na documentação do Curvine) cuida de metadados e journaling, persistidos no Amazon EBS para durabilidade, enquanto componentes Worker rodam em cada nó GPU e armazenam dados no NVMe local do nó. Se um Worker falha, o cache que ele mantinha é recomputado — sem preocupação com perda de dados, já que são blocos KV reproduzíveis.

Roteamento inteligente: levando requisições à réplica certa

Uma hierarquia de três camadas só entrega seu benefício máximo se as requisições chegarem às réplicas que já têm os blocos KV relevantes. O Inference Operator do HyperPod inclui um roteador integrado com três estratégias:

• prefix-aware (padrão): ideal para diálogo de múltiplos turnos e system prompts compartilhados
• kv-aware: indicado para processamento de documentos longos e sessões estendidas
• round-robin: adequado para inferência em lote sem estado e testes de carga

O roteador mantém uma árvore de prefixos (modo prefix-aware) ou consulta o estado de cache de cada worker (modo kv-aware) para selecionar a réplica com maior probabilidade de produzir um cache hit. Isso ocorre de forma transparente — sem necessidade de alterações no cliente.

Implementação passo a passo

A implementação está organizada em cinco estágios. O walkthrough assume um cluster SageMaker HyperPod orquestrado pelo Amazon EKS. Para criar um, a documentação da AWS orienta seguir o guia Orquestrando clusters SageMaker HyperPod com Amazon EKS, ou usar os templates de referência no repositório AWSome Distributed AI. É necessário provisionar pelo menos dois nós GPU — um único nó não demonstra reutilização entre nós.

Estágio 1: Habilitar o Tiered Storage do HyperPod

O Tiered Storage é uma opção no nível do cluster. Uma vez ativo, o HyperPod implanta automaticamente o DaemonSet ai-toolkit em todos os nós.

aws sagemaker update-cluster \
  --cluster-name hyperpod-cluster-eks \
  --tiered-storage-config Mode=Enable,InstanceMemoryAllocationPercentage=20 \
  --node-recovery Automatic

Atenção: chamar update-cluster apenas com --tiered-storage-config retorna ValidationException. É necessário fornecer também --node-recovery ou --instance-groups. O InstanceMemoryAllocationPercentage aceita valores entre 20 e 100 — comece com 20 e aumente conforme necessário.

Estágio 2: Instalar o Inference Operator e dependências

A forma mais conveniente é o Quick Install no console do SageMaker, que provisiona o papel IAM e instala S3 CSI, FSx CSI, Metrics Server, Cert Manager e o Inference Operator em uma única ação. A alternativa via CLI:

EKS_CLUSTER_NAME=$(aws sagemaker describe-cluster --cluster-name hyperpod-cluster-eks \
  --query 'Orchestrator.Eks.ClusterArn' --output text | cut -d'/' -f2)

for addon in aws-mountpoint-s3-csi-driver aws-fsx-csi-driver metrics-server cert-manager; do
  aws eks create-addon --cluster-name $EKS_CLUSTER_NAME --addon-name $addon --region us-west-2
done

aws eks create-addon \
  --cluster-name $EKS_CLUSTER_NAME \
  --addon-name amazon-sagemaker-hyperpod-inference \
  --configuration-values file://addon-config.json \
  --region us-west-2

Estágio 3: Implantar o cache distribuído Curvine

Antes de implantar o Curvine, é necessário atualizar o plugin VPC CNI e o driver EBS CSI, conceder ao papel aws-ebs-csi-dri-role as permissões de attach de EBS e verificar que uma StorageClass EBS está disponível no cluster. Em seguida, instala-se o CSI do Curvine via Helm:

helm repo add curvine https://curvineio.github.io/helm-charts
helm repo update
helm install curvine-csi curvine/curvine-csi \
  -n curvine --create-namespace \
  --version 0.3.2-alpha \
  --set controller.sidecars.provisioner.image=registry.k8s.io/sig-storage/csi-provisioner:v3.6.0 \
  --set node.sidecars.nodeDriverRegistrar.image=registry.k8s.io/sig-storage/csi-node-driver-registrar:v2.10.0 \
  --set controller.container.securityContext.privileged=true \
  --set node.container.securityContext.privileged=true

Depois, cria-se a StorageClass do Curvine e implanta-se o servidor Curvine (componentes Primary + Worker). Para workloads de cache KV, o NVMe local com hostPath é o backend recomendado — instâncias G6e/P5 vêm com NVMe (~3 GB/s), o que entrega performance muito superior ao EBS gp3, sem custo adicional, e é aceitável para caches onde perda é recuperável.

Após confirmar que todos os Pods estão em estado Running, é fundamental desabilitar imediatamente as flags de formatação para evitar que uma reinicialização futura do Pod reformate e apague os metadados existentes:

helm upgrade curvine curvine/curvine -n curvine \
  --version 0.3.2-alpha --reuse-values \
  --set cluster.formatMaster=false \
  --set cluster.formatWorker=false \
  --set cluster.formatJournal=false

Por fim, cria-se um PVC (PersistentVolumeClaim) ReadWriteMany para os Pods de inferência e aguarda-se o status Bound antes de prosseguir.

Estágio 4: Implantar o endpoint vLLM com cache KV em camadas

Com o Tiered Storage habilitado, o Operator instalado e o Curvine rodando, o estágio final implanta o endpoint de inferência. Isso envolve três passos: declarar o endpoint com o CRD InferenceEndpointConfig, fazer patch no Deployment renderizado para montar o PVC do Curvine, e sobrescrever a URL de cache L2 injetada pelo Operator para apontar ao Curvine.

Dois pontos merecem atenção especial nas variáveis de ambiente do deployment:

• LMCACHE_REMOTE_SERDE=naive: o serializador cachegen tem um bug de serialização zip no conector de sistema de arquivos do LMCache. O serializador naive é a escolha estável.
• PYTHONHASHSEED=0: o LMCache deriva chaves de cache de hashes Python. Sem um seed fixo, cada Pod computa chaves diferentes para o mesmo prompt e o compartilhamento entre Pods silenciosamente não funciona.

Como o Operator executa um loop de reconciliação que sobrescreve patches aplicados diretamente no Deployment, a sequência correta é: pausar o Operator, escalar o Deployment para zero, aplicar todos os patches em um único comando, escalar de volta, e restaurar o Operator somente após os Pods estarem prontos.

O patch substitui o valor de LMCACHE_REMOTE_URL para fs://localhost:0/mnt/curvine/l2cache/, adiciona o volume do PVC do Curvine e monta o volume no container vLLM. O formato localhost:0 é um placeholder — o conector fs:// do LMCache ignora host e porta e usa apenas o caminho do filesystem.

Importante para produção: o patch persiste enquanto o Operator não tiver motivo para re-renderizar o Deployment. Para uso produtivo de longa duração, a AWS recomenda substituir o patch manual por um MutatingWebhook ou uma ClusterPolicy do Kyverno que injete o volume, o mount e a URL do Curvine automaticamente a cada renderização.

Estágio 5: Verificar escrita L2, acerto e compartilhamento entre Pods

Um prompt curto não dispara escrita L2 — o LMCache armazena um bloco somente quando um prompt ultrapassa o tamanho de chunk de 256 tokens. O teste de validação usa um documento longo real e envia a requisição byte-idêntica para dois Pods diferentes em dois nós distintos: o primeiro Pod computa o prefill e escreve no Curvine; o segundo lê a mesma entrada pelo mount FUSE compartilhado.

Resultados observados (duas réplicas em dois nós G6e separados):

# POD1 (nó A) -- cold: 0 hits, computa prefill, escreve 1.925 tokens no Curvine
LMCache INFO: Reqid: ..., Total tokens 1925, LMCache hit tokens: 0, need to load: 0
LMCache INFO: Stored 1925 out of total 1925 tokens. size: 0.1028 GB, cost 10.71 ms, throughput: 9.60 GB/s

# POD2 (nó B) -- lê a MESMA entrada via Curvine: 100% de acerto entre Pods, sem prefill
LMCache INFO: Reqid: ..., Total tokens 1925, LMCache hit tokens: 1925, need to load: 1924
LMCache INFO: Retrieved 1925 out of 1925 required tokens. cost 55.75 ms, throughput: 1.84 GB/s

O acerto de 1.925/1.925 no POD2 é a prova de que o L2 compartilhado funciona: o POD2 nunca executou o prefill desse prompt, mas recuperou o cache completo via Curvine.

Benchmarks: quando o L2 compartilhado compensa

A AWS realizou dois benchmarks complementares usando Qwen2-7B-Instruct (fp16, paralelismo tensorial 1), servido por duas réplicas vLLM em dois nós GPU separados.

O primeiro benchmark variou prompts de 500 a 3.000 tokens em instâncias ml.g5.4xlarge. Para prompts acima de 1.000 tokens, o Pod B atingiu 100% de acerto dos tokens escritos pelo Pod A e pulou o prefill completamente: o speedup cresceu de 1,7x em 1.000 tokens até 2,7x em 2.500 tokens, onde uma requisição fria de 774 ms foi concluída em 287 ms. Abaixo de ~1.000 tokens, o round-trip do L2 custa tanto quanto recomputar o prefill (0,99x em 500 tokens) — para prompts curtos, as camadas L0/L1 são o lugar certo para acertar, que é exatamente o que o roteamento prefix-aware incentiva.

O segundo benchmark simulou uma conversa de quatro turnos com histórico acumulado (530 a 2.114 tokens de prompt) em instâncias ml.g6e.4xlarge e ml.g6.16xlarge. Todos os turnos atingiram 100% no L2, reduzindo a latência total da conversa de 4,21 s para 3,25 s (1,30x), com speedup por turno crescendo conforme o histórico acumulava — de 1,22x em 530 tokens a 1,34x em 2.114 tokens.

Duas conclusões práticas dos números: escritas custam pouco (caem no Worker NVMe local a velocidade próxima do disco); leituras são o custo a gerenciar, pois cruzam a rede do Pod — por isso o roteamento prefix-aware importa tanto. Além disso, a economia melhora com o comprimento do contexto até a zona de conforto da rede (~2.500 tokens nesse ambiente), e workloads dominados por prompts abaixo de ~1.000 tokens devem depender de L0/L1 em vez de L2.

Benefícios e operação

A arquitetura entrega benefícios mensuráveis em múltiplas dimensões. Instâncias econômicas como ml.g6e.4xlarge (48 GB por GPU) passam a ser suficientes para hospedar modelos como Qwen2-7B e Llama-3-8B com altas taxas de acerto de cache KV em prompts longos. O cache KV não fica mais limitado pela memória GPU: os dados mais quentes ficam na GPU, os mornos na CPU e os frios são descarregados para o NVMe local agregado, com capacidade L2 escalando linearmente (100 Gi de NVMe por Worker × N nós). Workloads multi-tenant de prompts longos que antes exigiam ml.g6e.12xlarge ou ml.p5.24xlarge podem ser migrados para instâncias menores.

Do ponto de vista operacional, o SageMaker HyperPod implanta o DaemonSet ai-toolkit automaticamente em todos os nós, com novos nós se auto-integrando sem intervenção. Com o Curvine, os Workers usam hostPath + NVMe de instância sem custo adicional de armazenamento, enquanto o componente Master usa apenas um pequeno volume EBS (10–50 Gi) para metadados. O Inference Operator gerencia o ciclo de vida dos Pods vLLM, roteamento inteligente, Cert Manager e métricas — as equipes de workload mantêm apenas um único CRD.

Para quais workloads faz sentido?

Essa arquitetura é adequada para workloads com alta sobreposição de prompts: pipelines RAG que reutilizam contexto recuperado, diálogo de múltiplos turnos onde o histórico de sessão se acumula, e deployments multi-tenant que compartilham um template de system prompt. Se o tráfego tem esse perfil e a equipe quer menor TTFT em instâncias menores, vale avaliar.

A mesma camada L2 também sustenta o serving com prefill/decode desagregados (PD) no Inference Operator do HyperPod, que roteia a troca KV entre pools de prefill e decode pelo mesmo stack LMCache — o Curvine pode ser estendido para modelos grandes multi-nó via o override padrão de LMCACHE_REMOTE_URL.

Para começar

• Saiba mais sobre o Amazon SageMaker HyperPod na página do serviço
• Ative o Cache KV Gerenciado em Camadas usando a documentação de deployment de modelos do HyperPod
• Consulte o post sobre Cache KV Gerenciado em Camadas e Roteamento Inteligente para resultados detalhados de benchmark e orientações sobre estratégias de roteamento
• Implante o sistema de arquivos distribuído Curvine usando os Helm charts do Curvine
• Explore o vLLM e o LMCache para detalhes sobre configuração de conectores de cache e políticas de despejo
• Para configuração do cluster e instalação do Inference Operator, consulte o guia de configuração do HyperPod

Fonte

Tiered KV cache for large LLMs on Amazon SageMaker HyperPod with Curvine (https://aws.amazon.com/blogs/machine-learning/tiered-kv-cache-for-large-llms-on-amazon-sagemaker-hyperpod-with-curvine/)

Contexto: o que foi coberto na Parte 1

A Parte 1 desta série apresentou a atribuição granular de custos do Amazon Bedrock — um recurso que rastreia automaticamente cada requisição de inferência até o principal do Serviço de Gerenciamento de Identidade e Acesso (IAM) que realizou a chamada. A coluna line_item_iam_principal no Relatório de Custo e Uso (CUR) passa a oferecer visibilidade por usuário e por aplicação, e com tags de alocação de custos opcionais, é possível agregar gastos por equipe, projeto ou tenant.

Nesta segunda parte, a AWS mostra como colocar esses dados em prática: como configurar o CUR 2.0 com dados de principal IAM, como consultar padrões de custo no Amazon Athena e como comparar gastos entre projetos e identidades. A publicação também apresenta os novos recursos do painel CUDOS com suporte completo à atribuição de custos do Bedrock.

Configurando o Relatório de Custo e Uso (CUR 2.0)

Antes de analisar os custos do Amazon Bedrock, é necessário configurar uma exportação de dados CUR 2.0 e conectá-la ao Amazon Athena. Os pré-requisitos são:

• Uma conta AWS com acesso ao console de faturamento
• Permissões IAM para Relatórios de Custo e Uso, S3 e Athena
• Um bucket do Amazon S3 para armazenar os dados do CUR
• Familiaridade básica com SQL e o Console de Gerenciamento da AWS
• (Opcional) Claude Code ou Kiro-CLI para configuração automatizada

Verifique se você possui as permissões IAM necessárias antes de começar. Para a atribuição de custos do Bedrock, é preciso habilitar os dados de principal IAM na exportação CUR 2.0, de forma que a coluna line_item_iam_principal e as tags associadas sejam populadas.

Criando a exportação CUR 2.0 com dados de principal IAM

Siga as instruções de criação de uma exportação de dados padrão para configurar a exportação CUR 2.0. Durante a configuração, certifique-se de que as seguintes opções estejam presentes:

• Em Conteúdo adicional da exportação, marque a opção Include caller identity (IAM principal) allocation data — essa é a configuração essencial que popula a coluna line_item_iam_principal e expõe as tags do principal IAM (prefixadas com iamPrincipal/) nos dados de custo.
• Em Configurações da tabela de dados, defina a granularidade de tempo como Hourly para o máximo de detalhes.
• Em Opções de entrega, selecione Overwrite existing report para evitar dados duplicados.

Atenção: habilitar os dados de principal IAM aumenta o tamanho dos arquivos CUR, pois o que antes era uma única linha de uso agora se expande em múltiplas linhas — uma para cada principal IAM que contribuiu para aquele uso. Para workloads de alto volume com muitos principals distintos, planeje o armazenamento no Amazon S3 adequadamente e considere o uso de políticas de ciclo de vida do Amazon S3 para arquivos CUR mais antigos. Pode levar até 24 horas para que a AWS entregue o primeiro relatório CUR 2.0 no bucket S3.

Conectando o CUR 2.0 ao Amazon Athena

Com o Amazon Athena, é possível consultar os dados do CUR usando SQL padrão sem nenhuma infraestrutura para gerenciar. Para simplificar essa configuração, há um repositório agent.md opcional que pode ser usado com assistentes de IA como Claude Code, Kiro-CLI ou Codex. Ele automatiza o processo completo de conexão do ambiente Athena aos dados do CUR:

1. Clone o repositório: git clone https://github.com/aws-samples/sample-cur-iam-principal-bedrock-tracking
2. Inicie o Claude Code (claude) ou o Kiro CLI (kiro) nesse diretório
3. Use o prompt: “Read agent.md and follow its workflow to set up Cost and Usage Report tracking and run the Amazon Bedrock-by-principal query for the current month.”

Também é possível seguir os passos de configuração manual. Se você planeja implantar o painel CUDOS, pode implantá-lo pelo AWS CloudFormation, que também cria o banco de dados do Athena como parte do processo.

Após a implantação, uma query de teste no Editor de Queries do Athena pode validar a configuração:

SELECT line_item_iam_principal,
       line_item_usage_type,
       line_item_unblended_cost --# Note: replace your_cur_table_name, like `cid_data_export.cur2`
FROM your_cur_table_name
WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService')
  AND line_item_iam_principal IS NOT NULL
LIMIT 10;

Se essa query retornar linhas com ARNs de principal IAM e tipos de uso do Bedrock, a configuração está completa e pronta para análises mais aprofundadas.

Padrões de queries no Athena para rastreamento de custos do Bedrock

Com os dados do CUR 2.0 disponíveis no Athena, é possível responder perguntas granulares de atribuição de custos usando SQL. A seguir, três padrões de queries progressivamente mais sofisticados que cobrem os cenários de análise mais comuns.

Nota: nas queries abaixo, substitua your_cur_table_name pelo nome real da sua tabela CUR no Athena (por exemplo, cid_data_export.cur2).

Query 1: Custos do Bedrock por principal IAM e tipo de uso

Esta query oferece um detalhamento completo dos gastos com o Amazon Bedrock por identidade do chamador e uso de modelo. Ela responde à pergunta: “Quem está chamando quais modelos e quanto está gastando?”

SELECT line_item_iam_principal,
       line_item_usage_type,
       SUM(line_item_usage_amount) AS total_tokens,
       SUM(line_item_unblended_cost) AS total_cost
FROM your_cur_table_name
WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService')
  AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m')
  AND line_item_iam_principal IS NOT NULL
  -- AND line_item_usage_type LIKE '%Sonnet%input%'
GROUP BY line_item_iam_principal, line_item_usage_type
ORDER BY total_cost DESC;

Dica de análise: use padrões LIKE como line_item_usage_type LIKE '%Sonnet%output%' ou %nova% para filtrar modelos específicos. A coluna line_item_iam_principal contém o ARN completo. Para roles assumidas, o nome de sessão após o último / identifica o usuário ou sessão específica.

Query 2: Custos agrupados por tags de principal IAM conhecidas

Quando os principais IAM estão marcados com dimensões como team, project ou costcenter — e essas tags foram ativadas como tags de alocação de custos —, elas aparecem nos dados do CUR 2.0 com o prefixo iamPrincipal/. Esta query agrupa os custos por essas tags para responder perguntas como: “Quanto a equipe de engenharia gastou com o Bedrock neste mês?” ou “Qual é o custo total do Bedrock para o projeto chatbot?”

SELECT tags['iamPrincipal/project'] AS project,
       line_item_usage_type,
       SUM(line_item_usage_amount) AS total_tokens,
       SUM(line_item_unblended_cost) AS total_cost
FROM your_cur_table_name
WHERE line_item_product_code in ('AmazonBedrock', 'AmazonBedrockService')
  AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m')
  AND line_item_iam_principal IS NOT NULL
GROUP BY tags['iamPrincipal/project'], line_item_usage_type
ORDER BY total_cost DESC;

Nota: esta query retorna resultados apenas se os principais IAM tiverem sido marcados com as chaves relevantes e essas tags tiverem sido ativadas como tags de alocação de custos.

Query 3: Descoberta dinâmica de tags com UNNEST para schemas desconhecidos

Em organizações maiores, pode não ser possível saber antecipadamente quais tags foram aplicadas em todos os principais IAM. Diferentes equipes podem usar chaves de tags distintas, ou novas tags podem ser introduzidas ao longo do tempo. A função UNNEST do Athena permite explorar isso dinamicamente, descobrindo todas as tags de principal IAM usadas nas workloads do Bedrock e mostrando a alocação de custo para cada par chave-valor de tag:

WITH iam_principal_costs AS (
  SELECT t.key AS tag_name,
         t.value AS tag_value,
         line_item_usage_type,
         line_item_unblended_cost
  FROM your_cur_table_name
  CROSS JOIN UNNEST(tags) AS t(key, value)
  WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService')
    AND line_item_iam_principal IS NOT NULL
    AND line_item_iam_principal != ''
    AND t.key LIKE 'iamPrincipal/%'
)
SELECT tag_name || ': ' || tag_value AS tags,
       line_item_usage_type,
       SUM(line_item_unblended_cost) AS total_cost
FROM iam_principal_costs
GROUP BY tag_name, tag_value, line_item_usage_type
ORDER BY total_cost DESC;

Caso de uso real: comparação de custos entre múltiplos serviços

Considere uma equipe de plataforma que executa múltiplos serviços com IA. Por exemplo, um pipeline de sumarização de documentos (DocProcessor) e um chatbot voltado ao cliente (ChatApp). Cada serviço é atribuído a sua própria role IAM. Com os padrões de query apresentados, é possível isolar como o gasto de cada serviço evolui:

SELECT line_item_iam_principal,
       line_item_usage_type,
       SUM(line_item_usage_amount) AS total_usage,
       SUM(line_item_unblended_cost) AS total_cost
FROM your_cur_table_name
WHERE line_item_product_code IN ('AmazonBedrock', 'AmazonBedrockService')
  AND billing_period = DATE_FORMAT(CURRENT_DATE, '%Y-%m')
  AND line_item_iam_principal IS NOT NULL
  AND (
    line_item_iam_principal LIKE '%DocProcessor%'
    OR line_item_iam_principal LIKE '%ChatApp%'
  )
GROUP BY line_item_iam_principal, line_item_usage_type
ORDER BY total_cost DESC;

Com os resultados, a equipe consegue responder perguntas como: qual aplicação é a maior responsável pelo gasto com Bedrock neste mês? No exemplo do artigo original, o ChatApp acumula mais de US$ 80 usando o Claude 4.6 Sonnet, enquanto o DocProcessor custa menos de US$ 5 usando o Nova Lite. Isso abre a discussão sobre se seria possível reduzir custos usando modelos diferentes para cada workload.

Custo das queries no Athena

No Athena, você paga apenas pelas queries executadas, com base na quantidade de dados varridos por cada consulta. As queries são cobradas a US$ 5 por TB varrido, com um mínimo de 10 MB por query. Como a tabela usa automaticamente projeção de partição Hive sobre o campo billing_period, queries limitadas a um único mês varrem apenas os arquivos Parquet daquele período — geralmente bem abaixo de 10 MB, o que representa cerca de US$ 0,00005 por query. Para manter os custos baixos, sempre inclua um filtro WHERE billing_period = ... e selecione apenas as colunas necessárias, evitando o SELECT *.

O painel CUDOS e os novos recursos para o Bedrock

O painel CUDOS faz parte do framework open source Cloud Intelligence Dashboards (CID), que pode ser implantado na sua conta AWS usando templates de infraestrutura como código (IaC). O framework ajuda a promover accountability financeiro e aumentar a eficiência operacional em organizações AWS.

A versão 5.8 do CUDOS introduz uma seção abrangente do Amazon Bedrock na aba AI/ML, com suporte completo à atribuição de custos por principal IAM. Os principais recursos são:

• Dimensões de agrupamento flexíveis: agrupe os gastos com o Bedrock por Principal IAM, Tags de Principal IAM (como Projeto ou Equipe), Modelo/Grupo de Recursos, Região ou qualquer outro campo de taxonomia de custos configurado durante a implantação.
• Rastreamento de custo por milhão de tokens: uma linha de tendência sobreposta ao gráfico de gastos mostra como o custo por milhão de tokens evolui ao longo do tempo, ajudando a medir o impacto de mudanças na seleção de modelos ou de esforços de otimização de prompts, como o uso de cache.
• Filtragem interativa com drill-down: ao selecionar qualquer valor no gráfico de gastos de alto nível (como um projeto, principal ou conta específicos), todos os outros visuais se filtram automaticamente para aquela seleção, permitindo navegar de uma visão geral até o detalhe por modelo e tipo de uso sem sair do painel.
• Detalhamento granular por modelo e tipo de uso: visuais adicionais mostram gastos por modelo, por tipo de uso e custo por milhão de tokens por modelo, para identificar quais modelos e tipos de token estão gerando custos para uma determinada equipe ou projeto.

Com esses visuais, é possível responder rapidamente a perguntas como “Qual projeto está gerando mais custos de tokens de saída?”, “Nossa equipe de chatbot está usando modelos eficientes em custo?” ou “Como o nosso custo por milhão de tokens mudou desde que migramos do Opus para o Sonnet?” — sem escrever nenhum SQL.

Como começar com o CUDOS

Para explorar os novos recursos, a AWS disponibiliza um demo interativo do painel. Para implantar em sua organização, siga o guia de implantação. Quem já usa o CUDOS pode seguir as instruções de atualização para a versão 5.8. Também é possível usar a funcionalidade de adicionar taxonomia organizacional para incluir dados de Principal IAM em um painel CUDOS já existente.

Limpeza dos recursos

Para remover os recursos criados, siga esta sequência:

1. Remova a tabela do Athena e o banco de dados do AWS Glue (são apenas metadados, sem compute em execução):

aws glue delete-table --region us-east-1 --database-name your_cur_table_name --name curexport
aws glue delete-database --region us-east-1 --name your_cur_table_name

Atenção: remover a tabela do Athena e o banco de dados do Glue eliminará a capacidade de consultar os dados do CUR. Será necessário recriar esses recursos caso queira analisar dados de faturamento no futuro.

2. Se os dados de custo não forem mais necessários, desative a exportação no console de Gerenciamento de Faturamento e Custos da AWS, em Data Exports, e esvazie o prefixo S3 correspondente. Atenção: isso representa o histórico bruto de faturamento — delete apenas se tiver certeza.

3. Limpe os resultados de queries do Athena acumulados:

aws s3 rm s3://<your-cur-bucket>/athena-results/ --recursive

Não há crawlers, funções AWS Lambda ou agendamentos para excluir. A projeção de partição significa que o único custo contínuo é o armazenamento S3 dos próprios arquivos CUR, que tipicamente representa centavos por mês. Para a limpeza do CUDOS, consulte as instruções de teardown do painel CUDOS.

Conclusão

Esta série de dois artigos apresenta um conjunto completo de ferramentas para entender e gerenciar os custos de inferência do Amazon Bedrock. A Parte 1 introduziu a atribuição granular de custos — como o Bedrock captura automaticamente o principal IAM por trás de cada chamada de inferência e como as tags de alocação de custos permitem agregar gastos por equipe, projeto ou tenant. Esta segunda parte mostrou como colocar esses dados em uso: configurando o CUR 2.0 com dados de principal IAM, consultando padrões de custo no Amazon Athena e comparando gastos entre projetos e principals para embasar decisões de alocação de custos. O painel CUDOS complementa essa visão com uma aba de AI/ML abrangente para o Bedrock.

O caminho prático sugerido pela AWS é: habilite o CUR 2.0 com dados de identidade do chamador no console de faturamento, conecte-o ao Athena usando o arquivo agent.md do repositório disponibilizado e execute sua primeira query de custo por principal. Em seguida, acompanhe a adoção do Bedrock na sua organização com o painel CUDOS.

Fonte

Part 2: Amazon Bedrock cost attribution with Amazon Athena and CUDOS (https://aws.amazon.com/blogs/machine-learning/part-2-amazon-bedrock-cost-attribution-with-amazon-athena-and-cudos/)