A AWS anunciou que o AWS Certificate Manager (ACM) vai encerrar o suporte à validação de certificados públicos por e-mail. O prazo final para essa descontinuação é 30 de setembro de 2027. Quem ainda utiliza esse método de validação precisa migrar para a validação via DNS antes dessa data.
A decisão não é isolada: ela acompanha uma mudança de padrão em toda a indústria, liderada pelo Fórum de Autoridades Certificadoras e Navegadores (CA/B). Em novembro de 2025, o fórum votou pelo encerramento da validação por e-mail a partir de 15 de março de 2028. Após essa data, certificados validados por e-mail simplesmente deixarão de ser reconhecidos pelos navegadores — independentemente de qual autoridade certificadora os emitiu. A AWS está se antecipando um ano a esse prazo para dar mais tempo de adaptação às equipes.
Por que esse prazo importa
O Fórum CA/B é o organismo que define os padrões que navegadores e autoridades certificadoras devem seguir para emitir certificados publicamente confiáveis. Quando esse fórum toma uma decisão, ela afeta toda a cadeia de confiança da web. Ou seja: não se trata de uma escolha da AWS, mas de uma exigência da indústria que a AWS está incorporando ao seu serviço com antecedência.
Certificados emitidos antes de março de 2028 continuam válidos até o vencimento normal — mas não serão mais renováveis por e-mail após os prazos estabelecidos.
Cronograma completo das mudanças
Para quem usa validação por e-mail no ACM, estes são os marcos que precisam estar no radar:
1º de janeiro de 2027: o ACM deixa de oferecer validação por e-mail em novas regiões AWS.
31 de março de 2027: o ACM deixa de aceitar novos pedidos de certificado com validação por e-mail em qualquer região.
30 de setembro de 2027: o ACM deixa de renovar certificados existentes que ainda usam validação por e-mail em qualquer região.
15 de março de 2028: prazo do Fórum CA/B — nenhuma autoridade certificadora pública pode mais emitir ou renovar certificados com validação por e-mail.
Como identificar certificados validados por e-mail
O primeiro passo é saber quais certificados na sua conta ainda usam esse método. A AWS disponibiliza duas formas para isso.
Pelo console do ACM
No console do ACM, basta aplicar os filtros Método de validação = E-mail e Tipo = Emitido pela Amazon. Qualquer certificado listado precisa ser migrado antes de 30 de setembro de 2027.
Pela AWS CLI
Para quem prefere automatizar ou verificar em múltiplas regiões, a Interface de Linha de Comando da AWS (AWS CLI) também resolve. O script abaixo lista todos os certificados públicos emitidos pela Amazon que ainda utilizam validação por e-mail em uma determinada região:
# Discover email validated public certificates
region="${1:-us-east-1}"
aws acm list-certificates --region "$region" \
--query "CertificateSummaryList[?Type=='AMAZON_ISSUED'].CertificateArn" --output text | tr '\t' '\n' | while read -r arn; do
aws acm describe-certificate --region "$region" --certificate-arn "$arn" \
--query 'Certificate.[DomainName,Type,DomainValidationOptions[0].ValidationMethod]' \
--output text
done | awk -F'\t' '$3 == "EMAIL"' | column -t
Usage:
chmod +x list-email-validated-certs.sh
./list-email-validated-certs.sh # default region, us-east-1
./list-email-validated-certs.sh us-west-2 # another region
Como migrar para validação DNS
A AWS atualizou a API UpdateCertificateOptions para permitir a troca do método de validação de e-mail para DNS diretamente no certificado existente. O ponto mais importante aqui: o ARN (Nome de Recurso Amazon) do certificado não muda. Isso significa que nenhum recurso AWS que referencia esse certificado — como um load balancer ou distribuição CloudFront — precisará ser reconfigurado.
Ao iniciar a atualização, o ACM fornece um registro CNAME que deve ser adicionado à configuração de DNS do domínio. Há uma janela de 72 horas para adicionar esse registro. Durante esse período, o certificado continua funcionando normalmente via validação por e-mail. Se as 72 horas expirarem sem que o registro DNS tenha sido adicionado, o certificado permanece ativo na validação por e-mail e a migração pode ser tentada novamente quando conveniente.
Após a conclusão da validação DNS, o ACM passa a renovar o certificado automaticamente, sem necessidade de intervenção manual — desde que o registro CNAME permaneça na configuração de DNS.
Migrando pelo console
Ao abrir um certificado com validação por e-mail no console do ACM, a opção Atualizar método de validação estará disponível no topo da página. Após acionar a atualização, o console exibe um aviso com a opção de visualizar e baixar os registros CNAME em formato CSV para importar em outros provedores de DNS.
Para quem usa o Amazon Route 53, há uma opção de criação automática dos registros de validação com um único clique.
Migrando pela AWS CLI
Para a migração via linha de comando, a AWS disponibiliza um guia detalhado na documentação oficial. Consulte o guia de migração de e-mail para DNS para instruções completas.
Alternativas disponíveis após o encerramento da validação por e-mail
Com o fim da validação por e-mail, o ACM passa a suportar dois métodos para novos certificados:
Validação DNS: adicione um registro CNAME à configuração de DNS do domínio. O ACM renova automaticamente os certificados enquanto o registro estiver presente. Este é o método recomendado para a maioria dos casos de uso.
Validação HTTP para CloudFront: o ACM fornece um token exclusivo que deve ser hospedado em um caminho de URL específico no domínio. Este método está disponível exclusivamente para certificados usados com o Amazon CloudFront.
Ambos os métodos eliminam a etapa de aprovação manual que a validação por e-mail exigia, permitindo que o ACM cuide das renovações de forma totalmente automática.
Conclusão
A descontinuação da validação por e-mail no ACM é uma consequência direta das novas exigências da indústria de certificados digitais. A AWS está se movendo com antecedência em relação ao prazo do Fórum CA/B, o que dá às equipes tempo suficiente para planejar e executar a migração sem pressão de última hora.
O caminho recomendado é claro: identificar os certificados com validação por e-mail, usar a API UpdateCertificateOptions para migrar para DNS em cada um deles, adicionar o registro CNAME no DNS, e deixar o ACM cuidar das renovações automaticamente a partir daí. Dúvidas ou dificuldades durante o processo podem ser direcionadas ao AWS Support ou ao Fórum ACM no AWS re:Post.
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.
A AWS anunciou uma versão completamente reconstruída do seu cliente VPN: o AWS VPN Client v6.0.x. A atualização traz três melhorias principais que vinham sendo esperadas por equipes de infraestrutura: suporte a Interface de Linha de Comando (CLI), controles administrativos centralizados e tempo de estabelecimento de conexão mais rápido.
Suporte a CLI: automação sem gambiarras
Até agora, quem precisava integrar a conectividade VPN a fluxos automatizados dependia de ferramentas de terceiros ou de intervenção manual — o que criava fricção em pipelines de infraestrutura como código e ambientes de automação. Com o novo suporte à CLI, esse problema deixa de existir.
A CLI do AWS VPN Client oferece paridade completa de recursos com a interface gráfica (GUI). Isso significa que é possível incluir conexões VPN diretamente em scripts de automação e em deployments de infraestrutura como código, com operações rodando em segundo plano sem depender da interface visual.
Vale destacar: a GUI e a CLI podem ser usadas simultaneamente, e as conexões VPN persistem independentemente de qual interface esteja ativa no momento.
Controles administrativos: gestão centralizada de perfis
Outro ponto relevante desta atualização é a chegada dos controles administrativos no cliente. Antes, os perfis de VPN precisavam ser distribuídos para todos os usuários da organização — e qualquer usuário podia gerenciá-los sem restrições de permissão.
Agora, com os controles administrativos, as equipes de TI e segurança ganham mais governança sobre o ambiente:
É possível centralizar a aplicação de políticas de VPN, vinculando perfis a usuários específicos;
Perfis globais podem ser gerenciados para todos os usuários de um dispositivo;
Configurações aprovadas de VPN podem ser aplicadas de forma padronizada em toda a organização.
Conexões mais rápidas com OpenVPN3
O cliente foi reconstruído com base no OpenVPN3, o que resulta em um estabelecimento de conexão mais rápido em todos os sistemas operacionais suportados. A mudança é transparente para o usuário final, mas representa uma melhoria real na experiência do dia a dia.
Compatibilidade e disponibilidade
A versão 6.0 em diante mantém compatibilidade retroativa completa com os endpoints existentes do AWS Client VPN — ou seja, não é necessário fazer nenhuma alteração nos endpoints já configurados.
O cliente atualizado já está disponível para download nas seguintes plataformas:
Não há cobranças adicionais além da precificação padrão do AWS Client VPN. Para se aprofundar, a AWS disponibiliza a documentação oficial com todos os detalhes técnicos da atualização.
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.
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.
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.
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.
Quem já montou uma aplicação na Amazon Web Services (AWS) sabe bem como é: você quer focar no que está construindo, mas antes de qualquer coisa precisa parar e configurar o Gerenciamento de Identidade e Acesso (IAM). Praticamente todo serviço AWS que age em seu nome precisa de uma função IAM — uma identidade que o serviço assume para acessar seus recursos com um conjunto definido de permissões.
Isso significa escrever uma política de confiança, escolher as permissões certas para a carga de trabalho e anexar tudo ao recurso. Para padrões comuns e repetitivos, esse processo é previsível — mas ainda assim consome tempo e exige conhecimento prévio de IAM, especialmente para quem está começando.
Foi exatamente esse atrito que a AWS quis eliminar com o lançamento do IAM Role Manager.
O que é o IAM Role Manager
O IAM Role Manager é um recurso que, quando habilitado, faz com que a AWS crie e configure automaticamente as funções IAM necessárias enquanto você constrói recursos nos consoles de serviços suportados. Em vez de interromper o fluxo de trabalho para configurar permissões manualmente, o Role Manager provisiona e anexa a função adequada como parte do mesmo processo de criação do recurso.
O resultado prático é direto: você cria o recurso que precisa, e a função IAM já vem configurada e pronta. Isso reduz o tempo de início para minutos e elimina a necessidade de experiência prévia com IAM para dar os primeiros passos.
Um exemplo concreto: ao criar uma função AWS Lambda, a função de execução já é criada e anexada automaticamente, sem que seja necessário sair do fluxo de criação para configurá-la separadamente.
Vale destacar que as funções criadas pelo Role Manager são funções IAM comuns. Elas podem ser visualizadas, editadas ou excluídas da mesma forma que qualquer outra função criada manualmente. O controle permanece totalmente nas mãos do time.
Como habilitar o Role Manager
O Role Manager opera em dois estados: habilitado e desabilitado. Quando habilitado em uma conta, ele autoriza a AWS a criar funções nessa conta conforme necessário.
Para ativá-lo, o processo é simples:
Abra o console do IAM e acesse Configurações da conta (Account settings).
Na seção do Role Manager, selecione Habilitar (Enable).
Em ambientes com múltiplas contas organizadas no AWS Organizations, administradores podem usar uma Política de Controle de Serviço (SCP — Service Control Policy) para controlar se as contas-membro podem habilitar ou usar o Role Manager.
Um ponto importante: o Role Manager não interfere nos serviços que já criam funções automaticamente ao provisionar recursos. Esses serviços continuam funcionando como antes, e as funções já existentes seguem ativas normalmente. O que o Role Manager acrescenta é um controle centralizado em nível de conta e cobertura para casos que os fluxos nativos não conseguem resolver — como tarefas cujas permissões não podem ser determinadas antecipadamente pela AWS, por exemplo, a execução de código próprio.
Sem o Role Manager, o fluxo seria interrompido nesse ponto para criar manualmente uma função que permita ao EventBridge invocar o destino — o que envolve escrever a política de confiança, definir as permissões e só então retornar à criação da regra.
Com o Role Manager habilitado, basta definir a regra e seu destino e clicar em Criar. O Role Manager provisiona e anexa a função automaticamente. O console do EventBridge exibe a regra criada e pronta para uso, sem que o fluxo de criação tenha sido interrompido em nenhum momento.
Tecnicamente, isso funciona por meio de um template de função gerenciado pela AWS — uma definição que a AWS constrói e mantém para uma tarefa específica, com a política de confiança e as permissões já definidas. O console chama uma nova API do IAM chamada AcquireRole, que localiza o template correspondente, provisiona a função a partir dele e a retorna ao serviço solicitante. Dependendo do contexto, o AcquireRole pode criar uma nova função ou reutilizar uma já existente que se encaixe no perfil, evitando que a conta acumule funções duplicadas para a mesma finalidade.
O Role Manager cria a função usando as permissões IAM do próprio usuário, não de um papel separado do gerenciador. Para provisionar uma nova função, são necessárias permissões mínimas de criação e anexação de funções. Quando o AcquireRole reutiliza uma função existente, ele precisa apenas de iam:GetRole e iam:GetRoleTemplateVersion. Se alguma permissão estiver faltando, o console informa qual é necessária.
Executando código que acessa outros serviços AWS
Nem todo caso tem um conjunto de permissões que a AWS consegue definir antecipadamente. Quando uma função executa código próprio — como uma função Lambda — a AWS não tem como saber quais serviços esse código vai chamar.
O Role Manager também cobre esse cenário: ao criar uma função Lambda com o Role Manager habilitado, ele anexa uma função de execução que o código pode usar imediatamente. Essa função pode ser refinada depois, quando as chamadas reais forem conhecidas.
Como as permissões necessárias não são conhecidas de antemão, o Role Manager anexa a política gerenciada PowerUserAccess à função. Essa política concede acesso amplo aos serviços AWS, permitindo que a função chame o que precisar. Por design, ela não concede permissão para gerenciar o IAM, o AWS Organizations ou as configurações da conta. O template também configura a função para confiar apenas no serviço Lambda.
Com isso, a função Lambda fica pronta para execução imediatamente após a criação, com a função de execução já anexada e visível na aba de configurações. É possível abrir essa função no console do IAM para revisar suas permissões a qualquer momento.
Toda função criada pelo Role Manager registra o template de origem. Tanto o GetRole quanto o ListRoles retornam essa referência, permitindo identificar facilmente quais funções foram criadas pelo gerenciador. As políticas de confiança e permissões são lidas da mesma forma que em qualquer outra função, e cada criação é registrada pelo AWS CloudTrail.
Refinando as permissões conforme a carga de trabalho amadurece
O Role Manager foi pensado para acelerar o início — mas a recomendação é clara: à medida que as cargas de trabalho amadurecem, as funções criadas por ele devem ser refinadas para seguir o princípio do menor privilégio.
Quando chegar esse momento, é possível desabilitar o Role Manager e utilizar gratuitamente a análise de acesso não utilizado do AWS IAM Access Analyzer por 90 dias sem custo adicional. O Access Analyzer analisa como cada função foi utilizada e recomenda uma política que mantém apenas as permissões realmente necessárias. A sugestão é começar pelas funções anexadas às cargas de trabalho mais críticas e ir ampliando o escopo gradualmente.
Desabilitar o Role Manager não interrompe nada que já esteja em execução: os recursos mantêm as funções que têm, essas funções permanecem na conta até que sejam alteradas, e a partir desse ponto novas funções são criadas manualmente, como sempre foi.
Se a preferência for ajustar apenas uma função específica sem desabilitar o Role Manager para toda a conta, basta editar essa função. Ao fazer isso, ela sai do controle do Role Manager e passa a ser uma função gerenciada pelo cliente, com as alterações preservadas.
A recomendação geral da AWS é manter o Role Manager habilitado em contas de sandbox e desenvolvimento para ganhar agilidade. Para cargas de trabalho em produção, a orientação é desabilitá-lo e refinar as funções criadas para o menor privilégio antes de ir ao ar.
Conclusão
O IAM Role Manager representa uma mudança significativa no ponto de partida para trabalhar com IAM na AWS. Ao automatizar a criação e configuração de funções durante o processo de construção de recursos, a AWS reduz uma das principais barreiras de entrada para quem está começando — e elimina trabalho repetitivo para quem já tem experiência.
O recurso não remove o controle do desenvolvedor: as funções criadas são funções IAM comuns, totalmente visíveis e editáveis. A proposta é acelerar o início e permitir que o refinamento de permissões aconteça de forma progressiva, conforme a carga de trabalho evolui.
Para começar, basta habilitar o Role Manager nas configurações de conta do console IAM e criar um recurso em um serviço suportado. Mais detalhes sobre a criação de funções IAM e a lista de serviços suportados estão disponíveis no Guia do Usuário do IAM.
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.
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:
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:
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:
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.
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:
Clone o repositório: git clone https://github.com/aws-samples/sample-cur-iam-principal-bedrock-tracking
Inicie o Claude Code (claude) ou o Kiro CLI (kiro) nesse diretório
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.”
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.
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:
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.
A AWS anunciou a disponibilidade geral do role manager, uma nova funcionalidade dentro do Gerenciamento de Identidade e Acesso (IAM) da AWS que automatiza a criação das roles necessárias para os serviços da plataforma. A novidade foi disponibilizada em 12 de agosto de 2026.
Como funciona o role manager
A ideia central é simples: ao configurar um serviço compatível pelo console da AWS, o role manager cuida automaticamente da criação da role necessária — ou reutiliza uma já existente na conta, caso ela já tenha as permissões adequadas. Isso elimina aquele passo manual de criar e configurar roles do zero toda vez que um novo serviço é habilitado.
A funcionalidade pode ser ativada ou desativada a qualquer momento. Além disso, é possível inspecionar os templates gerenciados pela AWS que o role manager utiliza para criar as roles, garantindo transparência sobre o que está sendo provisionado.
Serviços suportados no lançamento
No lançamento, o role manager oferece suporte a 6 consoles de serviços da AWS, incluindo AWS Lambda e Amazon EventBridge. Por exemplo, ao criar uma função Lambda, o role manager aplica automaticamente o template gerenciado pela AWS correspondente a esse fluxo de trabalho.
Visibilidade e controle total
As roles criadas pelo role manager aparecem no console do IAM como roles padrão — ou seja, o usuário mantém controle total sobre elas. É possível identificar facilmente quais roles foram criadas por essa funcionalidade, o que facilita a auditoria e o gerenciamento.
Quando chegar o momento de restringir permissões com mais precisão, basta desativar o role manager e utilizar o IAM Access Analyzer para refinar cada role, deixando apenas as permissões estritamente necessárias para cada caso.
Disponibilidade
O role manager está disponível em todas as regiões da AWS, com exceção das regiões AWS GovCloud (US) e das regiões da China.
O que é o C5:2020 e por que isso importa para empresas na Europa
Organizações que operam na Alemanha e em outros países europeus enfrentam uma exigência crescente: precisam comprovar que seus ambientes de nuvem estão em conformidade com o Catálogo de Critérios de Conformidade para Computação em Nuvem (C5:2020), um padrão publicado pelo Escritório Federal de Segurança da Informação da Alemanha (BSI — Bundesamt für Sicherheit in der Informationstechnik). Trata-se de um dos marcos regulatórios mais rigorosos da Europa para uso de nuvem pública, e atender a ele exige esforço considerável de arquitetura, documentação e evidências técnicas.
É nesse contexto que a AWS fez um anúncio relevante: a disponibilização de um novo relatório de avaliação independente no AWS Artifact, que analisa como o Landing Zone Accelerator (LZA) cobre os requisitos do C5:2020 por meio da implementação de quase 200 controles de segurança nativos.
O que é o Landing Zone Accelerator (LZA)
O Landing Zone Accelerator (LZA) é uma solução da AWS que automatiza a criação de um ambiente de nuvem seguro e bem arquitetado desde o início. Ele define uma linha de base de arquitetura de segurança e provisiona automaticamente o ambiente AWS de forma que ele escale conforme a organização cresce.
O LZA pode ser utilizado em duas configurações: a configuração padrão com múltiplas contas (multi-account) ou como uma opção de implantação baseada em contêiner no AWS European Sovereign Cloud. Essa segunda opção é especialmente importante para clientes com requisitos de residência de dados, pois permite usar a mesma linha de base de configuração de segurança em um ambiente soberano europeu.
No ano passado, a AWS já havia introduzido suporte do LZA para soberania digital. Agora, o passo seguinte é a publicação desse relatório de avaliação independente voltado ao C5:2020.
O que traz o novo relatório de avaliação independente
O LZA pode ajudar a implementar 325 controles de segurança no total, distribuídos em oito áreas de controle do C5:2020.
O documento descreve o design da arquitetura do LZA, as melhores práticas de segurança e as considerações de escopo para avaliações C5:2020.
Este é o primeiro relatório C5 independente para o LZA — e está prevista uma atualização em 2027 para cobrir a revisão C5:2026, que ainda está pendente.
Como isso acelera a jornada de conformidade
É importante entender a diferença entre o que a AWS já oferecia e o que esse novo relatório acrescenta. A AWS já disponibiliza os relatórios de atestação C5 Tipo 2, que cobrem a “segurança da nuvem” — ou seja, a responsabilidade da própria AWS como provedora de infraestrutura. O novo relatório do LZA, por sua vez, oferece uma opinião independente sobre como a linha de base de segurança provisionada pelo LZA se alinha aos critérios de “segurança na nuvem” — a parte que é responsabilidade do cliente.
Essa distinção é fundamental dentro do modelo de responsabilidade compartilhada. O LZA assume parte dessa responsabilidade do lado do cliente, definindo uma arquitetura de segurança e automatizando o provisionamento do ambiente. Com o relatório em mãos, as organizações podem:
Implantar o LZA já com uma cobertura de controles documentada e avaliada de forma independente;
Usar o relatório para entender o escopo de cobertura existente e identificar o que ainda precisa ser customizado;
Utilizar o LZA Compliance Workbook para construir e adaptar a documentação de conformidade para os casos de uso específicos da organização.
O resultado prático é uma redução significativa no tempo gasto com design de arquitetura, coleta de evidências e preparação para avaliações C5:2020.
Recursos disponíveis: Workbook, repositório e agente de conformidade com IA
Além do relatório de avaliação, a AWS também disponibilizou no AWS Artifact o LZA Compliance Workbook gratuitamente. Esse documento mapeia os identificadores de requisitos do C5:2020 para declarações de implementação de segurança, oferecendo um ponto de partida para que as equipes possam customizar e aprimorar a documentação de conformidade após implantar o LZA.
Por que isso é relevante para o público brasileiro
Embora o C5:2020 seja um padrão alemão, ele é cada vez mais adotado como referência de conformidade em toda a Europa — e empresas brasileiras com operações no continente europeu ou que atendem clientes europeus precisam estar atentas a esse tipo de exigência regulatória. Além disso, a abordagem do LZA — automatizar uma linha de base de segurança documentada e avaliada de forma independente — é um modelo que pode inspirar práticas de conformidade em outros contextos regulatórios.
A disponibilização desse relatório no AWS Artifact representa um avanço concreto para reduzir a carga de trabalho de equipes de segurança e conformidade que precisam demonstrar aderência a padrões rigorosos sem partir do zero.
