Category: Uncategorized

  • Comunicação bidirecional em tempo real para agentes de IA: a nova capacidade do Amazon Bedrock AgentCore

    Conversas naturais em IA: o desafio da engenharia em tempo real

    Construir conversas de voz naturais com agentes de IA exige infraestrutura complexa e uma quantidade considerável de código das equipes de engenharia. As interações baseadas em texto entre usuários e agentes seguem um padrão tradicional de turnos: o usuário envia uma solicitação completa, aguarda o agente processar a informação e recebe uma resposta integral antes de prosseguir. Este modelo funciona bem para muitos cenários, mas não replica a fluidez das conversas humanas.

    O streaming bidirecional muda essa dinâmica ao estabelecer uma conexão persistente que transmite dados simultânea e continuamente em ambas as direções. A Plataforma AgentCore Runtime do Amazon Bedrock agora oferece suporte nativo para esse tipo de comunicação em tempo real entre usuários e agentes de IA, permitindo que os agentes escutem a entrada do usuário enquanto geram respostas simultaneamente. Isso cria um fluxo conversacional muito mais natural, especialmente adequado para interações multimodais, como conversas com visão e voz.

    Capacidades habilitadas pelo streaming bidirecional

    Com o streaming bidirecional, os agentes de IA ganham habilidades que se aproximam da conversação humana. Um agente de voz bidirecional consegue conduzir diálogos falados com a fluidez natural de uma conversa entre pessoas, permitindo que os usuários interrompam, esclareçam dúvidas ou mudem de assunto sem pausas incômodas.

    Esses agentes processam entrada e saída de áudio em streaming simultaneamente mantendo o estado da conversa. A capacidade de começar a responder enquanto ainda recebe entrada do usuário, lidar com interrupções no meio da conversa e ajustar respostas com base em feedback em tempo real representa um avanço significativo em relação aos sistemas baseados em turnos.

    Implementar essa infraestrutura do zero exigiria gerenciar conexões persistentes de baixa latência, lidar com múltiplos fluxos de áudio concorrentes, preservar contexto entre trocas de mensagens e escalar várias conversas simultaneamente. Estimativas indicam que desenvolver essas capacidades exigir meses de esforço de engenharia e expertise especializada em sistemas em tempo real.

    O papel do AgentCore Runtime

    A Plataforma AgentCore Runtime do Amazon Bedrock resolve esses desafios ao oferecer um ambiente de hospedagem seguro, sem servidores (serverless) e propositalmente construído para implantar e executar agentes de IA. Developers não precisam mais construir e manter infraestrutura complexa de streaming por conta própria — a plataforma gerencia toda a complexidade subjacente das conexões, ordenação de mensagens e manutenção do estado conversacional.

    Fundamentos técnicos do streaming bidirecional

    O protocolo WebSocket

    O streaming bidirecional utiliza o protocolo WebSocket, que oferece comunicação full-duplex (bidireção completa) sobre uma única conexão TCP. Quando estabelecida, a conexão cria um canal persistente onde dados fluem continuamente em ambas as direções. Este protocolo possui amplo suporte em clientes diversos — navegadores, aplicações móveis e ambientes de servidor — tornando-o acessível para cenários variados de implementação.

    Uma vez que a conexão é estabelecida, o agente consegue receber a entrada do usuário como um fluxo enquanto simultaneamente envia fragmentos de resposta de volta. O AgentCore Runtime gerencia a infraestrutura subjacente que trata de conexão, ordenação de mensagens e manutenção do estado conversacional através da troca bidirecional, eliminando a necessidade de desenvolvedores construírem infraestrutura de streaming customizada ou gerenciarem as complexidades de fluxos de dados concorrentes.

    Conversa de voz versus interações de texto

    Conversas de voz diferem fundamentalmente de interações baseadas em texto em relação às expectativas de fluidez natural. Quando conversam com um agente de voz, os usuários esperam a mesma dinâmica de conversa que experimentam com humanos: a capacidade de interromper para se corrigir, interjeccionar esclarecimentos no meio de uma resposta, ou redirecionar a conversa sem pausas constrangedoras.

    O streaming bidirecional possibilita que agentes de voz processem áudio recebido enquanto geram respostas, detectem interrupções e ajustem comportamento em tempo real. O agente mantém contexto conversacional ao longo dessas interações, preservando o fio do diálogo mesmo conforme a conversa muda de direção. Essa capacidade transforma agentes de voz de sistemas baseados em turnos para um parceiro conversacional verdadeiramente responsivo.

    Além de conversas de voz

    O streaming bidirecional viabiliza diversos padrões de interação além de vozes. Sessões interativas de depuração permitem que desenvolvedores guiem agentes através de resolução de problemas em tempo real, fornecendo feedback conforme o agente explora soluções. Agentes colaborativos podem trabalhar ao lado de usuários em tarefas compartilhadas, recebendo entrada contínua enquanto o trabalho avança em vez de aguardar instruções completas. Agentes multimodais conseguem processar vídeo em streaming ou dados de sensores enquanto simultaneamente fornecedm análise e recomendações. Operações assíncronas de longa duração podem processar tarefas ao longo de minutos ou horas enquanto transmitem resultados incrementais aos clientes.

    Implementação de WebSocket

    Configuração básica

    Para criar uma implementação de WebSocket no AgentCore Runtime, alguns padrões devem ser seguidos. Primeiramente, seus contêineres devem implementar endpoints de WebSocket na porta 8080 no caminho /ws, alinhado com práticas padrão de servidores WebSocket. Esse endpoint de WebSocket habilitará um único contêiner de agente a servir tanto a API tradicional InvokeAgentRuntime quanto a nova API InvokeAgentRuntimeWithWebsocketStream. Além disso, clientes precisam fornecer um endpoint /ping para verificações de integridade.

    O streaming bidirecional usando WebSockets no AgentCore Runtime suporta aplicações que utilizem bibliotecas de linguagem de WebSocket. O cliente deve conectar ao endpoint de serviço com uma conexão de protocolo WebSocket:

    wss://bedrock-agentcore.<region>.amazonaws.com/runtimes/<agentRuntimeArn>/ws

    É necessário também utilizar um dos métodos de autenticação suportados (cabeçalhos SigV4, URL pré-assinada SigV4, ou OAuth 2.0) e garantir que a aplicação do agente implemente o contrato de serviço de WebSocket conforme especificado no contrato do protocolo HTTP.

    Implementação prática com Strands e Amazon Nova Sonic

    Modelos de implementação

    A AWS oferece múltiplas abordagens para implementar agentes de voz bidirecional. Uma implementação direta exige gerenciar manualmente conexões de WebSocket, fazer parsing de eventos de protocolo, lidar com fragmentos de áudio e orquestrar tarefas assíncronas — uma abordagem que oferece controle total mas demanda conhecimento especializado. Alternativamente, a implementação usando Strands abstrai essa complexidade, tratando internamente dessas etapas.

    O modelo Amazon Nova Sonic unifica compreensão e geração de fala em um único modelo, fornecendo IA conversacional similar à humana com baixa latência, precisão líder e excelente relação preço-desempenho. Sua arquitetura integrada oferece geração de fala expressiva e transcrição em tempo real em um único modelo, adaptando dinamicamente respostas com base na prosódia, ritmo e timbre da fala de entrada.

    Imagem original — fonte: AWS

    Exemplo de implementação com Strands

    Para desenvolver agentes de voz com a abordagem Strands, há um repositório com dois modelos de implementação: uma usando a implementação nativa de Python do Amazon Nova Sonic implantada diretamente no AgentCore Runtime, e outra usando uma implementação de framework de alto nível com o agente bidirecional Strands para conversas de áudio em tempo real simplificadas.

    O código a seguir exemplifica a simplificação oferecida pelo Strands:

    from strands.experimental.bidi.agent import BidiAgent
    from strands.experimental.bidi.models.nova_sonic import BidiNovaSonicModel
    from strands_tools import calculator
    
    @app.websocket("/ws")
    async def websocket_endpoint(websocket: WebSocket, model_name: str):
        # Define a Nova Sonic BidiModel
        model = BidiNovaSonicModel(
            region="us-east-1",
            model_id="amazon.nova-sonic-v1:0",
            provider_config={
                "audio": {
                    "input_sample_rate": 16000,
                    "output_sample_rate": 24000,
                    "voice": "matthew",
                }
            }
        )
    
        # Create a Strands Agent with tools and system prompt
        agent = BidiAgent(
            model=model,
            tools=[calculator],
            system_prompt="You are a helpful assistant with access to a calculator tool.",
        )
    
        # Start streaming conversation
        await agent.run(inputs=[receive_and_convert], outputs=[websocket.send_json])

    Essa implementação demonstra a simplicidade do Strands: instanciar um modelo, criar um agente com ferramentas e um prompt de sistema, e executá-lo com fluxos de entrada e saída. O framework trata a complexidade do protocolo internamente.

    Orquestração de ferramentas

    Na seção de declaração do agente, as ferramentas são passadas diretamente ao construtor:

    agent = BidiAgent(
        model=model,
        tools=[calculator, weather_api, database_query],
        system_prompt="You are a helpful assistant..."
    )

    O Strands orquestra automaticamente a chamada de funções, eliminando a necessidade de código manual para essa complexidade. Uma implementação nativa de WebSocket da mesma funcionalidade exigiria aproximadamente 150 linhas de código, enquanto a implementação Strands reduz isto para aproximadamente 20 linhas focadas na lógica de negócio.

    Developers conseguem focar em definir o comportamento do agente, integrar ferramentas e elaborar prompts de sistema em vez de gerenciar conexões de WebSocket, fazer parsing de eventos, lidar com fragmentos de áudio ou orquestrar tarefas assíncronas. Isso torna o streaming bidirecional acessível para desenvolvedores sem expertise especializada em sistemas em tempo real, mantendo acesso total às capacidades de conversa de áudio do Nova Sonic.

    Flexibilidade de implementação

    O recurso bidirecional do Strands atualmente é suportado apenas para o Python SDK. Para quem busca flexibilidade na implementação de seu agente de voz, a implementação nativa do Amazon Nova Sonic pode ser útil, especialmente importante para casos onde há múltiplos padrões diferentes de comunicação entre agente e modelo.

    Com a implementação do Amazon Nova Sonic há controle total sobre cada passo do processo. A abordagem de framework oferece melhor controle de dependências, pois isso é feito pelo SDK, e fornece consistência entre sistemas. A mesma estrutura de código do agente bidirecional Strands funciona com Nova Sonic, OpenAI Realtime API e Google Gemini Live — desenvolvedores simplesmente trocam a implementação do modelo mantendo o restante do código inalterado.

    Referências práticas

    Para explorar essas capacidades, há exemplos de código disponíveis. O repositório contém implementação bidirecional do Amazon Bedrock AgentCore, que demonstra comunicação bidirecional com o AgentCore. Estão disponíveis a implementação nativa de Python do Amazon Nova Sonic implantada diretamente no AgentCore Runtime, assim como a implementação de framework de alto nível usando o agente bidirecional Strands para conversas de áudio em tempo real simplificadas.

    Impacto para desenvolvimento de IA conversacional

    A capacidade de streaming bidirecional do AgentCore Runtime transforma como desenvolvedores conseguem criar agentes de IA conversacionais. Ao fornecer infraestrutura de comunicação em tempo real baseada em WebSocket, o AgentCore elimina meses de esforço de engenharia necessários para implementar sistemas de streaming do zero.

    O runtime do framework viabiliza implantação de múltiplos tipos de agentes de voz — desde implementações de protocolo nativo usando Amazon Nova Sonic até frameworks de alto nível como o agente bidirecional Strands — dentro do mesmo ambiente seguro e sem servidores. Isso democratiza o acesso a capacidades de conversação em tempo real para equipes com diferentes níveis de expertise em sistemas em tempo real.

    Fonte

    Bi-directional streaming for real-time agent interactions now available in Amazon Bedrock AgentCore Runtime (https://aws.amazon.com/blogs/machine-learning/bi-directional-streaming-for-real-time-agent-interactions-now-available-in-amazon-bedrock-agentcore-runtime/)

  • Agentes de IA em Escala: Integrando Strands, Bedrock AgentCore e NVIDIA NeMo

    Além dos Assistentes de Chat: A Era dos Agentes Autônomos

    A próxima fronteira da inteligência artificial não reside apenas em assistentes conversacionais mais sofisticados. O verdadeiro avanço está em agentes autônomos capazes de raciocinar, planejar e executar tarefas complexas em sistemas completos. No entanto, transformar protótipos em agentes prontos para produção que escalam de forma segura representa um desafio significativo para desenvolvedoras e desenvolvedores empresariais.

    Conforme os problemas corporativos se tornam mais complexos, surge a necessidade de arquiteturas sofisticadas onde múltiplos agentes especializados colaboram para realizar tarefas refinadas. Existe um abismo considerável entre desenvolver um agente em ambiente controlado e implantá-lo em escala, envolto em questões de otimização de desempenho, escalabilidade de recursos, implementação de segurança e monitoramento operacional.

    O Desafio de Levar Agentes do Desenvolvimento à Produção

    Abordagens convencionais frequentemente deixam equipes malabarando múltiplas ferramentas desconectadas e frameworks distintos. Essa fragmentação torna difícil manter consistência desde o desenvolvimento até a implantação, sem comprometer o desempenho.

    É neste contexto que emerge uma combinação poderosa: Strands Agents, Amazon Bedrock AgentCore e NVIDIA NeMo Agent Toolkit. Estas ferramentas trabalham em conjunto para permitir o design de sistemas sofisticados com múltiplos agentes, sua orquestração e implantação segura em produção, tudo isso com observabilidade integrada, avaliação de agentes, perfilagem e otimização de desempenho.

    Fundação para Agentes Prontos para Empresas

    O Framework Strands Agents

    O Strands Agents é um framework de código aberto que simplifica o desenvolvimento de agentes por meio de uma abordagem orientada por modelos. Desenvolvedoras e desenvolvedores criam agentes utilizando três componentes principais:

    • Modelos base (foundation models), como Amazon Nova, Claude da Anthropic e Llama da Meta
    • Ferramentas (mais de 20 integradas, além de ferramentas personalizadas usando decoradores Python)
    • Prompts que orientam o comportamento do agente

    O framework inclui integrações nativas com serviços da AWS como Amazon Bedrock e Amazon Simple Storage Service (Amazon S3), suporte a testes locais, fluxos de integração e entrega contínua (CI/CD), múltiplas opções de implantação e observabilidade via OpenTelemetry.

    Amazon Bedrock AgentCore: Plataforma de Agentes Gerenciada

    O Amazon Bedrock AgentCore funciona como plataforma agentic completa para construir, implantar e operar agentes eficazes em escala, com segurança de nível empresarial. Seus componentes modulares e totalmente gerenciados incluem:

    • Runtime: Execução segura e sem servidor de agentes
    • Memory: Retenção de contexto de curto e longo prazo
    • Gateway: Acesso seguro a ferramentas, transformando APIs e funções AWS Lambda em ferramentas compatíveis com agentes, e conectando a servidores Model Context Protocol (MCP) existentes
    • Identity: Gerenciamento seguro de identidade e controle de acesso
    • Code Interpreter: Execução segura de código em ambientes isolados
    • Browser: Interações web rápidas e seguras
    • Observability: Rastreamento e monitoramento abrangente do desempenho
    • Evaluations: Inspeção contínua da qualidade do agente
    • Policy: Mantém agentes dentro de limites definidos

    Estes serviços funcionam independentemente ou em conjunto, abstraindo a complexidade de construir e operar agentes sofisticados enquanto mantêm segurança e confiabilidade de nível empresarial.

    Avaliação, Perfilagem e Otimização com NeMo Agent Toolkit

    O NVIDIA NeMo Agent Toolkit é um framework de código aberto desenhado para ajudar desenvolvedoras e desenvolvedores a construir, perfilar e otimizar agentes de IA, independentemente do framework subjacente. Sua abordagem agnóstica funciona perfeitamente com Strands Agents, LangChain, LlamaIndex, CrewAI e frameworks customizados, permitindo interoperabilidade entre diferentes plataformas.

    Capacidades de Profiling e Avaliação

    O profiler fornecido pelo toolkit oferece análise completa do fluxo de trabalho do agente, rastreando uso de tokens, timing, latência específica do workflow, throughput e tempos de execução para agentes e ferramentas individuais. Isso permite identificar e atacar gargalos específicos.

    O harness de avaliação do toolkit inclui avaliadores específicos para Retrieval Augmented Generation (RAG), como precisão de resposta, relevância de contexto, fundamentação de resposta e trajetória do agente, além de suportar avaliadores customizados para casos especializados.

    Otimização Automática e Right-Sizing

    O otimizador automático de hiperparâmetros perfila e descobre sistematicamente configurações ideais para parâmetros como temperatura, top_p e max_tokens, enquanto maximiza acurácia e fundamentação, minimiza uso de tokens e latência. Esta abordagem identifica combinações ótimas que a sintonia manual poderia perder.

    A calculadora inteligente de dimensionamento de GPU alivia a adivinhação simulando cenários de latência e concorrência de agentes, predizendo os requisitos precisos de infraestrutura GPU necessários para implantação em produção.

    A integração de observabilidade do toolkit conecta-se com serviços populares de monitoramento incluindo Arize Phoenix, Weights & Biases Weave, Langfuse e sistemas compatíveis com OpenTelemetry, como Amazon Bedrock AgentCore Observability, criando um loop de feedback contínuo para otimização e manutenção permanentes.

    Exemplo Prático: Agente Baseado em Conhecimento

    Um exemplo ilustrativo envolve um agente capaz de recuperar e sintetizar informações de URLs para responder consultas do usuário. Construído com Strands Agents e NeMo Agent Toolkit integrado, a solução é containerizada para implantação rápida no Amazon Bedrock AgentCore Runtime, aproveitando serviços como Observability do AgentCore.

    Desenvolvedoras e desenvolvedores têm flexibilidade para integrar modelos totalmente gerenciados no Amazon Bedrock, modelos hospedados em Amazon SageMaker AI, modelos containerizados em Amazon Elastic Kubernetes Service (Amazon EKS) ou outros endpoints de API de modelo.

    Desenvolvimento e Avaliação do Agente

    O processo começa definindo o agente e seus workflows em Strands Agents, depois encapsulando-o com NeMo Agent Toolkit para configurar componentes como um modelo de linguagem grande (LLM) para inferência e ferramentas. Existe um exemplo de integração Strands Agents e NeMo Agent Toolkit disponível com guia de configuração detalhado.

    Após validar a lógica do agente executando um workflow individual via linha de comando, o próximo passo envolve estabelecer um servidor de API de longa duração capaz de lidar com requisições concorrentes, simulando o ambiente de produção onde o AgentCore executará o agente como serviço containerizado.

    Profiling e Monitoramento de Desempenho

    Usando um Llama 3.3 70B Instruct NIM auto-gerenciado em uma instância Amazon EC2 P4de.24xlarge com GPUs NVIDIA A100 Tensor Core (8x A100 80GB), o profiling revela insights profundos sobre o comportamento do agente. Os dados coletados incluem:

    • Latência, throughput e runtime do workflow em intervalos de confiança de 90%, 95% e 99%
    • Gráficos de Gantt do fluxo do agente e análise de stack aninhada para identificar exatamente onde estão os gargalos
    • Picos de concorrência e eficiência de tokens
    • Métricas de qualidade (acurácia, fundamentação, relevância)

    Em um cenário típico, a latência p90 fica em torno de 58,9 segundos, com a geração de resposta identificada como principal gargalo (~61,4 segundos de processamento LLM), enquanto overhead não-LLM permanece mínimo (requisições HTTP em 0,7–1,2 segundos).

    Otimização de Desempenho

    Após profiling, refina-se os parâmetros do agente para equilibrar qualidade, desempenho e custo. A sintonia manual de configurações LLM como temperatura e top_p é frequentemente um jogo de adivinhação. O NeMo Agent Toolkit transforma isso em ciência orientada por dados.

    Um sweep automático através do espaço de busca de parâmetros executa 20 testes com três repetições cada, usando métricas de avaliação ponderadas para descobrir automaticamente configurações ideais. O toolkit gera artefatos de desempenho e tabelas de resumo para identificação rápida da configuração ótima.

    Em um exemplo realístico, a otimização identificou temperatura ≈ 0,7, top_p ≈ 1,0 e max_tokens ≈ 6.144 como configuração ótima, resultando em melhoria de 35% em acurácia em relação à baseline, enquanto simultaneamente alcançava 20% de ganho em eficiência de tokens comparado à configuração de 8.192 max_tokens.

    Calibração de Infraestrutura GPU para Produção

    Após otimizar e finalizar o agente, o foco se desloca para avaliar infraestrutura de implantação. Para equipes que autogerenciam implantação de modelos em frotas de instâncias EC2 com GPU, prever com precisão quais recursos computacionais são necessários representa um dos maiores desafios ao levar agentes para produção.

    A calculadora de dimensionamento de GPU do NeMo Agent Toolkit aborda este desafio utilizando o perfil de desempenho real do agente para determinar o tamanho de cluster ideal para objetivos de nível de serviço (SLOs) específicos. Executar a calculadora em faixas de concorrência (por exemplo, 1–32 usuários simultâneos) em uma instância de referência produz análise de capacidade detalhada.

    Os dados demonstram que concorrência escala quase linearmente com latência e runtime fim-a-fim, com latência LLM e runtime de workflow apresentando ajustes de tendência próximos ao perfeito (R² ≈ 0,977/0,983). Cada requisição concorrente adicional introduz penalidade de latência previsível.

    Por exemplo, para suportar 25 usuários simultâneos com runtime de workflow alvo de 50 segundos, a ferramenta calcula que aproximadamente 30 GPUs são necessárias.

    Implantação em Produção no Amazon Bedrock AgentCore

    Após avaliar, perfilar e otimizar o agente, chega o momento da implantação em produção. Enquanto executar localmente é adequado para testes, implantação empresarial exige um runtime de agente que fornecça segurança, escalabilidade e gerenciamento robusto de memória sem overhead de gerenciar infraestrutura.

    O Amazon Bedrock AgentCore Runtime brilha precisamente aqui, oferecendo runtime de agente sem servidor de nível empresarial. Um guia passo-a-passo de implantação está disponível no repositório NeMo Agent Toolkit.

    Ao empacotar o agente otimizado em um container e implantá-lo no Bedrock AgentCore Runtime sem servidor, a equipe transforma o agente prototipado em aplicação resiliente para tarefas de longa duração e requisições de usuários concorrentes.

    Observabilidade em Produção

    Após implantação, visibilidade torna-se crítica. A integração cria experiência unificada de observabilidade, transformando execução opaca de caixa-preta em visibilidade profunda. Obtém-se traces exatos, spans e breakdowns de latência para cada interação em produção, integrado com Amazon Bedrock AgentCore Observability usando OpenTelemetry.

    Os serviços do Bedrock AgentCore estendem-se além de gerenciamento de runtime e observabilidade. Agentes implantados podem utilizar perfeitamente serviços adicionais como Amazon Bedrock AgentCore Identity para autenticação e autorização, Amazon Bedrock AgentCore Gateway para acesso a ferramentas, Amazon Bedrock AgentCore Memory para consciência de contexto, Amazon Bedrock AgentCore Code Interpreter para execução segura de código e Amazon Bedrock AgentCore Browser para interações web, criando agentes prontos para empresas.

    Síntese: Uma Solução Integrada de Ponta a Ponta

    Agentes de IA em produção exigem visibilidade de desempenho, otimização e infraestrutura confiável. Para o caso de uso ilustrado, esta integração entregou em todas as frentes: ganhos de 20% em eficiência de tokens, melhorias de 35% em acurácia para o exemplo prático e infraestrutura GPU ajustada ao desempenho para concorrência alvo.

    A combinação do Strands Agents para desenvolvimento e orquestração de agentes, NVIDIA NeMo Agent Toolkit para perfilagem profunda de agentes, otimização e calibração de infraestrutura GPU, e Amazon Bedrock AgentCore para infraestrutura agentic segura e escalável, fornece uma solução integrada fim-a-fim que permite que desenvolvedoras e desenvolvedores construam, avaliem, otimizem e implantem agentes em escala na AWS com resultados previsíveis.

    Para começar, consulte o exemplo de integração Strands Agents e NeMo Agent Toolkit e o guia de implantação de Strands Agents e NeMo Agent Toolkit no Amazon Bedrock AgentCore Runtime.

    Fonte

    Build and deploy scalable AI agents with NVIDIA NeMo, Amazon Bedrock AgentCore, and Strands Agents (https://aws.amazon.com/blogs/machine-learning/build-and-deploy-scalable-ai-agents-with-nvidia-nemo-amazon-bedrock-agentcore-and-strands-agents/)

  • Migração de Regras de Automação do Security Hub CSPM para o Security Hub Novo

    Contexto: Uma Nova Geração do Security Hub

    A AWS Security Hub acaba de receber uma renovação significativa. A plataforma agora oferece capacidades expandidas para agregar, correlacionar e contextualizar alertas de segurança em múltiplas contas da Amazon Web Services (AWS). Enquanto isso, a versão anterior recebeu uma nova denominação: AWS Security Hub CSPM, que continua disponível como um serviço especializado focado em gerenciamento de postura de segurança em nuvem e agregação de descobertas.

    Ambas as versões compartilham uma funcionalidade importante: as regras de automação. Esse recurso permite atualizar automaticamente campos de descobertas quando critérios específicos são atendidos. Porém, existe um desafio: as regras criadas em uma versão não sincronizam com a outra. Isso significa que usuários migrando do Security Hub CSPM para a nova plataforma precisam recriar suas automações manualmente — ou encontrar uma forma mais eficiente de fazer essa transição.

    O Problema de Compatibilidade de Esquemas

    Diferenças Fundamentais Entre os Esquemas

    O Security Hub CSPM utiliza o AWS Security Finding Format (ASFF) como esquema para suas descobertas. Esse formato é central para como as regras de automação funcionam — elas analisam campos ASFF específicos usando operadores (como igualdade ou contém) para determinar quando ativar ações que modificam outros campos ASFF.

    A nova versão do Security Hub, por sua vez, adota o Open Cybersecurity Schema Framework (OCSF), um padrão aberto amplamente adotado no setor de cibersegurança. Essa mudança traz melhorias em interoperabilidade e integração, mas cria um obstáculo para usuários existentes: as regras ASFF não são diretamente compatíveis com OCSF.

    Desafios Específicos da Migração

    Nem todas as regras podem ser migradas automaticamente. Alguns campos ASFF não possuem correspondentes diretos em OCSF. Por exemplo, campos como Criticality, GeneratorId e RelatedFindingsId não têm mapeamento na nova estrutura. Além disso, algumas ações suportadas no ASFF — como aquelas que modificam Confidence, VerificationState ou UserDefinedFields — também não estão disponíveis no OCSF.

    Isso significa que regras existentes podem ser migradas de forma parcial, preservando apenas as ações que têm equivalente no novo esquema, ou podem exigir redesenho completo.

    A Solução: Automatizando a Migração

    Como Funciona a Ferramenta

    A AWS oferece uma solução pronta baseada em scripts Python que automatiza o processo de migração. O fluxo funciona em etapas bem definidas:

    Descoberta: A solução escaneia seu ambiente Security Hub CSPM para identificar todas as regras de automação existentes em múltiplas regiões.

    Análise: Cada regra é avaliada para determinar se pode ser totalmente migrada, parcialmente migrada ou se exige intervenção manual, baseado na compatibilidade entre campos ASFF e OCSF.

    Transformação: Regras compatíveis são convertidas automaticamente de ASFF para OCSF usando mapeamentos pré-definidos.

    Geração de Template: A solução cria um template do AWS CloudFormation contendo as regras transformadas, preservando sua ordem original e contexto regional.

    Implantação e Validação: O template é revisado e implantado, criando as regras migradas em estado desabilitado por padrão, permitindo testes antes da ativação.

    Arquitetura da solução mostrando os scripts Python e suas interações — Fonte: Aws

    Componentes da Solução

    A ferramenta é composta por quatro scripts Python que trabalham de forma coordenada:

    Orquestrador: Coordena descoberta, transformação e geração, além de gerenciar relatórios e logs.

    Descoberta de Regras: Identifica e extrai regras de automação existentes do Security Hub CSPM em regiões especificadas.

    Transformação de Esquema: Converte regras de ASFF para OCSF utilizando o mapeamento de campos.

    Geração de Template: Cria templates CloudFormation prontos para implantação.

    Mapeamento de Campos: ASFF para OCSF

    Para entender o escopo da migração, é importante conhecer como os campos se relacionam. Campos ASFF usados como critérios em regras mapeiam para seus equivalentes OCSF da seguinte forma:

    Campos como AwsAccountId, ComplianceStatus, Confidence, CreatedAt, Description, SeverityLabel e Title possuem correspondentes diretos. Porém, Criticality, GeneratorId, NoteText, ResourceApplicationArn, UserDefinedFields e VerificationState são marcados como indisponíveis (N/A) e não podem ser migrados automaticamente.

    Regras que dependem desses campos precisam ser redesenhadas manualmente na nova plataforma.

    Da mesma forma, ações suportadas como modificação de Severity e atualização de Status são totalmente compatíveis. Porém, ações que envolvem Confidence, Criticality, RelatedFindings e VerificationState não possuem equivalente e precisarão ser recriadas ou removidas.

    Conceitos-Chave Para a Migração

    Estado Padrão das Regras Migradas

    Por segurança, todas as regras migradas são criadas em estado desabilitado. Isso permite que você as revise, valide o comportamento e só então as ative. A solução pode opcionalmente criar regras já habilitadas, mas essa abordagem não é recomendada.

    Ordem e Prioridade de Regras

    Tanto no Security Hub CSPM quanto no novo Security Hub, a ordem de execução das regras importa — especialmente quando múltiplas regras podem afetar os mesmos campos. A solução preserva a ordem original de suas regras. Se você já possui regras no Security Hub novo, as regras migradas começam sua numeração após as existentes.

    Quando múltiplas regiões estão envolvidas em um cenário de Região Base (home region), a ordem é preservada por região e agrupada na sequência final. Por exemplo: primeiramente todas as regras da Região 1, depois da Região 2, e assim por diante.

    Regiões: Base vs. Individual

    O Security Hub CSPM opera com regras baseadas em regiões — uma regra criada em uma região afeta apenas as descobertas geradas naquela região, mesmo se você usa uma região base para agregação central.

    O novo Security Hub funciona de forma diferente: regras definidas na região base são aplicadas a todas as regiões vinculadas. Regras não podem ser criadas em regiões vinculadas, apenas em regiões não vinculadas, onde afetarão apenas suas descobertas locais.

    A solução oferece dois modos de implantação para lidar com essas diferenças:

    Modo Região Base: Usa regiões especificadas e recria as regras na região base, adicionando um critério extra que preserva o contexto regional original. Um único template CloudFormation é gerado.

    Modo Região-por-Região: Gera um template separado para cada região, preservando o comportamento regional das regras originais. Templates são implantados individualmente.

    Se você usa uma região base com algumas regiões vinculadas e outras não, execute o Modo Região Base para a região base e regiões vinculadas, depois o Modo Região-por-Região para regiões não vinculadas.

    Pré-Requisitos e Configuração

    Softwares Necessários

    Antes de iniciar, você precisa de:

    Permissões Necessárias

    Sua conta AWS precisa ter permissões para:

    Descoberta e transformação: securityhub:ListAutomationRules, securityhub:BatchGetAutomationRules, securityhub:GetFindingAggregator, securityhub:DescribeHub, securityhub:ListAutomationRulesV2.

    Implantação de template: cloudformation:CreateStack, cloudformation:UpdateStack, cloudformation:DescribeStacks, cloudformation:CreateChangeSet, cloudformation:DescribeChangeSet, cloudformation:ExecuteChangeSet, cloudformation:GetTemplateSummary, securityhub:CreateAutomationRuleV2, securityhub:UpdateAutomationRuleV2, securityhub:DeleteAutomationRuleV2, securityhub:GetAutomationRuleV2, securityhub:TagResource, securityhub:ListTagsForResource.

    Configuração da Conta AWS

    O Security Hub suporta um modelo de administrador delegado quando usado com AWS Organizations. Nesse modelo, um administrador delegado centraliza a gestão de descobertas e configuração de segurança em toda a organização.

    Regras de automação devem ser criadas na conta do administrador delegado, na região base e em regiões não vinculadas. Contas membro não podem criar suas próprias regras.

    A recomendação é usar a mesma conta como administrador delegado tanto para Security Hub CSPM quanto para o novo Security Hub, garantindo consistência. Configure sua AWS CLI com credenciais dessa conta antes de executar a migração.

    Embora a solução seja principalmente para deployments com administrador delegado, também funciona com implementações de Security Hub em conta única.

    Passo a Passo: Executando a Migração

    Preparação e Execução

    Para iniciar o processo de migração:

    Primeiro, clone o repositório da ferramenta de migração. Acesse o repositório de amostras da AWS no GitHub e execute:

    git clone https://github.com/aws-samples/sample-SecurityHub-Automation-Rule-Migration.git

    Em seguida, consulte o arquivo README do repositório para obter as instruções de implementação mais atualizadas. Siga os passos especificados para executar os scripts. O processo gerará um template CloudFormation com suas regras de automação transformadas.

    Implante o template usando a AWS CLI ou o console. Veja como criar uma stack no console do CloudFormation para detalhes completos.

    Validação e Ativação das Regras

    Após a implantação, acesse o console do Security Hub para revisar suas regras migradas. Lembre-se: elas começam desabilitadas por padrão.

    Para cada regra migrada:

    • Acesse a seção de Automações no Security Hub
    • Selecione a regra e escolha Editar
    • Revise seus critérios e ações com cuidado
    • Use a opção de visualizar descobertas correspondentes para validar o comportamento esperado
    • Se tudo estiver correto, ative a regra

    Preste atenção especial às regras marcadas como “parcialmente migradas” em sua descrição. Isso significa que uma ou mais ações da regra original não têm equivalente no novo Security Hub. Essas regras podem se comportar diferentemente do que você espera e precisarão de revisão.

    A solução também gera um relatório detalhando quais regras foram parcialmente migradas e especificando quais ações não puderam ser replicadas. Revise esse relatório cuidadosamente antes de habilitar essas regras.

    Conclusão

    A nova geração do AWS Security Hub oferece capacidades significativamente melhoradas para agregar, correlacionar e contextualizar descobertas de segurança. Embora a mudança de esquema de ASFF para OCSF traga benefícios em termos de interoperabilidade e integrações com parceiros, ela também exige que regras de automação existentes sejam transformadas.

    A solução de migração automatizada simplifica esse processo, executando a descoberta, transformação e geração de templates de forma coordenada. Ao seguir as melhores práticas recomendadas — revisar o relatório de migração, testar regras em estado desabilitado, validar correspondências e ativar gradualmente — você consegue manter seus fluxos de trabalho de automação de segurança funcionando sem interrupções.

    Para mais informações sobre o Security Hub e suas capacidades ampliadas, consulte a documentação oficial do Security Hub.

    Fonte

    Security Hub CSPM automation rule migration to Security Hub (https://aws.amazon.com/blogs/security/security-hub-cspm-automation-rule-migration-to-security-hub/)

  • Bancos de Dados da AWS agora estão disponíveis no Marketplace da Vercel

    Integração Estratégica: Bancos de Dados AWS na Vercel

    Desde dezembro de 2025, a AWS disponibilizou seus bancos de dados no Marketplace da Vercel, marcando um passo importante na simplificação da infraestrutura para desenvolvedores. Agora é possível criar e conectar instâncias de Amazon Aurora PostgreSQL, Amazon Aurora DSQL e Amazon DynamoDB diretamente do dashboard da Vercel, sem necessidade de configurações complexas.

    Como Começar

    Para iniciar, desenvolvedores podem criar uma nova conta AWS diretamente pela Vercel, que já inclui acesso aos três serviços de banco de dados mencionados. A promoção oferece $100 USD em créditos que podem ser utilizados em qualquer uma das opções de banco de dados por até seis meses, reduzindo significativamente as barreiras de entrada para prototipagem e desenvolvimento.

    Configuração Rápida e Produção Imediata

    Uma vez que a conta está configurada, é possível ter um banco de dados Aurora pronto para produção ou uma tabela DynamoDB alimentando seus projetos Vercel em questão de segundos. Todo o gerenciamento — desde o plano escolhido até a adição de informações de pagamento e visualização de uso — pode ser feito no portal de configurações AWS acessível diretamente do dashboard da Vercel.

    Capacidades e Vantagens Técnicas

    A integração oferece opções serverless para Aurora PostgreSQL, Aurora DSQL e DynamoDB, simplificando as necessidades das aplicações e reduzindo custos através do dimensionamento automático para zero quando não há uso. Essa abordagem elimina a cobrança por recursos ociosos, tornando a solução especialmente atrativa para aplicações com padrões de consumo variáveis.

    Cobertura Geográfica e Escalabilidade

    Os bancos de dados podem ser criados em Regiões AWS estratégicas: US East (Virgínia do Norte), US East (Ohio), US West (Oregon), Europe (Irlanda), Europe (Frankfurt), Ásia Pacífico (Tóquio) e Ásia Pacífico (Mumbai). Novos locais estão previstos para o futuro, ampliando a disponibilidade para diferentes contextos geográficos.

    Segurança e Confiabilidade

    Os bancos de dados AWS entregam segurança, confiabilidade e eficiência de custo sem a sobrecarga operacional associada ao gerenciamento manual de infraestrutura. A abordagem é adequada tanto para desenvolvedores prototipando suas próximas ideias quanto para equipes mantendo aplicações de produção críticas e orientadas por dados ou inteligência artificial.

    Próximos Passos

    Para explorar melhor essas capacidades, a AWS fornece documentação completa na página AWS no Marketplace da Vercel. Além disso, o site de bancos de dados da AWS oferece informações técnicas detalhadas sobre cada serviço e suas possibilidades de integração.

    Fonte

    AWS Databases are now available on the Vercel Marketplace (https://aws.amazon.com/about-aws/whats-new/2025/12/aws-databases-are-available-on-the-vercel/)

  • MLflow no Amazon SageMaker: Monitore Experimentos de Machine Learning com Integração Snowflake

    O Desafio do Rastreamento de Experimentos em Ambientes Distribuídos

    Cientistas de dados frequentemente conduzem experimentos de machine learning em ambientes de dados diversos, como o Snowflake, utilizando a biblioteca Snowpark. No entanto, rastrear esses experimentos de forma centralizada apresenta desafios significativos. Manter um repositório único que monitore metadados de experimentos, parâmetros, hiperparâmetros, modelos, resultados e outras informações relevantes torna-se complexo quando esses processos ocorrem em plataformas distintas.

    A AWS apresenta uma solução: integrar o MLflow gerenciado do SageMaker como repositório central para registro desses experimentos, estabelecendo um sistema unificado de monitoramento de progresso.

    Capacidades do MLflow Gerenciado no SageMaker

    O MLflow gerenciado da AWS oferece serviços totalmente gerenciados para rastreamento de experimentos, empacotamento de modelos e registro de modelos. O Registro de Modelos do SageMaker simplifica o versionamento e a implantação de modelos, facilitando transições suaves do desenvolvimento para produção.

    A integração com Amazon S3, AWS Glue e Repositório de Características do SageMaker potencializa o gerenciamento de dados e a rastreabilidade de modelos. Os principais benefícios dessa arquitetura incluem:

    • Padronização de fluxos de trabalho de machine learning em toda a organização
    • Melhoria na colaboração entre equipes de ciência de dados
    • Aceleração da adoção de IA/ML com infraestrutura mais segura e escalável

    Arquitetura da Solução: Snowpark Integrado ao MLflow

    A integração entre Snowflake e SageMaker permite um fluxo de trabalho coeso. O Snowpark para Python funciona como biblioteca do lado cliente, permitindo que código Python interaja com o Snowflake a partir de kernels Python, como os notebooks Jupyter do SageMaker.

    Imagem original — fonte: Aws

    Um fluxo de trabalho típico inclui preparação de dados no Snowflake, juntamente com engenharia de características e treinamento de modelos dentro do Snowpark. Posteriormente, o MLflow gerenciado do SageMaker é utilizado para rastreamento de experimentos e registro de modelos, integrados às capacidades do SageMaker. Essa abordagem permite que cientistas de dados executem transformações e engenharia de características no Snowflake e aproveitem a infraestrutura gerenciada do SageMaker para treinamento e implantação, facilitando orquestração de fluxos de trabalho mais suave e tratamento seguro dos dados.

    Rastreamento Centralizado com MLflow

    O rastreamento MLflow é fundamental nessa integração entre SageMaker, Snowpark e Snowflake, pois fornece um ambiente centralizado para registro e gerenciamento de todo o ciclo de vida do machine learning. Enquanto o Snowpark processa dados do Snowflake e treina modelos, o Rastreamento MLflow captura detalhes essenciais:

    • Parâmetros e hiperparâmetros do modelo
    • Métricas de desempenho
    • Artefatos gerados durante o treinamento

    Isso permite que cientistas de dados monitorem experimentos, comparem diferentes versões de modelos e verifiquem reprodutibilidade. Com as capacidades de versionamento e registro do MLflow, equipes podem rastrear resultados até o conjunto de dados específico e as transformações utilizadas, tornando mais simples monitorar o desempenho de modelos ao longo do tempo e manter um fluxo de trabalho de machine learning transparente e eficiente.

    Essa abordagem oferece diversos benefícios práticos: fornece um rastreador MLflow escalável e gerenciado no SageMaker, enquanto aproveita as capacidades de processamento do Snowpark para inferência de modelo dentro do ambiente Snowflake, criando um sistema unificado de dados. O fluxo de trabalho permanece dentro do ambiente Snowflake, o que aprimora segurança e governança dos dados. Adicionalmente, reduz custos ao utilizar a potência de computação elástica do Snowflake para inferência sem necessidade de manter infraestrutura separada para servir modelos.

    Pré-requisitos para Implementação

    Antes de estabelecer o MLflow do SageMaker, é necessário criar e configurar os seguintes recursos:

    O usuário do Gerenciamento de Identidade e Acesso deve possuir permissões para fazer as chamadas de serviço AWS necessárias. Ao conceder essas permissões, é importante seguir o princípio do menor privilégio.

    Conectando Snowflake ao Servidor de Rastreamento MLflow

    Para conectar o ambiente Snowflake ao Servidor de Rastreamento MLflow gerenciado do SageMaker, siga estas etapas:

    Configuração Inicial no Snowflake

    • Faça login no Snowflake como usuário administrador
    • Crie um novo Notebook em Snowflake: Projects > Notebooks > +Notebook
    • Altere a função para uma função não-administrador
    • Atribua um nome, selecione banco de dados, schema, warehouse, e selecione ‘Run on container’
    • Nas configurações do Notebook, ative a opção de acesso externo para permitir todas as integrações

    Instalação de Dependências

    Instale a biblioteca necessária executando:

    !pip install sagemaker-mlflow

    Configuração do MLflow e Execução de Experimentos

    Execute o código do MLflow, substituindo o valor de ARN pelo seu:

    import mlflow
    import boto3
    import logging
    
    sts = boto3.client("sts")
    assumed = sts.assume_role(
        RoleArn="",
        RoleSessionName="sf-session"
    )
    creds = assumed["Credentials"]
    arn = ""
    
    try:
        mlflow.set_tracking_uri(arn)
        mlflow.set_experiment("Default")
        with mlflow.start_run():
            mlflow.log_param("test_size", 0.2)
            mlflow.log_param("random_state", 42)
            mlflow.log_param("model_type", "LinearRegression")
    except Exception as e:
        logging.error("Failed to set tracking URI: {e}")
    Imagem original — fonte: Aws

    Após uma execução bem-sucedida, os experimentos podem ser rastreados no MLflow do SageMaker. Clicando no nome da execução (“Run name”), é possível acessar insights detalhados sobre cada experimento.

    Limpeza de Recursos

    Para evitar custos contínuos, execute estas etapas para remover os recursos configurados:

    • Delete a conta SageMaker Studio (isso também deleta o servidor de rastreamento MLflow)
    • Delete o bucket S3 com seu conteúdo
    • Remova o notebook do Snowflake
    • Verifique que a conta SageMaker foi deletada

    Considerações Finais

    A integração entre o MLflow gerenciado do SageMaker e o Snowflake oferece uma solução abrangente para gerenciar o ciclo de vida completo do machine learning. Ao aproveitar o Snowpark, a solução aprimora ainda mais esse conjunto de capacidades, permitindo fluxos de trabalho mais suaves de processamento de dados e implantação de modelos.

    Para começar, siga as instruções passo a passo fornecidas acima para configurar o Servidor de Rastreamento MLflow no SageMaker Studio e integrá-lo com o Snowflake. Lembre-se de implementar as práticas recomendadas de segurança da AWS, incluindo funções e permissões apropriadas de Gerenciamento de Identidade e Acesso, e garantindo que todas as credenciais sejam protegidas adequadamente. Os exemplos de código e instruções neste artigo servem como ponto de partida — podem ser adaptados para casos de uso e requisitos específicos enquanto se mantêm as práticas recomendadas de segurança e escalabilidade.

    Fonte

    Track machine learning experiments with MLflow on Amazon SageMaker using Snowflake integration (https://aws.amazon.com/blogs/machine-learning/track-machine-learning-experiments-with-mlflow-on-amazon-sagemaker-using-snowflake-integration/)

  • Compreensão de Vídeos Potencializada: TwelveLabs Marengo no Amazon Bedrock

    Desafios na Compreensão de Conteúdo Audiovisual

    Conteúdo de mídia, entretenimento, publicidade, educação e treinamento corporativo combinam elementos visuais, sonoros e de movimento para contar histórias e transmitir informações. Essa complexidade multidimensional supera em muito a simplicidade do texto, onde palavras individuais possuem significados bem definidos. Para sistemas de IA, essa riqueza de informação representa um desafio considerável.

    Um vídeo típico integra diversos elementos simultaneamente: componentes visuais como cenas, objetos e ações; dinâmica temporal expressa através de movimento e transições; elementos de áudio incluindo diálogos, música e efeitos sonoros; além de textos sobrepostos como legendas e capturas. Essa multiplicidade de camadas de informação cria desafios significativos para organizações que precisam buscar em arquivos de vídeo, localizar cenas específicas, categorizar automaticamente e extrair insights de seus ativos de mídia para tomada de decisão efetiva.

    Abordagem Multimodal com Embeddings Especializados

    A solução apresentada pela AWS com o TwelveLabs Marengo utiliza uma arquitetura de múltiplos vetores para criar representações especializadas de diferentes modalidades de conteúdo. Em vez de comprimir toda a informação em um único vetor — abordagem que resulta em perda considerável de nuances — o modelo gera embeddings distintos para cada aspecto do vídeo.

    Embeddings são representações vetoriais densas que capturam significado semântico em um espaço de alta dimensionalidade. Funcionam como impressões digitais numéricas que codificam a essência do conteúdo de forma compreensível e comparável por máquinas. Para texto, um embedding pode capturar que “rei” e “rainha” são conceitos relacionados; para imagens, pode compreender que um retriever dourado e um labrador são ambos cães, apesar de aparências diferentes.

    A arquitetura multivetor do Marengo 3.0 oferece vantagens significativas: cada vetor captura uma modalidade específica, evitando perda de informação; permite buscas flexíveis direcionadas a aspectos particulares do conteúdo — somente visual, apenas áudio ou combinadas; e proporciona precisão superior em cenários complexos enquanto mantém escalabilidade eficiente para grandes volumes de dados videoconteúdo em empresas.

    Integração com Amazon Bedrock e OpenSearch Serverless

    A AWS expandiu as capacidades do Amazon Bedrock para suportar o modelo TwelveLabs Marengo Embed 3.0 com processamento de texto e imagem em tempo real através de inferência síncrona. Essa integração possibilita que negócios implementem funcionalidade de busca em vídeos mais rápida utilizando consultas em linguagem natural, além de viabilizar descoberta interativa de produtos através de sofisticado matching de similaridade de imagens.

    Para armazenar e recuperar embeddings, a solução utiliza Amazon OpenSearch Serverless como banco de dados vetorial. Como banco de dados específico para vetores, o OpenSearch Serverless permite localizar conteúdo similar rapidamente através de busca semântica, sem necessidade de gerenciar servidores ou infraestrutura subjacente.

    O código completo de exemplo está disponível em repositório GitHub, demonstrando como integrar essas tecnologias em uma aplicação prática.

    Como Funciona a Geração de Embeddings de Vídeo

    O Amazon Bedrock utiliza API assíncrona para geração de embeddings de vídeo com o modelo Marengo. Um vídeo típico é processado para gerar múltiplas representações vetoriais especializadas:

    • Embeddings Visuais: capturam elementos visuais do conteúdo
    • Embeddings de Transcrição: representam texto transcrito do áudio
    • Embeddings de Áudio: codificam características sonoras do vídeo

    Por padrão, um único processamento com o Marengo gera embeddings para visual-texto, visual-imagem e áudio. É possível configurar para gerar apenas tipos específicos de embedding conforme necessário.

    O processamento segmenta automaticamente o vídeo em clips. Para vídeo, a divisão ocorre em mudanças naturais de cena (shot boundaries). Para áudio, os segmentos são divididos em durações próximas a 10 segundos — por exemplo, áudio de 50 segundos resulta em 5 segmentos de 10 segundos cada.

    Preparando o Ambiente

    Antes de começar a implementação, é necessário verificar alguns pré-requisitos:

    Para demonstração prática, a solução utiliza Netflix Open Content, conteúdo de código aberto disponível sob licença Creative Commons Attribution 4.0 International. Especificamente, um vídeo chamado Meridian é usado para demonstrar o funcionamento do modelo.

    Criando Embeddings de Vídeo

    O seguinte fragmento de código Python mostra um exemplo de invocação da API que processa um vídeo armazenado em um bucket S3:

    bedrock_client = boto3.client("bedrock-runtime")
    model_id = 'us.twelvelabs.marengo-embed-3-0-v1:0'
    video_s3_uri = ""
    aws_account_id = ""
    s3_bucket_name = ""
    s3_output_prefix = ""
    
    response = bedrock_client.start_async_invoke(
        modelId=model_id,
        modelInput={
            "inputType": "video",
            "video": {
                "mediaSource": {
                    "s3Location": {
                        "uri": video_s3_uri,
                        "bucketOwner": aws_account_id
                    }
                }
            }
        },
        outputDataConfig={
            "s3OutputDataConfig": {
                "s3Uri": f's3://{s3_bucket_name}/{s3_output_prefix}'
            }
        }
    )

    Um vídeo típico processado desta forma gera 280 embeddings individuais — um para cada segmento — viabilizando busca temporal precisa e análise detalhada. A saída inclui embeddings multimodais com estrutura similar a esta:

    [
        {
            'embedding': [0.053192138671875,...],
            'embeddingOption': "visual",
            'embeddingScope': "clip",
            "startSec": 0.0,
            "endSec": 4.3
        },
        {
            'embedding': [0.053192138645645,...],
            'embeddingOption': "transcription",
            'embeddingScope': "clip",
            "startSec": 3.9,
            "endSec": 6.5
        },
        {
            'embedding': [0.3235554er443524,...],
            'embeddingOption': "audio",
            'embeddingScope': "clip",
            "startSec": 4.9,
            "endSec": 7.5
        }
    ]

    Para personalizar o processamento, é possível utilizar o seguinte fragmento com opções configuráveis:

    response = bedrock_client.start_async_invoke(
        modelId=model_id,
        modelInput={
            "modelId": model_id,
            "modelInput": {
                "inputType": "video",
                "video": {
                    "mediaSource": {
                        "base64String": "base64-encoded string",
                        "s3Location": {
                            "uri": "s3://amzn-s3-demo-bucket/video/clip.mp4",
                            "bucketOwner": "123456789012"
                        }
                    },
                    "startSec": 0,
                    "endSec": 6,
                    "segmentation": {
                        "method": "dynamic",
                        "dynamic": {
                            "minDurationSec": 4
                        },
                        "method": "fixed",
                        "fixed": {
                            "durationSec": 6
                        }
                    },
                    "embeddingOption": ["visual", "audio", "transcription"],
                    "embeddingScope": ["clip", "asset"]
                },
                "inferenceId": "some inference id"
            }
        }
    )

    Consulte a documentação completa para conhecer toda funcionalidade suportada.

    Configurando o Índice no OpenSearch Serverless

    Após criar uma coleção no OpenSearch Serverless, é necessário criar um índice que contenha propriedades adequadas para armazenar embeddings vetoriais. O seguinte código demonstra essa configuração:

    index_mapping = {
        "mappings": {
            "properties": {
                "video_id": {"type": "keyword"},
                "segment_id": {"type": "integer"},
                "start_time": {"type": "float"},
                "end_time": {"type": "float"},
                "embedding": {
                    "type": "dense_vector",
                    "dims": 1024,
                    "index": True,
                    "similarity": "cosine"
                },
                "metadata": {"type": "object"}
            }
        }
    }

    Indexando os Embeddings do Marengo

    Após gerar os embeddings, é necessário ingeri-los no índice do OpenSearch. O fragmento abaixo demonstra esse processo:

    documents = []
    for i, segment in enumerate(video_embeddings):
        document = {
            "embedding": segment["embedding"],
            "start_time": segment["startSec"],
            "end_time": segment["endSec"],
            "video_id": video_id,
            "segment_id": i,
            "embedding_option": segment.get("embeddingOption", "visual")
        }
        documents.append(document)
    
    bulk_data = []
    for doc in documents:
        bulk_data.append({"index": {"_index": self.index_name}})
        bulk_data.append(doc)
    
    bulk_body = "\n".join(json.dumps(item) for item in bulk_data) + "\n"
    response = oss_client.bulk(body=bulk_body, index=self.index_name)

    Busca Semântica Cruzada Entre Modalidades

    Uma das grandes vantagens do design multivetor do Marengo é permitir buscas cruzadas entre diferentes modalidades — capacidade impossível com modelos de vetor único. Criando embeddings separados mas alinhados para elementos visuais, áudio, movimento e contexto, é possível buscar vídeos utilizando o tipo de entrada que for mais conveniente.

    Por exemplo, uma consulta por texto “jazz tocando” retorna clipes de vídeo com músicos em apresentação, faixas de áudio de jazz e cenas de salas de concerto extraídas de uma única consulta textual.

    Busca por Texto

    O seguinte fragmento demonstra capacidade de busca semântica cruzada utilizando texto:

    text_query = "a person smoking in a room"
    modelInput={
        "inputType": "text",
        "text": {
            "inputText": text_query
        }
    }
    response = self.bedrock_client.invoke_model(
        modelId="us.twelvelabs.marengo-embed-3-0-v1:0",
        body=json.dumps(modelInput))
    result = json.loads(response["body"].read())
    query_embedding = result["data"][0]["embedding"]
    
    search_body = {
        "query": {
            "knn": {
                "embedding": {
                    "vector": query_embedding,
                    "k": top_k
                }
            }
        },
        "size": top_k,
        "_source": ["start_time", "end_time", "video_id", "segment_id"]
    }
    response = opensearch_client.search(index=self.index_name, body=search_body)
    
    print(f"\n✅ Found {len(response['hits']['hits'])} matching segments:")
    results = []
    for hit in response['hits']['hits']:
        result = {
            "score": hit["_score"],
            "video_id": hit["_source"]["video_id"],
            "segment_id": hit["_source"]["segment_id"],
            "start_time": hit["_source"]["start_time"],
            "end_time": hit["_source"]["end_time"]
        }
        results.append(result)

    Busca por Imagem

    O modelo também suporta busca semântica iniciada a partir de uma imagem. O fragmento seguinte demonstra essa funcionalidade:

    s3_image_uri = f's3://{self.s3_bucket_name}/{self.s3_images_path}/{image_path_basename}'
    s3_output_prefix = f'{self.s3_embeddings_path}/{self.s3_images_path}/{uuid.uuid4()}'
    modelInput={
        "inputType": "image",
        "image": {
            "mediaSource": {
                "s3Location": {
                    "uri": s3_image_uri,
                    "bucketOwner": self.aws_account_id
                }
            }
        }
    }
    response = self.bedrock_client.invoke_model(
        modelId=self.cris_model_id,
        body=json.dumps(modelInput),
    )
    result = json.loads(response["body"].read())
    
    query_embedding = result["data"][0]["embedding"]
    
    search_body = {
        "query": {
            "knn": {
                "embedding": {
                    "vector": query_embedding,
                    "k": top_k
                }
            }
        },
        "size": top_k,
        "_source": ["start_time", "end_time", "video_id", "segment_id"]
    }
    response = opensearch_client.search(index=self.index_name, body=search_body)

    Busca por Áudio

    Além de buscas textuais e visuais, o modelo Marengo também possibilita buscar vídeos utilizando embeddings de áudio, com foco em diálogo e fala. Essa capacidade permite que usuários localizem vídeos com base em palestrantes específicos, conteúdo de diálogo ou tópicos falados, criando uma experiência de busca abrangente que combina texto, imagem e áudio para compreensão integrada do conteúdo videoconteúdo.

    Impacto Prático

    A combinação do TwelveLabs Marengo com Amazon Bedrock abre possibilidades significativas para compreensão de vídeos através de sua abordagem multimodal de múltiplos vetores. Uma chamada única à API do Bedrock transformou um arquivo de vídeo em 336 segmentos pesquisáveis capazes de responder a consultas textuais, visuais e de áudio.

    Essas capacidades criam oportunidades para descoberta de conteúdo em linguagem natural, gerenciamento simplificado de ativos de mídia e outras aplicações que auxiliam organizações a compreender melhor e utilizar seu acervo de conteúdo videoconteúdo em escala. Conforme vídeo continua dominando experiências digitais, modelos como o Marengo oferecem fundação sólida para construir sistemas de análise de vídeo mais inteligentes.

    Explore o código de exemplo e descubra como compreensão de vídeo multimodal pode transformar suas aplicações.

    Fonte

    Unlocking video understanding with TwelveLabs Marengo on Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/unlocking-video-understanding-with-twelvelabs-marengo-on-amazon-bedrock/)

  • AWS Security Incident Response integra-se com Slack para resposta a incidentes de segurança

    Colaboração em tempo real para resposta a incidentes

    A AWS Security Incident Response agora oferece integração com o Slack, a plataforma colaborativa baseada em nuvem amplamente utilizada por times de tecnologia. Essa integração possibilita que equipes de segurança se preparem, respondam e se recuperem de eventos de segurança de maneira mais ágil e eficiente, mantendo os fluxos de notificação e comunicação já existentes nas organizações.

    Funcionalidades da integração bidirecional

    A integração oferece sincronização bidirecional completa: os times podem criar e atualizar casos tanto no console do Security Incident Response quanto no Slack, com replicação automática de dados entre as plataformas. Cada caso de incidente de segurança é representado como um canal dedicado no Slack, enquanto comentários e anexos são sincronizados instantaneamente.

    Essa abordagem garante que os responders tenham acesso imediato às informações críticas do caso e possibilita colaboração mais eficiente, independentemente da ferramenta que cada membro do time prefira utilizar. A integração facilita o engajamento mais rápido dos times de segurança, acelerando os tempos de resposta ao adicionar automaticamente os observadores do Security Incident Response ao canal correspondente no Slack.

    Arquitetura modular e extensibilidade

    A solução está disponível como código aberto no repositório GitHub, permitindo que clientes e parceiros personalizem e estendam a funcionalidade conforme suas necessidades específicas. A integração utiliza o EventBridge, o que possibilita que as organizações continuem usando suas ferramentas existentes de gerenciamento de incidentes de segurança e notificações, enquanto aproveitam as capacidades do AWS Security Incident Response.

    Graças à arquitetura modular, há também orientações sobre como utilizar assistentes de Inteligência Artificial, como o Amazon Q Developer ou similares, que facilitam a adição de novos alvos de integração além do Slack.

    Como começar

    Para iniciar o uso da integração do Security Incident Response com Slack, as organizações podem acessar o repositório GitHub da AWS. A documentação técnica para Slack fornece detalhes de implementação, enquanto o Guia do Usuário do serviço oferece informações completas sobre o AWS Security Incident Response.

    Fonte

    AWS Security Incident Response introduces integration with Slack (https://aws.amazon.com/about-aws/whats-new/2025/12/aws-security-incident-response-integration-slack)

  • AWS Artifact agora permite acessar versões anteriores de relatórios de conformidade

    Autoatendimento para histórico de conformidade

    A AWS anunciou uma melhoria importante no serviço Artifact: agora é possível acessar diretamente versões anteriores de relatórios de conformidade sem necessidade de contatar o suporte ou representantes da conta. Esse recurso de autoatendimento foi desenvolvido para ajudar clientes a gerenciar de forma mais eficiente sua documentação de conformidade, especialmente em momentos críticos como auditorias e avaliações de fornecedores, quando é frequente a necessidade de apresentar evidências históricas de conformidade.

    Como acessar as versões anteriores

    Para utilizar esse novo recurso, é necessário contar com a permissão IAM artifact:ListReportVersions, que já está incluída na política gerenciada AWSArtifactReportsReadOnlyAccess. Se você não conseguir visualizar versões anteriores de relatórios no console do Artifact, será necessário entrar em contato com o administrador da sua conta AWS para solicitar essa permissão.

    Uma vez autorizado, o processo é simples: acesse o console do Artifact, navegue até a página de relatórios e selecione qualquer relatório para visualizar suas versões disponíveis. Você poderá consultar relatórios de conformidade anteriores, como SOC, ISO e C5.

    Disponibilidade e cobertura histórica

    A disponibilidade de versões anteriores varia conforme o programa de conformidade. Alguns relatórios oferecem histórico de vários anos anteriores, enquanto outros possuem cobertura histórica mais limitada. O recurso está disponível, no momento, nas regiões US East (N. Virginia) e AWS GovCloud (US-West).

    Implementação prática

    Para organizações que conduzem avaliações periódicas de conformidade, essa funcionalidade representa uma redução significativa no tempo administrativo. Em vez de depender de processos manuais ou do suporte técnico para acessar documentação anterior, as equipes agora podem consultar o histórico completo de forma autônoma e imediata através da interface do console.

    Próximos passos

    Para aprofundar seu conhecimento sobre como acessar versões anteriores de relatórios de conformidade, consulte a documentação técnica do Artifact. Para informações gerais sobre o AWS Artifact, visite a página oficial do serviço.

    Fonte

    AWS Artifact enables access to previous versions of compliance reports (https://aws.amazon.com/about-aws/whats-new/2025/12/aws-artifact-access-previous-versions-compliance-reports)

  • Governança por Design: O Guia Essencial para Escalar IA com Sucesso

    O Dilema da Escalabilidade em IA

    Imagine que sua empresa acaba de colocar em produção seu primeiro aplicativo de IA generativa. Os resultados iniciais são promissores, mas conforme você planeja expandir a solução para outros departamentos, surgem questões críticas: como garantir consistência em políticas de segurança? Como evitar vieses nos modelos? Como manter controle à medida que as aplicações de IA se multiplicam?

    A realidade é que muitas organizações enfrentam esses mesmos desafios. Uma pesquisa de líderes empresariais em 38 países envolvendo mais de 750 executivos revelou tanto desafios quanto oportunidades ao construir uma estratégia de governança. Embora as organizações estejam comprometendo recursos significativos — a maioria planeja investir mais de 1 milhão de dólares em IA responsável — obstáculos de implementação persistem. Mais de 50% dos respondentes apontam lacunas de conhecimento como a barreira primária, enquanto 40% citam incerteza regulatória.

    Porém, há uma luz no fim do túnel. Empresas com programas estabelecidos de IA responsável relatam benefícios substanciais: 42% observam melhor eficiência operacional, enquanto 34% experimentam aumento de confiança dos consumidores. Esses dados demonstram por que uma gestão robusta de riscos é fundamental para desbloquear todo o potencial da IA.

    IA Responsável: Não é Negociável Desde o Primeiro Dia

    A AWS, através de seu centro de inovação em IA generativa, tem observado que organizações com resultados mais sólidos incorporam governança em sua essência desde o início. Essa visão alinha-se com o compromisso da AWS com desenvolvimento responsável de IA, evidenciado pelo lançamento recente do framework AWS Well-Architected para IA Responsável, um guia abrangente para implementar práticas responsáveis ao longo de todo o ciclo de vida do desenvolvimento.

    O centro de inovação tem aplicado consistentemente esses princípios abraçando uma filosofia de “responsabilidade por design”, delimitando cuidadosamente casos de uso e seguindo orientações validadas cientificamente. Essa abordagem resultou na criação da solução AI Risk Intelligence (AIRI), que transforma essas melhores práticas em controles de governança automatizados e acionáveis — tornando a implementação de IA responsável tanto alcançável quanto escalável.

    Quatro Estratégias para Deployments Seguros de IA Generativa

    Com base na experiência de ajudar mais de mil organizações em diversos setores e geografias, aqui estão estratégias-chave para integrar controles robustos de governança e segurança no desenvolvimento, revisão e deployment de aplicações de IA através de um processo automatizado e contínuo.

    1. Adotar uma Mentalidade de Governança por Design

    No centro de inovação, trabalham diariamente com organizações na vanguarda da adoção de IA generativa e agentic. Um padrão consistente emerge: enquanto a promessa da IA generativa seduz líderes de negócios, eles frequentemente enfrentam dificuldades em traçar um caminho rumo a uma implementação responsável e segura. As organizações que alcançam resultados mais impressionantes estabelecem uma mentalidade de governança por design desde o início — tratando gerenciamento de riscos de IA e considerações de IA responsável como elementos fundamentais, não como checkboxes de conformidade.

    Essa abordagem transforma governança de uma barreira percebida em uma vantagem estratégica para inovar mais rapidamente, mantendo controles apropriados. Ao incorporar governança no próprio processo de desenvolvimento, essas organizações conseguem escalar suas iniciativas de IA com maior confiança e segurança.

    2. Alinhar Tecnologia, Negócios e Governança

    A missão principal do centro de inovação é ajudar clientes a desenvolver e implementar soluções de IA que atendam às necessidades empresariais, aproveitando otimamente os serviços da AWS. Porém, exploração técnica deve caminhar lado a lado com planejamento de governança. Pense nisto como coordenar uma orquestra — você não dirigiria uma sinfonia sem compreender como cada instrumento funciona e como harmonizam juntos. Similarmente, uma governança efetiva de IA exige compreensão profunda da tecnologia subjacente antes de implementar controles.

    O centro ajuda organizações a estabelecer conexões claras entre capacidades tecnológicas, objetivos de negócios e requisitos de governança desde o início, garantindo que esses três elementos trabalhem em conjunto.

    3. Integrar Segurança como Base da Governança

    Após estabelecer uma mentalidade de governança por design e alinhar objetivos de negócios, tecnologia e governança, o próximo passo crucial é a implementação. A experiência mostra que segurança serve como o ponto de entrada mais efetivo para operacionalizar governança abrangente de IA. Segurança não apenas oferece proteção vital, mas também suporta inovação responsável construindo confiança na fundação de sistemas de IA.

    A abordagem enfatizada pelo centro de inovação privilegia segurança-por-design ao longo de toda a jornada de implementação, desde proteção básica de infraestrutura até detecção sofisticada de ameaças em workflows complexos. Para suportar essa abordagem, a AWS oferece capacidades como o AWS Security Agent, que automatiza validação de segurança ao longo do ciclo de vida do desenvolvimento. Esse agente fronteiriço realiza revisões de segurança customizadas e testes de penetração baseados em padrões definidos centralmente, ajudando organizações a escalar sua expertise em segurança para acompanhar a velocidade de desenvolvimento.

    Essa abordagem focada em segurança ancora um conjunto mais amplo de controles de governança. O framework AWS de IA Responsável unifica justiça, explicabilidade, privacidade e segurança, segurança, controlabilidade, veracidade e robustez, governança e transparência em uma abordagem coerente. Conforme sistemas de IA se integram profundamente aos processos empresariais e tomada de decisão autônoma, automatizar esses controles mantendo supervisão rigorosa torna-se crucial para escalar com êxito.

    4. Automatizar Governança em Escala Corporativa

    Com os elementos fundamentais em lugar — mentalidade, alinhamento e controles de segurança — organizações precisam de um meio para escalar sistematicamente seus esforços de governança. É aqui que a solução AIRI entra. Em vez de criar novos processos, ela operacionaliza os princípios e controles discutidos através de automação, em uma abordagem faseada. A arquitetura da solução integra-se perfeitamente aos workflows existentes através de um processo em três etapas: entrada do usuário, avaliação automatizada e insights acionáveis.

    A solução analisa tudo, desde código-fonte até documentação de sistemas, usando técnicas avançadas como processamento automatizado de documentos e avaliações baseadas em modelos de linguagem para conduzir avaliações abrangentes de risco. Mais importante, ela realiza testes dinâmicos de sistemas de IA generativa, verificando consistência semântica e vulnerabilidades potenciais enquanto se adapta aos requisitos específicos de cada organização e padrões industriais.

    Da Teoria à Prática

    A verdadeira medida de uma governança de IA efetiva é como ela evolui com uma organização mantendo padrões rigorosos em escala. Quando implementada com êxito, governança automatizada permite que times se concentrem em inovação, confiantes de que seus sistemas de IA operam dentro de guardrails apropriados.

    Um exemplo compelling vem da colaboração com Ryanair, o maior grupo de companhias aéreas da Europa. Enquanto escalam em direção a 300 milhões de passageiros até 2034, a Ryanair precisava de governança de IA responsável para sua aplicação de tripulação de cabine, que fornece ao pessoal de frente linhas informações operacionais cruciais. Usando Amazon Bedrock, o centro de inovação conduziu uma avaliação alimentada por IA. Isso estabeleceu gerenciamento de risco transparente e baseado em dados onde riscos eram previamente difíceis de quantificar — criando um modelo de governança de IA responsável que a Ryanair agora pode expandir por toda sua carteira de IA.

    Essa implementação demonstra o impacto mais amplo de governança sistemática de IA. Organizações usando esse framework reportam consistentemente caminhos acelerados para produção, redução de trabalho manual e capacidades aprimoradas de gerenciamento de risco. Mais importante ainda, alcançaram forte alinhamento entre funções, desde times de tecnologia até legal e segurança — todos trabalhando a partir de objetivos claros e mensuráveis.

    Uma Fundação para Inovação

    Governança de IA responsável não é uma restrição — é um catalisador. Ao incorporar governança na urdidura do desenvolvimento de IA, organizações podem inovar com confiança, sabendo que possuem controles para escalar segura e responsavelmente. O exemplo acima demonstra como governança automatizada transforma frameworks teóricos em soluções práticas que impulsionam valor comercial mantendo confiança.

    Para aprender mais, consulte as informações sobre o centro de inovação em IA generativa da AWS e como estão ajudando organizações de diferentes tamanhos implementar IA responsável para complementar seus objetivos empresariais.

    Fonte

    Governance by design: The essential guide for successful AI scaling (https://aws.amazon.com/blogs/machine-learning/governance-by-design-the-essential-guide-for-successful-ai-scaling/)

  • AWS Direct Connect chega a Hanói com primeira localização no Vietnã

    Nova Localização de Direct Connect no Vietnã

    Em dezembro de 2025, a AWS anunciou a abertura de uma nova localização de AWS Direct Connect dentro da CMC Tower em Hanói, Vietnã. Este é o primeiro ponto de presença do serviço Direct Connect no país e marca uma expansão significativa da infraestrutura da AWS na região do Sudeste Asiático.

    A partir dessa localização, é possível estabelecer acesso privado e direto a todas as regiões públicas da AWS (com exceção daquelas localizadas na China), ao AWS GovCloud, bem como às AWS Local Zones. Isso abre novas possibilidades para empresas vietnamitas e da região que buscam conectividade otimizada com a infraestrutura de nuvem global da AWS.

    Capacidades e Velocidades de Conexão

    A localização em Hanói oferece opções de conectividade em múltiplas velocidades. Os clientes podem contratar conexões dedicadas de 1 Gbps, 10 Gbps e 100 Gbps conforme suas necessidades. Para as conexões de maior capacidade (10 Gbps e 100 Gbps), a AWS disponibiliza criptografia MACsec, garantindo camadas adicionais de segurança para dados em trânsito.

    Entendendo o AWS Direct Connect

    O serviço AWS Direct Connect funciona como um intermediário que estabelece uma conexão física e privada entre a infraestrutura da AWS e os ambientes locais dos clientes — que podem ser datacenters, escritórios ou ambientes de colocação. Diferentemente das conexões convencionais pela internet pública, as conexões via Direct Connect proporcionam uma experiência de rede mais consistente e previsível, com menor latência e maior confiabilidade.

    Expansão Global da Rede de Direct Connect

    A nova localização em Hanói se integra à rede global da AWS Direct Connect, que agora conta com mais de 149 localizações espalhadas pelo mundo. Essa expansão contínua reflete o compromisso da AWS em trazer conectividade de alta qualidade para regiões emergentes e mercados em crescimento.

    Para obter mais informações sobre todas as localizações disponíveis do Direct Connect em todo o mundo, os usuários podem consultar a seção dedicada nos detalhes do produto. Além disso, há um guia de primeiros passos disponível para quem deseja aprender como adquirir e implantar o serviço Direct Connect.

    Fonte

    AWS Direct Connect announces new location in Hanoi, Vietnam (https://aws.amazon.com/about-aws/whats-new/2025/12/aws-direct-connect-hanoi/)