Blog

  • Instâncias Amazon EC2 G7 chegam à Região AWS Europa (Espanha)

    Expansão das instâncias G7 para a Europa

    A AWS anunciou a disponibilidade das instâncias Amazon EC2 G7 na região Europa (Espanha). Equipadas com GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition, essas instâncias chegam com ganhos expressivos de desempenho em relação à geração anterior — até 4,6x mais performance em inferência de Inteligência Artificial (IA) e até 2,1x mais desempenho gráfico em comparação com as instâncias G6.

    Para que servem as instâncias G7?

    As instâncias G7 são projetadas para cobrir uma ampla gama de cargas de trabalho modernas que exigem poder computacional de GPU. Entre os principais casos de uso destacados pela AWS estão:

    • Inferência de modelos de IA: tradução de idiomas, análise de vídeo e imagem, e reconhecimento de fala.
    • Workloads gráficos: criação e renderização de gráficos em tempo real com qualidade cinematográfica, além de streaming de jogos.
    • Computação espacial e transcodificação de vídeo.
    • Análise de dados acelerada por GPU: sistemas de recomendação, inferência com Geração Aumentada por Recuperação (RAG) e pipelines de dados em tempo real.

    Especificações técnicas

    Do ponto de vista de hardware, as instâncias G7 entregam uma configuração robusta:

    • Até 8 GPUs NVIDIA RTX PRO 4500 Blackwell Server Edition, com 32 GB de memória por GPU.
    • Processadores Intel Xeon 6 customizados.
    • Suporte a até 192 CPUs virtuais (vCPUs).
    • Até 700 Gbps de largura de banda de rede com Adaptador de Malha Elástica (EFA — Elastic Fabric Adapter).
    • Até 768 GiB de memória de sistema.
    • Até 7,6 TB de armazenamento local NVMe SSD.

    Disponibilidade e formas de aquisição

    As instâncias EC2 G7 já estão disponíveis em quatro regiões AWS:

    • Leste dos EUA (Norte da Virgínia e Ohio)
    • Oeste dos EUA (Oregon)
    • Europa (Espanha)

    É possível adquiri-las como Instâncias On-Demand, Instâncias Spot ou por meio de Planos de Economia (Savings Plans). Para começar, a AWS indica o Console de Gerenciamento AWS, a Interface de Linha de Comando AWS (CLI) ou os SDKs da AWS. Para mais detalhes técnicos, acesse a página oficial das instâncias G7.

    Fonte

    Amazon EC2 G7 instances are now available in the AWS Europe (Spain) Region (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ec2-g7-available-spain)

  • AWS firma parceria com Anthropic e OpenAI para integrar o AWS Continuum nos fluxos de trabalho de desenvolvedores

    Segurança de código no ritmo das máquinas

    Os modelos de IA estão evoluindo em ritmo acelerado. Cada nova geração traz janelas de contexto maiores, raciocínio mais sofisticado e custos menores por token. Nesse cenário, a AWS entende que a segurança mais eficaz virá de ferramentas que combinem os modelos mais avançados com um conhecimento profundo do ambiente específico de cada cliente.

    É com essa premissa que a AWS anunciou a AWS Continuum para vulnerabilidades de código (Preview) — e agora vai além, revelando parcerias com a Anthropic e a OpenAI para levar o Continuum diretamente para dentro dos ambientes onde o código está sendo escrito: Claude Code, OpenAI Codex e Kiro.

    O desafio por trás da evolução dos modelos

    Os modelos de fronteira mais recentes já conseguem identificar vulnerabilidades e rastrear caminhos de ataque em múltiplas etapas — algo que levaria semanas para uma equipe de segurança humana fazer manualmente. Isso representa um avanço real na detecção. Mas cria um novo problema: mais achados, mais complexidade e a necessidade de determinar quais realmente importam para aquele ambiente específico.

    O próximo desafio é construir a orquestração correta para transformar esses modelos em uma interface única que vá da detecção até a correção. Foi exatamente isso que a AWS se propôs a fazer ao criar o Continuum: reunir diferentes modelos e usar o mais eficaz para cada etapa do processo.

    A AWS também participa do Frontier Model Forum, um consórcio da indústria que desenvolve padrões de segurança compartilhados, métodos de avaliação e benchmarks para garantir que os modelos possam ser avaliados de forma eficaz. Além disso, a empresa trabalha com os provedores de modelos em benchmarks de desempenho de segurança para assegurar que o melhor modelo seja usado para cada tarefa dentro do Continuum e de outros produtos de segurança da AWS.

    O conceito de “harness”: o motor e tudo ao redor

    Para entender o Continuum, é importante compreender o que a AWS chama de harness — a camada de orquestração que envolve um modelo para conectá-lo a ferramentas, guardrails, memória e fluxos de trabalho, transformando-o em resultados concretos. A analogia usada pela própria AWS é direta: o modelo é o motor; o harness é tudo ao redor. Você precisa dos dois para ter um carro de alto desempenho.

    Esses harnesses estão ficando cada vez mais complexos. As equipes estão costurando múltiplos modelos, agentes que chamam outros agentes e fluxos de trabalho dinâmicos — tudo isso em um cenário de mudanças constantes. Esse nível de complexidade faz com que muitas organizações criem infraestruturas paralelas e não oficiais para gerenciar as camadas de integração entre modelos e ferramentas. Cada vez que o ecossistema muda, os controles de segurança e governança potencialmente quebram, forçando as equipes a revisitá-los.

    A AWS posiciona o gerenciamento dessa complexidade como um peso que ela mesma deve resolver. A empresa trata o harness como infraestrutura, aplicando o mesmo rigor usado em identidade, descoberta, aplicação de políticas, observabilidade e conformidade na infraestrutura central da AWS.

    Como o AWS Continuum funciona na prática

    O AWS Continuum para vulnerabilidades de código descobre vulnerabilidades, prioriza-as dentro do contexto do negócio do cliente, valida-as em um ambiente isolado (sandbox) e oferece correção em velocidade de máquina.

    Por baixo dos panos, o Continuum opera com uma arquitetura de loop de equipe de agentes — um harness sofisticado que orquestra tudo: seleção do modelo adequado, conexão com o ambiente do cliente e entrega de código seguro validado em contexto. O desenvolvedor não precisa se preocupar com como a orquestração funciona ou o que mudou na última versão.

    A integração com Anthropic e OpenAI

    A AWS está trabalhando com a Anthropic e a OpenAI para trazer o Continuum para os ambientes de desenvolvimento onde o código está sendo escrito. O funcionamento será o seguinte:

    • Dentro dos ambientes Claude Code, Codex e Kiro, varreduras de vulnerabilidades sob demanda identificam possíveis problemas e enviam os achados ao Continuum.
    • O Continuum prioriza esses achados dentro do contexto do ambiente AWS do cliente — considerando configurações, políticas do Gerenciamento de Identidade e Acesso da AWS (IAM), topologia de rede e superfícies de exposição.
    • Em seguida, valida os achados em um sandbox e retorna inteligência priorizada e contextualizada de volta ao assistente de código, que ajusta suas recomendações de acordo.

    Isso colapsa o que era tradicionalmente um processo de múltiplas etapas e múltiplas equipes — escrever, escanear, triar, priorizar, corrigir, reescanear — em um único resultado: a própria sugestão de código.

    Dois modos, um objetivo

    A solução opera em dois modos complementares:

    • Para código existente: use o Continuum para vulnerabilidades de código da AWS para descobrir, priorizar, validar e corrigir em todo o ambiente.
    • Para código novo (greenfield): use o plugin do Continuum dentro do Codex, Claude Code ou Kiro para receber sugestões com validação de segurança diretamente no ambiente de desenvolvimento.

    Parceiros de design que já testaram a solução relatam resultados concretos. Mike Johnson, CISO da Rivian, destacou que o AWS Continuum conecta o código-fonte ao conhecimento corporativo, permitindo que as equipes identifiquem com precisão vulnerabilidades de segurança e verifiquem se os problemas sinalizados são realmente relevantes — reduzindo o tempo até a correção de vulnerabilidades críticas.

    Disponibilidade

    O AWS Continuum para vulnerabilidades de código já está disponível em preview. É possível solicitar acesso diretamente pelo formulário de interesse do AWS Continuum. A integração do Continuum com os fluxos de trabalho do Claude Code, Codex e Kiro está prevista para breve.

    Fonte

    AWS partners with Anthropic and OpenAI to bring AWS Continuum into developer workflows (https://aws.amazon.com/blogs/security/aws-partners-with-anthropic-and-openai-to-bring-aws-continuum-into-developer-workflows/)

  • Execute agentes de IA em produção no n8n com o Amazon Bedrock AgentCore Harness

    Do fluxo simples ao agente de produção

    Quem já usou o n8n para automatizar fluxos de trabalho sabe que o nó de AI Agent embutido resolve bem o caso mais básico: uma chamada a um modelo de linguagem dentro de um workflow. Mas um agente de produção exige muito mais do que isso. Ele precisa de memória que sobreviva entre execuções, ferramentas reais como navegador e sandbox de código, e capacidade de lidar com tarefas mais longas e complexas. Montar essa estrutura do zero é exatamente onde a maioria das equipes perde tempo.

    É nesse contexto que a AWS posiciona o Amazon Bedrock AgentCore — uma plataforma para construir, conectar e otimizar agentes em escala, compatível com qualquer framework ou modelo. O AgentCore Harness, uma das capacidades do Amazon Bedrock AgentCore, passou a ser disponibilizado em disponibilidade geral (GA) e entrega exatamente essa camada de infraestrutura gerenciada. Um novo nó comunitário de código aberto traz essa capacidade para o editor visual do n8n.

    O nó, publicado como @aws/n8n-nodes-agentcore, não prende o usuário a um único provedor. Ele funciona com Amazon Bedrock, OpenAI, Google Gemini e provedores suportados pelo LiteLLM — e é possível até trocar de provedor entre turnos de uma mesma conversa. O harness é construído sobre o Strands Agents, o framework de agentes de código aberto da AWS, e o nó é licenciado sob MIT.

    O que o harness faz por você

    Um agente não é apenas um modelo. O modelo raciocina, mas é o harness que executa o trabalho ao redor: ele roda o loop de orquestração, chama ferramentas, gerencia a janela de contexto, mantém o estado entre turnos, se recupera de falhas e isola cada sessão. Construir essa camada é onde a maioria das equipes concentra esforço.

    Com o AgentCore Harness, você define o agente em configuração — modelo, ferramentas, habilidades e instruções — e o AgentCore monta e executa o loop por você. Cada sessão roda em um ambiente isolado com sistema de arquivos próprio, memória entre sessões e navegação web. Quando a configuração não for suficiente, é possível exportar o harness para código Strands e continuar rodando no mesmo sistema.

    O nó comunitário expõe o harness completo no editor do n8n com uma única operação controlada pelo campo Harness ARN: deixe-o em branco e o nó cria o agente na primeira execução, reutiliza nas seguintes e atualiza quando a configuração muda. Cole um ARN existente e o nó invoca diretamente um agente criado fora do n8n. O padrão de credenciais é o mesmo já usado pelos nós de AWS Lambda e Amazon S3 no n8n.

    Pré-requisitos

    Antes de começar, é necessário ter:

    • Uma instância do n8n (self-hosted ou n8n Cloud). Consulte a documentação de deploy do n8n para escolher a opção adequada.
    • O nó instalado. Como nó comunitário verificado, basta pesquisar por Amazon Bedrock AgentCore no painel de nós do n8n e selecioná-lo. Também é possível instalar via Settings > Community Nodes informando @aws/n8n-nodes-agentcore. O guia usa a versão 0.3 do nó.
    • Uma conta AWS com acesso ao AgentCore Harness em uma região AWS suportada.
    • Credenciais AWS para o chamador, com as permissões de caller do harness, mais uma função de execução do AWS Identity and Access Management (IAM) separada que o harness assume em tempo de execução. As políticas de menor privilégio estão na documentação de segurança do AgentCore Harness e o README do nó mapeia cada funcionalidade às permissões necessárias.

    Importante: sempre que possível, use credenciais temporárias do AWS IAM Identity Center ou do AWS Security Token Service (AWS STS) e siga o princípio do menor privilégio ao configurar permissões IAM. Não armazene credenciais em controle de versão.

    Sobre custos: o AgentCore Harness, o armazenamento de memória gerenciada provisionado e, se utilizado, os endpoints de VPC são recursos faturáveis na AWS. Consulte a documentação do AgentCore para detalhes de preço e lembre-se de remover os recursos criados ao final.

    Configurando a credencial

    A credencial AWS é configurada uma única vez, da mesma forma que outros nós AWS no n8n. Em Credentials, crie uma nova credencial do tipo Amazon Bedrock AgentCore API. Informe o Access Key ID, o Secret Access Key e, se usar credenciais temporárias, o Session Token. Selecione a região, informe o ARN da função de execução que o harness assumirá em runtime e teste a conexão antes de salvar.

    Construindo o primeiro agente com memória persistente

    O primeiro cenário demonstrado pela AWS é um agente que lembra detalhes ao longo de turnos de conversa. A memória é ativada por padrão — o nó provisiona automaticamente um armazenamento de memória gerenciada sem configuração adicional.

    O fluxo básico é: adicionar um trigger manual, conectar o nó do Amazon Bedrock AgentCore com a credencial configurada, deixar o campo Harness ARN em branco, definir um nome para o agente (por exemplo, travel_concierge), escolher o provedor e o modelo (como um modelo Claude via Amazon Bedrock), escrever um System Prompt, definir um Session ID e inserir o prompt do primeiro turno.

    A primeira execução leva cerca de 30 a 60 segundos enquanto a AWS provisiona o agente. A saída inclui a resposta do agente, o uso de tokens e um resumo do que foi provisionado, incluindo o ARN do armazenamento de memória criado automaticamente. Nos turnos seguintes, mantendo o mesmo Session ID, o agente recupera o contexto anterior — o contador de tokens de entrada sobe porque o nó carrega a conversa prévia antes de o agente raciocinar. Deixar o Session ID em branco inicia uma nova conversa a cada execução.

    Isolando memória por usuário com Actor ID

    Quando um único agente atende múltiplas pessoas, é possível manter o histórico de cada uma separado usando o campo Actor ID, disponível nas opções adicionais do nó. A hierarquia de escopo é: o agente guarda a configuração compartilhada, o Actor ID isola a memória de um usuário de outro, e o Session ID isola conversas individuais dentro de um mesmo ator. Um ator diferente com o mesmo Session ID ainda terá sua própria memória separada.

    Na prática: configure um agente como team_assistant com memória gerenciada, defina o Actor ID como um valor por usuário (por exemplo, user-alice) e um Session ID para esse usuário. No primeiro turno, armazene uma informação. No segundo, recupere-a com o mesmo actor e session. Trocando o Actor ID, o agente não terá acesso ao histórico do usuário anterior.

    Adicionando ferramentas: interpretador de código em sandbox

    Agentes se tornam muito mais capazes quando podem usar ferramentas. O segundo cenário demonstrado é um agente com acesso a um interpretador de código que executa scripts em um ambiente isolado.

    Configure um agente como data_analyst com um modelo Claude. No System Prompt, instrua o agente a escrever e executar código para responder e reportar o resultado. Ative Add Tools, adicione uma ferramenta do tipo AgentCore Code Interpreter e insira um prompt que exija computação — por exemplo, gerar 500 notas aleatórias entre 0 e 100 e calcular média, mediana e desvio padrão.

    O agente escreve e executa o código no sandbox e retorna os resultados computados, em vez de estimá-los. O resumo do harness na saída confirma uma ferramenta configurada. Da mesma forma, é possível adicionar outras ferramentas: navegador em nuvem, AgentCore Gateway e servidores MCP remotos.

    Imagem original — fonte: Aws

    Dando habilidades ao agente com Skills

    Skills são pacotes de instruções e scripts que fornecem conhecimento de domínio ao agente sob demanda. Elas podem ser carregadas do catálogo curado da AWS, de um repositório Git, do Amazon S3 ou de um caminho no sistema de arquivos — e o harness as carrega apenas quando a tarefa exige.

    Configure um agente como aws_architect com um modelo Claude. Ative Add Skills, adicione uma skill e defina a fonte. Para o catálogo curado, escolha AWS Skills e informe um padrão glob como core-skills/*. É possível adicionar mais skills de outras fontes. Insira um prompt que se beneficie da skill, como solicitar um esboço de pipeline serverless para upload de imagens na AWS. O agente aplica as habilidades carregadas para produzir orientações, e o resumo do harness mostra o número de skills configuradas.

    Executando o agente dentro da sua VPC

    Para agentes que precisam de acesso a redes privadas, o harness pode ser executado dentro de uma Nuvem Privada Virtual (VPC). A configuração de rede é feita na credencial, então todos os agentes provisionados com aquela credencial rodarão de forma privada.

    Edite a credencial Amazon Bedrock AgentCore API, defina o Network Mode como VPC, informe os IDs de sub-redes e grupos de segurança e salve. As sub-redes não precisam de acesso à internet: o harness busca sua imagem de contêiner gerenciada em um repositório privado do Amazon ECR na mesma região, então são necessários endpoints de VPC para o Amazon ECR e o Amazon S3 — não um NAT gateway. Consulte a documentação de segurança do AgentCore Harness para os endpoints necessários e as permissões da função de execução.

    Em um workflow, use um agente como private_vpc_agent com a credencial configurada para VPC. A saída do nó confirmará que o modo de rede é VPC no resumo do harness.

    Limpeza dos recursos

    Cada agente criado é um recurso de harness na conta AWS e pode provisionar um armazenamento de memória gerenciada. Para evitar cobranças contínuas, remova os agentes que não forem mais necessários.

    Liste os harnesses com a Interface de Linha de Comando da AWS (AWS CLI):

    aws bedrock-agentcore-control list-harnesses --region us-west-2

    Exclua os criados durante o guia:

    aws bedrock-agentcore-control delete-harness --harness-id <harness-id> --region us-west-2

    Se você habilitou VPC, remova também os endpoints de interface criados, pois eles geram cobranças enquanto existem. Consulte a documentação do AgentCore para detalhes de preço.

    O que explorar a seguir

    O nó já suporta um conjunto mais amplo de funcionalidades do AgentCore Harness. Confira o que é possível explorar com a mesma abordagem de configuração apresentada acima:

    • Troca de provedor de modelo mid-session: use OpenAI, Google Gemini ou provedores LiteLLM ao lado do Amazon Bedrock e troque entre turnos da mesma sessão sem perder contexto. Provedores não-Bedrock usam uma chave de API armazenada no AgentCore Identity.
    • Mais ferramentas: adicione navegador em nuvem, AgentCore Gateway com autenticação OAuth de saída opcional e servidores MCP remotos junto ao interpretador de código.
    • Funções inline: permita que o agente chame de volta o workflow do n8n para uma etapa de revisão humana (human-in-the-loop) e retorne o resultado ao agente.
    • Contêineres customizados: traga sua própria imagem de contêiner Linux/arm64 para o agente rodar com suas próprias dependências.
    • Montagem de sistemas de arquivos: use armazenamento de sessão gerenciada ou monte Amazon EFS ou Amazon S3 para dados que sobrevivam a uma sessão.
    • Invocação autenticada com OAuth: invoque agentes protegidos por um autorizador JSON Web Token (JWT) de entrada com um token do seu provedor de identidade.
    • Versões e endpoints: cada mudança de configuração gera uma versão imutável, e endpoints nomeados permitem fixar staging e produção em versões específicas.

    A pasta examples no repositório GitHub inclui workflows importáveis para muitos desses cenários. Para casos de uso completos, a pasta examples/templates traz automações mais completas mostrando o agente funcionando junto a outros nós do n8n.

    Conclusão

    O AgentCore Harness entrega a camada de infraestrutura que faltava para quem quer rodar agentes de IA em produção a partir do editor visual do n8n. Com memória persistente, isolamento por usuário, ferramentas como interpretador de código, habilidades de domínio e suporte a execução privada em VPC — tudo configurável sem escrever código de infraestrutura — a AWS reduz significativamente a barreira de entrada para agentes robustos.

    O nó está disponível como nó comunitário verificado no n8n. Para começar, adicione o nó Amazon Bedrock AgentCore pelo painel de nós (ou instale @aws/n8n-nodes-agentcore via Settings > Community Nodes), importe um workflow de exemplo e construa seu primeiro agente. O nó é de código aberto sob licença MIT, construído sobre o framework Strands Agents, e contribuições são bem-vindas no repositório GitHub. Para aprofundar no funcionamento da capacidade subjacente, consulte a documentação do AgentCore.

    Fonte

    Run production AI agents in n8n with Amazon Bedrock AgentCore harness (https://aws.amazon.com/blogs/machine-learning/run-production-ai-agents-in-n8n-with-amazon-bedrock-agentcore-harness/)

  • Amazon DynamoDB agora suporta busca vetorial em tempo real

    Busca vetorial nativa chega ao DynamoDB em disponibilidade geral

    A AWS anunciou, em agosto de 2026, a disponibilidade geral da busca vetorial nativa no Amazon DynamoDB. Trata-se de um novo recurso que permite indexar e pesquisar vetores em tempo real, diretamente dentro do banco de dados NoSQL já consolidado no mercado.

    O problema que essa novidade resolve

    À medida que conjuntos de dados vetoriais crescem para bilhões ou até trilhões de entradas, a busca vetorial em escala enfrenta um dilema clássico: ou você aceita maior latência, ou abre mão de precisão e throughput. Até então, escalar buscas vetoriais sem comprometer a qualidade dos resultados era um desafio significativo de infraestrutura.

    Com essa atualização, o DynamoDB passa a oferecer busca vetorial nativa com latência de milissegundos de um único dígito, mantendo 99%+ de recall — e tudo isso projetado para funcionar em qualquer escala, inclusive com trilhões de vetores.

    Como funciona na prática

    A proposta é simples e integrada ao modelo já conhecido do DynamoDB. Os vetores são armazenados junto com os demais atributos do item, e podem ser gerados por qualquer modelo de sua escolha — incluindo os modelos disponíveis no Amazon Bedrock. A partir daí, o fluxo envolve:

    • Criação de um índice vetorial;
    • Execução de buscas por vizinhos mais próximos aproximados (Approximate Nearest Neighbor — ANN);
    • Escolha da chave de partição do índice vetorial para escalar a solução;
    • Filtragem por atributos para refinar os resultados.

    E o modelo serverless segue intacto: sem gerenciamento de infraestrutura, sem janelas de manutenção, sem downtime, e com cobrança apenas pelo que for utilizado.

    Casos de uso habilitados pelo recurso

    O DynamoDB já era utilizado para armazenar memória de agentes de IA. Com a busca vetorial, agora é possível adicionar recuperação semântica sobre essa memória — o que abre caminho para uma série de aplicações práticas:

    • Grounding de agentes de IA com recuperação semântica;
    • Busca por similaridade de produtos em e-commerce;
    • Publicidade personalizada;
    • Geração Aumentada por Recuperação (RAG — Retrieval Augmented Generation);
    • Sistemas de recomendação com desempenho previsível.

    Disponibilidade

    A busca vetorial no DynamoDB já está disponível em todas as regiões comerciais da AWS e também nas regiões AWS GovCloud (EUA), sem necessidade de configuração adicional de infraestrutura.

    Para se aprofundar no tema, a AWS disponibiliza o AWS News Blog, a página do produto Amazon DynamoDB e o Guia do Desenvolvedor do Amazon DynamoDB.

    Fonte

    Amazon DynamoDB now supports real-time vector search (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-dynamodb-vector-search)

  • Como a AWS construiu uma ponte MCP para conectar agentes de IA na nuvem a ferramentas locais

    O problema: agente na nuvem, arquivos no laptop

    Existe um desafio bastante concreto no uso de agentes de IA hospedados na nuvem: e quando as ferramentas que o agente precisa usar estão na máquina local do usuário? Planilhas Excel, repositórios Git, arquivos de configuração — tudo isso vive no computador de quem trabalha, não em um servidor remoto.

    Foi exatamente esse problema que a equipe da AWS se propôs a resolver. Em um post técnico detalhado, a AWS descreve como construiu uma ponte entre um agente hospedado no Amazon Bedrock AgentCore e servidores MCP (Model Context Protocol) rodando localmente na máquina do usuário final.

    O resultado prático? Um assistente de IA para finanças que, segundo a AWS, acumulou mais de 41.000 conversas em um ano desde o lançamento interno — lendo planilhas diretamente do computador do analista, sem expor credenciais ao navegador.

    O que é o MCP e qual é a lacuna que a ponte resolve

    O Model Context Protocol (MCP) é um padrão aberto lançado pela Anthropic em novembro de 2024 para padronizar como modelos de IA se conectam a dados externos e ferramentas. Ele segue uma arquitetura cliente-servidor: o host MCP (uma aplicação de IA, como o Amazon Quick ou o Claude Code) estabelece conexões com um ou mais servidores MCP.

    O protocolo suporta dois mecanismos de transporte: stdio (para comunicação entre processos na mesma máquina) e HTTP com streaming (para comunicação entre cliente remoto e servidor remoto). O que faltava era justamente o cenário inverso: servidor MCP local, cliente MCP remoto. A ponte MCP da AWS resolve exatamente essa lacuna.

    Esse padrão é o mesmo que alimenta produtos como o Claude Cowork — um agente na nuvem chamando ferramentas locais via MCP — mas, neste caso, totalmente auto-hospedado na AWS com modelo e servidores de ferramentas próprios.

    Arquitetura da solução: quatro componentes em conjunto

    A arquitetura descrita pela AWS tem quatro componentes principais que trabalham em conjunto:

    • AgentCore Runtime: hospeda o agente Strands na nuvem. O agente atua como cliente MCP, emitindo requisições de descoberta e invocação de ferramentas.
    • Extensão de navegador: fornece a interface de chat e age como retransmissora bidirecional, encaminhando mensagens MCP entre o AgentCore Runtime (via WebSocket) e a MCP Bridge (via native messaging).
    • MCP Bridge: um proxy FastMCP rodando na máquina local do usuário, iniciado pelo navegador através do registro de host de native messaging. Ele traduz entre o formato de envelope do native messaging e o JSON-RPC bruto do MCP.
    • Servidor MCP: um servidor MCP padrão rodando localmente. Como a bridge está co-localizada, a comunicação usa transporte stdio.

    O fluxo completo funciona assim: o usuário envia uma mensagem pela extensão, que se conecta ao AgentCore Runtime via WebSocket pré-assinado. Quando o agente Strands precisa chamar uma ferramenta, ele envia uma requisição JSON-RPC MCP encapsulada em um envelope JSON de volta pela WebSocket para a extensão. A extensão repassa a mensagem para a bridge via native messaging. A bridge desencapsula o envelope, extrai o conteúdo JSON-RPC e o encaminha para o servidor MCP via stdio. A resposta percorre o caminho inverso.

    A tabela abaixo mostra como uma única chamada de ferramenta percorre os saltos entre o agente e o servidor MCP, com cada salto removendo uma camada de encapsulamento:

    Salto 1 — Agente → Extensão (WebSocket):
    {"type": "mcpbridge", "content": {"type": "mcp", "payload": ""}, "session_id": "session_123"}
    
    Salto 2 — Extensão → Bridge (Native Messaging):
    {"type": "mcp", "payload": ""}
    
    Salto 3 — Bridge → Servidor MCP (stdio):
    {"jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": {"name": "read_sheet", "arguments": {"file_path": "budget.xlsx"}}}

    Como o agente Strands funciona no AgentCore Runtime

    Conexão WebSocket

    A extensão de navegador se conecta ao AgentCore Runtime via uma URL WebSocket pré-assinada. Na inicialização, o painel lateral envia uma requisição de pré-assinatura pelo script de background para a bridge nativa, que usa as credenciais AWS locais do usuário e o SDK do bedrock-agentcore para gerar uma URL wss:// assinada com SigV4, com escopo para o ARN do runtime implantado (válida por 5 minutos). Nenhuma credencial sai da máquina do usuário ou entra no navegador.

    Inicialização MCP e descoberta de ferramentas

    Antes de descobrir ferramentas, o agente realiza o handshake de inicialização MCP padrão: envia uma requisição initialize com a versão do protocolo, aguarda a resposta de capacidades do servidor e envia a notificação notifications/initialized. Somente após esse handshake o servidor aceita requisições tools/list e tools/call.

    A cada mensagem do usuário, o agente chama tools/list e recebe um array de esquemas de ferramentas. Ele encapsula cada esquema em um Strands AgentTool cujo método stream() envia uma requisição tools/call pela bridge. Ferramentas adicionadas ao servidor MCP ficam automaticamente disponíveis na próxima requisição, sem nenhuma alteração no código do agente.

    Correlação de requisição e resposta

    Cada requisição JSON-RPC de saída do agente recebe um ID único e é registrada em um asyncio.Future indexado por (session_id, jsonrpc_id). Quando a resposta chega de volta pela WebSocket, ela é associada ao Future correspondente e resolvida. Isso permite que múltiplas chamadas de ferramentas estejam em andamento simultaneamente sem ambiguidade.

    Como funciona o native messaging

    Para que a extensão se comunique com um processo local de longa duração sem permissões de rede ou prompts por mensagem, a solução usa o native messaging — suportado tanto pelo Chrome quanto pelo Firefox. O navegador procura um arquivo de manifesto em um local conhecido na máquina do usuário que especifica qual binário iniciar.

    O arquivo de manifesto do native messaging para Chrome no macOS tem o seguinte formato:

    # Stored at ~/Library/Application\ Support/Google/Chrome/NativeMessagingHosts/com.example.mcp_bridge.json
    {
      "name": "com.example.mcp_bridge",
      "description": "MCP Bridge - Routes MCP messages to local servers",
      "path": "/path/to/mcp-bridge-demo/bridge/run_bridge.sh",
      "type": "stdio",
      "allowed_origins": [
        "chrome-extension:///"
      ]
    }

    Na inicialização da extensão, o script de background chama chrome.runtime.connectNative("com.example.mcp_bridge") para iniciar o aplicativo nativo localmente. O script run_bridge.sh referenciado no manifesto ativa o ambiente Python e inicia a bridge:

    #!/bin/bash
    cd "/path/to/mcp-bridge-demo/bridge"
    source .venv/bin/activate
    exec python3 bridge.py

    Cada mensagem é serializada como JSON, codificada em UTF-8 e precedida por um comprimento de mensagem de 32 bits em ordem little-endian. O tamanho máximo de uma mensagem do host de native messaging é 1 MB; o tamanho máximo de uma mensagem enviada ao host é 64 MiB.

    Como a MCP Bridge funciona internamente

    A MCP Bridge age como tradutora de protocolo entre dois mundos: o protocolo de native messaging do Chrome de um lado, e o padrão MCP (JSON-RPC 2.0 sobre stdio) do outro.

    No caminho de entrada, ela remove o cabeçalho de 4 bytes do stdin, analisa o corpo JSON e desencapsula o envelope para extrair a mensagem JSON-RPC bruta. No caminho de saída, faz o inverso: encapsula a resposta JSON-RPC em um envelope e a escreve de volta com o cabeçalho de comprimento.

    Internamente, a bridge executa dois loops concorrentes conectados por um proxy FastMCP. O loop principal lê mensagens do navegador, as desencapsula e coloca o conteúdo JSON-RPC em uma fila de entrada. O proxy FastMCP, iniciado uma vez e mantido ativo pelo tempo de vida da bridge, pega mensagens dessa fila, as encaminha para o subprocesso do servidor MCP via stdin e coloca as respostas do stdout do servidor em uma fila de saída. Um segundo loop em background lê da fila de saída, encapsula cada resposta de volta em um envelope e a escreve no stdout para o navegador receber.

    O servidor MCP em si é um processo filho iniciado pela bridge na inicialização, configurado por um arquivo mcp.json. Adicionar um novo servidor MCP é uma mudança de uma linha nesse arquivo:

    # mcp.json
    {
      "mcpServers": {
        "excel": {
          "command": "python3",
          "args": ["excel_server.py"]
        }
      }
    }

    Pré-requisitos e implantação

    Para implantar e testar a solução, são necessários:

    • Conta AWS com acesso ao modelo Bedrock habilitado (o código usa Claude Opus 4.7). Disponibilidade do modelo varia por região — consulte a documentação de disponibilidade de modelos do Amazon Bedrock.
    • Permissões de Gerenciamento de Identidade e Acesso (IAM) para Bedrock AgentCore (bedrock-agentcore:*), AWS CloudFormation, criação de roles IAM e S3.
    • Interface de Linha de Comando da AWS (AWS CLI) configurada com credenciais.
    • Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) inicializado na região alvo.
    • Python 3.10+, Node.js 20+, Google Chrome e Git.

    O processo de implantação consiste em clonar o repositório, instalar dependências Python, criar e implantar o agente no AgentCore via CLI, configurar o arquivo bridge_config.json com o ARN do runtime, carregar a extensão no Chrome e registrar a bridge de native messaging. O código completo está disponível no GitHub.

    git clone https://github.com/aws-samples/sample-mcp-bridge-agentcore.git
    cd mcp-bridge-demo
    chmod +x scripts/setup.sh manifests/install.sh
    ./scripts/setup.sh
    npm install -g @aws/agentcore
    cd agent
    agentcore create --name McpBridgeAgent --defaults
    cd McpBridgeAgent
    cp ../agent.py app/McpBridgeAgent/main.py
    cp ../mcp_bridge_transport.py app/McpBridgeAgent/
    agentcore deploy
    {
      "runtime_arn": "arn:aws:bedrock-agentcore:::runtime/",
      "region": "us-east-1",
      "presign_expires": 300
    }
    ./manifests/install.sh 

    Considerações de segurança

    A AWS destaca que a solução demonstrada prioriza a funcionalidade da bridge MCP e, portanto, inclui apenas medidas básicas de segurança: restrição de origem do native messaging (o Chrome verifica o ID da extensão contra a lista allowed_origins), expiração de URL pré-assinada (URLs WebSocket são assinadas com SigV4 e expiram em 5 minutos) e isolamento de processos.

    A principal superfície de exposição única dessa arquitetura é a própria bridge: ela aceita instruções de um agente hospedado na nuvem e as executa localmente com as permissões do sistema de arquivos do usuário. Para um sistema em produção, além de implementar o Amazon Bedrock Guardrails para filtragem de conteúdo, a AWS recomenda medidas adicionais:

    • Autenticação: exigir um handshake com Token Web JSON (JWT) como primeiro frame WebSocket, verificado via Amazon Cognito ou segredo HMAC no AWS Systems Manager.
    • Assinatura de payload: assinar cada mensagem MCP com Ed25519 (chave privada no agente, chave pública na bridge) para garantir que mensagens não foram modificadas em trânsito.
    • Escopo do sistema de arquivos: configurar uma lista explícita de diretórios que o servidor MCP pode acessar, rejeitando caminhos fora do limite — prevenindo que uma injeção de prompt engane o agente para ler arquivos sensíveis.
    • Registro de auditoria: registrar cada invocação de ferramenta (nome, argumentos, timestamp, status do resultado) em um arquivo local para rastreabilidade.

    O que vem a seguir: extensões da arquitetura

    A AWS aponta que a arquitetura atual pode ser estendida para suportar mais casos de uso:

    • Ações no navegador: a extensão pode implementar suas próprias ferramentas de navegador modeladas nas definições de ferramentas do Playwright MCP e expô-las ao agente para realizar ações como clicar em elementos, preencher formulários, navegar em páginas e tirar screenshots.
    • Automação de ferramentas locais: a bridge fala JSON-RPC MCP padrão sobre stdio, então servidores MCP compatíveis com transporte stdio funcionam sem modificação. Exemplos incluem acesso ao sistema de arquivos para leitura/escrita em sandbox, Git para operações em repositórios e memory para grafos de conhecimento local persistentes. O diretório awesome-mcp-servers lista servidores disponíveis.
    • Empacotamento como binário standalone: para distribuição em produção, a AWS usa o PyInstaller para empacotar a bridge em um binário standalone que inclui o runtime Python, dependências e configuração em um único executável.

    Conclusão

    A solução descrita pela AWS demonstra como é possível manter um agente de IA centralmente implantado e gerenciado enquanto se dá a ele acesso a ferramentas que precisam rodar localmente — planilhas Excel, repositórios Git ou outros servidores MCP locais. O padrão usa uma extensão de navegador como camada de retransmissão e o native messaging do Chrome como transporte local, tunelando mensagens JSON-RPC MCP padrão entre a nuvem e o sistema de arquivos do usuário sem expor credenciais ao navegador ou modificar o próprio protocolo MCP.

    Para explorar a solução, o repositório de exemplo está disponível para implantação e experimentação com servidores MCP próprios. Para aprofundamento, a AWS disponibiliza a documentação do Amazon Bedrock AgentCore, o SDK do Strands Agents e a especificação do Model Context Protocol.

    Fonte

    How we built an MCP bridge to give our AgentCore-hosted AI agent access to local MCP tools (https://aws.amazon.com/blogs/machine-learning/how-we-built-an-mcp-bridge-to-give-our-agentcore-hosted-ai-agent-access-to-local-mcp-tools/)

  • AWS Glue Data Quality torna detecção de anomalias em ETL gratuita e melhora as previsões

    O que mudou no AWS Glue Data Quality

    A AWS anunciou duas novidades relevantes para quem trabalha com qualidade de dados no AWS Glue Data Quality: a detecção de anomalias em jobs de Extração, Transformação e Carga (ETL) passou a ser gratuita, e um novo modo de observação foi introduzido para tornar as detecções mais precisas e com menos ruído.

    Novo modo de observação: menos falsos positivos

    Um dos problemas clássicos em sistemas de detecção de anomalias é o excesso de alertas que não representam problemas reais — os chamados falsos positivos. Para endereçar isso, a AWS introduziu um novo modo de observação de anomalias que utiliza uma linha de base constante no lugar de uma tendência linear para analisar os dados.

    Na prática, isso significa que o serviço para de extrapolar tendências de forma exagerada, entregando alertas mais precisos e reduzindo o ruído. Com isso, as equipes conseguem focar nas anomalias genuínas, sem perder tempo investigando falsos alarmes.

    Quando esse novo modo é mais útil

    A AWS destaca que o novo modo de observação é particularmente indicado para os seguintes cenários:

    • Análises exploratórias de dados (EDA — Exploratory Data Analysis), como as realizadas em notebooks interativos;
    • Datasets com padrões planos ou aleatórios, sem tendências previsíveis;
    • Cargas de trabalho com intervalos irregulares de chegada de dados;
    • Verificações de qualidade executadas em horários variados ou em ambientes interativos.

    Em resumo, qualquer cenário onde os dados não seguem um ritmo previsível se beneficia diretamente dessa melhoria.

    Detecção de anomalias em ETL agora sem custo adicional

    Além da melhoria técnica, a AWS removeu a cobrança pela detecção de anomalias em jobs ETL do Glue. Isso significa que é possível monitorar a qualidade dos dados em todos os pipelines do Glue sem preocupação com custos adicionais por essa funcionalidade específica.

    Para quem já utilizava o serviço com restrições por conta do preço, essa mudança abre espaço para ampliar o monitoramento sem impacto no orçamento.

    Disponibilidade

    As melhorias estão disponíveis em todas as regiões comerciais da AWS e nas regiões AWS GovCloud (US). Para começar a usar, a AWS recomenda consultar a documentação oficial do AWS Glue Data Quality. Para detalhes sobre preços, a página de preços do AWS Glue traz as informações atualizadas.

    Fonte

    AWS Glue Data Quality makes ETL anomaly detection free and improves anomaly predictions (https://aws.amazon.com/about-aws/whats-new/2026/08/aws-glue-data-quality-anomaly-detection-free)

  • Amazon Cognito lança limites provisionados: ajuste de capacidade em minutos, não semanas

    O problema que todo time de identidade já enfrentou

    Imagine que sua empresa está se preparando para o maior evento de vendas do ano — uma Black Friday, uma virada de exercício fiscal, ou o pico de declarações de imposto de renda. Você precisa garantir que o serviço de autenticação vai aguentar o tranco. Aí você descobre que aumentar os limites de taxa do Amazon Cognito exige abrir um ticket de suporte e esperar entre 10 e 14 dias para a aprovação.

    Esse cenário foi realidade por muito tempo para equipes de segurança, arquitetos de identidade e times de engenharia que dependem do Cognito em produção. A necessidade de planejar com semanas de antecedência — ou correr para escalar uma solicitação urgente — criava um gargalo operacional considerável, especialmente para negócios com tráfego sazonal intenso.

    A AWS identificou esse problema e respondeu com uma mudança significativa: a partir de 6 de julho de 2026, o Amazon Cognito passou a oferecer os chamados limites provisionados (provisioned limits), um mecanismo de autoatendimento que permite ajustar a capacidade de autenticação em minutos, diretamente pelo console.

    O que são os limites provisionados

    Os limites provisionados são uma nova camada de controle de capacidade disponível na aba Provisioned limits dentro do console do Amazon Cognito, no nível de conta (por Região AWS, por conta). Com esse recurso, é possível aumentar ou reduzir a capacidade provisionada sob demanda, com efeito imediato.

    O modelo funciona com dois mecanismos complementares:

    • Limite provisionado (console do Amazon Cognito): controla a capacidade que você reserva ativamente. Alterações entram em vigor imediatamente. A cobrança ocorre sobre a capacidade provisionada acima do limite padrão, independentemente do quanto é efetivamente consumido.
    • Limite máximo de conta (console do AWS Service Quotas): define o teto máximo de Requisições por Segundo (RPS) que sua conta pode provisionar. Elevar esse teto não gera cobrança adicional — ele apenas desbloqueia a possibilidade de provisionar mais capacidade.

    Juntos, esses dois controles oferecem precisão tanto na gestão de custos quanto na gestão de capacidade. Você pode subir o teto com antecedência, sem custo, e só ativar a capacidade extra quando realmente precisar.

    Imagem original — fonte: Aws

    Como os três valores funcionam juntos

    Para entender a lógica do modelo, vale usar o exemplo da API UserCreation, que tem limite padrão de 50 RPS. No estado inicial, você tem três valores:

    • Limite padrão: 50 RPS (incluso sem custo adicional)
    • Limite provisionado: 50 RPS (igual ao padrão — capacidade faturada é 0)
    • Limite máximo de conta: 50 RPS (teto atual da conta)

    Se você tentar provisionar 55 RPS diretamente, o console bloqueará a ação, pois o valor excede o teto máximo de 50 RPS. Para avançar, é necessário primeiro solicitar um aumento do limite máximo de conta via Service Quotas. Aproximadamente 90% dessas solicitações são aprovadas automaticamente em minutos. Para aumentos maiores, dependendo da categoria de API e da Região, pode ser necessária revisão manual pelo suporte da AWS.

    Após a aprovação do novo teto (digamos, 55 RPS), você retorna ao console do Cognito e ajusta o limite provisionado para 55 RPS. A partir daí, a capacidade faturada passa a ser de 5 RPS (55 menos os 50 do padrão). Quando o evento de pico termina, basta reduzir o limite provisionado de volta ao padrão — a cobrança extra cessa imediatamente.

    Um detalhe importante sobre o modelo de cobrança: você é cobrado pela capacidade que provisiona acima do padrão, e não pelo que efetivamente usa. Se você provisionar 80 RPS (com padrão de 50), será cobrado por 30 RPS mesmo que o uso real seja de apenas 60 RPS. Isso reforça a importância de dimensionar a capacidade com precisão, alinhada à demanda esperada.

    Categorias ajustáveis e não ajustáveis

    Nem todas as categorias de API do Cognito podem ter seus limites ajustados. A aba de limites provisionados exibe cada categoria com seu status de ajustabilidade. Por exemplo, UserCreation é marcada como Adjustable (ajustável) e pode ser modificada. Já UserList aparece como Not adjustable (não ajustável) — você consegue visualizar os valores de limite padrão e provisionado, mas não pode alterá-los.

    Para as categorias ajustáveis, a visão consolidada mostra o limite padrão, o limite provisionado atual e a capacidade faturada de forma direta, facilitando o acompanhamento e a tomada de decisão.

    Casos de uso práticos

    A flexibilidade do novo modelo atende a cenários bem variados. Serviços de declaração de imposto de renda, por exemplo, concentram cerca de 90% do volume anual de autenticação em poucos meses. Plataformas de e-commerce enfrentam picos intensos em datas comemorativas. Antes, essas equipes precisavam solicitar aumentos de capacidade semanas antes do evento e torcer para que a aprovação chegasse a tempo.

    Agora, o fluxo muda completamente: eleve o teto máximo de conta com antecedência (sem custo), e quando o pico se aproximar, aumente o limite provisionado para o valor necessário. Após o evento, reduza a capacidade e pare de ser cobrado pela capacidade extra. Tudo isso sem abrir um único ticket de suporte.

    O mesmo vale para testes de carga planejados ou para crescimento viral inesperado — qualquer ajuste é feito em autoatendimento, em minutos.

    Considerações para SaaS multi-tenant

    Para provedores de Software como Serviço (SaaS) que gerenciam múltiplos tenants com requisitos de throughput diferentes, a AWS disponibilizou também a API UpdateProvisionedLimit, que permite o gerenciamento programático dos limites provisionados.

    Equipes que utilizam user pools dedicados por tenant, por exemplo, podem integrar essa API em seus pipelines de infraestrutura como código para ajustar os limites por tier de serviço. Isso abre a possibilidade de provisionar maior capacidade para tenants enterprise e menor capacidade para tenants em plano gratuito, com ajustes independentes por tenant conforme a demanda de cada um.

    Como começar

    O recurso de limites provisionados para user pools do Amazon Cognito está disponível desde 6 de julho de 2026, em todas as Regiões AWS onde o Cognito é suportado. Para colocar em prática, a AWS recomenda o seguinte fluxo:

    • Revise os padrões atuais de tráfego de autenticação usando métricas do Amazon CloudWatch para entender sua linha de base
    • Configure alarmes no CloudWatch em 70% e 85% dos seus limites de taxa atuais
    • Verifique se sua equipe tem as permissões adequadas de Gerenciamento de Identidade e Acesso da AWS (IAM) tanto para o Service Quotas quanto para a aba de limites provisionados no console do Cognito
    • Eleve o limite máximo de conta no Service Quotas com base nas suas expectativas de demanda
    • Use a aba Provisioned limits no console do Amazon Cognito para ajustar a capacidade conforme necessário

    Recursos adicionais

    Fonte

    From 2 weeks to 2 minutes: Amazon Cognito launches Provisioned limits for self-service rate limit management (https://aws.amazon.com/blogs/security/from-2-weeks-to-2-minutes-amazon-cognito-launches-provisioned-limits-for-self-service-rate-limit-management/)

  • Pacotes de conformidade PCI DSS e PCI 3DS da AWS para a Primavera de 2026 já estão disponíveis

    AWS renova certificações PCI e expande escopo de serviços e regiões

    A Amazon Web Services (AWS) anunciou a conclusão bem-sucedida da renovação de suas certificações de Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI DSS) e de Segurança em Três Domínios (PCI 3DS). Além da renovação em si, a AWS ampliou o escopo desta certificação, incluindo três novos serviços e uma nova região.

    O que foi adicionado ao escopo

    Novos serviços certificados

    Nova região incluída

    • Ásia-Pacífico – Nova Zelândia

    Com essa expansão, clientes que utilizam esses serviços podem continuar operando dentro dos requisitos de conformidade PCI DSS e PCI 3DS, sem precisar abrir mão de inovação por conta de restrições regulatórias. A lista completa de serviços cobertos pode ser consultada na página de serviços no escopo por programa de conformidade da AWS.

    O que compõe os pacotes de conformidade

    Os pacotes de conformidade PCI DSS e PCI 3DS disponibilizados pela AWS incluem dois componentes principais para cada certificação:

    • Atestado de Conformidade (AOC) – documento que comprova que a AWS foi validada com sucesso em relação aos padrões PCI DSS e PCI 3DS.
    • Resumo de Responsabilidades da AWS – material que orienta os clientes a entenderem suas próprias responsabilidades ao desenvolver e operar ambientes seguros na AWS para o tratamento de dados de cartões de pagamento.

    A avaliação foi conduzida pela Coalfire, empresa terceirizada credenciada como Avaliadora de Segurança Qualificada (QSA).

    Como acessar os relatórios

    Os pacotes de relatórios PCI DSS e PCI 3DS estão disponíveis pelo AWS Artifact, portal de autoatendimento da AWS que oferece acesso sob demanda a relatórios de conformidade, facilitando processos de auditoria.

    Para saber mais sobre os programas PCI e outras iniciativas de conformidade e segurança da AWS, acesse a página de Programas de Conformidade da AWS. Em caso de dúvidas relacionadas à conformidade, a AWS disponibiliza o canal de suporte de conformidade.

    Fonte

    Spring 2026 PCI DSS and PCI 3DS compliance packages for AWS now available (https://aws.amazon.com/blogs/security/spring-2026-pci-dss-and-pci-3ds-compliance-packages-for-aws-now-available/)

  • Amazon EMR no EC2 agora suporta sessões interativas com Spark Connect

    O que foi anunciado

    A AWS anunciou que o Amazon EMR on EC2 passa a suportar sessões interativas do Apache Spark por meio do Spark Connect. A novidade é voltada para engenheiros de dados e cientistas de dados que precisam de um ciclo de desenvolvimento mais ágil — permitindo criar, testar e depurar aplicações Spark de forma interativa, sem precisar submeter jobs completos a cada iteração.

    Como funciona na prática

    Com o Spark Connect, cada sessão interativa roda em um cluster dedicado do EMR on EC2. O desenvolvimento pode acontecer a partir de notebooks gerenciados no Amazon SageMaker Unified Studio ou diretamente em IDEs de preferência do time, como Jupyter e Visual Studio Code.

    Um ponto importante da arquitetura do Spark Connect é a separação entre o cliente da aplicação e o driver do Spark — o que tecnicamente é chamado de arquitetura cliente-servidor. Isso significa que o ambiente de desenvolvimento local fica desacoplado da infraestrutura Spark que roda no cluster. Na prática, o desenvolvedor mantém suas ferramentas e fluxo de trabalho habituais enquanto o processamento pesado acontece remotamente.

    Sessão persistente e execução híbrida

    Cada sessão interativa oferece um contexto Spark persistente que se mantém ativo entre células e scripts. Isso permite combinar execução local de código Python com operações remotas no Spark — algo especialmente útil em fluxos de trabalho como:

    • Exploração ad hoc de dados
    • Depuração iterativa passo a passo
    • Desenvolvimento incremental de jobs PySpark antes de subir para produção

    Observabilidade e monitoramento

    Para acompanhar o que está acontecendo nas sessões, a AWS disponibiliza monitoramento em tempo real via Spark UI, histórico de execuções pelo Spark History Server e gerenciamento de sessões diretamente pelo console do EMR ou via API, CLI e SDK. Sessões ativas e já concluídas podem ser inspecionadas pelo console.

    Disponibilidade

    O recurso de Sessões Interativas está disponível no Amazon EMR on EC2 com o runtime AWS para Apache Spark (emr-spark-8.0) ou versões posteriores. A funcionalidade está presente em todas as regiões AWS onde o Amazon EMR está disponível, com exceção das regiões AWS GovCloud e das regiões da China. A experiência pelo Amazon SageMaker Unified Studio está disponível nas regiões suportadas.

    Para começar a usar, a AWS disponibiliza o guia de sessões interativas com Spark Connect e o guia de introdução ao Amazon SageMaker Unified Studio.

    Fonte

    Run interactive workloads on Amazon EMR on EC2 with Spark Connect (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-emr-ec2-spark-connect/)

  • Web Search no Amazon Bedrock: busca na web como capacidade nativa para aterramento de modelos de fundação

    O problema que o Web Search resolve

    Modelos de fundação são treinados com um recorte de dados que tem data de corte definida. Quando alguém pergunta sobre o resultado de uma reunião de resultados da semana passada, uma mudança regulatória de ontem ou a previsão do tempo desta manhã, o modelo simplesmente não tem essa informação — ela não existia quando ele foi treinado.

    A técnica de resolver isso se chama grounding (aterramento): conectar o modelo a fontes de conhecimento externas e atuais para que ele possa responder com base em dados reais, não apenas em inferências sobre o que aprendeu. Isso reduz alucinações e aumenta a confiabilidade das respostas em aplicações como chatbots, assistentes de código, ferramentas de linha de comando e sistemas empresariais.

    Até agora, implementar esse aterramento web exigia que os times de desenvolvimento identificassem, integrassem e mantivessem um provedor externo de busca — um processo que atrasa projetos, introduz riscos de residência de dados e gera sobrecarga operacional. A AWS decidiu resolver isso de forma nativa.

    O que é o Web Search no Amazon Bedrock

    No AWS New York Summit 2026, a AWS anunciou a disponibilidade geral do Web Search no AgentCore. Agora, a empresa estende esse recurso com a disponibilidade geral do Web Search no Amazon Bedrock — uma ferramenta nativa do lado do servidor que aterra as respostas dos modelos em conhecimento web atualizado.

    Com isso, o aterramento web passa a ser uma capacidade nativa do Bedrock: sem fornecedores terceiros para contratar, sem APIs externas para orquestrar e sem revisões de segurança adicionais de parceiros externos.

    Diferenciais técnicos do recurso

    Abordagem de aterramento multi-fonte

    O Web Search é respaldado por um índice web que a própria Amazon opera, cobrindo bilhões de documentos e atualizado continuamente. Além disso, ele combina esse índice com um grafo de conhecimento embutido que ancora entidades de um domínio e as conexões entre elas.

    Quando a pergunta é factual — quem escreveu determinado livro, em que ano ocorreu determinado evento — o Web Search usa o grafo de conhecimento para responder com alta confiança, em vez de deixar o modelo inferir a resposta a partir de fragmentos de páginas. Isso reduz as pequenas imprecisões factuais que costumam aparecer quando um agente monta uma resposta por conta própria.

    Recuperação eficiente de contexto

    Em vez de entregar uma página bruta ao modelo e esperar que ele encontre a parte relevante, o Web Search realiza extração semântica de trechos: ele seleciona as passagens de cada página que são pertinentes à consulta e as entrega em um formato otimizado para a janela de contexto do modelo. O modelo recebe apenas o que importa, com menos tokens desperdiçados em conteúdo genérico. A recuperação é rápida, o que permite respostas aterradas com latência mínima.

    Habilitação com parâmetro único

    O Web Search é ativado com um único parâmetro na chamada de API compatível com OpenAI que o desenvolvedor já utiliza. Não há necessidade de onboarding de fornecedor, chaves de API adicionais, camadas de orquestração ou SDKs separados.

    Conformidade corporativa por padrão

    Por padrão, o Web Search no Bedrock opera com zero saída de dados: os dados nunca saem do ambiente AWS. O recurso funciona inteiramente dentro da infraestrutura do Amazon Bedrock, o que facilita o atendimento a requisitos de conformidade corporativa. Futuras capacidades que eventualmente exponham dados fora desse perímetro serão habilitadas apenas mediante solicitação explícita.

    Como o Web Search funciona internamente

    Quando o Web Search está habilitado em uma chamada de API, o Bedrock gerencia todo o ciclo de busca no lado do servidor. O fluxo é o seguinte:

    • O modelo identifica que a consulta requer conhecimento web atualizado.
    • O Bedrock formula uma query de busca.
    • O sistema recupera conteúdo relevante do índice web e do grafo de conhecimento da Amazon.
    • Os resultados — incluindo trechos relevantes, URLs e títulos das fontes — são injetados na janela de contexto do modelo.
    • O modelo raciocina sobre o conteúdo recuperado e gera uma resposta aterrada com citações das fontes.

    A API retorna a resposta final com anotações de citação estruturadas, incluindo URL e título da página para cada fonte referenciada. Não há loop de uso de ferramentas no lado do cliente para construir, nenhuma resposta de API externa para parsear e nenhum retry ou limite de taxa para gerenciar — uma única chamada de API retorna uma resposta aterrada.

    Como começar: usando a Responses API compatível com OpenAI

    A Responses API suporta ferramentas nativas, então o Web Search pode ser chamado sem definir um schema de função ou construir um loop no lado do cliente. A habilitação ocorre em três etapas: configurar credenciais AWS, apontar o cliente OpenAI para o endpoint bedrock-mantle e adicionar a ferramenta Web Search à requisição. No lançamento, o Web Search está disponível para modelos OpenAI servidos pelo motor de inferência de próxima geração do Amazon Bedrock.

    Passo 1: Configurar autenticação e permissões

    O Web Search utiliza as credenciais AWS existentes — não há chaves de API separadas para provisionar. O ambiente precisa ter credenciais AWS disponíveis pela cadeia de credenciais padrão (uma função do Serviço de Gerenciamento de Identidade e Acesso — IAM, o perfil da AWS CLI, ou variáveis de ambiente), que são usadas para autenticar requisições ao endpoint bedrock-mantle.

    A identidade que faz a chamada precisa de dois conjuntos de permissões:

    • Permissões de inferência no Amazon Bedrock: anexe a política gerenciada AmazonBedrockMantleInferenceAccess ou conceda as ações de inferência específicas que sua chamada requer.
    • Permissões da ferramenta Web Search: conceda no mínimo bedrock-websearch:InvokeSearch; adicione bedrock-websearch:InvokeFetch para permitir que o modelo leia o conteúdo completo de uma página de resultado. A recuperação de conteúdo web ao vivo requer adicionalmente bedrock-websearch:ExternalWebAccess, que é o comportamento padrão da requisição — se sua identidade não tiver essa permissão, defina external_web_access: false na ferramenta. Se InvokeSearch for negado, o Web Search é efetivamente desabilitado e o modelo responde a partir de seus dados de treinamento.

    As requisições ao endpoint são autenticadas com um token bearer emitido pela AWS, que pode ser gerado a partir das credenciais AWS existentes usando o pacote aws-bedrock-token-generator. Esse token bearer não é uma chave de API separada — é uma credencial de curta duração (até 12 horas) derivada da identidade IAM existente via SigV4, empacotada no formato que o cliente OpenAI espera para o parâmetro api_key. Nenhum gerenciamento adicional de chaves é necessário.

    Uma chamada normal da Responses API, sem aterramento, tem a seguinte estrutura:

    response = client.responses.create(
        model="openai.gpt-5.4",
        input="What were the key announcements at AWS re:Invent 2025?",
    )

    Passo 2: Habilitar o Web Search

    Para aterrar essa mesma chamada em conhecimento web, basta adicionar uma única entrada em tools:

    tools=[{"type": "web_search", "external_web_access": False}]

    O campo opcional external_web_access seleciona de onde o Web Search recupera conteúdo: do corpus web pré-indexado da Amazon, ou de conteúdo ao vivo buscado diretamente da web. Atualmente, apenas a recuperação por índice está disponível; a recuperação ao vivo será habilitada em uma atualização futura, e o parâmetro já está na API para que o código não precise ser alterado. O padrão é true, o que requer a permissão bedrock-websearch:ExternalWebAccess. Os exemplos abaixo definem false, o que não requer permissão adicional.

    Passo 3: Ler a resposta aterrada com citações

    O exemplo completo de ponta a ponta, incluindo como extrair as citações de fontes:

    from openai import OpenAI
    from aws_bedrock_token_generator import provide_token
    
    REGION = "us-east-1"
    
    client = OpenAI(
        base_url=f"https://bedrock-mantle.{REGION}.api.aws/openai/v1",
        api_key=provide_token(region=REGION),
    )
    
    response = client.responses.create(
        model="openai.gpt-5.4",
        input="What were the key announcements at AWS re:Invent 2025?",
        tools=[{"type": "web_search", "external_web_access": False}],
    )
    
    searches = [item for item in response.output if item.type == "web_search_call"]
    print(f"Retrieval steps: {len(searches)}")
    for call in searches:
        if call.action.type == "search":
            print(f"  search: {call.action.queries}")
        elif call.action.type == "open_page":
            print(f"  open_page: {call.action.url}")
    
    for item in response.output:
        if item.type == "message":
            for content in item.content:
                if content.type == "output_text":
                    print(content.text)
                    for citation in content.annotations or []:
                        if citation.type == "url_citation":
                            print(f"  [{citation.title}] {citation.url}")

    O código acima produz uma saída (resumida) como esta:

    Retrieval steps: 2
      search: ['AWS re:Invent 2025 key announcements official AWS blog keynote recap']
      open_page: https://aws.amazon.com/blogs/aws/top-announcements-of-aws-reinvent-2025
    
    The biggest AWS re:Invent 2025 announcements clustered around **AI agents, custom silicon/infrastructure, and developer productivity**.
    ...
    [Top announcements of AWS re:Invent 2025 | AWS News Blog] https://aws.amazon.com/...
    [AWS re:Invent 2025: Amazon announces Nova 2, Trainium3, frontier agents] https://...

    Nesse exemplo, a requisição inclui uma entrada de Web Search no array tools. O Bedrock executa a busca no lado do servidor e retorna a resposta aterrada em uma única ida e volta — não há schema de função para definir e nenhum loop no lado do cliente para gerenciar.

    Cada citação é um objeto url_citation no array de anotações do conteúdo da mensagem. Sua estrutura:

    {
      "type": "url_citation",
      "start_index": 120,
      "end_index": 303,
      "title": "Top announcements of AWS re:Invent 2025 | AWS News Blog",
      "url": "https://aws.amazon.com/blogs/aws/top-announcements-of-aws-reinvent-2025"
    }

    start_index e end_index são deslocamentos de caracteres no output_text, permitindo renderizar notas de rodapé inline ou destacar exatamente o trecho que cada citação suporta.

    Auditoria e observabilidade

    O Web Search é integrado nativamente ao AWS CloudTrail. Cada chamada a bedrock-websearch:InvokeSearch e bedrock-websearch:InvokeFetch é registrada como um evento de gerenciamento, capturando a identidade que fez a chamada, o timestamp, a ação, a identidade de origem e o contexto de conta e região da requisição.

    Resultados de acesso negado são sempre registrados, e cada evento AccessDeniedException inclui a chave de condição específica que causou a negação — o que torna fácil diagnosticar configurações incorretas de IAM sem precisar ativar trilhas adicionais.

    Por design, o CloudTrail não registra o texto da query, as URLs retornadas pela busca ou o conteúdo bruto da página recuperado pelo fetch. O texto da query é tratado da mesma forma que um prompt de inferência e nunca é exposto nos eventos da trilha. Combinado com o processamento em região e zero saída de dados, isso oferece às equipes de segurança e conformidade uma trilha de auditoria completa de quem usou a ferramenta e quando, sem expor o que os usuários finais pesquisaram.

    Disponibilidade e próximos passos

    O Web Search no Bedrock está geralmente disponível nos Estados Unidos, com processamento de queries em região nas regiões us-east-1, us-east-2 e us-west-2. Para detalhes de preços, consulte a página de preços do Amazon Bedrock. Para começar, acesse a documentação do Web Search com referências completas de API e exemplos.

    Conclusão

    O Web Search no Amazon Bedrock remove a complexidade operacional de conectar modelos de fundação ao conhecimento web atualizado. A AWS entrega resultados aterrados multi-fonte com eficiência de contexto, baixa latência e habilitação simples por um único parâmetro de API — para que desenvolvedores possam adicionar aterramento web sem gerenciar fornecedores, camadas de orquestração ou revisões de conformidade adicionais. Para equipes que constroem aplicações com IA generativa na AWS, esse é um passo relevante para tornar respostas mais confiáveis e atualizadas com muito menos esforço de integração.

    Fonte

    Introducing Web Search on Amazon Bedrock for foundation model grounding (https://aws.amazon.com/blogs/machine-learning/introducing-web-search-on-amazon-bedrock-for-foundation-model-grounding/)