Author: Make.com Service User

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/)

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/)

O problema de monitorar a web manualmente

Acompanhar dezenas de sites ao mesmo tempo é um trabalho que rapidamente se torna inviável quando feito de forma manual. Times de design precisam rastrear produtos de concorrentes, equipes de marketing querem monitorar tendências de conteúdo, e gerentes de produto precisam estar por dentro da inteligência de mercado. Mas fazer isso na mão significa visitar sites, copiar conteúdo e organizar informações antes mesmo de começar qualquer análise real.

Scrapers baseados em regras oferecem alguma automação, mas são fortemente acoplados à estrutura das páginas. Uma redesign do site ou uma migração para um frontend renderizado via JavaScript pode quebrar silenciosamente o pipeline por dias antes que alguém perceba.

Para resolver esse cenário, a AWS publicou uma solução de extração automatizada de insights utilizando o Amazon Bedrock AgentCore — uma plataforma para construir, conectar e otimizar agentes em escala, com qualquer framework ou modelo. O componente central da solução é o AgentCore Browser, um serviço de navegador totalmente gerenciado que renderiza páginas com muito JavaScript de forma confiável, tornando o pipeline mais resiliente às mudanças nos sites.

O que a solução entrega

A arquitetura combina quatro serviços principais: o Amazon Bedrock AgentCore Browser para automação do navegador, o Amazon Bedrock para análise com IA, o Amazon OpenSearch Serverless para busca semântica e o AWS Lambda para orquestração. O resultado é um sistema que monitora feeds RSS, recupera conteúdo da web usando o navegador gerenciado, extrai insights com IA e disponibiliza tudo em uma interface de busca.

Os casos de uso cobertos pela solução incluem:

• Inteligência competitiva: rastreamento de blogs de concorrentes, anúncios de produtos e comunicados à imprensa, com identificação de novos recursos, mudanças de preço ou movimentos estratégicos.
• Pesquisa de mercado: monitoramento de notícias do setor, relatórios de analistas e publicações especializadas para identificar tendências emergentes.
• Curadoria de conteúdo: agregação de conteúdo de múltiplas fontes com a IA identificando as peças mais relevantes para o público.
• Monitoramento de conformidade: acompanhamento de sites regulatórios e fontes de notícias para mudanças que possam afetar o negócio.

A implementação completa está disponível neste repositório no GitHub.

Como a arquitetura funciona

A arquitetura segue um padrão orientado a eventos que separa a coleta de conteúdo do processamento. O sistema é organizado em três camadas funcionais.

Coleta via feeds RSS

Um agendamento no Amazon EventBridge dispara uma função AWS Lambda a cada 15 minutos para verificar os feeds RSS configurados em busca de novos artigos, realizando deduplicação com base no Amazon Simple Storage Service (Amazon S3).

Recuperação de conteúdo via navegador gerenciado

Para cada novo artigo, a função Lambda abre uma sessão de navegador pelo Amazon Bedrock AgentCore e se conecta a ela usando o Playwright sobre o Protocolo Chrome DevTools (CDP). Diferente de requisições HTTP comuns, o navegador remoto renderiza a página completa — incluindo conteúdo JavaScript pesado —, aguarda o carregamento de elementos dinâmicos, tira um screenshot e faz o download de imagens. Esse é o passo que torna o restante do pipeline possível: sem renderização confiável de páginas, a extração por IA receberia conteúdo incompleto ou quebrado. Os artefatos são enviados ao Amazon S3 em um formato estruturado.

Vale destacar que esse não é um navegador headless rodando dentro do Lambda. É um serviço de navegador gerenciado: o AgentCore hospeda o navegador remoto, e o Playwright o controla por meio de uma conexão WebSocket.

Os arquivos são armazenados com a seguinte estrutura no S3:

s3://bucket/
└── example.com/
    └── abc123def456/  # hash da URL
        ├── article.html    # HTML completo
        ├── screenshot.png  # screenshot da página
        ├── metadata.json   # metadados do artigo
        └── images/         # imagens capturadas
            ├── image1.jpg
            └── image2.jpg

O arquivo metadata.json inclui a URL original, título, timestamp e referências para os assets baixados. Quando esse arquivo é enviado ao Amazon S3, ele dispara automaticamente o pipeline de processamento.

Processamento orientado a eventos

Eventos de upload no Amazon S3 publicam mensagens em uma fila do Amazon Simple Queue Service (Amazon SQS), e uma segunda função Lambda extrai o texto limpo do HTML bruto.

Extração de insights com IA

O Amazon Bedrock gera resumos, identifica temas e entidades, extrai insights acionáveis e cria embeddings vetoriais a partir do conteúdo limpo. Antes de enviar o conteúdo ao Bedrock, a função Lambda executa um pré-processamento do HTML para reduzir o consumo de tokens — um passo que melhora significativamente a consistência da saída gerada pela IA. Arquivos HTML grandes (acima de 1 MB) são simplificados com a biblioteca html-to-text para evitar limites de tokens. Arquivos menores usam a biblioteca Readability da Mozilla, que faz um trabalho melhor de extrair o conteúdo principal e identificar a imagem primária.

O prompt enviado ao Amazon Bedrock solicita a extração de:

• Um resumo conciso
• Temas e tópicos principais
• Entidades principais (pessoas, empresas, produtos)
• Categorias relevantes
• Insights acionáveis

Para verificar a disponibilidade de modelos por região da AWS, consulte a documentação de modelos suportados por região no Amazon Bedrock.

Indexação e busca semântica

Os resultados enriquecidos são indexados no Amazon OpenSearch Serverless, que suporta tanto busca por palavras-chave quanto busca vetorial. Uma consulta como “quais são as tendências emergentes de design” retorna resultados relevantes mesmo que essas palavras exatas não apareçam no conteúdo-fonte — é o embedding vetorial que torna a interface de busca genuinamente útil para inteligência competitiva ou pesquisa de mercado.

Acesso via interface web e API

Os usuários finais se autenticam pelo Amazon Cognito e acessam um frontend em React hospedado no Amazon Elastic Container Service (Amazon ECS) com AWS Fargate. Para acesso programático, um servidor MCP (Protocolo de Contexto de Modelo) no Amazon ECS com Fargate expõe o sistema via Amazon CloudFront. O MCP é um padrão aberto que permite que assistentes de IA e ferramentas se conectem a fontes de dados externas por meio de uma interface unificada.

Controles de IA responsável

Como o pipeline envia conteúdo de terceiros a um modelo de fundação e publica a saída gerada pela IA para a equipe, implantações em produção devem incluir salvaguardas. O Amazon Bedrock Guardrails permite aplicar esses controles sem alterar o prompt de extração:

• Filtragem de conteúdo: bloqueia material prejudicial ou inapropriado que possa aparecer em páginas web antes de chegar ao índice pesquisável.
• Tópicos negados e filtros de palavras: mantêm os insights extraídos dentro do escopo esperado pelos times, o que importa quando os feeds de origem estão fora do controle da organização.
• Verificações de fundamentação contextual: validam que os resumos e insights gerados estão fundamentados no artigo-fonte, reduzindo o risco de afirmações alucinadas serem indexadas como fatos.

Como o pipeline ingere conteúdo de sites externos, o texto coletado deve ser tratado como entrada não confiável — os guardrails atuam como ponto de controle entre o conteúdo bruto da web e os insights que a organização consome.

Lições aprendidas na construção do pipeline

A AWS compartilhou algumas decisões arquiteturais que tiveram impacto desproporcional em custo, confiabilidade e qualidade de saída:

• Sessões do AgentCore Browser são poderosas, mas custosas. Cada renderização via Playwright pelo Amazon Bedrock AgentCore leva de 10 a 30 segundos e custa significativamente mais do que uma requisição HTTP simples. O uso de hash de URL para deduplicação — verificando o Amazon S3 antes de acionar uma nova sessão do AgentCore — é essencial para manter os custos gerenciáveis em escala.
• HTML bruto é uma entrada ruim para LLMs. Limpar o HTML antes de enviá-lo ao Amazon Bedrock reduz o consumo de tokens e melhora a consistência da saída. Esse pré-processamento não é uma otimização — é um pré-requisito para resultados confiáveis.
• A busca semântica amplia o que você consegue encontrar. Uma busca por palavras-chave retorna correspondências exatas, enquanto a busca vetorial traz conteúdo conceitualmente relacionado independentemente da terminologia usada.
• O desacoplamento via SQS é o que torna o pipeline confiável. Sem ele, uma falha de processamento significa que o artigo nunca é analisado. Uma fila de mensagens mortas (DLQ) entre o Amazon S3 e a Lambda de extração fornece retentativas automáticas — uma pequena mudança arquitetural com impacto significativo na confiabilidade.
• O Amazon OpenSearch Serverless tem um custo mínimo real. O serviço exige unidades de capacidade mínimas independentemente do uso, o que é adequado para cargas de trabalho de produção com volume consistente de consultas. Para implantações de menor volume, o Amazon Relational Database Service (Amazon RDS) com pgvector suporta as mesmas capacidades de busca vetorial com um custo base menor. Consulte os detalhes de preços do Amazon OpenSearch Serverless.

Conclusão

A solução apresentada pela AWS transforma o monitoramento manual da web em uma base de conhecimento pesquisável e enriquecida com IA. A arquitetura orientada a eventos desacopla a coleta de conteúdo do processamento, o Amazon Bedrock AgentCore lida com sites com JavaScript pesado, e o Amazon OpenSearch Serverless com embeddings vetoriais potencializa a busca semântica além da correspondência por palavras-chave.

O código-fonte completo, o guia de implantação e as instruções de configuração estão disponíveis no repositório no GitHub. Para quem quiser se aprofundar nos serviços envolvidos, a AWS também disponibiliza a documentação do Amazon Bedrock AgentCore Browser e o guia do desenvolvedor do Amazon OpenSearch Serverless.

Fonte

Automated web insight extraction with Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/automated-web-insight-extraction-with-amazon-bedrock-agentcore/)

Busca na web direto no Amazon Bedrock, sem intermediários

A AWS anunciou a disponibilidade geral do Web Search no Amazon Bedrock — uma ferramenta nativa do lado do servidor que realiza buscas na web inteiramente dentro do ambiente AWS. O recurso permite que modelos OpenAI (GPT-5.4, GPT-5.5 e GPT-5.6 Sol/Terra/Luna) fundamentem suas respostas com informações atuais da web, sem que nenhum dado saia do ambiente seguro da AWS.

O problema que o Web Search resolve

Até então, quem precisava que um modelo de linguagem respondesse com base em informações recentes da internet tinha um caminho trabalhoso pela frente: contratar um provedor de busca terceiro, gerenciar chaves de API e cobranças separadas, construir uma orquestração personalizada e passar por revisões de conformidade adicionais para cada fornecedor externo envolvido.

O Web Search elimina toda essa complexidade. Basta adicionar um único parâmetro à chamada de API já existente — sem onboarding de fornecedor, sem APIs externas para orquestrar e sem revisões de segurança adicionais.

Como o Web Search funciona por dentro

O recurso foi desenvolvido pela própria Amazon, com base em anos de experiência acumulada em produtos como Alexa+, Amazon Quick e Kiro. Ele combina dois componentes principais:

• Índice web próprio da Amazon: abrange dezenas de bilhões de documentos, atualizado continuamente.
• Grafo de conhecimento integrado: fornece fatos verificados, indo além da simples recuperação de páginas brutas.

Em vez de devolver páginas cruas ao modelo, o Web Search realiza extração semântica de trechos relevantes — entregando resultados otimizados para a janela de contexto do modelo, com baixa latência.

Integração simples via API padrão

O Web Search se integra por meio de uma interface padronizada de uso de ferramentas, compatível com a API de Respostas da OpenAI (OpenAI Responses API). O fluxo é direto: adiciona-se a ferramenta de busca na chamada de API e o Bedrock cuida de todo o ciclo de busca no lado do servidor. Uma única chamada retorna uma resposta fundamentada, já com as citações incluídas.

Disponibilidade e próximos passos

O Web Search no Amazon Bedrock já está disponível nas regiões US East (N. Virginia), US East (Ohio) e US West (Oregon).

Para se aprofundar no tema, a AWS disponibiliza os seguintes recursos:

• Post introdutório sobre o Web Search no Amazon Bedrock para fundamentação de modelos — com detalhes técnicos e casos de uso.
• Seção de Web Search no Guia do Usuário do Amazon Bedrock — para documentação técnica completa.
• Página de preços do Amazon Bedrock — para entender os custos envolvidos.

Fonte

Amazon Bedrock launches Web Search for OpenAI GPT models (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-bedrock-web/)

O que foi anunciado

A AWS anunciou que os modelos OpenAI GPT-5.6 Sol, Terra e Luna passam a suportar janelas de contexto de 1 milhão de tokens no Amazon Bedrock. Isso significa que é possível processar bases de código completas, documentos extensos e históricos de conversas em agentes com múltiplas etapas — tudo em uma única requisição, sem precisar fragmentar o conteúdo.

Com uma janela de contexto tão ampla, os modelos conseguem raciocinar sobre um volume muito maior de informações de uma vez, retornando respostas mais precisas e coerentes. A principal vantagem prática é eliminar a necessidade de técnicas de chunking (divisão do conteúdo em pedaços menores) e reduzir a perda de informações que costuma ocorrer quando o contexto é truncado.

Casos de uso habilitados

A AWS destaca três cenários principais que se beneficiam diretamente dessa capacidade expandida:

• Revisão e migração de código: é possível analisar repositórios inteiros em uma única passagem, sem precisar dividir o projeto em partes menores.
• Documentos jurídicos e regulatórios: contratos longos, normas e regulamentações podem ser processados do início ao fim sem interrupções.
• Fluxos de trabalho agênticos com múltiplas etapas: o histórico completo de uma conversa ou de uma sequência de ações pode ser mantido durante toda a execução do agente.

Prompt caching e desconto de cobrança

Um detalhe importante para quem vai usar esses modelos em produção: o prompt caching com pontos de cache explícitos já se aplica às requisições de contexto longo. Na prática, contextos repetidos são cobrados com desconto de cache, o que pode representar uma economia relevante em aplicações que reutilizam grandes blocos de contexto com frequência.

Disponibilidade por região

A disponibilidade dos modelos varia conforme a região AWS:

• GPT-5.6 Sol: disponível em US East (N. Virginia) e US East (Ohio).
• GPT-5.6 Terra e Luna: disponíveis em US East (N. Virginia), US East (Ohio) e US West (Oregon).

Como começar a usar

Para experimentar os modelos Sol, Terra e Luna com suporte a 1 milhão de tokens, a AWS indica dois caminhos: pelo Console do Amazon Bedrock ou pela Responses API no endpoint bedrock-mantle. Para detalhes técnicos e configurações, a documentação do Amazon Bedrock traz as informações completas. Quem quiser entender o contexto mais amplo do lançamento pode conferir também o post de lançamento oficial.

Fonte

OpenAI GPT-5.6 Sol, Terra, and Luna now support 1 million token context windows on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/08/gpt-sol-terra-luna-long-context-bedrock)