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.
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.
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:
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.
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.
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.
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.
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.
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.
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
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.
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.
O treinamento de robôs físicos está deixando de ser um tema de pesquisa acadêmica e entrando de vez nas operações reais de fábricas, armazéns e centros de logística. O motivo é simples: treinar um robô no mundo real é lento, caro e muitas vezes perigoso. A simulação acelerada por GPU resolve esse problema ao comprimir meses de aprendizado em horas de processamento.
O desafio, então, passa a ser de infraestrutura. Aprendizado por Reforço (RL) para comportamentos complexos — como locomoção de robôs humanoides em terrenos irregulares — é extremamente intensivo em GPU, com execuções que podem durar de horas a dias em um único nó. Equipes de robótica precisam iterar rapidamente durante a pesquisa e também executar treinamentos de longa duração em produção, sem precisar manter clusters de computação manualmente.
A AWS publicou um guia técnico detalhado mostrando como fazer exatamente isso: treinar políticas de controle para o robô humanoide Unitree H1 usando o NVIDIA Isaac Lab no Amazon SageMaker AI. O código completo da solução está disponível no repositório GitHub.
Por que usar o Amazon SageMaker AI para treinar robôs?
O SageMaker AI elimina a necessidade de gerenciar a infraestrutura de computação para treinamento de Aprendizado de Máquina (ML). O serviço provisiona instâncias, configura drivers e redes, monitora a saúde dos nós e libera os recursos ao final de cada job — permitindo que a equipe de engenharia foque no desenvolvimento da política do robô, não na infraestrutura.
Isso é especialmente relevante para RL de políticas robóticas, que é pesado em infraestrutura: execuções longas, intensivas em GPU e frequentemente distribuídas em múltiplos nós. O desenvolvimento costuma ter duas fases distintas: experimentos iterativos curtos para ajustar funções de recompensa e arquiteturas de modelo, e execuções de produção mais longas para treinar uma configuração ajustada até a convergência.
Para cobrir essas duas fases, o SageMaker AI oferece duas opções de computação.
Resiliência e controle com o SageMaker HyperPod
O SageMaker HyperPod é uma infraestrutura gerenciada e dedicada para treinamento distribuído de modelos de grande escala. A resiliência é o núcleo do serviço: falhas de hardware em execuções multi-nó significam perda de progresso de treinamento, tempo para detectar a falha, substituir o nó e reiniciar a partir do último checkpoint. O HyperPod executa um agente de monitoramento de saúde em cada nó que realiza verificações básicas e profundas. Quando uma falha é detectada, ele reinicia ou substitui a instância com defeito automaticamente. Com a funcionalidade de retomada automática, o job de treinamento reinicia a partir do último checkpoint sem intervenção manual.
Orquestrado pelo Amazon Elastic Kubernetes Service (Amazon EKS) ou Slurm, o HyperPod oferece acesso direto aos nós do cluster e um ambiente estável que persiste entre execuções. O complemento de observabilidade do HyperPod publica centenas de métricas de cluster, nó e job para o Amazon Managed Service for Prometheus, com dashboards pré-construídos no Amazon Managed Grafana. A governança de tarefas do HyperPod, construída sobre o Kueue, permite que administradores dividam o cluster em filas com cotas de computação, prioridades e preempção por instância, GPU inteira ou partição de GPU com NVIDIA Multi-Instance GPU (MIG).
Computação efêmera com SageMaker Training Jobs
Os SageMaker Training Jobs são uma forma totalmente gerenciada e sob demanda de executar cargas de trabalho de treinamento em contêineres, sem manter computação de longa duração. Cada job provisiona instâncias de GPU, baixa o contêiner do Amazon Elastic Container Registry (Amazon ECR), executa o script de treinamento, faz upload dos artefatos para o Amazon Simple Storage Service (Amazon S3) e encerra as instâncias ao final. Não há custo de computação ociosa entre execuções.
Esse modelo é ideal para a fase de iteração do desenvolvimento de políticas, onde funções de recompensa, espaços de observação e arquiteturas de rede mudam frequentemente entre execuções curtas. Também é adequado para varreduras de ajuste de hiperparâmetros, onde muitas execuções curtas rodam em paralelo e depois liberam a computação.
NVIDIA Isaac Lab: simulação paralela em GPU
O NVIDIA Isaac Lab é um framework open-source de aprendizado robótico construído sobre o NVIDIA Isaac Sim. Ele usa simulação paralela em GPU para executar milhares de instâncias de robôs simultaneamente em uma ou múltiplas GPUs, transformando o que seriam meses de experiência no mundo real em horas de treinamento simulado. O Isaac Lab fornece APIs estruturadas para definir tarefas, espaços de observação e ação, funções de recompensa e loops de treinamento para aprendizado por reforço e aprendizado por imitação.
A tarefa de treinamento usada no guia é Isaac-Velocity-Rough-H1-v0, onde o robô humanoide Unitree H1 aprende a seguir comandos de velocidade enquanto caminha por terrenos irregulares. O robô precisa coordenar seus 19 juntas para manter o equilíbrio em superfícies irregulares geradas proceduralmente. O treinamento usa Otimização de Política Proximal (PPO) através do skrl, um dos vários frameworks de RL suportados pelo Isaac Lab. Escalar para múltiplos nós multiplica o número de ambientes paralelos, produzindo experiências mais diversas por atualização de política e acelerando a convergência.
Visão geral da solução
A solução no repositório GitHub consiste em duas partes principais: (1) uma única imagem Docker que executa o código de treinamento tanto no SageMaker HyperPod quanto no SageMaker Training Jobs, e (2) um script gerador que renderiza os manifestos Kubernetes e o script de lançamento do SageMaker a partir de um arquivo de configuração compartilhado.
As duas opções de serviço diferem apenas na forma como a imagem é lançada: como um PyTorchJob do Kubernetes no SageMaker HyperPod, ou por meio de uma chamada à API CreateTrainingJob para um SageMaker Training Job. A tarefa de locomoção do H1 é a mesma do workshop NVIDIA Isaac Lab na AWS, que executa a carga de trabalho no Amazon Elastic Compute Cloud (Amazon EC2) e no AWS Batch. A migração para o SageMaker AI mantém o código de treinamento inalterado e adiciona clusters gerenciados, recuperação integrada de falhas e execução serverless de jobs de treinamento.
Um ponto importante sobre compatibilidade de hardware: o Isaac Sim é construído sobre o NVIDIA Omniverse e usa o Omniverse RTX Renderer, que exige GPUs com RT Cores de hardware. A família G de instâncias GPU da AWS é adequada para cargas de trabalho do Isaac Lab. A família P não é compatível, pois usa GPUs de data center sem RT Cores. Consulte a página de requisitos do Isaac Sim 5.1 para a lista completa de hardware suportado. Os exemplos usam ml.g6.12xlarge ao longo de todo o guia.
Configuração inicial: repositório e imagem Docker
Dois passos de configuração são compartilhados entre os dois fluxos: clonar o repositório e construir a imagem de treinamento.
git clone https://github.com/awslabs/awsome-distributed-ai.git
cd awsome-distributed-ai/3.test_cases/pytorch/nvidia-isaac-lab
Em seguida, defina as variáveis de ambiente, verifique ou crie o repositório no Amazon ECR, autentique-se, construa e faça o push da imagem:
export AWS_REGION=us-east-1 # your region
export ACCOUNT=$(aws sts get-caller-identity --query Account --output text)
O fluxo do HyperPod usa um cluster existente orquestrado pelo Amazon EKS, com um grupo de instâncias de dois nós ml.g6.12xlarge (4× NVIDIA L4 cada, 8 GPUs no total). O objetivo é um job de treinamento distribuído para a tarefa de locomoção do H1, com métricas ao vivo no SageMaker managed MLflow e os checkpoints resultantes gravados no FSx for Lustre.
Pré-requisitos do HyperPod
Cota de serviço suficiente para o tipo de instância GPU escolhido na região alvo. Solicite um aumento pelo AWS Service Quotas antes de criar ou escalar o cluster.
O script gera os seguintes arquivos: generated/storage.yaml (PersistentVolume e PersistentVolumeClaim para o FSx), generated/training-job.yaml (PyTorchJob do Kubeflow) e generated/viz-eks-webrtc-pod.yaml (pod de visualização via WebRTC, opcional).
Deploy do armazenamento e lançamento do treinamento
Quando o job inicia, o Kubeflow Training Operator injeta as variáveis de ambiente PyTorch distribuído (MASTER_ADDR, MASTER_PORT, RANK, WORLD_SIZE) em cada pod. O script de lançamento do contêiner as repassa ao torchrun, que gerencia o rendezvous e a configuração do grupo de processos. Com dois nós e 4 GPUs cada, o treinamento usa 8 GPUs no total. O manifesto também verifica no FSx a existência de um best_agent.pt de execuções anteriores e, se encontrado, retoma o treinamento a partir daquele ponto.
Rastreamento de experimentos com SageMaker managed MLflow
As métricas de treinamento, parâmetros de execução (tarefa, iterações, seed) e o diretório do checkpoint final são encaminhados para o Amazon SageMaker managed MLflow como store de experimentos persistente e pesquisável. Métricas de sistema como utilização de GPU e uso de CPU/memória são amostradas pela própria thread de background do MLflow. A habilitação do MLflow é opcional: deixar o MLFLOW_TRACKING_URI vazio (padrão) faz o script de treinamento ignorar todas as chamadas MLflow.
Treinamento com SageMaker Training Jobs
Os SageMaker Training Jobs executam a mesma imagem por um ciclo de vida diferente: cada job provisiona as instâncias de GPU solicitadas, baixa a imagem do Amazon ECR, executa o entrypoint, faz upload de tudo que o script copiou para /opt/ml/model/ como model.tar.gz para o caminho de saída no S3 e encerra as instâncias.
Pré-requisitos dos Training Jobs
Cota de serviço suficiente para o tipo de instância GPU. Solicite aumento pelo AWS Service Quotas.
Uma role IAM que o SageMaker possa assumir para o job de treinamento, com permissões para baixar do Amazon ECR, ler o entrypoint do S3 e gravar artefatos de volta no S3. Consulte a documentação de execution role do SageMaker.
Um bucket S3 para o script de entrypoint (entrada) e os artefatos de treinamento (saída).
boto3 instalado localmente (pip install boto3).
Geração e lançamento
Após configurar a seção sagemaker_training no config.yaml, execute o gerador e lance o job:
O launcher chama CreateTrainingJob com um nome de job com sufixo de timestamp, a imagem do Amazon ECR e a localização do entrypoint no S3. Em caso de sucesso, imprime o nome do job e um comando describe-training-job para monitorar o progresso.
Os logs de treinamento são transmitidos para o Amazon CloudWatch Logs no grupo /aws/sagemaker/TrainingJobs, com um stream de log por instância. A mesma integração com MLflow descrita para o HyperPod se aplica aos Training Jobs.
Visualização de políticas treinadas
O repositório inclui um pod de visualização para o SageMaker HyperPod que transmite a interface gráfica do Isaac Sim diretamente para um navegador via WebRTC, usando o mesmo volume FSx dos jobs de treinamento para que qualquer checkpoint produzido no HyperPod possa ser reproduzido.
Como o kubectl port-forward suporta apenas TCP e a mídia WebRTC exige UDP, o plugin krelay adiciona o encaminhamento UDP necessário. Para equipes que preferem um desktop Linux completo, o workshop NVIDIA Isaac Lab na AWS descreve como configurar uma instância Amazon EC2 GPU com NICE DCV para executar a mesma imagem interativamente via streaming de desktop remoto de baixa latência.
Considerações de custo e limpeza
As duas opções de computação têm perfis de custo diferentes. O SageMaker HyperPod é um cluster persistente: as instâncias são cobradas enquanto fazem parte do cluster. O FSx for Lustre cobra por hora por capacidade provisionada. Os SageMaker Training Jobs cobram apenas pelo tempo de execução de cada job — sem custo de computação ociosa entre execuções. Consulte as páginas de preços do SageMaker AI e do FSx for Lustre para as tarifas atuais.
Escale o grupo de instâncias GPU para zero entre sessões para pausar os custos de instância mantendo o cluster configurado, ou exclua o cluster inteiramente. Consulte Gerenciar um cluster SageMaker HyperPod. Os Training Jobs encerram automaticamente ao concluir ou falhar — nenhuma limpeza de computação é necessária.
Conclusão
À medida que as cargas de trabalho de Physical AI avançam para a produção, equipes de robótica precisam escalar o treinamento de políticas sem a sobrecarga operacional de gerenciar infraestrutura de computação. A solução publicada pela AWS demonstra como o SageMaker HyperPod e os SageMaker Training Jobs permitem executar treinamento distribuído do Isaac Lab em infraestrutura de GPU gerenciada, usando uma única imagem de contêiner e uma configuração compartilhada entre os dois modelos de computação.
O HyperPod oferece clusters de GPU persistentes com treinamento resiliente de longa duração. Os Training Jobs oferecem execuções efêmeras e sob demanda adequadas para experimentos e varreduras de hiperparâmetros. Ambos executam a mesma imagem e a mesma invocação do torchrun do trainer skrl — alternar entre eles é apenas uma mudança de configuração.
