Blog

  • Como Construir um Assistente de Reparo de Equipamentos com IA Usando o Amazon Bedrock AgentCore

    O problema que essa solução resolve

    Quem trabalha com manutenção de maquinário agrícola pesado conhece bem o cenário: o técnico chega ao campo sem a peça certa, o equipamento fica parado, e durante a época de colheita cada hora de inatividade representa prejuízo real. A AWS publicou um guia técnico mostrando como o Amazon Bedrock AgentCore pode ser usado para construir um assistente de reparo com Inteligência Artificial (IA) que ajuda agricultores e técnicos de campo a diagnosticar problemas, identificar peças necessárias e acessar procedimentos de reparo aprovados pelos fabricantes — tudo por linguagem natural.

    Visão geral da arquitetura

    A solução combina um frontend web com um agente hospedado no AgentCore que responde perguntas de diagnóstico consultando documentação técnica indexada dos fabricantes. Os componentes principais são:

    • AgentCore Runtime com o Strands Agents SDK para hospedar e executar o agente
    • Amazon Nova 2 Lite como modelo de fundação para inferência
    • Amazon Bedrock Knowledge Base para Geração Aumentada por Recuperação (RAG — Retrieval-Augmented Generation)
    • AgentCore Memory para persistência de conversas entre sessões
    • Amazon Cognito para autenticação de usuários
    • AWS Amplify para hospedar a aplicação web React

    A arquitetura é organizada em quatro seções principais:

    • Seção A – Autenticação e Frontend: Uma stack do CloudFormation implanta o Amazon Cognito (User Pool e Identity Pool) e o AWS Amplify. Os usuários se autenticam pelo Cognito, e o frontend se comunica diretamente com o endpoint do AgentCore Runtime.
    • Seção B – AgentCore Runtime: Hospeda o agente baseado em Strands e expõe o endpoint /invocations. O frontend chama esse endpoint usando um token Bearer do Cognito. O agente roteia requisições internamente com base no campo path do payload (/chat para consultas de IA e /issues para operações de criação, leitura, atualização e exclusão — CRUD).
    • Seção C – Processamento com IA: O agente Strands usa uma ferramenta customizada chamada search_equipment_knowledge que consulta a Base de Conhecimento do Bedrock via API retrieve_and_generate. A Base de Conhecimento indexa documentação armazenada no Amazon S3 usando o Amazon OpenSearch Serverless para busca vetorial e o Amazon Titan Embeddings para correspondência semântica.
    • Seção D – Dados e Memória: O Amazon DynamoDB armazena os chamados de serviço dos equipamentos. O AgentCore Memory oferece memória de curto prazo (dentro da sessão) e de longo prazo (entre sessões). O Amazon CloudWatch e o AWS X-Ray fornecem observabilidade automática.

    Como o fluxo de uma consulta funciona

    O caminho percorrido desde a pergunta do técnico até a resposta do agente segue estas etapas:

    • O técnico abre a aplicação web e se autentica pelo Amazon Cognito.
    • A pergunta é enviada ao endpoint /invocations do AgentCore Runtime com um token Bearer do Cognito.
    • O AgentCore valida o token, encaminha a requisição ao agente e recupera o contexto de conversas anteriores.
    • O agente Strands envia a consulta ao Amazon Nova 2 Lite para inferência.
    • O modelo invoca a ferramenta search_equipment_knowledge, que consulta a Base de Conhecimento do Bedrock.
    • A Base de Conhecimento pesquisa os manuais indexados e retorna documentação relevante com citações de fontes.
    • O modelo sintetiza uma resposta de diagnóstico com procedimentos de reparo e recomendações de peças, devolvendo o resultado ao técnico com atribuição de fonte para verificação.

    O código da ferramenta de busca na Base de Conhecimento

    O trecho abaixo mostra como a ferramenta de recuperação do agente consulta a documentação dos fabricantes:

    @tool
    def search_equipment_knowledge(query: str) -> str:
        """Search equipment manuals, parts catalogs, and repair docs."""
        response = bedrock_agent_runtime.retrieve_and_generate(
            input={"text": query},
            retrieveAndGenerateConfiguration={
                "type": "KNOWLEDGE_BASE",
                "knowledgeBaseConfiguration": {
                    "knowledgeBaseId": KNOWLEDGE_BASE_ID,
                    "modelArn": f"arn:aws:bedrock:{REGION}::foundation-model/{MODEL_ID}",
                },
            },
        )
        return response.get("output", {}).get("text", "No results found.")

    Pré-requisitos e estimativa de custos

    Antes de começar a implantação, é necessário ter:

    Em termos de custos para testes, os principais são as invocações do modelo Amazon Nova 2 Lite (US$ 0,30/US$ 2,50 por milhão de tokens de entrada/saída) e a Base de Conhecimento do Bedrock (OpenSearch Serverless a aproximadamente US$ 0,24/hora enquanto ativo). Os demais serviços — AgentCore Runtime, Amazon DynamoDB, Amazon S3, Amazon Cognito e AWS Amplify — se enquadram no nível gratuito da AWS para volumes de teste. Para estimativas detalhadas, utilize a AWS Pricing Calculator.

    Criando a Base de Conhecimento

    Passo 1: Prepare a documentação

    Para testes, a AWS recomenda baixar manuais de equipamentos da John Deere Technical Information Store — o guia usa especificamente os manuais dos tratores compactos John Deere 1023E e 1025R. Também é possível usar a documentação da própria organização. Os documentos devem ser pesquisáveis por texto (não imagens escaneadas), com nomenclatura consistente e sem informações proprietárias que não devam ser acessíveis a todos os usuários.

    Passo 2: Crie um bucket S3 para a Base de Conhecimento

    aws s3 mb s3://agriculture-kb-documents-<unique-suffix>
    aws s3 cp ./equipment-docs s3://agriculture-kb-documents-<unique-suffix> --recursive

    Passo 3: Crie a Base de Conhecimento do Bedrock

    Siga as instruções da documentação para criar a Base de Conhecimento com as seguintes configurações:

    • Nome: Agriculture-Equipment-Repair-KB
    • Fonte de dados: o bucket S3 criado no passo anterior
    • Estratégia de parsing: parser padrão do Amazon Bedrock
    • Estratégia de chunking: chunking padrão
    • Modelo de embeddings: Amazon Titan Embeddings G1 – Text
    • Vector store: criação rápida de um novo (Amazon OpenSearch Serverless)

    Passo 4: Sincronize e teste a Base de Conhecimento

    Após criar a Base de Conhecimento, sincronize a fonte de dados para iniciar a ingestão dos documentos (normalmente 10 a 20 minutos). Consulte como sincronizar suas fontes de dados. Use a funcionalidade de teste no console do Bedrock para verificar se a Base de Conhecimento responde corretamente. Anote o ID da Base de Conhecimento na página de detalhes.

    Implantando a solução

    Passo 5: Implante a infraestrutura de suporte

    Inicie a stack do CloudFormation. Nos parâmetros, informe um nome para o deployment (padrão: ag-repair-assist) e o ID da Base de Conhecimento do passo anterior. Após a conclusão, anote os valores da aba Outputs da stack — eles serão usados nos passos seguintes.

    Passo 6: Implante o agente a partir da máquina local

    Com Python 3.10 ou superior e credenciais AWS configuradas, execute os seguintes comandos:

    mkdir agriculture-repair-agent && cd agriculture-repair-agent
    python3 -m venv .venv
    source .venv/bin/activate
    pip install "bedrock-agentcore-starter-toolkit>=0.1.21" strands-agents strands-agents-tools boto3

    Em seguida, baixe e extraia o código do agente (dois arquivos: agriculture_repair_agent.py e requirements.txt). Configure o agente com:

    agentcore configure -e agriculture_repair_agent.py

    Durante a configuração interativa, selecione “Direct Code Deploy” (sem Docker), informe o ARN do papel de execução, a URL de descoberta OAuth do Cognito e o ID do cliente do User Pool — todos obtidos dos Outputs do CloudFormation. Depois, faça o deploy:

    agentcore launch --env KNOWLEDGE_BASE_ID=<your-kb-id> --env TABLE_NAME=<EquipmentIssuesTableName> --env MODEL_ID=us.amazon.nova-2-lite-v1:0

    O processo leva aproximadamente 5 a 10 minutos. Ao final, anote o ARN do AgentCore Runtime gerado.

    Passo 7: Implante o frontend

    Baixe o arquivo ML-18699-FrontEnd.zip, acesse o console do AWS Amplify pela URL fornecida nos Outputs do CloudFormation, clique em “Deploy updates”, escolha o método de arrastar e soltar, selecione o arquivo .zip e aguarde a conclusão do deploy.

    Usando a aplicação

    Acesse a URL da aplicação Amplify, configure os valores obtidos nos passos anteriores, crie uma conta, verifique o e-mail e faça login. Alguns exemplos de consultas para testar:

    • Análise de problema: “My John Deere 1023E series tractor is losing hydraulic pressure on the left side when lifting heavy implements. The pressure drops from 2500 PSI to about 1800 PSI under load.”
    • Consulta técnica: “What hydraulic fluid is recommended for John Deere 1025R?”

    Limpeza dos recursos

    Os recursos implantados geram cobranças contínuas até serem removidos. Para encerrar tudo:

    agentcore destroy
    aws cloudformation delete-stack --stack-name ag-repair-assist

    No console do Amazon Bedrock Knowledge Bases, selecione Agriculture-Equipment-Repair-KB e escolha Delete. Por fim, esvazie e remova o bucket S3:

    aws s3 rm s3://agriculture-kb-documents-<unique-suffix> --recursive
    aws s3 rb s3://agriculture-kb-documents-<unique-suffix>

    Considerações para produção

    A solução foi projetada para ser leve e servir como ponto de partida. Para ambientes produtivos, a AWS recomenda considerar os seguintes aprimoramentos:

    • Amazon Bedrock Guardrails: Adicionar detecção de ataques de prompt e filtragem de conteúdo para proteger contra entradas maliciosas, além de configurar tópicos negados para limitar o escopo do agente.
    • Proteção de API: Posicionar o Amazon CloudFront na frente do endpoint do AgentCore Runtime com AWS WAF para limitação de taxa e proteção OWASP.
    • Autenticação multifator: Habilitar MFA no Amazon Cognito com tokens de software baseados em TOTP.
    • Observabilidade e alertas: O AgentCore gera automaticamente métricas, logs e rastreamentos visíveis nos dashboards de observabilidade de IA generativa do Amazon CloudWatch. Configure alarmes para taxas de erro e latência de resposta.
    • Ciclo de vida dos dados: Implementar políticas de ciclo de vida no Amazon S3 para versionamento de documentação e recuperação point-in-time no Amazon DynamoDB.
    • Deploy multi-região: Para equipes de campo globais, implantar o AgentCore Runtime em múltiplas regiões AWS com Bases de Conhecimento específicas por região.

    Próximos passos e extensibilidade

    Uma das vantagens da arquitetura é que novas capacidades podem ser adicionadas simplesmente criando uma nova função com o decorador @tool no código do agente — sem necessidade de alterações na infraestrutura. Algumas extensões sugeridas pela AWS:

    • Integração com pedidos de peças: Uma ferramenta @tool que conecta ao sistema de estoque e permite verificar disponibilidade e fazer pedidos diretamente da conversa de diagnóstico.
    • Comunicação com revendedores: Uma ferramenta que envia resumos de diagnóstico ao revendedor autorizado mais próximo via Amazon Simple Email Service (SES) ou Amazon Simple Notification Service (SNS).
    • Integração com telemetria IoT: Conectar sensores dos equipamentos via AWS IoT Core para criar chamados automaticamente quando leituras anômalas forem detectadas, pré-populando o contexto de diagnóstico do agente.
    • Aplicativo mobile para campo: Construir um frontend otimizado para mobile com cache offline para áreas com conectividade limitada.

    Benefícios da implementação

    De acordo com a AWS, os principais benefícios dessa arquitetura são:

    • Redução do tempo médio de resolução por meio de diagnósticos mais rápidos fundamentados na documentação dos fabricantes
    • Melhora nas taxas de resolução na primeira visita, já que os técnicos chegam ao local com as peças e procedimentos corretos
    • Memória de conversa que mantém contexto dentro de sessões e persiste conhecimento entre sessões
    • Operações simplificadas: um único endpoint AgentCore Runtime substitui a necessidade de API Gateway, Lambda e Bedrock Agent separados
    • Observabilidade integrada com rastreamento X-Ray e integração com CloudWatch sem configuração adicional
    • Desenvolvimento orientado a código com o padrão @tool do Strands Agent, permitindo extensão e teste local antes do deploy

    O código de exemplo deste guia está disponível sob a licença MIT-0.

    Recursos adicionais

    Fonte

    Build an AI-Powered Equipment Repair Assistant Using Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/build-an-ai-powered-equipment-repair-assistant-using-amazon-bedrock-agentcore/)

  • Amazon ECS Managed Daemons agora suportam visibilidade e comunicação entre tarefas

    O que mudou nos ECS Managed Daemons

    A AWS anunciou uma atualização relevante para equipes que utilizam o Amazon ECS com ECS Managed Instances: os ECS Managed Daemons agora suportam visibilidade e comunicação entre tarefas. Isso abre caminho para implantar agentes de rastreamento, profiling e segurança que precisam acessar processos da aplicação e recursos compartilhados de Comunicação entre Processos (IPC) diretamente na instância gerenciada.

    Dois novos parâmetros nas definições de daemon

    Com esse lançamento, é possível configurar dois novos campos nas definições de daemon do ECS:

    • pidMode: controla se o daemon pode enxergar todos os processos em execução na instância.
    • ipcMode: controla se o daemon compartilha o namespace IPC com os demais contêineres da instância.

    Em ambos os casos, definir o valor como "shared" concede ao daemon acesso ao namespace correspondente. O valor padrão é "none", que mantém o daemon isolado dos contêineres de aplicação e das demais tarefas — comportamento já existente e preservado por padrão.

    Por que isso importa na prática

    Antes dessa atualização, agentes que precisavam de visibilidade sobre processos ou acesso a recursos IPC precisavam ser incorporados como sidecars dentro das definições de tarefas das aplicações. Isso criava acoplamento entre a plataforma e os times de produto, dificultando atualizações independentes dos agentes.

    Com os novos parâmetros, equipes de plataforma podem implantar e atualizar esses agentes de forma independente, como daemons dedicados. O ECS já garante que exatamente uma tarefa daemon seja executada por instância gerenciada e que os daemons sejam iniciados antes das tarefas de aplicação — o que assegura cobertura consistente em todas as cargas de trabalho do cluster.

    Como começar a usar

    Para habilitar o recurso, basta registrar uma definição de tarefa daemon especificando pidMode ou ipcMode com o valor "shared". Essa configuração pode ser feita pelo Console da AWS, pela CLI, via CloudFormation ou pelos SDKs da AWS. Em seguida, é necessário criar ou atualizar um daemon associando-o aos provedores de capacidade do ECS Managed Instances no cluster desejado.

    Disponibilidade e custo

    O recurso já está disponível em todas as regiões da AWS e não tem custo adicional. Para mais detalhes técnicos, a AWS disponibiliza a documentação oficial com os parâmetros suportados nas definições de daemon.

    Fonte

    Amazon ECS Managed Daemons now support inter-task visibility and communication (https://aws.amazon.com/about-aws/whats-new/2026/06/ecs-managed-daemons-pid-ipc-modes/)

  • Instâncias Amazon EC2 P6-B200 chegam à região AWS GovCloud (US-East)

    Expansão das instâncias P6-B200 para o ambiente governamental da AWS

    A AWS anunciou a disponibilidade das instâncias Amazon Elastic Compute Cloud (Amazon EC2) P6-B200 na região AWS GovCloud (US-East). Aceleradas pelas GPUs NVIDIA Blackwell, essas instâncias chegam a mais uma região, ampliando o acesso a cargas de trabalho de Inteligência Artificial (IA) em ambientes com requisitos regulatórios governamentais.

    O que são as instâncias P6-B200?

    As instâncias EC2 P6-B200 são projetadas para cargas de trabalho intensivas de treinamento e inferência de IA. Em comparação com as instâncias P5en — a geração anterior de referência —, as P6-B200 entregam até 2x mais desempenho, um salto considerável para equipes que trabalham com modelos de grande escala.

    Do ponto de vista técnico, cada instância conta com:

    • 8 GPUs NVIDIA Blackwell
    • 1.440 GB de memória GPU de alta largura de banda
    • 60% mais largura de banda de memória GPU em relação às P5en
    • Processadores Intel Xeon de 5ª Geração (Emerald Rapids)
    • Até 3,2 terabits por segundo de rede via Elastic Fabric Adapter (EFAv4)

    Segurança e escalabilidade com o AWS Nitro System

    As instâncias P6-B200 são alimentadas pelo AWS Nitro System, a arquitetura de virtualização da AWS que oferece isolamento de hardware, segurança reforçada e desempenho próximo ao bare metal. Graças a essa base, é possível escalar cargas de trabalho de IA de forma confiável dentro dos Amazon EC2 UltraClusters, chegando a dezenas de milhares de GPUs interconectadas.

    Para organizações governamentais e parceiros que precisam operar em ambientes com controles rigorosos de conformidade, essa combinação — hardware de ponta com a infraestrutura segura do Nitro — representa um diferencial importante.

    Disponibilidade por região

    As instâncias P6-B200 estão disponíveis no tamanho p6-b200.48xlarge nas seguintes regiões da AWS:

    • US West (Oregon)
    • US East (N. Virginia)
    • US East (Ohio)
    • AWS GovCloud (US-West)
    • AWS GovCloud (US-East) — novidade anunciada agora

    Saiba mais

    Para equipes que desejam entender melhor as especificações técnicas, casos de uso recomendados e como provisionar essas instâncias, a AWS disponibiliza documentação detalhada na página oficial: Instâncias Amazon EC2 P6.

    Fonte

    Amazon EC2 P6-B200 instances are now available in the AWS GovCloud (US-East) Region (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-ec2-p6-b200-aws-govcloud/)

  • Amazon OpenSearch Service lança MCP Apps para observabilidade agêntica

    O que mudou no Amazon OpenSearch Service

    A AWS anunciou o suporte a MCP Apps no Amazon OpenSearch Service, trazendo fluxos de observabilidade diretamente para dentro de IDEs agênticas compatíveis, como o Claude Desktop e o VS Code. Com isso, agentes de IA que rodam em ambiente local passam a conseguir investigar incidentes usando dados já armazenados no OpenSearch — incluindo logs, traces, métricas e alertas — além de dados do Amazon Managed Service for Prometheus.

    Como funciona na prática

    A lógica central da funcionalidade é simples: cada chamada de ferramenta MCP App retorna uma resposta dupla. De um lado, um resumo textual conciso que o agente usa para raciocinar sobre o problema. Do outro, uma visualização interativa renderizada no mesmo fio de conversa, para que o desenvolvedor possa revisar e validar os resultados sem precisar trocar de contexto ou abrir outra ferramenta.

    Isso significa que é possível trabalhar lado a lado com o agente de observabilidade em um único fluxo contínuo — desde o disparo de um alerta até a análise de causa raiz, passando por:

    • Exploração de traces distribuídos
    • Mapas de serviço
    • Gráficos de métricas em PromQL
    • Correlações entre diferentes sinais de observabilidade

    Ferramentas disponíveis nos MCP Apps

    O conjunto de ferramentas disponíveis cobre uma gama ampla de cenários de observabilidade. Entre as capacidades anunciadas estão:

    • Investigação de logs, métricas e traces
    • Análise de performance de serviços
    • Topologia de infraestrutura
    • Visualizações dinâmicas
    • Saúde do agente e do cluster
    • Pontuação de instrumentação

    Disponibilidade

    A experiência com MCP Apps no OpenSearch está disponível em todas as regiões da AWS onde a interface do Amazon OpenSearch é oferecida. Para começar a usar, a AWS disponibilizou instruções detalhadas na documentação de observabilidade agêntica com MCP Apps no OpenSearch. Quem quiser se aprofundar no serviço como um todo pode consultar o Guia do Desenvolvedor do Amazon OpenSearch Service.

    Fonte

    Amazon OpenSearch Service launches MCP Apps for agentic observability (https://aws.amazon.com/about-aws/whats-new/2026/06/opensearch-agentic-observability-mcp-app)

  • Como construir um assistente agêntico de triagem de incidentes com Amazon Quick e New Relic

    Triagem de incidentes: um problema de coordenação entre ferramentas

    Quando um incidente acontece em produção, os Engenheiros de Confiabilidade de Site (SREs) e engenheiros de suporte precisam agir rápido — e o problema é que as evidências estão espalhadas em ferramentas diferentes. Coletar logs, avaliar o impacto para os usuários e registrar o acompanhamento em um sistema de tarefas são etapas que, feitas manualmente, consomem tempo precioso e aumentam o risco de perda de contexto entre turnos.

    A AWS publicou um tutorial que mostra como resolver exatamente esse problema usando o Amazon Quick em conjunto com o Servidor de Protocolo de Contexto de Modelo (MCP) do New Relic e o Asana. A proposta é coordenar todas essas etapas de investigação e handoff em um único fluxo de trabalho conversacional.

    O que é o Amazon Quick e como ele se conecta ao New Relic

    O Amazon Quick é uma plataforma da AWS que permite criar agentes de chat capazes de explorar dados e executar ações por meio de conversas abertas. Esses agentes são conectados a serviços externos por meio de conectores de ação — integrações pré-construídas que ligam o Amazon Quick a ferramentas do ecossistema corporativo.

    O New Relic já é um conector nativo do Amazon Quick, o que simplifica bastante a configuração. Ele dá ao agente acesso a ferramentas de raciocínio de IA voltadas para resposta a incidentes e análise de desempenho. O Asana também é um conector nativo, utilizado para criação de tarefas. O agente orquestra os dois, produzindo um relatório de Análise de Causa Raiz (RCA) e uma tarefa no Asana a partir de um único prompt.

    As cinco ferramentas de raciocínio do New Relic

    O agente de triagem utiliza cinco ferramentas do New Relic para conduzir a investigação. O próprio agente decide quais chamar com base no prompt recebido:

    • generate_alert_insights_report: identifica os principais gatilhos de alertas.
    • generate_user_impact_report: quantifica o raio de impacto, incluindo número de usuários e serviços afetados.
    • analyze_entity_logs: exibe assinaturas de erro e exceções nos logs.
    • analyze_transactions: identifica requisições lentas ou com falha.
    • natural_language_to_nrql_query: converte perguntas em linguagem natural para a Linguagem de Consulta do New Relic (NRQL) e as executa contra os dados de observabilidade.

    O fluxo completo vai de um prompt do engenheiro de plantão até a criação automática de uma tarefa no Asana, passando pela chamada sequencial das ferramentas do New Relic e pela montagem do relatório de RCA com links de evidências.

    Pré-requisitos para montar a solução

    Antes de começar a implementação, é necessário ter em mãos os acessos corretos nas três plataformas envolvidas:

    • Amazon Quick: É necessária uma assinatura Professional. O usuário precisa ter permissões de Author ou superior para criar integrações e agentes de chat. Consulte os detalhes de preços do Amazon Quick para entender os planos disponíveis.
    • New Relic: O conector do New Relic já está integrado ao Amazon Quick. A autenticação é feita com as credenciais da conta New Relic existente durante a configuração do conector.
    • Asana: É preciso ter um workspace com um projeto chamado SRE Incident Triage e acesso administrativo para criar uma aplicação OAuth no console de desenvolvedor do Asana, obtendo assim as credenciais necessárias.

    Implementação passo a passo

    Passo 1: Configurar a integração com o New Relic

    O New Relic está disponível como conector nativo no console de Integrações do Amazon Quick. O processo consiste em navegar até a aba de Ações, localizar o tile do New Relic e iniciar a configuração. Na tela de criação da integração, basta informar um nome e uma descrição opcional, manter o tipo de conexão como rede pública e prosseguir. A autenticação com a conta New Relic é feita em uma etapa posterior, na página de detalhes da integração, onde também ficam disponíveis as ações suportadas e as URLs de conexão.

    Passo 2: Configurar a integração com o Asana

    O conector do Asana utiliza OAuth 2.0. Antes de configurá-lo no Amazon Quick, é necessário criar uma aplicação OAuth no console de desenvolvedor do Asana para obter o Client ID e o Client Secret. Em seguida, no Amazon Quick, acesse Integrações → Ações e selecione o Asana. Os valores necessários para preencher são:

    • Base URL: https://app.asana.com/api/1.0
    • URL de Autorização: https://app.asana.com/-/oauth_authorize
    • URL de Redirecionamento: copiar da tela de configuração do Amazon Quick e colar nas URLs de redirecionamento permitidas do aplicativo OAuth no Asana.
    • Client ID e Client Secret: obtidos na aplicação OAuth do Asana.

    Para instruções completas, a documentação oficial está disponível no guia de integração com o Asana no Amazon Quick User Guide.

    Passo 3: Criar o agente de triagem de incidentes

    Com as duas integrações configuradas, o próximo passo é criar o agente de chat. No Amazon Quick, acesse Chat agents, clique em Create chat agent, defina um nome e uma finalidade para o agente. Para instruções detalhadas de criação, consulte a documentação de agentes de chat personalizados no Amazon Quick User Guide.

    Na seção de Ações do construtor de agentes, é preciso vincular as duas integrações criadas anteriormente — New Relic e Asana. Depois disso, substitua as instruções geradas automaticamente pelo seguinte bloco de instruções, que define o comportamento completo do agente:

    You are the Incident triage assistant.
    
    Primary job
    Help on-call engineers triage incidents using New Relic reasoning tools.
    When the investigation is complete, create an Asana task with the RCA brief.
    
    How to respond
    Keep responses concise and operational. Do not guess. Use tool outputs as evidence.
    If inputs are missing, ask for: service or entity name, environment, and time window.
    
    Default RCA brief format:
    Summary (1-2 lines)
    Blast radius
    Likely trigger
    Key evidence (bullets with links)
    Recommended next actions (3 bullets)
    
    Tool routing: New Relic investigation
    alert fired, key drivers, signals changed -> generate_alert_insights_report
    blast radius, customer impact, users affected -> generate_user_impact_report
    logs, error signature, exceptions, anomalies -> analyze_entity_logs
    slow requests, latency, transactions -> analyze_transactions
    segmentation by region, version, endpoint -> natural_language_to_nrql_query
    
    Tool routing: output
    After generating the RCA brief -> create an Asana task.
    Task fields: Name = incident title, Notes = full RCA brief with evidence links,
    Due date = today, Tags = [sre-triage, incident].
    Confirm the Asana project name with the user if not already known.
    
    Output rules
    If a tool call fails (permissions, timeout, missing entity), state what failed
    and what input you need next.
    Do not include PII, customer identifiers, user IDs, email addresses, IP addresses,
    session tokens, raw credentials, internal hostnames, infrastructure topology details,
    database connection strings, or environment variables in the RCA brief or Asana task notes.

    Passo 4: Testar o fluxo completo

    Com o agente criado e as integrações vinculadas, basta abrir o assistente de triagem no Amazon Quick e enviar o seguinte prompt para iniciar uma investigação:

    "Checkout is slow and we are seeing server errors on checkout-service in production. Check the last 24 hours. Generate RCA brief."

    O agente chama as cinco ferramentas de raciocínio do New Relic em sequência, monta o relatório de RCA com resumo, raio de impacto, provável gatilho, evidências com links e três próximas ações recomendadas. Em seguida, pergunta ao engenheiro se pode criar a tarefa no Asana. Para confirmar, basta responder:

    "Yes, create an Asana task in project SRE Incident Triage with this RCA brief."

    O agente então cria a tarefa no projeto indicado, com o relatório completo nas notas, pronta para handoff.

    Segurança e governança: pontos de atenção

    Antes de disponibilizar o agente para toda a rotação de plantão, a AWS recomenda atenção a alguns pontos importantes de segurança:

    • Menor privilégio para o New Relic: O conector do New Relic opera com as permissões da conta autenticada. O recomendado é usar uma conta de serviço dedicada com a função de somente leitura padrão do New Relic, ou uma função personalizada limitada ao acesso de leitura de APM (Monitoramento de Desempenho de Aplicação), logs, alertas, entidades e NRQL. Credenciais de administrador completo não devem ser usadas.
    • Escopo de permissões do Asana: Use uma conta de serviço dedicada no Asana com acesso de criação de tarefas limitado ao projeto SRE Incident Triage. Os escopos OAuth do aplicativo devem incluir apenas o necessário: tasks:write, tasks:read, projects:read e workspaces:read.
    • Dados sensíveis nas notas de tarefas: As notas das tarefas do Asana devem ser tratadas como um resumo de handoff, não como uma exportação bruta de dados de incidentes. Não devem constar Informações de Identificação Pessoal (PII), identificadores de clientes, IDs de usuários, endereços de e-mail, endereços IP, tokens de sessão, hostnames internos, detalhes de topologia de infraestrutura, strings de conexão de banco de dados, variáveis de ambiente ou credenciais brutas.
    • Armazenamento de credenciais: Rotacione as credenciais OAuth do New Relic e do Asana de acordo com a política de rotação de chaves da organização.
    • Auditoria: O Amazon Quick registra as invocações dos conectores de ação, o que facilita o rastreamento das ações realizadas pelo agente.

    Limpeza dos recursos

    Para quem construiu a solução como protótipo e deseja evitar cobranças contínuas, a AWS indica remover os seguintes recursos:

    • No Amazon Quick: excluir o agente de chat personalizado.
    • No Amazon Quick: excluir os conectores de integração do New Relic e do Asana.
    • No console de desenvolvedor do Asana: revogar as credenciais da aplicação OAuth criada para a integração.
    • Rotacionar ou excluir quaisquer credenciais de teste utilizadas durante a configuração, seguindo a política de segurança da organização.

    Conclusão

    O tutorial publicado pela AWS demonstra como o Amazon Quick pode ser usado para eliminar a coordenação manual entre o sistema de observabilidade e o sistema de rastreamento de tarefas durante um incidente. Com um único prompt, o agente chama as cinco ferramentas de raciocínio do New Relic, monta um relatório de RCA padronizado com links de evidências e cria uma tarefa rastreável no Asana pronta para handoff.

    O benefício vai além da velocidade: cada investigação produz um formato de RCA consistente, independentemente de quem está de plantão, tornando as trocas de turno mais rápidas e as análises pós-mortem mais diretas. Para começar, a AWS indica seguir o artigo de integração do New Relic para o Amazon Quick e o Amazon Quick User Guide.

    Fonte

    Build an agentic incident triage assistant with Amazon Quick and New Relic (https://aws.amazon.com/blogs/machine-learning/build-an-agentic-incident-triage-assistant-with-amazon-quick-and-new-relic/)

  • FNOL sem atrito: como a AWS usa agentes de IA para automatizar o intake de sinistros no setor de seguros

    O problema: o intake de sinistros consome tempo demais de quem mais sabe

    No setor de seguros, o Primeiro Aviso de Perda — em inglês, First Notice of Loss (FNOL) — é o momento em que um sinistro entra no sistema pela primeira vez. Fotos tiradas em campo, vídeos de inspeção, documentos digitalizados e gravações de áudio chegam juntos, geralmente sem padronização, com rótulos inconsistentes e frequentemente incompletos.

    O desafio é que profissionais experientes de sinistros precisam navegar por portais, abrir cada artefato manualmente, correlacionar evidências entre diferentes mídias e confirmar se a submissão está completa antes de qualquer avaliação real começar. Esse trabalho é repetitivo e mecânico — exige atenção, não julgamento. O resultado é que ajustadores qualificados gastam uma parcela desproporcional do tempo validando intake em vez de aplicar sua expertise nas decisões que realmente importam.

    Durante picos de volume — como eventos catastróficos ou sazonalidades — esse gargalo se amplifica, criando filas que atrasam a resolução de sinistros e prejudicam a experiência do cliente.

    A proposta da AWS: agentes que trabalham com o portal, não contra ele

    A AWS publicou uma demonstração técnica mostrando como construir um sistema de intake FNOL hands-free (sem intervenção manual) combinando duas capacidades complementares:

    • Strands Agents: um SDK de código aberto que adota uma abordagem orientada a modelos para construir agentes de IA generativa. Nessa arquitetura, os agentes aplicam regras de negócio específicas do setor de seguros — como interpretação de evidências, correlação entre modalidades e avaliação de complexidade de sinistros — usando modelos de fundação (FMs) servidos pelo Amazon Bedrock.
    • Amazon Nova Act: um SDK cliente que interpreta instruções em linguagem natural (por exemplo, “abra o próximo sinistro não processado” ou “acione a análise de imagens”) e as traduz em ações reais na interface do portal. O Amazon Bedrock AgentCore Browser Tool fornece a sessão Chrome gerenciada e isolada à qual o Nova Act se conecta para executar essas ações, além de oferecer gravação de sessão e visualização ao vivo para observabilidade.

    A separação é intencional: o Nova Act cuida do fluxo de controle da interface — quando e onde agir —, enquanto os agentes Strands determinam o que a evidência significa, aplicando a mesma lógica de domínio que um revisor humano usaria.

    Arquitetura da solução

    A solução é estruturada em camadas complementares:

    • Interação com o navegador: o Nova Act se conecta a uma sessão do AgentCore Browser Tool via Protocolo Chrome DevTools (CDP) sobre WebSocket, raciocina sobre o estado atual da interface do portal FNOL e age de forma deliberada sobre o que está visível.
    • Raciocínio de domínio: dois agentes construídos com o Strands Agents SDK — um Agente Analisador de Evidências, que interpreta e classifica evidências multimodais, e um Agente Analisador de Complexidade de Sinistros, que avalia a complexidade geral do caso.
    • Observabilidade de execução: capturas de tela, prompts, raciocínio e transições de estado da interface são registrados automaticamente a cada etapa, produzindo uma trilha de auditoria completa sem instrumentação adicional.
    • Infraestrutura e persistência: o Amazon ECS no AWS Fargate executa a aplicação; o Amazon S3 armazena os artefatos de evidência; o Amazon DynamoDB mantém o estado dos sinistros e os resultados gerados pelos agentes; e o Amazon CloudWatch fornece visibilidade operacional.

    A infraestrutura é provisionada via AWS Cloud Development Kit (AWS CDK), que constrói as imagens de contêiner e cria os recursos de computação, armazenamento e rede como parte de um único fluxo de implantação. O código completo está disponível no repositório GitHub da solução.

    Imagem original — fonte: Aws

    O fluxo em prática: da fila ao sinistro classificado

    Seleção do sinistro na fila

    O fluxo começa na fila de FNOL. O Nova Act observa o estado atual do portal por meio da sessão do AgentCore Browser Tool, identifica o próximo sinistro pronto para processamento com base nos indicadores de status visíveis e navega até a visão detalhada do sinistro. Como a decisão é baseada no estado atual da interface — e não em scripts pré-gravados ou seletores fixos —, a mesma lógica funciona independentemente de mudanças no layout da fila, reordenação de colunas ou variações na quantidade de registros.

    Análise de evidências: revisão estruturada por modalidade

    A revisão de evidências é onde o intake de FNOL tipicamente desacelera. A solução divide essa etapa em três ações distintas — Analisar Imagens, Analisar Vídeos e Analisar Áudio — espelhando como um examinador humano avalia cada tipo de artefato separadamente.

    Imagens: quando a análise de imagens é acionada, cada foto submetida é avaliada de forma independente pelos agentes Strands. Isso inclui identificar o que a imagem retrata (dano ao veículo, superfície de telhado, interior, documentação médica etc.), avaliar se a perspectiva é adequada para o tipo de sinistro, confirmar clareza e usabilidade, e sinalizar indicadores de dano. Em vez de deixar essa interpretação implícita, cada imagem recebe atributos estruturados que tornam o julgamento explícito, consistente e reutilizável ao longo do ciclo de vida do sinistro.

    Vídeos: quando a análise de vídeos é acionada, as submissões em vídeo são tratadas como evidências de primeira classe, não como anexos opacos. Os agentes Strands avaliam o que cada vídeo captura: se adiciona informações além das fotos, complementa imagens ausentes ou corrobora outros artefatos. Os sinais derivados do vídeo são normalizados para participar diretamente do raciocínio downstream ao lado de imagens e documentos.

    Áudio: quando a análise de áudio é acionada, o sistema processa as evidências por meio das transcrições correspondentes. O Agente Analisador de Evidências analisa o texto da transcrição para extrair observações materiais, declarações factuais, danos reportados e detalhes contextuais que complementam as evidências visuais. Os sinais transcritos são então correlacionados com as tags de imagens e vídeos, espelhando como um revisor humano cruza contexto falado com provas visuais durante o intake.

    Ao final dessas três etapas, cada imagem, vídeo e artefato de áudio foi avaliado e classificado. Nenhuma evidência permanece sem categorização, e qualidade, relevância e completude tornam-se explícitas em vez de inferidas.

    Análise de complexidade: do tagging à decisão de triagem

    Com as evidências completamente classificadas, o agente avalia cada sinistro de forma holística. Em vez de depender apenas de campos estáticos de intake, os agentes Strands combinam metadados do sinistro com sinais derivados das evidências para avaliar a complexidade usando regras já familiares às operações de seguros. Isso inclui indicadores de severidade entre modalidades, completude e consistência interna das evidências, e limites de apólice que determinam escalonamento ou roteamento.

    Os sinistros são classificados como Simples ou Complexos. Sinistros simples são resolvidos automaticamente, enquanto sinistros complexos são encaminhados para o status “Necessita Revisão” com notas estruturadas geradas automaticamente explicando por que o sinistro foi sinalizado — fornecendo contexto imediato e acionável para os usuários downstream.

    Por que o tagging automatizado de evidências importa — agora e no futuro

    O tagging automatizado acelera o sinistro atual ao garantir completude e clareza do intake antes que as etapas downstream comecem. Revisores gastam menos tempo confirmando o básico e mais tempo aplicando julgamento onde importa.

    Com o tempo, evidências consistentemente classificadas tornam-se um ativo de dados durável. Como as tags são geradas por raciocínio de domínio codificado — não por interpretação pontual —, as seguradoras podem:

    • Melhorar o roteamento e a priorização de sinistros
    • Reduzir retrabalho causado por submissões incompletas
    • Identificar padrões que levam a atrasos ou escalonamentos
    • Refinar regras de intake à medida que novos cenários surgem, sem alterar limites de conformidade ou autoridade de decisão

    À medida que evidências classificadas se acumulam, artefatos não estruturados deixam de ser arquivos isolados e passam a funcionar como sinais operacionais pesquisáveis e analisáveis. Isso suporta novos fluxos de trabalho — como alcance proativo quando lacunas comuns são detectadas, pré-posicionamento de sinistros para equipes especializadas e redução de tempos de ciclo para sinistros futuros semelhantes.

    Humano no loop, não humano no detalhe

    A solução não remove pessoas do processo — ela muda onde elas se engajam. Com evidências já analisadas e classificadas, os ajustadores começam seu trabalho com contexto em vez de artefatos brutos. A revisão substitui o reprocessamento. Correções tornam-se feedback em vez de retrabalho.

    Com o tempo, esse feedback aprimora as regras de negócio de forma incremental à medida que padrões emergem entre sinistros. O intake de FNOL evolui de um gargalo para um sistema de aprendizado — que refina continuamente como evidências são interpretadas, roteadas e tratadas sem aumentar a carga operacional.

    Essa abordagem funciona sem substituir sistemas existentes ou interromper fluxos de trabalho estabelecidos. A automação opera com os portais que as seguradoras já utilizam, porque o Nova Act interage com a interface como um humano faria.

    Além do FNOL: o valor das evidências estruturadas ao longo do ciclo de vida

    Embora o FNOL seja o ponto de entrada, o valor das evidências estruturadas e classificadas se estende por todo o ciclo de vida dos sinistros. Depois que artefatos não estruturados são consistentemente interpretados e classificados na ingestão, eles deixam de se comportar como anexos estáticos e passam a funcionar como sinais operacionais.

    Sinistros podem ser roteados com base no que as evidências realmente mostram, em vez de depender de campos grosseiros de intake ou triagem manual. Fluxos de trabalho downstream chegam pré-populados com contexto — indicadores de dano, sinais de completude e evidências corroborativas. À medida que padrões emergem entre sinistros, a orientação de coleta de evidências melhora organicamente, ajudando as seguradoras a identificar lacunas comuns antes que criem atrasos downstream.

    Explorar a solução

    Para explorar essa abordagem em seu próprio ambiente, a AWS disponibiliza o protótipo no repositório GitHub. A documentação complementar está disponível na documentação do Amazon Bedrock AgentCore, na documentação do Amazon Nova Act e na documentação do Strands Agents.

    Fonte

    Hands-free first notice of loss: Using Strands Agents and Amazon Bedrock AgentCore Browser Tool for intelligent claims intake (https://aws.amazon.com/blogs/machine-learning/hands-free-first-notice-of-loss-using-strands-agents-and-amazon-bedrock-agentcore-browser-tool-for-intelligent-claims-intake/)

  • Amazon SageMaker Unified Studio agora suporta EMR Serverless nos Notebooks

    O que foi anunciado

    A AWS expandiu as capacidades dos Notebooks do Amazon SageMaker Unified Studio, adicionando suporte ao Amazon EMR Serverless com Apache Spark Connect. Com essa novidade, engenheiros de dados e analistas ganham mais flexibilidade na escolha do runtime Spark para workloads de analytics interativo e engenharia de dados.

    Mais opções de runtime Spark

    Antes dessa atualização, o Amazon Athena Spark era a única opção de runtime Spark disponível nos Notebooks do SageMaker Unified Studio. Agora, os usuários podem escolher entre o Athena Spark e o Amazon EMR Serverless, selecionando o motor mais adequado conforme as necessidades de cada projeto.

    A seleção do runtime é feita diretamente no painel lateral do Notebook, e a escolha se aplica tanto às células Python quanto às células SQL — mantendo consistência em toda a sessão de trabalho.

    O que é possível fazer com o EMR Serverless nos Notebooks

    Com essa integração, os usuários podem executar PySpark e Spark SQL diretamente em células de Notebook, conectados a uma aplicação EMR Serverless Spark. Entre os principais benefícios destacados pela AWS, estão:

    • SageMaker Data Agent: o assistente de IA integrado ao SageMaker Unified Studio agora pode gerar código e planos de execução a partir de prompts em linguagem natural, acelerando o desenvolvimento de workflows Spark com EMR Serverless.
    • Capacidade pré-inicializada: as organizações podem utilizar capacidade pré-inicializada para reduzir o tempo de início das sessões, melhorando a experiência em workloads interativos.
    • Monitoramento unificado via Spark UI: a interface de monitoramento do Spark é unificada entre todos os motores suportados, oferecendo visibilidade consistente sobre a execução e o desempenho dos jobs.
    • Suporte a conectividade VPC: o EMR Serverless oferece suporte à conectividade via Virtual Private Cloud (VPC) para workloads que exigem isolamento de rede.

    Disponibilidade

    O recurso está disponível em todas as regiões AWS onde o Amazon SageMaker Unified Studio já opera, com suporte tanto para os Notebooks do SageMaker Unified Studio quanto para o ambiente JupyterLab IDE.

    Para começar a usar, a AWS disponibiliza o Guia do Usuário do Amazon SageMaker Unified Studio com as instruções necessárias.

    Fonte

    Amazon SageMaker Unified Studio Notebooks now support EMR Serverless (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-sagemaker-unified-studio-emr/)

  • AWS Backup agora suporta Amazon EKS na Região Soberana Europeia da AWS (Alemanha)

    Proteção de clusters Kubernetes chega à Nuvem Soberana Europeia

    A AWS anunciou a disponibilidade do suporte do AWS Backup para o Serviço Elástico de Kubernetes da Amazon (Amazon EKS) na Região da Nuvem Soberana Europeia da AWS (Alemanha). A expansão leva proteção e recuperação de dados gerenciada, baseada em políticas, para clusters EKS nessa região — um passo importante para organizações europeias com requisitos rigorosos de conformidade e soberania de dados.

    O que está disponível

    Com essa expansão, os recursos já conhecidos do AWS Backup passam a estar disponíveis para workloads Kubernetes na Região Soberana Europeia. Entre as capacidades incluídas estão:

    • Agendamento automatizado de backups, sem necessidade de scripts manuais
    • Gerenciamento de retenção de dados com controle centralizado
    • Cofres imutáveis (immutable vaults) para proteção contra exclusão ou alteração indevida
    • Cópias entre regiões e entre contas (cross-Region e cross-account)

    A solução é totalmente sem agente (agent-free), o que significa que não é preciso instalar nenhum componente adicional nos clusters para que o backup funcione.

    O que pode ser protegido

    O AWS Backup para Amazon EKS permite proteger diferentes granularidades do ambiente Kubernetes:

    • Clusters EKS inteiros
    • Namespaces específicos
    • Volumes persistentes individuais

    Essa flexibilidade permite que as equipes adaptem a estratégia de backup conforme a criticidade de cada parte do ambiente, sem depender de ferramentas de terceiros ou scripts customizados.

    Casos de uso principais

    A AWS destaca três cenários principais onde o recurso agrega valor direto:

    • Recuperação de desastres: garantir que os clusters possam ser restaurados rapidamente em caso de falhas
    • Conformidade regulatória: atender requisitos de retenção e proteção de dados exigidos por normas europeias e setoriais
    • Antes de atualizações do cluster EKS: criar um ponto de restauração seguro antes de realizar upgrades, reduzindo o risco operacional

    Como começar

    Para utilizar o AWS Backup com Amazon EKS na Região Soberana Europeia, é possível acessar o console do AWS Backup, consultar a documentação oficial do AWS Backup ou acompanhar os detalhes técnicos no AWS News Blog.

    Fonte

    AWS Backup support for Amazon EKS is now available in the AWS European Sovereign Cloud (Germany) Region (https://aws.amazon.com/about-aws/whats-new/2026/06/aws-backup-amazon-eks-aws-european-sovereign-cloud/)

  • AWS anuncia o Claude Fable 5, primeiro modelo da classe Mythos com disponibilidade geral

    Claude Fable 5 chega com disponibilidade geral na AWS

    A AWS anunciou a disponibilidade geral do Claude Fable 5, tornando-o o primeiro modelo da classe Mythos acessível a todos os clientes da plataforma. A novidade representa um passo significativo para empresas e desenvolvedores que buscam aplicar inteligência artificial de alto desempenho em ambientes de produção, com salvaguardas robustas projetadas para garantir um uso mais seguro em escala.

    Vale destacar que o Claude Mythos 5 — a mesma arquitetura base, porém sem os classificadores de segurança — permanece disponível apenas para um grupo restrito de clientes que já participavam do programa de acesso antecipado ao Claude Mythos Preview.

    O que torna o Fable 5 diferente

    De acordo com a AWS, o Claude Fable 5 apresenta desempenho de ponta em praticamente todos os benchmarks testados. Mais do que números em avaliações, o modelo representa uma mudança de paradigma na forma como sistemas de IA podem atuar em tarefas complexas: ele é capaz de operar por períodos prolongados em atividades de conhecimento intensivo e codificação sem necessidade de intervenção humana constante.

    Esse comportamento abre possibilidades concretas para equipes que precisam automatizar fluxos de trabalho profissionais em áreas como:

    • Finanças
    • Jurídico
    • Marketing e vendas
    • Dados e engenharia

    O modelo também é descrito como capaz de atualizar suas próprias habilidades com base em aprendizados, desenvolver seus próprios mecanismos de avaliação e verificar o trabalho antes de entregá-lo — características que apontam para um novo nível de autonomia em agentes de IA para uso corporativo.

    Como acessar o Claude Fable 5

    A AWS disponibiliza o Claude Fable 5 por meio de dois caminhos distintos, atendendo a diferentes perfis de uso:

    Amazon Bedrock

    Pelo Amazon Bedrock, os dados permanecem dentro da infraestrutura da AWS. O acesso ao Claude Fable 5 é feito por um serviço unificado que inclui recursos gerenciados pela própria AWS, como Guardrails, Knowledge Bases e residência regional de dados. Para saber mais, consulte a documentação do Amazon Bedrock e a disponibilidade por região.

    Claude Platform on AWS

    Operada pela Anthropic, a Claude Platform on AWS oferece acesso direto à experiência nativa da plataforma Claude, com cobrança e autenticação unificadas pela AWS. É a opção indicada para quem prefere trabalhar diretamente no ecossistema da Anthropic, sem abrir mão da integração com a conta AWS.

    Fonte

    AWS announces Claude Fable 5, the first generally available Mythos-class model (https://aws.amazon.com/about-aws/whats-new/2026/06/claude-fable-5-aws/)

  • Amazon S3 Access Grants agora disponível na Região Soberana Europeia da AWS (Alemanha)

    Novidade na Nuvem Soberana Europeia

    A AWS anunciou que o Amazon S3 Access Grants está agora disponível na região AWS European Sovereign Cloud (Alemanha). Para equipes que operam nessa região com requisitos elevados de soberania de dados, essa é uma expansão relevante de capacidade de controle de acesso.

    O que é o Amazon S3 Access Grants?

    O S3 Access Grants é um recurso do Amazon S3 que permite mapear identidades corporativas — como usuários e grupos gerenciados no Microsoft Entra ID ou em Identidade e Gerenciamento de Acesso da AWS (IAM) — diretamente a conjuntos de dados armazenados no S3.

    Na prática, isso significa que uma organização pode conceder acesso a buckets e prefixos do S3 com base na identidade corporativa do usuário final, sem precisar criar e manter políticas individuais para cada pessoa. O controle de permissões acontece de forma automatizada e em escala, refletindo a estrutura de diretórios já existente na empresa.

    Por que isso importa para quem usa a Nuvem Soberana?

    A AWS European Sovereign Cloud foi desenvolvida para atender organizações europeias com requisitos rigorosos de residência de dados, conformidade regulatória e controle operacional — especialmente relevante para setores como governo, saúde e serviços financeiros na Europa.

    Com a chegada do S3 Access Grants a essa região, as equipes que já utilizam a Nuvem Soberana da AWS na Alemanha passam a contar com uma forma mais escalável de gerenciar permissões de dados no S3, integrada às suas identidades corporativas existentes — sem abrir mão dos controles de soberania que motivaram a escolha dessa região.

    Disponibilidade e recursos adicionais

    Para verificar a disponibilidade completa do S3 Access Grants por região, a AWS disponibiliza a tabela de regiões da AWS. Quem quiser se aprofundar no funcionamento do recurso pode acessar a página oficial do produto com detalhes técnicos e casos de uso.

    Fonte

    Amazon S3 Access Grants are now available in the AWS European Sovereign Cloud (Germany) Region (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-s3-access-grants-european-sovereign-cloud-germany-region)