Blog

  • Amazon Connect ganha oito novas métricas para medir desempenho de agentes de IA

    O que foi anunciado

    A AWS anunciou a disponibilização de oito novas métricas no Amazon Connect voltadas especificamente para monitorar e aprimorar o desempenho de agentes de Inteligência Artificial (IA) em interações com clientes. Entre as novidades, destacam-se métricas como taxa de sucesso de objetivos, pontuação de fidelidade e precisão na seleção de ferramentas.

    O que essas métricas permitem monitorar

    Com esse conjunto de indicadores, equipes que utilizam o Amazon Connect passam a ter visibilidade real sobre a qualidade das interações conduzidas por agentes de IA. Na prática, é possível acompanhar:

    • Se os agentes de IA conseguiram de fato resolver as solicitações dos clientes;
    • O nível de fidelidade das respostas geradas — incluindo a detecção de alucinações contextuais, ou seja, quando o agente produz informações incorretas ou inventadas;
    • A precisão com que o agente seleciona e utiliza as ferramentas disponíveis para cada situação;
    • O feedback direto dos clientes, por meio de avaliações do tipo curtir/não curtir, quando esse recurso estiver habilitado.

    Como acessar as novas métricas

    As oito novas métricas podem ser acessadas de três formas distintas:

    • Pelo painel de desempenho de agentes de IA do próprio Amazon Connect;
    • Via API GetMetricDataV2, para quem prefere integrar os dados a fluxos de análise personalizados;
    • Por meio do data lake zero-ETL, que facilita a integração com ferramentas de análise já existentes na organização — sem a necessidade de pipelines de transformação de dados.

    Disponibilidade

    O recurso já está disponível em todas as regiões da AWS onde o Amazon Connect com agentes de IA é suportado. Para consultar a documentação completa e entender como configurar o painel de desempenho, a AWS disponibilizou o Guia do Administrador do Amazon Connect. Quem quiser conhecer mais sobre a plataforma em geral pode acessar o site oficial do Amazon Connect.

    Por que isso importa

    Monitorar agentes de IA em produção ainda é um desafio para muitas equipes. Ter métricas nativas dentro da própria plataforma de atendimento reduz a complexidade operacional e permite que times de CX (Experiência do Cliente) e engenharia atuem com mais precisão na melhoria contínua dos fluxos automatizados. A detecção de alucinações, em especial, é um ponto crítico para garantir que o cliente receba respostas confiáveis — e agora isso pode ser rastreado diretamente no Amazon Connect.

    Fonte

    Amazon Connect now provides eight new metrics to measure and improve AI agent performance (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-connect-ai-agent-metrics/)

  • Amazon Bedrock AgentCore Gateway e Identity ganham suporte a egresso de VPC

    O que foi anunciado

    A AWS anunciou que o Amazon Bedrock AgentCore Gateway e o AgentCore Identity passam a oferecer suporte a egresso de Nuvem Privada Virtual (VPC). Com isso, aplicações baseadas em agentes de IA conseguem se comunicar de forma segura e controlada com recursos que estão rodando dentro da VPC do próprio cliente — sem precisar expor esses recursos à internet pública.

    Como o egresso de VPC funciona no AgentCore

    O suporte ao egresso de VPC está disponível em duas modalidades: gerenciada e autogerenciada. A maioria dos casos de uso é atendida pela configuração gerenciada, que a AWS provisiona e mantém automaticamente. Para cenários de rede mais complexos, os clientes têm a opção de configurar seus próprios recursos do VPC Lattice — o serviço de rede gerenciada da AWS para comunicação entre serviços.

    Um exemplo prático: com esse suporte, é possível invocar diretamente, a partir do AgentCore Gateway, servidores MCP hospedados em clusters do Elastic Kubernetes Service (EKS) que estejam rodando dentro de uma VPC privada. Isso amplia bastante as possibilidades de integração em arquiteturas corporativas que priorizam isolamento de rede.

    Novidades no AgentCore Identity

    O AgentCore Identity também recebe suporte a egresso de VPC, com foco específico em conectividade com Provedores de Identidade (IdPs) que rodam dentro da VPC do cliente. Esse suporte habilita duas capacidades importantes:

    • Validação de tokens de acesso de entrada: permite verificar tokens emitidos por um IdP privado antes de autorizar requisições recebidas pelo agente.
    • Obtenção de tokens para autenticação de saída: permite que o agente busque tokens diretamente no IdP privado para autenticar requisições que ele mesmo faz a outros serviços.

    Resolução de DNS privado

    Outro ponto relevante desse lançamento é o suporte à resolução de DNS privado para recursos de egresso VPC gerenciado, tanto no Gateway quanto no Identity. Isso significa que os recursos internos podem ser acessados pelos seus nomes de domínio privados, sem depender de IPs fixos ou configurações manuais adicionais.

    Disponibilidade por região

    O suporte a egresso de VPC no AgentCore Gateway e Identity está disponível em 14 regiões da AWS:

    • US East (Norte da Virgínia e Ohio)
    • US West (Oregon)
    • Canada (Central)
    • Asia Pacific (Mumbai, Seul, Singapura, Sydney e Tóquio)
    • Europe (Frankfurt, Irlanda, Londres, Paris e Estocolmo)

    Saiba mais e comece a usar

    Para quem quiser se aprofundar nas capacidades de egresso de VPC, a AWS disponibiliza a documentação do AgentCore Gateway e a documentação do AgentCore Identity. Para dar os primeiros passos de forma prática, o ponto de entrada recomendado é o AgentCore CLI.

    Fonte

    Amazon Bedrock AgentCore Gateway and Identity support VPC egress (https://aws.amazon.com/about-aws/whats-new/2024/04/agentcore-gateway-identity-vpc/)

  • Amazon SageMaker HyperPod passa a gerenciar automaticamente a topologia do Slurm

    Gerenciamento automático de topologia no SageMaker HyperPod

    A AWS anunciou uma melhoria significativa no Amazon SageMaker HyperPod: o serviço agora seleciona e mantém automaticamente a configuração ideal de topologia de rede para clusters Slurm, levando em conta os tipos de instâncias GPU presentes no cluster.

    Por que a topologia de rede importa no treinamento distribuído

    A topologia de rede tem impacto direto na performance do treinamento distribuído. Quando os jobs são alocados em nós que estão topologicamente próximos uns dos outros, a comunicação entre GPUs se torna mais rápida, as operações coletivas do NCCL ficam mais eficientes e o throughput geral do treinamento aumenta. Em outras palavras, a disposição física e lógica dos nós no cluster não é detalhe — ela define o quão bem os recursos de hardware são aproveitados.

    Como o HyperPod gerencia a topologia automaticamente

    Ao criar um cluster, o HyperPod inspeciona os tipos de instâncias presentes em todos os grupos de instâncias, identifica as características de rede e interconexão de cada tipo, e seleciona automaticamente o modelo de topologia mais adequado. O serviço suporta dois modelos principais:

    • Topologia em árvore (tree topology): indicada para instâncias com interconexões hierárquicas, como ml.p5.48xlarge, ml.p5e.48xlarge e ml.p5en.48xlarge.
    • Topologia em bloco (block topology): indicada para instâncias com conectividade uniforme de alta largura de banda, como ml.p6e-gb200.NVL72.

    Para clusters com tipos de instâncias mistos, o HyperPod seleciona automaticamente uma topologia compatível que funcione de forma coerente em todos os nós.

    Adaptação dinâmica ao longo do ciclo de vida do cluster

    Um dos pontos mais relevantes dessa novidade é a capacidade de adaptação contínua. À medida que o cluster passa por operações de escalonamento — seja para cima, para baixo ou por substituição de nós — o HyperPod atualiza a configuração de topologia automaticamente, sem necessidade de intervenção manual. Isso garante que a topologia sempre reflita o estado real do cluster, sem exigir atualizações em arquivos de configuração nem reconfigurações do Slurm.

    Como começar a usar

    Para aproveitar esse recurso, basta criar um cluster SageMaker HyperPod Slurm com os tipos de instâncias GPU suportados. O agendamento com consciência de topologia já vem habilitado por padrão e não requer nenhuma configuração adicional. O recurso está disponível em todas as regiões AWS onde o Amazon SageMaker HyperPod é suportado.

    Para mais detalhes sobre o agendamento com consciência de topologia, consulte a documentação oficial do Amazon SageMaker HyperPod.

    Fonte

    Amazon SageMaker HyperPod now supports automatic Slurm topology management (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-sagemaker-hyperpod-automatic-slurm-topology/)

  • Amazon SageMaker passa a suportar notebooks e agente de dados para domínios IdC

    O que mudou no SageMaker Unified Studio

    A AWS anunciou uma expansão importante no Amazon SageMaker Unified Studio: a partir de agora, os notebooks serverless (sem servidor) com agente de dados integrado também estão disponíveis para domínios que utilizam o AWS IAM Identity Center (IdC) para autenticação e gerenciamento de acesso.

    Antes dessa atualização, tanto o ambiente de notebooks quanto o agente de dados estavam disponíveis apenas em domínios IAM. Com essa mudança, equipes que já adotaram o IdC como mecanismo de autenticação passam a ter acesso ao mesmo ambiente de alta performance para cargas de trabalho de análise de dados e aprendizado de máquina (ML).

    O que são os notebooks serverless do SageMaker

    O notebook serverless do SageMaker Unified Studio funciona como um espaço de trabalho unificado para diferentes perfis técnicos — engenheiros de dados, analistas e cientistas de dados. Em um único ambiente interativo, é possível:

    • Executar consultas SQL
    • Rodar código Python
    • Processar grandes volumes de dados
    • Executar cargas de trabalho de ML
    • Criar visualizações

    A infraestrutura por trás desse ambiente é o Amazon Athena para Apache Spark, o que garante escalabilidade desde consultas SQL interativas até o processamento de dados em escala de petabytes.

    O papel do agente de dados com IA integrada

    Junto com os notebooks, o agente de dados com inteligência artificial (IA) integrada acelera o desenvolvimento ao gerar código e instruções SQL diretamente a partir de prompts em linguagem natural. Ou seja, o profissional descreve o que precisa em texto simples, e o agente sugere o código correspondente — guiando o usuário ao longo das tarefas.

    Essa combinação permite que SQL, Python e linguagem natural coexistam no mesmo workspace, eliminando a necessidade de alternar entre ferramentas diferentes dependendo do tipo de tarefa. Um exemplo prático: é possível começar explorando dados com SQL, avançar para análises mais complexas com Python, e ainda usar prompts em linguagem natural para gerar código automaticamente em qualquer etapa do processo.

    Disponibilidade

    Os recursos de notebook e agente de dados do SageMaker estão disponíveis em todas as regiões da AWS onde o Amazon SageMaker Unified Studio é suportado.

    Para saber mais, a AWS disponibiliza o guia do usuário de notebooks do SageMaker e o guia do usuário do agente de dados do SageMaker com detalhes completos sobre como utilizar esses recursos.

    Fonte

    Amazon SageMaker supports notebooks and data agent for IdC domains (https://aws.amazon.com/about-aws/whats-new/2026/04/amazon-sagemaker-idc/)

  • Do zero ao primeiro agente funcional em minutos: novidades no Amazon Bedrock AgentCore

    O problema que o AgentCore resolve

    Qualquer desenvolvedor que já tentou colocar um agente de IA em funcionamento sabe bem como é: antes de testar se o agente faz algo útil, você passa horas — ou dias — resolvendo problemas de infraestrutura. Precisa escolher um framework, escrever código de orquestração, conectar ferramentas, configurar autenticação, montar pipeline de deploy. Só então o agente consegue processar a primeira requisição de verdade.

    É trabalho necessário, mas não é o trabalho que diz se o agente vai ser bom. A AWS identificou esse gargalo e construiu o Amazon Bedrock AgentCore justamente para mudar essa equação — permitindo que times foquem na lógica do agente, não no encanamento de infraestrutura. O serviço já suportava frameworks populares como LangGraph, LlamaIndex, CrewAI e Strands Agents. Agora, a AWS anuncia novas capacidades que aprofundam essa proposta.

    Harness gerenciado: do zero ao agente em três etapas

    Todo agente precisa de uma camada de orquestração — o loop que chama o modelo, decide qual ferramenta acionar, repassa os resultados, gerencia a janela de contexto e lida com falhas. Para esse loop funcionar, existe uma infraestrutura de suporte: computação para hospedar o agente, sandbox para execução segura de código, conexões seguras com ferramentas, armazenamento persistente e recuperação de erros. Esse conjunto é o que a AWS chama de agent harness.

    Até agora, montar esse harness era a primeira tarefa de qualquer time — e consumia dias antes mesmo de o agente processar uma única requisição real. A nova funcionalidade de harness gerenciado no AgentCore substitui toda essa construção inicial por uma configuração direta. Você declara o agente e o coloca para rodar com apenas três chamadas de API, sem escrever código de orquestração.

    A ideia é simples: você define o que o agente faz — qual modelo usa, quais ferramentas pode chamar e quais instruções deve seguir. O AgentCore cuida de montar computação, ferramentas, memória, identidade e segurança para criar um agente funcional que pode ser testado em minutos. Trocar de modelo ou adicionar uma ferramenta vira uma mudança de configuração, não uma reescrita de código. É possível testar várias variações do agente em minutos apenas alterando parâmetros na chamada de API.

    Essa velocidade não sacrifica flexibilidade. O harness do AgentCore é alimentado pelo Strands Agents, o framework open source da AWS. Quando você precisar de lógica de orquestração personalizada, roteamento especializado ou coordenação entre múltiplos agentes, basta migrar da configuração para um harness definido em código — na mesma plataforma, com o mesmo isolamento por microVM e o mesmo pipeline de deploy.

    Outro ponto relevante: o AgentCore persiste o estado da sessão em um sistema de arquivos durável. Isso significa que agentes podem suspender uma tarefa no meio e retomá-la exatamente de onde pararam — tornando padrões de human-in-the-loop (humano no ciclo de decisão) viáveis sem nenhuma customização extra.

    A VTEX, empresa brasileira de tecnologia para e-commerce, já está entre os casos de uso mencionados pela AWS. Rodrigo Moreira, VP de Engenharia da VTEX, destacou que antes cada novo protótipo de agente exigia dias de código de orquestração e configuração de infraestrutura antes de validar uma ideia. Com o harness do AgentCore, trocar de modelo, adicionar uma ferramenta ou refinar instruções passa a ser uma mudança de configuração — e a validação de ideias cai de dias para minutos.

    AgentCore CLI: um único terminal do protótipo ao produção

    Outro obstáculo clássico no ciclo de vida de agentes é a transição do desenvolvimento local para a produção. Normalmente isso significa sair do editor, configurar um pipeline de deploy separado e lidar com um processo que tem pouco a ver com o fluxo usado para construir o agente.

    O novo AgentCore CLI unifica esse ciclo em um único terminal: prototipar, fazer deploy e operar o agente sem trocar de ferramenta. Você itera localmente e, quando o agente estiver pronto, faz o deploy sem montar um pipeline separado.

    O AgentCore suporta deploy via Infraestrutura como Código (IaC) com suporte ao CDK e ao Terraform (em breve). Isso garante que a configuração do agente seja reproduzível e versionada — o que você testou localmente é exatamente o que roda em produção.

    Skills para agentes de código: contexto que faz diferença

    Boa parte do desenvolvimento de agentes hoje acontece com o apoio de assistentes de código como Claude Code ou Kiro. Mas um assistente de código só é tão eficaz quanto o contexto que ele tem. Um servidor MCP (Protocolo de Contexto de Modelo) genérico pode dar acesso a APIs e documentação, mas não captura as boas práticas específicas de uma plataforma: quais padrões usar, como as capacidades se encaixam, qual é o caminho recomendado para tarefas comuns.

    As novas skills pré-construídas do AgentCore vão além do acesso bruto à API. Elas fornecem aos agentes de código conhecimento atualizado e curado sobre as melhores práticas do AgentCore — de forma que as sugestões recebidas reflitam como a plataforma deve ser usada, não apenas quais endpoints existem. O Kiro já inclui isso como um Power nativo. Plugins para Claude Code, Codex e Cursor chegam em breve.

    Disponibilidade e preços

    O harness gerenciado do AgentCore está disponível em prévia em quatro regiões AWS: US West (Oregon), US East (N. Virginia), Asia Pacific (Sydney) e Europe (Frankfurt). O AgentCore CLI e o sistema de arquivos persistente para agentes estão disponíveis em todas as regiões comerciais da AWS onde o AgentCore é oferecido. As skills para agentes de código devem estar disponíveis até o final de abril.

    O modelo de cobrança é baseado nos recursos consumidos, sem custo adicional pelo CLI, pelo harness ou pelas skills. Mais detalhes estão na página de preços do AgentCore. Para começar, a documentação do AgentCore cobre os primeiros passos.

    O que muda na prática

    A proposta do AgentCore é clara: a plataforma em que você prototipa é a mesma em que você roda em produção. À medida que o agente evolui, você adiciona avaliações, memória, conexões com ferramentas e políticas de controle — sem precisar rearquitetar nada. O foco se mantém na lógica do agente, não na infraestrutura que o sustenta.

    Fonte

    Get to your first working agent in minutes: Announcing new features in Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/get-to-your-first-working-agent-in-minutes-announcing-new-features-in-amazon-bedrock-agentcore/)

  • Amazon SageMaker Unified Studio agora suporta múltiplos espaços de código em projetos para domínios IAM

    O que mudou no SageMaker Unified Studio

    A AWS anunciou uma atualização relevante para o Amazon SageMaker Unified Studio: agora é possível criar e gerenciar múltiplos espaços de código (code spaces) dentro de um único projeto, para domínios com Gerenciamento de Identidade e Acesso (IAM). Essa mudança amplia consideravelmente a flexibilidade do ambiente de desenvolvimento para equipes de dados.

    Antes dessa atualização, cada projeto era limitado a apenas um espaço JupyterLab e um espaço Code Editor. Ou seja, quem precisava trabalhar em experimentos diferentes ao mesmo tempo dentro do mesmo projeto enfrentava uma barreira real de organização e isolamento de ambientes.

    O que os múltiplos espaços de código permitem

    Com o novo suporte a múltiplos espaços, cientistas de dados e engenheiros de machine learning podem agora trabalhar em paralelo em diferentes fluxos de trabalho — como transformação de dados de longa duração e treinamento de modelos — tudo dentro do mesmo projeto colaborativo, sem precisar alternar entre projetos distintos.

    Cada espaço de código criado conta com:

    • Seu próprio volume Amazon EBS (Elastic Block Store) persistente, garantindo que arquivos, dados e estado da sessão sejam preservados de forma independente;
    • Configurações individuais de computação e armazenamento, que podem ser ajustadas para cima ou para baixo conforme a necessidade de cada tarefa;
    • A possibilidade de pausar e retomar o espaço a qualquer momento;
    • Ambiente de execução customizável para cada caso de uso específico.

    Como os espaços podem ser acessados

    Os espaços de código podem ser abertos em abas dedicadas do navegador ou conectados a um ambiente de desenvolvimento local (IDE), caso o desenvolvedor prefira trabalhar com suas próprias ferramentas. Em ambos os casos, toda a funcionalidade é mantida — incluindo suporte ao Amazon Q no plano pago.

    Para quem esse recurso é mais útil

    A atualização é especialmente vantajosa para equipes que precisam de ambientes isolados para fluxos de trabalho paralelos, mas que ainda querem manter a colaboração dentro de um único projeto. É o caso típico de times que rodam experimentos simultâneos com diferentes configurações de hardware ou que separam etapas do pipeline de dados em ambientes distintos.

    Disponibilidade

    O recurso já está disponível em todas as regiões AWS onde o Amazon SageMaker Unified Studio opera. Para saber mais sobre como gerenciar espaços de código em projetos do SageMaker Unified Studio, a AWS disponibiliza a documentação oficial: Gerenciando Espaços de Código no Guia do Usuário do Amazon SageMaker.

    Fonte

    Amazon SageMaker Unified Studio now supports multiple code spaces within projects for IAM domains (https://aws.amazon.com/about-aws/whats-new/2026/04/sagemaker-code-spaces/)

  • Segurança multicloud de ponta a ponta: como funciona o AWS Security Hub Extended

    O problema que o Security Hub Extended tenta resolver

    Equipes de segurança modernas enfrentam um desafio que vai muito além das ameaças em si: o peso operacional de gerenciar dezenas de fornecedores ao mesmo tempo. Negociações de contrato, múltiplos ciclos de cobrança, integrações manuais entre ferramentas — tudo isso consome tempo que deveria estar sendo dedicado à gestão de riscos reais.

    Além disso, o modelo tradicional de aquisição de soluções de segurança forçava as organizações a assinar contratos plurianuais baseados apenas em testes de prova de conceito (PoC) e estimativas de uso anual. Ou seja, era preciso comprometer orçamento antes de validar se a solução funcionaria em escala real no ambiente da empresa.

    É exatamente esse cenário que a AWS busca transformar com o AWS Security Hub Extended: uma oferta de segurança empresarial completa que reúne serviços nativos da AWS com soluções de parceiros cuidadosamente selecionados, entregando procurement unificado, cobrança consolidada e operações integradas.

    O que é o Security Hub Extended

    O AWS Security Hub já consolidava análise de ameaças do Amazon GuardDuty, gestão de vulnerabilidades do Amazon Inspector e descoberta de dados sensíveis do Amazon Macie, correlacionando esses sinais com findings de exposição para determinar risco geral, alcançabilidade e assumibilidade de recursos.

    O Security Hub Extended vai além: ele estende essas operações de segurança unificadas para toda a organização, incluindo ambientes multicloud, on-premises e endpoints, por meio de soluções de parceiros curados integradas diretamente na experiência do Security Hub. Não há console separado para gerenciar — tudo acontece no mesmo lugar onde você já administra a segurança da sua organização.

    Os parceiros do lançamento inicial foram selecionados pelos próprios clientes com base em valor comprovado, e incluem: 7AI, Britive, CrowdStrike, Cyera, Island, Noma, Okta, Oligo, Opti, Proofpoint, SailPoint, Splunk, Upwind e Zscaler.

    Como começar com o Security Hub Extended

    Para quem ainda não usa o Security Hub, o processo de onboarding é direto: basta acessar o AWS Management Console, buscar por Security Hub e seguir o fluxo de configuração inicial. O primeiro passo é designar uma conta de administrador delegado (Delegated Administrator — DA) da organização AWS, o que permite habilitar e gerenciar o Security Hub de forma centralizada em todas as contas e regiões AWS da organização a partir de um único ponto. Para mais detalhes sobre esse processo, a AWS disponibiliza a Introdução ao AWS Security Hub.

    A partir da interface centralizada de configuração, é possível habilitar capacidades de detecção e resposta para toda a organização, definir configurações granulares por unidade organizacional ou conta-membro, selecionar regiões específicas e ativar ou desativar funcionalidades individualmente.

    Quem já usa o Security Hub pode navegar diretamente para a seção do plano Extended. Ela fica no painel de navegação à esquerda, em Management, dentro da conta do administrador delegado — e só fica visível a partir dessa conta.

    Entendendo riscos por meio de caminhos de ataque

    Um dos recursos centrais do Security Hub é o motor de correlação de riscos, que identifica exposições potenciais ao cruzar ameaças, vulnerabilidades e configurações incorretas, revelando como esses fatores se conectam e podem levar ao comprometimento de recursos críticos.

    Imagem original — fonte: Aws

    A visualização de caminhos de ataque (attack path) expõe causas-raiz e o raio de explosão (blast radius) — ou seja, o impacto potencial caso um agente malicioso explore uma vulnerabilidade. Em vez de tratar sintomas isolados, a equipe de segurança pode focar na causa original do problema. Por exemplo, atualizar a configuração de um único security group pode eliminar um caminho de ataque inteiro, cortando todas as exposições downstream associadas a ele.

    Descobrindo e assinando soluções de parceiros

    O plano Extended traz soluções de terceiros curadas diretamente para dentro da experiência do Security Hub. Para adotar uma solução de parceiro, basta selecionar View Product para iniciar um fluxo automatizado de onboarding. Dependendo da solução, o usuário é direcionado ao console do parceiro ou recebe orientações para que o parceiro conduza o processo de ativação conforme o ambiente específico.

    Imagem original — fonte: Aws

    A cobrança só começa após a ativação completa na solução do parceiro, e já entra automaticamente na fatura unificada da AWS — sem necessidade de nenhuma ação adicional. Para quem já usa alguma das soluções dos parceiros, a transição para o Security Hub Extended não interrompe os serviços em uso. A diferença é que, em vez de receber faturas separadas para cada parceiro além do Amazon Inspector, GuardDuty e Security Hub, tudo passa a aparecer em uma única fatura consolidada.

    Precificação transparente e sem compromissos iniciais

    Diferente dos modelos tradicionais que exigem negociações longas, acordos de preço privados e compromissos plurianuais, o Security Hub Extended adota um modelo de preços mensais no modelo pay-as-you-go, com total transparência. Cada solução de parceiro exibe seus valores de forma clara. Como referência, o Cloud Security da Upwind custa US$ 3,75 por recurso por mês, e o Identity Security da Okta custa US$ 20 por usuário por mês.

    Todas as ofertas do Security Hub Extended são elegíveis para os descontos do Programa de Desconto Empresarial (Enterprise Discount Program — EDP) da AWS, que são aplicados automaticamente. Se a organização já possui um acordo de desconto empresarial com a AWS, esses descontos se estendem automaticamente às soluções do Extended, reduzindo ainda mais o custo efetivo.

    Após validar que uma solução funciona em escala no ambiente real, a organização pode então alinhar sua estratégia com fornecedores e assinar compromissos de longo prazo para obter condições de preço ainda mais favoráveis — mas sem a pressão de fazer isso antes de ter certeza.

    Operações unificadas com OCSF

    O Security Hub Extended unifica as operações de segurança ao consolidar findings da AWS e das soluções de parceiros em um único fluxo. Todos os findings utilizam o Open Cybersecurity Schema Framework (OCSF) — uma estrutura de esquema aberto para cibersegurança — garantindo consistência sem a necessidade de processos complexos de normalização, transformação ou pipelines de Extração, Transformação e Carga (ETL).

    Na prática, ao implantar soluções como CrowdStrike, Noma e Upwind junto com Splunk e 7AI por meio do Security Hub Extended, os findings de segurança fluem automaticamente para o Security Hub e são roteados diretamente para o Splunk e o 7AI, todos no formato OCSF. O resultado é que a equipe de segurança pode se concentrar em responder a ameaças — não em gerenciar pipelines de dados ou integrações manuais.

    A visão de segurança full-stack

    O Security Hub Extended representa uma mudança na forma como as organizações descobrem, adquirem e consturam programas de segurança abrangentes. Em vez de gerenciar dezenas de relacionamentos com fornecedores, negociar contratos separados e integrar ferramentas díspares manualmente, a proposta é simplificar tudo em cinco pilares:

    • Um processo de procurement centralizado via AWS
    • Uma fatura com preços competitivos e transparentes no modelo pay-as-you-go
    • Um console para operações de segurança unificadas
    • Um canal de suporte para clientes do AWS Enterprise Support
    • Um esquema (OCSF) para todos os findings de segurança

    O objetivo declarado é reduzir o risco de segurança, melhorar a produtividade das equipes e criar uma abordagem mais coesa para operações de segurança em toda a empresa — abrangendo endpoint, identidade, e-mail, rede, dados, browser, nuvem, IA e operações de segurança.

    Disponibilidade

    O Security Hub Extended está disponível globalmente em todas as regiões comerciais da AWS onde o Security Hub está disponível. A AWS também publicou um vídeo de demonstração explicando como o Security Hub Extended funciona na prática. Feedbacks podem ser enviados pelo AWS re:Post na categoria de Segurança ou por meio dos canais de suporte da AWS.

    Fonte

    A technical walkthrough of multicloud full-stack security using AWS Security Hub Extended (https://aws.amazon.com/blogs/security/a-technical-walkthrough-of-multicloud-full-stack-security-using-aws-security-hub-extended/)

  • Melhorias nas Regras Gerenciadas do AWS Network Firewall via Parceiros do AWS Marketplace

    O que mudou no AWS Network Firewall

    A AWS anunciou expansões importantes nas Regras Gerenciadas (Managed Rules) do AWS Network Firewall, disponibilizadas por parceiros do AWS Marketplace. A novidade traz otimizações nos grupos de regras que agora suportam até 10 milhões de indicadores de nomes de domínio e até 1 milhão de endereços IP por grupo — um salto significativo em capacidade de proteção para workloads na nuvem.

    O que cada parceiro está entregando

    Três parceiros lideram as expansões anunciadas:

    • Infoblox: amplia os indicadores de nomes de domínio para proteger workloads contra domínios de risco crítico e alto.
    • Lumen: introduz novos grupos de regras focados em bloquear ataques de comando e controle (command and control).
    • ThreatSTOP: adiciona regras gerenciadas para conformidade com sanções do Escritório de Controle de Ativos Estrangeiros — OFAC (Office of Foreign Assets Control) — e expande a cobertura de conformidade global com novas regras para sanções da União Europeia, Japão e Nações Unidas.

    Por que isso importa para equipes de segurança

    Essas melhorias permitem que as equipes acessem inteligência de ameaças mais rica e abrangente diretamente dentro do AWS Network Firewall, sem precisar gerenciar feeds de ameaças manualmente. O resultado prático é uma proteção mais rápida e precisa contra ameaças emergentes — seja para bloquear domínios maliciosos em escala, defender a infraestrutura contra ataques de comando e controle ou aplicar políticas de conformidade baseadas em sanções internacionais.

    As regras gerenciadas ficam prontas para implantação e são atualizadas continuamente pelos parceiros, reduzindo a carga operacional das equipes de segurança.

    Parceiros disponíveis e expansão regional

    Além de Infoblox, Lumen e ThreatSTOP, as regras gerenciadas para o AWS Network Firewall também estão disponíveis por meio de outros parceiros do AWS Marketplace: Check Point, Fortinet, Rapid7 e Trend Micro.

    A AWS também expandiu a disponibilidade regional dos grupos de regras do Marketplace para 9 novas regiões:

    • Ásia-Pacífico (Jacarta)
    • Ásia-Pacífico (Hyderabad)
    • Ásia-Pacífico (Melbourne)
    • Ásia-Pacífico (Malásia)
    • Canadá Oeste (Calgary)
    • Europa (Zurique)
    • Europa (Espanha)
    • Israel (Tel Aviv)
    • México (Central)

    Como começar

    Para explorar as regras disponíveis, o caminho é acessar o console do AWS Network Firewall ou navegar pelas opções no AWS Marketplace. Para mais detalhes técnicos, a AWS disponibiliza a página do produto AWS Network Firewall e a documentação oficial do serviço.

    Fonte

    Enhancements to AWS Network Firewall Managed Rules from AWS Marketplace Partners (https://aws.amazon.com/about-aws/whats-new/2026/04/marketplace-managed-rules-enhancements/)

  • Amazon EC2 anuncia configurações de visibilidade de recursos gerenciados

    O que mudou no Amazon EC2

    A AWS anunciou uma novidade importante para quem trabalha com o Amazon EC2: agora é possível controlar se os recursos provisionados por ofertas de instâncias gerenciadas aparecem ou não nas visualizações do console do EC2 e nas operações de listagem via API.

    O que são instâncias gerenciadas no EC2

    As Instâncias Gerenciadas do Amazon EC2 (Amazon EC2 Managed Instances) são instâncias provisionadas e administradas por um provedor de serviço designado — como o Amazon EKS, o Amazon ECS, o AWS Lambda ou o Amazon Workspaces. Nesses casos, a própria AWS assume a responsabilidade pela configuração, aplicação de patches e monitoramento de saúde dessas instâncias, além de outros recursos associados, como volumes EBS, snapshots e Interfaces de Rede.

    Qual era o problema antes dessa mudança

    Até agora, por padrão, esses recursos gerenciados apareciam misturados com os recursos autogerenciados nas respostas de API e nos respectivos consoles. Isso gerava confusão, já que esses recursos são de responsabilidade da AWS — e não do time que opera a conta. Ver instâncias, volumes e snapshots que você não criou e não precisa gerenciar no meio da sua lista de recursos não é o ideal para quem quer ter clareza sobre o que está sob sua responsabilidade.

    Como funciona a nova configuração de visibilidade

    Com as novas configurações de visibilidade de recursos gerenciados (Managed resource visibility settings), qualquer novo recurso gerenciado passa a ficar oculto por padrão nas visualizações do console e nas respostas de APIs como o describe-instances. Essa mudança foi pensada para alinhar melhor a experiência do usuário ao modelo de responsabilidade compartilhada — afinal, se a AWS gerencia aquele recurso, faz sentido que ele não polua a visão de quem está gerenciando os próprios recursos.

    A configuração pode ser feita diretamente pelo console do Amazon EC2 ou por meio da AWS CLI. Para saber mais sobre como configurar essa funcionalidade, a AWS disponibiliza o Guia do Usuário do Amazon EC2 com todos os detalhes sobre as configurações de visibilidade de recursos gerenciados.

    Por que isso importa para o seu ambiente

    Para equipes que utilizam serviços como EKS ou ECS em larga escala, a quantidade de recursos gerenciados automaticamente pela AWS pode ser expressiva. Ter esses recursos aparecendo lado a lado com os recursos autogerenciados dificulta auditorias, inventários e até a identificação de anomalias. Com essa novidade, a visão do console e das APIs fica mais limpa e representativa do que realmente está sob gestão do time.

    Fonte

    Amazon EC2 announces Managed resource visibility settings (https://aws.amazon.com/about-aws/whats-new/2026/04/ec2-managed-resource-visibility/)

  • Transcrição de áudio multilíngue em escala com Parakeet-TDT e AWS Batch

    O problema de custo em transcrição de áudio em escala

    Muitas organizações lidam com volumes crescentes de áudio: bibliotecas de mídia para arquivamento, gravações de contact center, dados de treinamento para Inteligência Artificial (IA) ou vídeos sob demanda que precisam de legendas. Quando esses volumes crescem, os custos de serviços gerenciados de Reconhecimento Automático de Fala (ASR, do inglês Automatic Speech Recognition) passam a ser o principal limitador de escala.

    Para endereçar esse desafio, a AWS publicou um guia mostrando como combinar o modelo NVIDIA Parakeet-TDT-0.6B-v3 com o AWS Batch em instâncias aceleradas por GPU. O resultado é um pipeline capaz de transcrever áudio em escala por frações de centavo por hora de áudio processado.

    O modelo Parakeet-TDT-0.6B-v3

    Lançado em agosto de 2025, o Parakeet-TDT-0.6B-v3 é um modelo open-source multilíngue de ASR desenvolvido pela NVIDIA. Ele usa uma arquitetura chamada Token-and-Duration Transducer (TDT), que prevê simultaneamente os tokens de texto e suas durações — o que permite ao modelo pular silêncios e processamentos redundantes de forma inteligente, atingindo velocidades de inferência muito superiores ao tempo real.

    De acordo com as métricas publicadas pela NVIDIA, o modelo mantém uma Taxa de Erro por Palavra (WER, do inglês Word Error Rate) de 6,34% em condições limpas e 11,66% de WER a 0 dB de Relação Sinal-Ruído (SNR, do inglês Signal-to-Noise Ratio). Ele também suporta áudios de até três horas no modo de atenção local.

    Os 25 idiomas europeus suportados incluem: búlgaro, croata, tcheco, dinamarquês, holandês, inglês, estoniano, finlandês, francês, alemão, grego, húngaro, italiano, letão, lituano, maltês, polonês, português, romeno, eslovaco, esloveno, espanhol, sueco, russo e ucraniano. Isso elimina a necessidade de modelos separados ou configurações específicas por idioma ao atender economias europeias internacionais.

    Para implantação na AWS, o modelo requer instâncias com GPU e no mínimo 4 GB de VRAM, embora 8 GB ofereçam melhor desempenho. As instâncias G6 (GPUs NVIDIA L4) apresentam a melhor relação custo-desempenho para cargas de inferência. O modelo também funciona bem em G5 (A10G), G4dn (T4) e, para máximo throughput, P5 (H100) ou P4 (A100).

    Arquitetura da solução

    O fluxo começa quando um arquivo de áudio é enviado para um bucket do Amazon Simple Storage Service (Amazon S3). Esse upload dispara uma regra do Amazon EventBridge, que submete um job ao AWS Batch. O Batch provisiona os recursos de computação com GPU, e as instâncias provisionadas puxam a imagem de container — com o modelo já em cache — do Amazon Elastic Container Registry (Amazon ECR). O script de inferência baixa e processa o arquivo de áudio, e depois envia o transcript em JSON com timestamps para um bucket S3 de saída.

    A arquitetura escala a zero quando ociosa, ou seja, custos são gerados apenas durante a computação ativa. Para uma análise aprofundada dos componentes arquiteturais gerais, a AWS referencia o post anterior sobre transcrição de áudio com Whisper usando AWS Batch e AWS Inferentia.

    Pré-requisitos

    Construindo a imagem de container

    O repositório inclui um Dockerfile que constrói uma imagem de container otimizada para performance de inferência. A imagem usa o Amazon Linux 2023 como base, instala o Python 3.12 e faz o cache do modelo Parakeet-TDT-0.6B-v3 durante o build — eliminando a latência de download em tempo de execução:

    FROM public.ecr.aws/amazonlinux/amazonlinux:2023
    WORKDIR /app
    
    # Install system dependencies, Python 3.12, and ffmpeg
    RUN dnf update -y && \
        dnf install -y gcc-c++ python3.12-devel tar xz && \
        ln -sf /usr/bin/python3.12 /usr/local/bin/python3 && \
        python3 -m ensurepip && \
        python3 -m pip install --no-cache-dir --upgrade pip && \
        dnf clean all && rm -rf /var/cache/dnf
    
    # Install Python dependencies and pre-cache the model
    COPY ./requirements.txt requirements.txt
    RUN pip install -U --no-cache-dir -r requirements.txt && \
        rm -rf ~/.cache/pip /tmp/pip* && \
        python3 -m compileall -q /usr/local/lib/python3.12/site-packages
    
    COPY ./parakeet_transcribe.py parakeet_transcribe.py
    
    # Cache model during build to eliminate runtime download
    RUN python3 -c "from nemo.collections.asr.models import ASRModel; \
        ASRModel.from_pretrained('nvidia/parakeet-tdt-0.6b-v3')"
    
    CMD ["python3", "parakeet_transcribe.py"]

    Enviando a imagem para o Amazon ECR

    O repositório inclui um script updateImage.sh que detecta o ambiente (CodeBuild ou EC2), constrói a imagem, cria um repositório ECR se necessário, habilita o escaneamento de vulnerabilidades e faz o push da imagem. Para executá-lo:

    ./updateImage.sh

    Implantando a solução

    A solução usa um template do AWS CloudFormation (deployment.yaml) para provisionar a infraestrutura. O script buildArch.sh automatiza a implantação detectando a Região AWS, coletando informações de VPC, sub-redes e grupos de segurança, e implantando a stack do CloudFormation:

    ./buildArch.sh

    Internamente, esse script executa:

    aws cloudformation deploy --stack-name batch-gpu-audio-transcription \
      --template-file ./deployment.yaml \
      --capabilities CAPABILITY_IAM \
      --region ${AWS_REGION} \
      --parameter-overrides VPCId=${VPC_ID} SubnetIds="${SUBNET_IDS}" \
      SGIds="${SecurityGroup_IDS}" RTIds="${RouteTable_IDS}"

    O template do CloudFormation cria: o ambiente de computação do AWS Batch com instâncias GPU G6 e G5; uma fila de jobs; uma definição de job referenciando a imagem ECR; buckets S3 de entrada e saída com notificações do EventBridge habilitadas; uma regra do EventBridge que dispara um job do Batch no upload ao S3; configuração do agente do Amazon CloudWatch para monitoramento de GPU, CPU e memória; e Funções de Gerenciamento de Identidade e Acesso (IAM, do inglês Identity and Access Management) com políticas de privilégio mínimo.

    O AWS Batch permite selecionar imagens Amazon Linux 2023 com GPU especificando ImageType: ECS_AL2023_NVIDIA na configuração do ambiente de computação.

    Usando instâncias Spot para reduzir ainda mais os custos

    As instâncias Amazon EC2 Spot permitem executar cargas de trabalho na capacidade ociosa da EC2 com descontos de até 90%, dependendo do tipo de instância. Para habilitá-las, basta modificar o ambiente de computação no deployment.yaml:

    DefaultComputeEnv:
      Type: AWS::Batch::ComputeEnvironment
      Properties:
        Type: MANAGED
        State: ENABLED
        ComputeResources:
          AllocationStrategy: SPOT_PRICE_CAPACITY_OPTIMIZED
          Type: SPOT
          BidPercentage: 100
          InstanceTypes:
            - "g6.xlarge"
            - "g6.2xlarge"
            - "g5.xlarge"
          MinvCpus: !Ref DefaultCEMinvCpus
          MaxvCpus: !Ref DefaultCEMaxvCpus
          # ... remaining configuration unchanged

    Isso pode ser ativado passando --parameter-overrides UseSpotInstances=Yes ao executar o aws cloudformation deploy. A estratégia SPOT_PRICE_CAPACITY_OPTIMIZED seleciona pools de instâncias Spot com menor probabilidade de interrupção e menor preço. Diversificar os tipos de instância (G6 xlarge, G6 2xlarge, G5 xlarge) melhora a disponibilidade Spot. Definir MinvCpus: 0 garante que o ambiente escale a zero quando ocioso. Como os jobs de ASR são stateless e idempotentes, eles são ideais para Spot — e se uma instância for reclamada, o AWS Batch automaticamente tenta novamente o job (configurado com até 2 tentativas na definição do job).

    Gerenciando memória para áudios longos

    O consumo de memória do modelo Parakeet-TDT escala linearmente com a duração do áudio. O encoder Fast Conformer precisa gerar e armazenar representações de features para todo o sinal de áudio — dobrar a duração do áudio dobra aproximadamente o uso de VRAM. Com atenção completa, o modelo consegue processar até 24 minutos com 80 GB de VRAM.

    A NVIDIA endereça isso com um modo de atenção local que suporta até 3 horas de áudio em um A100 de 80 GB:

    # Enable local attention for long audio
    asr_model.change_attention_model("rel_pos_local_attn", [128, 128])
    asr_model.change_subsampling_conv_chunking_factor(1)  # auto select
    asr_model.transcribe(["input_audio.wav"])

    Esse modo pode apresentar uma leve queda de precisão — recomenda-se testar no seu caso de uso específico.

    Inferência em streaming com buffer para áudios muito longos

    Para áudios que excedem 3 horas, ou para processar áudios longos de forma econômica em hardware padrão como uma instância g6.xlarge, a solução usa inferência em streaming com buffer. Adaptada do exemplo de inferência em streaming do NVIDIA NeMo, essa técnica processa o áudio em chunks sobrepostos em vez de carregar o contexto completo na memória.

    A configuração utiliza chunks de 20 segundos com 5 segundos de contexto à esquerda e 3 segundos de contexto à direita para manter a qualidade da transcrição nas fronteiras dos chunks. Reduzir o tamanho do chunk aumenta o tempo de processamento, então é recomendado experimentar para encontrar a configuração ideal:

    # Streaming inference loop
    while left_sample < audio_batch.shape[1]:
        # add samples to buffer
        chunk_length = min(right_sample, audio_batch.shape[1]) - left_sample
        # [Logic to manage buffer and flags omitted for brevity]
        buffer.add_audio_batch_(...)
        # Encode using full buffer [left-chunk-right]
        encoder_output, encoder_output_len = asr_model(
            input_signal=buffer.samples,
            input_signal_length=buffer.context_size_batch.total(),
        )
        # Decode only chunk frames (constant memory usage)
        chunk_batched_hyps, _, state = decoding_computer(...)
        # Advance sliding window
        left_sample = right_sample
        right_sample = min(right_sample + context_samples.chunk, audio_batch.shape[1])

    Processar o áudio em chunks de tamanho fixo desacopla o uso de VRAM da duração total do áudio — uma única instância g6.xlarge consegue processar um arquivo de 10 horas com o mesmo footprint de memória de um arquivo de 10 minutos. Para implantar com streaming habilitado, basta definir o parâmetro EnableStreaming=Yes:

    aws cloudformation deploy \
      --stack-name batch-gpu-audio-transcription \
      --template-file ./deployment.yaml \
      --capabilities CAPABILITY_IAM \
      --parameter-overrides EnableStreaming=Yes \
      VPCId=your-vpc-id SubnetIds=your-subnet-ids SGIds=your-sg-ids RTIds=your-rt-ids

    Testes, monitoramento e resultados

    Para validar a solução em escala, foram processados 1.000 arquivos de áudio idênticos de 50 minutos — gravações de uma conferência de imprensa pré-voo da NASA — distribuídos em 100 instâncias g6.xlarge, cada uma processando 10 arquivos.

    A implantação inclui uma configuração do agente do Amazon CloudWatch que coleta métricas de utilização de GPU, consumo de energia, uso de VRAM, utilização de CPU, consumo de memória e uso de disco em intervalos de 10 segundos. Essas métricas aparecem no namespace CWAgent, permitindo a criação de dashboards para monitoramento em tempo real.

    Desempenho e análise de custos

    O modelo Parakeet-TDT-0.6B-v3 atingiu uma velocidade de inferência bruta de 0,24 segundos por minuto de áudio. Considerando o overhead completo do pipeline (carregamento do modelo, carregamento do áudio, pré e pós-processamento), os resultados do benchmark em uma instância g6.xlarge foram:

    • Duração do áudio: 3 horas e 25 minutos (205 minutos)
    • Duração total do job: 100 segundos
    • Velocidade efetiva de processamento: 0,49 segundos por minuto de áudio

    Em termos de custo, com base nos preços da instância g6.xlarge na região us-east-1:

    • On-Demand (~$0,805/hora): aproximadamente $0,00011 por minuto de áudio
    • Spot Instances (~$0,374/hora): aproximadamente $0,00005 por minuto de áudio

    Os preços são estimativas com base nas taxas da us-east-1 no momento da publicação original. Os preços Spot variam por Zona de Disponibilidade e estão sujeitos a mudanças.

    Esses números evidenciam a vantagem econômica da abordagem self-hosted para cargas de trabalho de alto volume em comparação com serviços gerenciados de API.

    Limpeza dos recursos

    Para evitar cobranças futuras, é necessário excluir os recursos criados pela solução: esvaziar todos os buckets S3 (entrada, saída e logs) e deletar a stack do CloudFormation:

    aws cloudformation delete-stack --stack-name batch-gpu-audio-transcription

    Opcionalmente, remova o repositório ECR e as imagens de container. Para instruções detalhadas, consulte a seção de limpeza do README do repositório.

    Conclusão

    A combinação do modelo NVIDIA Parakeet-TDT-0.6B-v3 com o AWS Batch e as instâncias EC2 Spot resulta em um pipeline de transcrição de áudio capaz de processar em escala por frações de centavo por hora. Com suporte a 25 idiomas europeus — incluindo português — e detecção automática de idioma, a solução elimina a necessidade de modelos separados por idioma. A técnica de inferência em streaming com buffer estende essa capacidade para áudios de qualquer duração em hardware padrão, e a arquitetura orientada a eventos escala automaticamente do zero para lidar com cargas de trabalho variáveis.

    O código de exemplo está disponível no repositório GitHub para quem quiser explorar e implementar a solução.

    Fonte

    Cost-effective multilingual audio transcription at scale with Parakeet-TDT and AWS Batch (https://aws.amazon.com/blogs/machine-learning/cost-effective-multilingual-audio-transcription-at-scale-with-parakeet-tdt-and-aws-batch/)