Blog

  • Métricas Aprimoradas para Endpoints do Amazon SageMaker AI: Visibilidade Mais Profunda para Melhor Performance

    Monitoramento Granular de Modelos em Produção

    Executar modelos de aprendizado de máquina em ambiente produtivo vai muito além de simplesmente garantir infraestrutura resiliente e escalabilidade eficiente. É preciso manter visibilidade contínua sobre o desempenho e a utilização de recursos. Quando a latência aumenta, invocações falham ou recursos ficam sobrecarregados, é necessário diagnosticar e resolver os problemas rapidamente, antes que eles impactem os clientes.

    Até o momento, o Amazon SageMaker AI fornecia métricas do Amazon CloudWatch com visibilidade útil em alto nível. Porém, essas eram métricas agregadas — combinando dados de todas as instâncias e containers. Embora adequadas para monitoramento geral de saúde, essas métricas agregadas obscureciam detalhes de instâncias e containers individuais, dificultando a identificação de gargalos, otimização de recursos e resolução de problemas.

    O Que Mudou: Métricas Aprimoradas

    O SageMaker AI agora oferece métricas aprimoradas com frequência de publicação configurável. Esse lançamento fornece a visibilidade granular necessária para monitorar, diagnosticar e melhorar endpoints em produção.

    Com as métricas aprimoradas do SageMaker AI, é possível agora investigar detalhes em nível de container e instância, oferecendo capacidades como:

    • Visualizar métricas de cópias específicas de modelos. Quando múltiplas cópias de modelos são implantadas em um endpoint do SageMaker AI usando Inference Components, é útil visualizar métricas por cópia de modelo, como requisições simultâneas, utilização de GPU e utilização de CPU, para diagnosticar problemas e entender os padrões de tráfego de workloads em produção.
    • Calcular o custo de cada modelo. Quando múltiplos modelos compartilham a mesma infraestrutura, calcular o custo real por modelo pode ser complexo. Com métricas aprimoradas, agora é possível calcular e associar custo por modelo rastreando a alocação de GPU em nível de componente de inferência.

    Categorias de Métricas Aprimoradas

    As métricas aprimoradas introduzem duas categorias com múltiplos níveis de granularidade:

    Métricas de Utilização de Recursos EC2

    Rastreiam consumo de CPU, GPU e memória em nível de instância e container.

    Métricas de Invocação

    Monitoram padrões de requisição, erros, latência e concorrência com dimensões precisas.

    Cada categoria oferece diferentes níveis de visibilidade dependendo da configuração do endpoint.

    Métricas em Nível de Instância

    Todos os endpoints do SageMaker AI agora têm acesso a métricas em nível de instância, fornecendo visibilidade do que acontece em cada instância Amazon Elastic Compute Cloud (Amazon EC2) no endpoint.

    Utilização de Recursos

    Rastreie utilização de CPU, consumo de memória e utilização e consumo de memória por GPU em cada host. Quando um problema ocorre, é possível identificar imediatamente qual instância específica precisa de atenção. Para instâncias baseadas em aceleradores, você verá métricas de utilização para cada acelerador individual.

    Métricas de Invocação

    Monitore padrões de requisição, erros e latência investigando até o nível de instância. Acompanhe invocações, erros 4XX/5XX, latência do modelo e latência de overhead com dimensões precisas que ajudam a identificar exatamente qual instância experimentou problemas. Essas métricas ajudam a diagnosticar distribuição desigual de tráfego, identificar instâncias propensas a erros e correlacionar problemas de performance com recursos específicos.

    Métricas em Nível de Container

    Se você usa Inference Components para hospedar múltiplos modelos em um único endpoint, agora tem visibilidade em nível de container.

    Utilização de Recursos

    Monitore consumo de recursos por container. Visualize utilização de CPU, memória, GPU e consumo de memória de GPU para cada cópia de modelo. Essa visibilidade ajuda a entender quais componentes de inferência estão consumindo recursos, manter alocação justa em cenários multi-tenant e identificar containers com problemas de performance. Essas métricas detalhadas incluem dimensões para InferenceComponentName (Nome do Componente de Inferência) e ContainerId (ID do Container).

    Métricas de Invocação

    Rastreie padrões de requisição, erros e latência em nível de container. Monitore invocações, erros 4XX/5XX, latência do modelo e latência de overhead com dimensões precisas que ajudam a identificar exatamente onde os problemas ocorreram.

    Como Configurar Métricas Aprimoradas

    Ativar métricas aprimoradas é simples: adicione um parâmetro ao criar a configuração do endpoint:

    response = sagemaker_client.create_endpoint_config(
        EndpointConfigName='my-config',
        ProductionVariants=[{
            'VariantName': 'AllTraffic',
            'ModelName': 'my-model',
            'InstanceType': 'ml.g6.12xlarge',
            'InitialInstanceCount': 2
        }],
        MetricsConfig={
            'EnableEnhancedMetrics': True,
            'MetricsPublishFrequencyInSeconds': 10,  # Default 60s
        }
    )

    Escolhendo a Frequência de Publicação

    Após ativar métricas aprimoradas, configure a frequência de publicação conforme suas necessidades de monitoramento:

    • Resolução Padrão (60 segundos): A frequência padrão oferece visibilidade detalhada para a maioria dos workloads em produção. É suficiente para planejamento de capacidade, resolução de problemas e otimização, mantendo custos do CloudWatch gerenciáveis.
    • Alta Resolução (10 ou 30 segundos): Para aplicações críticas que exigem monitoramento quase em tempo real, ative publicação a cada 10 segundos. Isso é valioso para auto-scaling agressivo, padrões de tráfego altamente variáveis ou troubleshooting profundo.

    Casos de Uso Práticos

    As métricas aprimoradas oferecem valor comercial mensurável em cenários comuns. Exemplos completos estão disponíveis em um notebook.

    Rastreamento em Tempo Real de Utilização de GPU em Inference Components

    Ao executar múltiplos modelos em infraestrutura compartilhada usando Inference Components, entender a alocação e utilização de GPU é crítico para otimização de custos e ajuste de performance.

    Com métricas aprimoradas, é possível consultar alocação de GPU por componente de inferência:

    response = cloudwatch.get_metric_data(
        MetricDataQueries=[
            {
                'Id': 'm1',
                'Expression': 'SEARCH(\'{/aws/sagemaker/InferenceComponents,InferenceComponentName,GpuId} MetricName="GPUUtilizationNormalized" InferenceComponentName="IC-my-model"\', \'SampleCount\', 10)'
            },
            {
                'Id': 'e1',
                'Expression': 'SUM(m1)'  # Returns GPU count
            }
        ],
        StartTime=start_time,
        EndTime=end_time
    )

    Essa consulta usa a dimensão GpuId para contar GPUs individuais alocadas a cada componente de inferência. Rastreando a estatística SampleCount, você obtém uma contagem precisa de GPUs em uso para um Inference Component específico, essencial para:

    • Validar que alocação de recursos corresponde à sua configuração
    • Detectar quando componentes de inferência fazem scale up ou down
    • Calcular custos por GPU para modelos de chargeback

    Atribuição de Custo por Modelo em Implantações Multi-Modelo

    Uma das capacidades mais solicitadas é entender o custo real de cada modelo quando múltiplos modelos compartilham a mesma infraestrutura de endpoint. Métricas aprimoradas tornam isso possível através do rastreamento de GPU em nível de container.

    Eis como calcular custo cumulativo por modelo:

    response = cloudwatch.get_metric_data(
        MetricDataQueries=[
            {
                'Id': 'e1',
                'Expression': 'SEARCH(\'{/aws/sagemaker/InferenceComponents,InferenceComponentName,GpuId} MetricName="GPUUtilizationNormalized" InferenceComponentName="IC-my-model"\', \'SampleCount\', 10)'
            },
            {
                'Id': 'e2',
                'Expression': 'SUM(e1)'  # GPU count
            },
            {
                'Id': 'e3',
                'Expression': 'e2 * 5.752 / 4 / 360'  # Cost per 10s based on ml.g6.12xlarge hourly cost
            },
            {
                'Id': 'e4',
                'Expression': 'RUNNING_SUM(e3)'  # Cumulative cost
            }
        ],
        StartTime=start_time,
        EndTime=end_time
    )

    Esse cálculo:

    • Conta GPUs alocadas ao componente de inferência (e2)
    • Calcula custo por período de 10 segundos baseado no custo horário da instância (e3)
    • Acumula custo total ao longo do tempo usando RUNNING_SUM (e4)

    Por exemplo, com uma instância ml.g6.12xlarge ($5.752/hora para 4 GPUs), se seu modelo usa 4 GPUs, o custo por 10 segundos é de $0.016. O RUNNING_SUM fornece um total continuamente crescente, perfeito para dashboards e rastreamento de custos.

    Monitoramento de Recursos em Nível de Cluster

    Métricas aprimoradas habilitam monitoramento abrangente de cluster agregando métricas de todos os componentes de inferência em um endpoint:

    response = cloudwatch.get_metric_data(
        MetricDataQueries=[
            {
                'Id': 'e1',
                'Expression': 'SUM(SEARCH(\'{/aws/sagemaker/InferenceComponents,EndpointName,GpuId} MetricName="GPUUtilizationNormalized" EndpointName="my-endpoint"\', \'SampleCount\', 10))'
            },
            {
                'Id': 'm2',
                'MetricStat': {
                    'Metric': {
                        'Namespace': '/aws/sagemaker/Endpoints',
                        'MetricName': 'CPUUtilizationNormalized',
                        'Dimensions': [
                            {
                                'Name': 'EndpointName',
                                'Value': 'my-endpoint'
                            },
                            {
                                'Name': 'VariantName',
                                'Value': 'AllTraffic'
                            }
                        ]
                    },
                    'Period': 10,
                    'Stat': 'SampleCount'  # Returns instance count
                }
            },
            {
                'Id': 'e2',
                'Expression': 'm2 * 4 - e1'  # Free GPUs (assuming 4 GPUs per instance)
            }
        ],
        StartTime=start_time,
        EndTime=end_time
    )

    Essa consulta oferece:

    • Total de GPUs em uso em todos os componentes de inferência (e1)
    • Número de instâncias no endpoint (m2)
    • GPUs disponíveis para novas implantações (e2)

    Essa visibilidade é crucial para planejamento de capacidade e garantir que você tenha recursos suficientes para novas implantações de modelos ou scaling de modelos existentes.

    Criando Dashboards Operacionais

    O notebook acompanhante demonstra como criar dashboards do CloudWatch programaticamente que combinam essas métricas:

    from endpoint_metrics_helper import create_dashboard
    
    create_dashboard(
        dashboard_name='my-endpoint-monitoring',
        endpoint_name='my-endpoint',
        inference_components=[
            {
                'name': 'IC-model-a',
                'label': 'MODEL_A'
            },
            {
                'name': 'IC-model-b',
                'label': 'MODEL_B'
            }
        ],
        cost_per_hour=5.752,
        region='us-east-1'
    )

    Isso cria um dashboard com:

    • Utilização de recursos em nível de cluster (instâncias, GPUs usadas/não utilizadas)
    • Rastreamento de custo por modelo com totais cumulativos
    • Custo em tempo real por período de 10 segundos

    O notebook também inclui widgets interativos para análise ad-hoc:

    from endpoint_metrics_helper import create_metrics_widget, create_cost_widget
    
    # Cluster metrics
    create_metrics_widget('my-endpoint')
    
    # Per-model cost analysis
    create_cost_widget('IC-model-a', cost_per_hour=5.752)

    Esses widgets oferecem seleção de intervalo de tempo (últimos 5/10/30 minutos, 1 hora ou intervalo personalizado) e exibem:

    • Número de instâncias
    • GPUs totais/usadas/livres
    • Custo cumulativo por modelo
    • Custo por período de 10 segundos

    Melhores Práticas

    • Comece com resolução de 60 segundos: Oferece granularidade suficiente para a maioria dos casos, mantendo custos do CloudWatch gerenciáveis. Note que apenas métricas de Utilização geram cobranças — todos os outros tipos são publicados sem custo adicional.
    • Use resolução de 10 segundos seletivamente: Ative métricas de alta resolução apenas para endpoints críticos ou durante períodos de troubleshooting.
    • Use dimensões estrategicamente: Utilize InferenceComponentName, ContainerId e GpuId para investigar de visualizações em nível de cluster até containers específicos.
    • Crie dashboards de alocação de custos: Use expressões RUNNING_SUM para rastrear custos cumulativos por modelo para chargeback e budgeting precisos.
    • Configure alarmes sobre capacidade de GPU não utilizada: Monitore a métrica de GPU não utilizada para garantir que você mantenha buffer de capacidade para scaling ou novas implantações.
    • Combine com métricas de invocação: Correlacione utilização de recursos com padrões de requisição para entender a relação entre tráfego e consumo de recursos.

    Conclusão

    As Métricas Aprimoradas para Endpoints do Amazon SageMaker AI transformam como você monitora, melhora e opera workloads de aprendizado de máquina em produção. Ao fornecer visibilidade em nível de container com frequência de publicação configurável, você ganha a inteligência operacional necessária para:

    • Atribuir custos com precisão a modelos individuais em implantações multi-tenant
    • Monitorar alocação e utilização de GPU em tempo real em componentes de inferência
    • Rastrear disponibilidade de recursos em nível de cluster para planejamento de capacidade
    • Resolver problemas de performance com métricas granulares e precisas

    A combinação de métricas detalhadas, frequência de publicação flexível e dimensões ricas permite construir soluções de monitoramento sofisticadas que crescem com suas operações de aprendizado de máquina. Seja executando um único modelo ou gerenciando dezenas de componentes de inferência em múltiplos endpoints, métricas aprimoradas oferecem a visibilidade necessária para executar IA eficientemente em escala.

    Comece hoje ativando métricas aprimoradas em seus endpoints do SageMaker AI e explore o notebook acompanhante para exemplos de implementação completos e funções auxiliares reutilizáveis.

    Fonte

    Enhanced metrics for Amazon SageMaker AI endpoints: deeper visibility for better performance (https://aws.amazon.com/blogs/machine-learning/enhanced-metrics-for-amazon-sagemaker-ai-endpoints-deeper-visibility-for-better-performance/)

  • Residência de Dados com Extensões do Amazon Quick para Microsoft Teams

    Conformidade com Residência de Dados em Ambientes Globais

    Organizações distribuídas em múltiplas geografias enfrentam desafios significativos para manter seus dados dentro de limites específicos. Regulamentações como a Lei Geral de Proteção de Dados (LGPD) no Brasil, o Regulamento Geral de Proteção de Dados (GDPR) na Europa, leis de soberania de dados específicas de cada país e políticas de conformidade internas criam um cenário complexo que exige soluções técnicas robustas.

    A Amazon Quick com extensões do Microsoft 365 oferece suporte a roteamento regional, permitindo que organizações mantenham dados em seus locais geográficos apropriados. A plataforma suporta implantações em múltiplas regiões da AWS, direcionando usuários automaticamente para recursos do Amazon Quick específicos de cada região — como agentes de chat, fluxos automatizados, bases de conhecimento e outros componentes.

    Setores altamente regulados, como serviços financeiros, saúde, energia e telecomunicações, adotam esse padrão com frequência para garantir que informações sensíveis permaneçam dentro de fronteiras geográficas específicas. A integração com o Microsoft Teams oferece uma experiência contínua para usuários corporativos que já trabalham dentro do ecossistema Microsoft 365.

    Visão Geral da Solução

    Quando o Amazon Quick é integrado a aplicações Microsoft 365, como o Microsoft Teams, os usuários precisam se autenticar e conectar aos recursos regionais apropriados do Amazon Quick. Este processo garante que cada usuário acesse apenas os agentes de chat e recursos construídos na região AWS designada para sua localização geográfica.

    A solução apresentada aqui utiliza um exemplo prático: uma organização global fictícia (MyCompany) com matriz europeia acessando o Amazon Quick na região Europa (Irlanda) e uma filial nos EUA usando a região Leste dos EUA (N. Virgínia). Uma única conta do Amazon Quick mantém agentes de chat específicos por região, cada um contendo informações corporativas localizadas.

    Para implementar o roteamento regional, é necessário configurar o AWS IAM Identity Center com um emissor de token confiável para autenticação entre sistemas. Esta solução utiliza o Microsoft Entra ID para controle de acesso baseado em grupos, demonstrando como organizações podem rotear automaticamente usuários para suas regiões AWS apropriadas. A extensão do Amazon Quick para Microsoft Teams é o ponto de integração principal neste cenário.

    A arquitetura integra o Microsoft Entra ID com o IAM Identity Center, automatizando o roteamento de usuários entre múltiplas regiões AWS. Ao usar a associação de grupos do Microsoft Entra ID para direcionar usuários a suas implantações regionais designadas do Amazon Quick, organizações mantêm a residência de dados dentro de limites geográficos específicos enquanto oferecem uma experiência consistente a sua força de trabalho global.

    Processo de Implementação

    A implementação segue uma abordagem faseada que começa com configuração no AWS Management Console e culmina na implantação de complementos regionais para os usuários. O processo envolve uma configuração única de identidade e confiança, seguida por um conjunto pequeno de etapas regionais repetidas para cada região AWS ativa.

    As etapas gerais do fluxo de trabalho incluem:

    • Iniciar a configuração no console do Amazon Quick e selecionar a região AWS a configurar
    • Configurar a integração regional da extensão Microsoft Teams, incluindo uma função AWS Identity and Access Management (IAM) e um segredo do AWS Secrets Manager para aquela região AWS, e confiar no IAM Identity Center como um emissor de token
    • Ativar a extensão no Amazon Quick para gerar o arquivo de manifesto regional
    • Registrar os retornos de chamada da extensão na aplicação Microsoft Entra ID e completar o retorno de chamada de ativação para a aplicação em todas as regiões AWS
    • Implantar o complemento Microsoft Teams para grupos de usuários regionais através do Microsoft Entra ID
    • Mapear o complemento regional para seu agente de conhecimento designado, concedendo aos usuários acesso a dados localizados

    Pré-requisitos e Configuração

    Antes de começar a implementação, o ambiente AWS deve atender a requisitos específicos. Para os serviços AWS, é necessário ter uma conta do Amazon Quick ativa, o IAM Identity Center configurado e gerenciando identidades de usuários com integração SAML com Microsoft Entra ID, Secrets Manager disponível em ambas as regiões AWS alvo, e acesso IAM para criar funções e políticas.

    Para o Microsoft 365, os requisitos incluem funções de Administrador Global ou Administrador de Aplicações no Microsoft Entra ID, acesso ao Centro de Administração do Microsoft 365 para implantação de aplicações, e permissões para criar e configurar aplicações corporativas no Microsoft Entra ID.

    Criar Aplicação no Microsoft Entra ID

    O primeiro passo estabelece a base de identidade compartilhada usada por todas as regiões AWS. Cria-se uma aplicação no Microsoft Entra ID que as extensões Microsoft 365 utilizarão para autenticar usuários contra o Amazon Quick através do IAM Identity Center.

    O processo começa selecionando Registros de Aplicação e criando um novo registro com suporte apenas para contas no diretório organizacional. Após o registro, configura-se a guia de Autenticação para adicionar URLs de redirecionamento. A solução utiliza dois URLs de redirecionamento seguindo o padrão https://qbs-cell001.dp.appintegrations.[AWS_REGION].prod.plato.ai.aws.dev/auth/idc-tti/callback:

    • https://qbs-cell001.dp.appintegrations.eu-west-1.prod.plato.ai.aws.dev/auth/idc-tti/callback
    • https://qbs-cell001.dp.appintegrations.us-east-1.prod.plato.ai.aws.dev/auth/idc-tti/callback

    O Microsoft Entra ID usa esses URLs de retorno para devolver a resposta de login do usuário ao IAM Identity Center para a região AWS correta. É essencial usar esses URLs exatos — eles são os valores reais necessários para implantações do Amazon Quick. A aplicação deve receber permissão do Microsoft Graph para User.Read, permitindo que ela faça login de usuários e leia suas informações básicas de perfil.

    Criar Emissores de Token Confiáveis no IAM Identity Center

    Nesta etapa, configuram-se emissores de token confiáveis no IAM Identity Center. Um emissor de token confiável é uma configuração que valida tokens emitidos pelo Microsoft Entra ID, permitindo autenticação entre sistemas para que usuários se movimentem entre Microsoft 365 e AWS sem logins repetidos.

    Na configuração do emissor de token confiável, define-se a URL do emissor no formato https://login.microsoftonline.com/[SEU_ID_LOCATARIO]/v2.0 e um nome descritivo para referência organizacional. Esta configuração é aplicada a cada região AWS onde as extensões serão implantadas.

    Configurar Permissões IAM e Entradas no Secrets Manager

    Para cada região AWS, é necessário criar um segredo no Secrets Manager seguindo a convenção de nomenclatura [NOME_EMPRESA]/MS365/Extensions/[AWS_REGION] contendo as credenciais:

    { "client_id":"[SEU_CLIENT_ID]", "client_secret":"[SEU_CLIENT_SECRET]"}

    Cria-se uma política IAM que concede acesso para ler esses segredos:

    { "Version": "2012-10-17", "Statement": [ { "Sid": "SecretManagerPermissions", "Effect": "Allow", "Action": [ "secretsmanager:GetSecretValue" ], "Resource": [ "[ARN_SECRET_EU_WEST_1]", "[ARN_SECRET_US_EAST_1]" ] }, { "Sid": "TokenIssuerPermissions", "Effect": "Allow", "Action": [ "sso:DescribeTrustedTokenIssuer" ], "Resource": "[ARN_SEU_TTI]" } ] }

    A relação de confiança da função deve permitir que os principais de serviço regionais específicos do Amazon Quick assumam a função:

    { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": [ "eu-west-1.prod.appintegrations.plato.aws.internal", "us-east-1.prod.appintegrations.plato.aws.internal" ] }, "Action": "sts:AssumeRole", "Condition": {} } ] }

    Cada vez que uma nova região AWS é ativada, é necessário criar um novo segredo no Secrets Manager e adicionar seu ARN à lista de recursos da política IAM, além de adicionar a nova região ao campo de Principal de Serviço na relação de confiança da função.

    Configurar Extensões no Amazon Quick

    No console do Amazon Quick, para cada região AWS, realiza-se a seguinte sequência:

    Seleciona-se a região desejada (por exemplo, EU – Irlanda) e acessa-se Gerenciar Quick. Em Permissões na navegação, escolhe-se Acesso de Extensão e adiciona-se um novo acesso de extensão. Configura-se o emissor de token confiável informando seu ARN e o ID do cliente como a alegação de Audiência, que funciona como um identificador de segurança validando que o token de autenticação é utilizado apenas pela aplicação específica para a qual foi destinado.

    Seleciona-se Microsoft Teams entre os tipos de extensão disponíveis e configuração com o ID de locatário Microsoft 365, atributos de segurança e configurações de autenticação. Insere-se um nome descritivo, o ID de locatário Microsoft, o ARN da função Secrets Manager e o ARN do segredo específico da região.

    Ao retornar ao console do Amazon Quick, cria-se uma extensão Microsoft Teams. Ao acessar o menu de opções da extensão (três pontos), escolhe-se Instalar. Este processo cria uma aplicação corporativa no Microsoft Entra ID com URLs únicos e instruções que o Microsoft 365 Teams precisa para comunicar com os ativos AWS regionais específicos.

    Repetem-se esses passos para criar uma extensão e instalar a aplicação na região us-east-1, seguindo a mesma convenção de nomenclatura com o sufixo da região AWS e usando o ARN do segredo apropriado para aquela região.

    Criar Agentes de Chat Regionais

    Após as aplicações regionais serem implantadas, criam-se os agentes específicos de cada região AWS que cada complemento acessará. Cada região AWS mantém seu próprio agente com bases de conhecimento localizadas.

    No console do Amazon Quick de eu-west-1, na navegação, escolhe-se Agentes de Chat e Criar Agente de Chat. Cria-se um agente de chat regional em eu-west-1 com conhecimento corporativo europeu, seguindo a convenção de nomenclatura [NOME_EMPRESA]-Knowledge-Agent-eu-west-1 para facilitar gerenciamento entre múltiplas regiões.

    Repete-se o processo para criar um agente de chat em us-east-1 com informações corporativas específicas dos EUA, denominado [NOME_EMPRESA]-Knowledge-Agent-us-east-1.

    Implantar Aplicações Microsoft Teams

    A etapa final envolve atribuir cada aplicação Microsoft Teams a seus respectivos grupos regionais. No Microsoft Teams Admin Center, acessa-se Aplicativos de Equipe, escolhe-se Gerenciar Aplicativos e filtra-se pela Amazon Quick. Seleciona-se a primeira aplicação (da região eu-west-1) e edita-se sua Disponibilidade.

    É fundamental atribuir a extensão a grupos de usuários regionais específicos em vez de toda a organização. Essa implantação baseada em grupos roteia automaticamente os usuários para seus recursos corretos de conta do Amazon Quick regional.

    Repete-se o mesmo processo com a aplicação Microsoft Teams da região us-east-1.

    Verificar a Implementação

    Após a implantação se propagar, valida-se que usuários são roteados automaticamente para o agente regional correto. Usuários europeus podem utilizar o agente MyCompany-Teams-eu-west-1, embora o complemento selecione Meu Assistente como agente de chat padrão, sendo necessário acessar as configurações (ícone de engrenagem) e escolher o agente de chat MyCompany-Knowledge-Agent-eu-west-1.

    Usuários nos EUA podem utilizar o agente MyCompany-Knowledge-Agent-us-east-1, demonstrando roteamento regional bem-sucedido sem configuração manual.

    Resolução de Problemas Comuns

    Durante a configuração, podem surgir desafios específicos:

    • Extensão do Quick não aparece no Microsoft Teams: Aguardar 24-48 horas para propagação de implantação do Microsoft 365, verificar se o usuário está no grupo Microsoft Entra ID correto e limpar o cache de complementos do Microsoft Office antes de reiniciar Teams
    • Problemas com autenticação na extensão do Amazon Quick: Verificar se os URLs de redirecionamento correspondem exatamente no Microsoft Entra ID, confirmar a configuração do emissor de token confiável e validar que a relação de confiança da função IAM inclui o principal de serviço correto
    • Agente incorreto listado na extensão do Amazon Quick: Verificar a associação ao grupo de usuários (deve estar apenas em um grupo regional), consultar a atribuição de manifesto para grupo no Microsoft 365 Admin Center e solicitar que o usuário faça logout e login novamente
    • Lista de agentes vazia na extensão do Amazon Quick: Validar que o agente está compartilhado com usuários no console do Amazon Quick, verificar se o agente existe na mesma região AWS que a extensão e confirmar que as permissões do agente estão configuradas pelo menos como Nível de Usuário

    Limpeza de Recursos

    Para evitar custos contínuos, recomenda-se remover os recursos criados durante a implementação se eles não forem mais necessários.

    Conclusão

    A solução de extensões do Amazon Quick em múltiplas regiões para Microsoft 365 oferece capacidades de inteligência artificial em conformidade com leis regionais para força de trabalho global. A arquitetura e os passos de implementação apresentados demonstram como integrar IA corporativa com ferramentas de produtividade mantendo limites de residência de dados e conformidade. Para mais detalhes sobre assistentes com tecnologia de IA que aumentam produtividade sem troca de aplicações, consulte Acesso de Extensão. Para iniciar o uso do Amazon Quick, consulte Primeiros Passos com Amazon Quick.

    Fonte

    Enforce data residency with Amazon Quick extensions for Microsoft Teams (https://aws.amazon.com/blogs/machine-learning/enforce-data-residency-with-amazon-quick-extensions-for-microsoft-teams/)

  • AWS anuncia suporte a NIXL com EFA para acelerar inferência de modelos de linguagem em escala

    A integração NIXL com EFA na AWS

    A AWS anunciou o suporte para NIXL (Biblioteca de Transferência de Inferência NVIDIA) em conjunto com EFA (Adaptador de Malha Elástica) para acelerar a inferência desagregada de modelos de linguagem de grande escala executados no Amazon EC2. Esse anúncio representa um avanço significativo para organizações que precisam processar grandes volumes de inferências com performance otimizada.

    Melhorias principais da solução

    A combinação de NIXL com EFA traz três melhorias fundamentais para a inferência desagregada:

    • Throughput aumentado de cache KV: O cache de chave-valor é transferido de forma mais eficiente entre os nós de prefill e decode
    • Latência reduzida entre tokens: Há diminuição no tempo necessário para processar tokens consecutivos, melhorando a responsividade da inferência
    • Otimização de utilização de memória: O cache KV pode ser movimentado de forma mais eficiente entre diferentes camadas de armazenamento

    Como funciona a aceleração de inferência

    O NIXL com EFA possibilita transferências de cache KV entre prefill e decode nodes com alto throughput e baixa latência. Além disso, permite o movimento eficiente do cache KV entre várias camadas de armazenamento, o que é particularmente útil em arquiteturas de inferência complexas que precisam escalar.

    Compatibilidade e integração com frameworks

    A solução é interoperável com todas as instâncias EC2 habilitadas para EFA. O NIXL integra-se nativamente com frameworks populares de inferência, incluindo NVIDIA Dynamo, SGLang e vLLM. Essa compatibilidade oferece flexibilidade para escolher a combinação de instância EC2 e framework que melhor se adequa às necessidades de cada projeto.

    Disponibilidade e requisitos técnicos

    A AWS suporta NIXL versão 1.0.0 ou superior combinado com o instalador EFA versão 1.47.0 ou superior em todos os tipos de instância EC2 habilitadas para EFA. O serviço está disponível em todas as regiões AWS, sem custos adicionais.

    Para mais detalhes técnicos sobre a configuração e implementação, consulte a documentação de EFA.

    Fonte

    AWS adds support for NIXL with EFA to accelerate LLM inference at scale (https://aws.amazon.com/about-aws/whats-new/2026/03/aws-support-nixl-with-efa/)

  • Personalizando Modelos Nova: Um Guia Prático com o SDK Nova Forge

    Democratizando a Customização de Modelos de Linguagem

    A personalização de modelos grandes de linguagem (LLMs) sempre foi uma tarefa desafiadora. Tradicionalmente, equipes enfrentam obstáculos significativos: necessidade de expertise técnica profunda, configuração complexa de infraestrutura e investimento considerável de tempo. A AWS anunciou o SDK Nova Forge precisamente para resolver esse cenário.

    O Nova Forge SDK transforma a customização em um processo acessível e estruturado. Em vez de lidar com dependências complicadas, seleção de imagens e configuração de receitas, os times podem agora focar no que realmente importa: adaptar modelos para seus contextos específicos. A SDK suporta todo o espectro de customização, desde ajustes baseados no Amazon SageMaker até personalizações profundas aproveitando as capacidades completas do Nova Forge.

    Um Caso Prático: Classificando Qualidade de Perguntas

    Para ilustrar como o SDK Nova Forge funciona na prática, a AWS apresenta um cenário real extraído do Stack Overflow. O objetivo é automático: classificar perguntas em três categorias bem definidas (HQ — alta qualidade; LQ_EDIT — qualidade baixa com edições; LQ_CLOSE — qualidade baixa e fechada).

    Moderadores do Stack Overflow enfrentam milhares de perguntas variadas. Uma ferramenta que classifique automaticamente a qualidade libera seus esforços, permitindo priorizar ações e guiar usuários. A solução utiliza o conjunto de dados Stack Overflow Question Quality, com 60 mil perguntas de 2016-2020 distribuídas nas três categorias mencionadas.

    Para os experimentos, a AWS selecionou aleatoriamente 4.700 perguntas, organizadas assim:

    • Treinamento (Ajuste Fino Supervisionado): 3.500 amostras (~75%)
    • Avaliação: 500 amostras (~10%)
    • Ajuste por Reforço: 700 amostras (~15%), combinadas com as 3.500 do treinamento anterior para evitar esquecimento catastrófico

    O experimento segue quatro estágios: avaliação de desempenho base, ajuste fino supervisionado, ajuste por reforço e, finalmente, implantação no Amazon SageMaker Inference.

    Etapa 1: Estabelecendo o Desempenho de Linha de Base

    Antes de qualquer ajuste fino, é essencial medir como o modelo pré-treinado Nova 2.0 se comporta naturalmente. Essa avaliação inicial fornece um ponto de referência concreto para quantificar melhorias futuras. Compreender capacidades do modelo sem refinamento, identificar lacunas de desempenho e validar se ajuste fino é necessário são passos críticos.

    O SDK Nova Forge oferece utilitários poderosos para carregamento de dados que lidam automaticamente com validação e transformação. Usando a classe CSVDatasetLoader, os dados são carregados e transformados para o formato esperado pelos modelos Nova:

    from amzn_nova_forge import (
        NovaModelCustomizer,
        SMTJRuntimeManager,
        TrainingMethod,
        EvaluationTask,
        CSVDatasetLoader,
        Model,
    )
    
    # Configuração geral
    MODEL = Model.NOVA_LITE_2
    INSTANCE_TYPE = 'ml.p5.48xlarge'
    EXECUTION_ROLE = '<YOUR_EXECUTION_ROLE_ARN>'
    S3_BUCKET = '<YOUR_S3_BUCKET>'
    S3_PREFIX = 'stack-overflow'
    EVAL_DATA = './eval.csv'
    
    # Carregar dados
    loader = CSVDatasetLoader(
        query='Body',
        response='Y',
        system='system'
    )
    loader.load(EVAL_DATA)
    loader.transform(method=TrainingMethod.EVALUATION, model=MODEL)
    loader.validate(method=TrainingMethod.EVALUATION, model=MODEL)
    
    # Salvar no S3
    eval_s3_uri = loader.save_data(f"s3://{S3_BUCKET}/{S3_PREFIX}/data/eval.jsonl")

    Com os dados preparados, inicializa-se o gerenciador de runtime e executa-se a avaliação:

    runtime_manager = SMTJRuntimeManager(
        instance_type=INSTANCE_TYPE,
        instance_count=1,
        execution_role=EXECUTION_ROLE
    )
    
    baseline_customizer = NovaModelCustomizer(
        model=MODEL,
        method=TrainingMethod.EVALUATION,
        infra=runtime_manager,
        data_s3_path=eval_s3_uri,
        output_s3_path=f"s3://{S3_BUCKET}/{S3_PREFIX}/baseline-eval"
    )
    
    baseline_result = baseline_customizer.evaluate(
        job_name="blogpost-baseline",
        eval_task=EvaluationTask.GEN_QA
    )

    Os resultados da linha de base revelaram um desempenho inicial de apenas 13,0% de precisão em coincidência exata (EM). Para uma tarefa de classificação em três categorias, adivinhar aleatoriamente resultaria em 33,3%, indicando que o modelo não está seguindo as instruções de formato apropriadamente. A distribuição de respostas mostrava verbosidade excessiva, com explicações longas quando a instrução pedia apenas o nome da categoria.

    Imagem original — fonte: Aws

    Etapa 2: Ajuste Fino Supervisionado para Aprender o Padrão

    Com a linha de base estabelecida, o próximo passo é aplicar Ajuste Fino Supervisionado (SFT — Supervised Fine-Tuning). Essa técnica ensina ao modelo os padrões específicos do domínio e o formato de saída esperado.

    A preparação de dados para SFT segue um processo similar, mas utiliza uma estrutura diferente — o formato de API Converse:

    loader = CSVDatasetLoader(
        question='Body',
        answer='Y',
        system='system'
    )
    loader.load('sft.csv')
    loader.transform(method=TrainingMethod.SFT_LORA, model=Model.NOVA_LITE_2)
    loader.validate(method=TrainingMethod.SFT_LORA, model=Model.NOVA_LITE_2)
    
    train_path = loader.save_data(f"s3://{S3_BUCKET}/{S3_PREFIX}/data/train.jsonl")

    O treinamento é configurado com infraestrutura específica e hiperparâmetros controlados:

    runtime = SMTJRuntimeManager(
        instance_type=INSTANCE_TYPE,
        instance_count=4,
        execution_role=EXECUTION_ROLE
    )
    
    customizer = NovaModelCustomizer(
        model=MODEL,
        method=TrainingMethod.SFT_LORA,
        infra=runtime,
        data_s3_path=train_path,
        output_s3_path=f"s3://{S3_BUCKET}/{S3_PREFIX}/sft-output"
    )
    
    training_config = {
        "lr": 5e-6,
        "warmup_steps": 17,
        "max_steps": 100,
        "global_batch_size": 64,
        "max_length": 8192,
    }
    
    result = customizer.train(
        job_name="blogpost-sft",
        overrides=training_config
    )

    Após o treinamento, a avaliação sobre o mesmo conjunto de dados de teste revelou melhorias expressivas. A precisão em coincidência exata saltou para 77,2%, e a métrica de precisão de classificação extraída chegou a 79,0%. A distribuição de respostas agora mostra 100% de respostas concisas, eliminando a verbosidade problemática.

    Imagem original — fonte: Aws

    Etapa 3: Ajuste por Reforço para Otimizar Precisão

    Embora o SFT tenha ensinado o formato correto, há ainda espaço para melhorar a precisão real das classificações. O Ajuste por Reforço (RFT — Reinforcement Fine-Tuning) usa uma função de recompensa para guiar o modelo em direção a decisões mais precisas.

    A função de recompensa para essa tarefa é binária: +1,0 para predições corretas e -1,0 para incorretas. Uma função Lambda AWS implementa essa lógica, lidando com variações menores no formato de saída:

    def calculate_reward(prediction: str, ground_truth: str) -> float:
        """Calcula recompensa binária"""
        extracted = extract_category(prediction)
        truth_norm = normalize_text(ground_truth)
        
        if extracted and extracted == truth_norm:
            return 1.0
        return -1.0
    
    def lambda_handler(event, context):
        """Handler Lambda com recompensas binárias"""
        scores = []
        for sample in event:
            idx = sample.get("id", "no_id")
            ground_truth = sample.get("reference_answer", "")
            prediction = sample.get("content", "")
            reward = calculate_reward(prediction, ground_truth)
            scores.append({"id": idx, "aggregate_reward_score": reward})
        return scores

    O treinamento RFT é então iniciado a partir do checkpoint SFT anterior:

    REWARD_LAMBDA_ARN = "arn:aws:lambda:us-east-1:ACCOUNT:function:classification-reward"
    
    rft_runtime = SMTJRuntimeManager(
        instance_type=INSTANCE_TYPE,
        instance_count=2,
        execution_role=EXECUTION_ROLE
    )
    
    rft_customizer = NovaModelCustomizer(
        model=MODEL,
        method=TrainingMethod.RFT_LORA,
        infra=rft_runtime,
        data_s3_path=rft_s3_uri,
        output_s3_path=f"s3://{S3_BUCKET}/{S3_PREFIX}/rft-output",
        model_path=sft_checkpoint
    )
    
    rft_overrides = {
        "lr": 0.00001,
        "number_generation": 4,
        "max_new_tokens": 50,
        "kl_loss_coef": 0.02,
        "temperature": 1,
        "ent_coeff": 0.01,
        "max_steps": 40,
        "save_steps": 30,
        "top_k": 5,
        "global_batch_size": 64,
    }
    
    rft_result = rft_customizer.train(
        job_name="stack-overflow-rft",
        rft_lambda_arn=REWARD_LAMBDA_ARN,
        overrides=rft_overrides
    )

    O RFT trouxe melhorias adicionais incrementais. A precisão em coincidência exata aumentou para 78,8%, com a métrica Quasi-EM chegando a 80,6%. Embora o ganho seja menor que o do SFT, indica que o ajuste por reforço refina padrões diferentes, calibrando as decisões do modelo além da simples conformidade de formato.

    Imagem original — fonte: Aws

    Resultados Consolidados

    Comparando todas as três fases — linha de base, pós-SFT e pós-RFT — observam-se ganhos consistentes em praticamente todas as métricas:

    • ROUGE-1: 0,158 → 0,829 → 0,84 (ganho total: +0,682)
    • Precisão em Coincidência Exata (EM): 0,13 → 0,772 → 0,788 (ganho total: +0,658)
    • F1 Score: 0,138 → 0,772 → 0,788 (ganho total: +0,65)

    O SFT proporcionou o maior salto, com ganhos expressivos no aprendizado de padrões específicos do domínio. O RFT refinou a tomada de decisão através de sinais baseados em recompensa, consolidando e otimizando o comportamento do modelo.

    Etapa 4: Implantação no Amazon SageMaker Inference

    Com o modelo final ajustado e testado, chega o momento da implantação para servir predições em produção. O Nova Forge SDK simplifica esse processo oferecendo duas opções: Amazon Bedrock para uma experiência totalmente gerenciada, ou Amazon SageMaker Inference para maior controle sobre a infraestrutura.

    ENDPOINT_NAME = "blogpost-sdkg6"
    
    deployment_result = rft_customizer.deploy(
        job_result=rft_result,
        deploy_platform=DeployPlatform.SAGEMAKER,
        unit_count=1,
        endpoint_name=ENDPOINT_NAME,
        execution_role_name="blogpost-sagemaker",
        sagemaker_instance_type="ml.p5.48xlarge",
        sagemaker_environment_variables={
            "CONTEXT_LENGTH": "12000",
            "MAX_CONCURRENCY": "16"
        }
    )
    
    # Invocar o endpoint
    streaming_chat_request = {
        "messages": [{"role": "user", "content": "sua pergunta aqui"}],
        "max_tokens": 200,
        "stream": True,
    }
    
    inference_result = rft_customizer.invoke_inference(
        request_body=streaming_chat_request,
        endpoint_arn=ENDPOINT_NAME
    )

    Conclusão: Da Complexidade à Acessibilidade

    O SDK Nova Forge transforma a customização de modelos — tradicionalmente um processo complexo e demorado — em um fluxo estruturado e acessível. O caso de estudo do Stack Overflow demonstra isso concretamente: começando em 13% de precisão, o modelo alcançou 79% após ajuste supervisionado e 80,6% após ajuste por reforço.

    A SDK elimina barreiras históricas: não é mais necessário expertise profunda em configuração de infraestrutura, gerenciamento de dependências ou orquestração de pipelines complexos. Organizações podem agora construir modelos especializados e inteligentes, sensíveis ao contexto empresarial específico, sem perder as capacidades gerais que tornam os modelos de fundação tão valiosos.

    Para começar a customizar modelos Nova, a AWS convida a comunidade a explorar o SDK Nova Forge no GitHub e consultar a documentação completa para construir modelos adaptados às necessidades empresariais específicas.

    Fonte

    Kick off Nova customization experiments using Nova Forge SDK (https://aws.amazon.com/blogs/machine-learning/kick-off-nova-customization-experiments-using-nova-forge-sdk/)

  • Motor de Testes A/B Inteligente com Amazon Bedrock

    Superando as limitações dos testes A/B tradicionais

    Empresas dependem frequentemente de testes A/B para otimizar a experiência do usuário, mensagens e fluxos de conversão. No entanto, a abordagem tradicional apresenta desafios significativos: a atribuição aleatória de usuários às variantes, combinada com a necessidade de coletar dados por semanas até atingir significância estatística, torna o processo lento e pode desperdiçar oportunidades de aprendizado.

    A AWS apresenta uma solução baseada em Amazon Bedrock, Amazon Elastic Container Service, Amazon DynamoDB e o Model Context Protocol (MCP) que melhora significativamente os testes A/B tradicionais. Em vez de confiar apenas em atribuição aleatória, o sistema analisa contexto de usuário em tempo real para tomar decisões de variante mais inteligentes durante o experimento, reduzindo ruído, identificando padrões comportamentais mais rapidamente e atingindo um vencedor confiável com maior velocidade.

    Por que a atribuição aleatória limita os resultados

    O fluxo tradicional segue um padrão conhecido: atribuir aleatoriamente usuários às variantes, coletar dados e selecionar o vencedor. Essa abordagem tem limitações claras. A atribuição puramente aleatória ignora sinais iniciais que indicam diferenças significativas. A convergência é lenta — é necessário esperar semanas para coletar dados suficientes. O ruído é alto — o sistema pode atribuir usuários a variantes que claramente não se alinham com suas necessidades. A otimização é manual — frequentemente é preciso segmentar dados posteriori para compreender o resultado.

    Considere um varejista testando dois botões de chamada para ação (CTA) em páginas de produtos. A Variante A apresenta “Compre Agora” e a Variante B, “Compre Agora – Frete Grátis”. Nos primeiros dias, a Variante B se destaca. No entanto, uma análise mais profunda revela algo importante: membros premium com benefício de frete grátis hesitam ao ver a mensagem de “Frete Grátis” e alguns até navegam para verificar seus benefícios. Visitantes orientados a descontos, chegando de sites de cupons, se engajam muito mais com a Variante B. Usuários mobile preferem a Variante A porque o CTA mais curto se ajusta melhor em telas pequenas.

    Embora a Variante B pareça vencer em curto prazo, diferentes grupos de usuários influenciam esse desempenho — não necessariamente uma preferência universal. Como a atribuição é aleatória, o experimento precisa de uma janela longa para balancear esses efeitos, e análises manuais de múltiplos segmentos se tornam necessárias para compreender o resultado. É aqui que a atribuição assistida por inteligência artificial oferece uma melhoria real.

    Transformando testes A/B com inteligência artificial

    Arquitetura do sistema adaptativo

    O motor de testes A/B assistido por IA aprimora a experimentação clássica utilizando contexto de usuário em tempo real e padrões comportamentais iniciais para fazer atribuições de variante mais inteligentes. A solução introduz um mecanismo adaptativo construído com Amazon Bedrock, onde em vez de confirmar cada usuário a mesma variante, o motor avalia o contexto do usuário em tempo real, recupera dados comportamentais passados e seleciona uma variante ideal para aquele indivíduo específico.

    A arquitetura inclui componentes-chave: Amazon CloudFront + AWS WAF para rede de distribuição de conteúdo global com proteção contra negação de serviço distribuído, prevenção de injeção SQL e limitação de taxa; uma Origem VPC com conexão privada do CloudFront para um Load Balancer de Aplicação interno; Amazon ECS com AWS Fargate para orquestração serverless de contêineres rodando aplicação FastAPI; Amazon Bedrock como mecanismo de decisão de IA utilizando Claude Sonnet com suporte nativo a chamada de ferramentas; o Model Context Protocol (MCP) proporcionando acesso estruturado a dados de comportamento e experimentos; VPC Endpoints para conectividade privada a diversos serviços AWS; Amazon DynamoDB com cinco tabelas para experimentos, eventos, atribuições, perfis e trabalhos em lote; e Amazon Simple Storage Service (Amazon S3) para hospedagem de frontend estático e armazenamento de logs de eventos.

    Como a inteligência artificial melhora as decisões

    A inovação central reside em combinar contexto de usuário, histórico comportamental, padrões de usuários similares e dados de desempenho em tempo real para selecionar a variante ideal. Quando um usuário dispara uma solicitação de variante, o sistema constrói um prompt abrangente que fornece ao Amazon Bedrock todo o conteúdo necessário para uma decisão informada.

    O prompt combina dois níveis: um prompt de sistema que define o Amazon Bedrock como “especialista em otimização de testes A/B” com acesso a onze ferramentas MCP e regras críticas (verificar atribuições existentes primeiro, aplicar limite de 30% para mudanças, responder apenas em JSON); e um prompt de usuário que fornece contexto completo de decisão incluindo atributos de usuário, dados de personalização, configurações de variante formatadas dinamicamente, métricas de desempenho em tempo real e um framework de cinco passos para decisão.

    A estrutura em dois níveis permite que o Amazon Bedrock orquestre inteligentemente chamadas de ferramentas e faça seleções de variante baseadas em dados com total transparência. Para um novo usuário mobile, o sistema pode chamar análise de usuários similares e descobrir que 23% mais usuários mobile convertem com a Variante B. Para um cliente premium retornando, pode chamar o perfil do usuário e descobrir que o histórico sugere manter a Variante A atual. Cada situação dispara uma estratégia de coleta de dados diferente.

    Comparação com aprendizado de máquina tradicional

    Modelos tradicionais de aprendizado de máquina — árvores de decisão, regressão logística, redes neurais — impulsionaram segmentação de usuários por anos. Por que usar Amazon Bedrock então?

    Orquestração inteligente de ferramentas: aprendizado de máquina tradicional requer engenharia de características hard-coded. O Amazon Bedrock, através do Model Context Protocol, decide inteligentemente quais ferramentas chamar baseado na situação específica. Um novo usuário dispara análise de similaridade; um cliente retornando dispara análise de perfil; casos especiais podem disparar todas as ferramentas.

    Síntese de raciocínio multifatorial: modelos tradicionais de aprendizado de máquina produzem previsões sem explicação. O Amazon Bedrock fornece raciocínio que sintetiza múltiplos fatores. Uma decisão pode articular como restrições de dispositivo, padrões de usuários similares e métricas de engajamento pessoal combinam-se para informar a seleção.

    Tratamento de sinais conflitantes: quando sinais entram em conflito, o Amazon Bedrock raciocina através dos trade-offs. Se a Variante A tem taxa de conversão agregada mais alta, mas usuários similares ao cliente atual mostram 34% de aumento com a Variante B, o sistema pondera essas informações e explica sua decisão final.

    Sem treinamento, adaptação instantânea: aprendizado de máquina tradicional requer coleta de dados históricos, engenharia de características e treinamento periódico de modelo. O Amazon Bedrock funciona imediatamente, começando com padrões de usuários similares existentes no Dia 1 e refinando com dados de resultado acumulados nos dias seguintes.

    Implementação do mecanismo adaptativo

    Estratégia híbrida de atribuição

    A implementação utiliza uma abordagem inteligente: usuários novos recebem atribuição baseada em hash (eficiente em custo), enquanto usuários retornando recebem seleção baseada em IA (alto valor).

    Para usuários novos, não há dados comportamentais, portanto análise de IA fornece valor mínimo. A atribuição baseada em hash oferece experiência consistente enquanto dados são coletados.

    Para usuários retornando, o backend invoca o Amazon Bedrock que utiliza o Model Context Protocol para acessar dados comportamentais através de um sistema de orquestração inteligente de ferramentas. Em vez de inserir todos os dados no prompt (caro e lento), o Amazon Bedrock chamadas ferramentas seletivamente para reunir exatamente a informação necessária.

    Framework de ferramentas MCP e execução

    O Model Context Protocol (MCP) fornece ao Amazon Bedrock acesso estruturado aos dados comportamentais através de um sistema inteligente de orquestração de ferramentas. A resposta do Amazon Bedrock pode incluir chamadas de ferramentas que o backend FastAPI executa, retornando o resultado e continuando a conversa. Esse loop continua até o modelo produzir a decisão final em JSON.

    As ferramentas principais incluem: get_similar_users() que encontra usuários com padrões comportamentais similares usando correspondência baseada em cluster, calculando scores de similaridade (0.0-1.0) derivados de similaridade de scores de engajamento (30%), correspondência de estilo de interação (20%), sobreposição de preferências de conteúdo (20%), similaridade de probabilidade de conversão (15%) e correspondência de preferência visual (15%); get_user_profile() que recupera perfil comportamental abrangente incluindo sinais comportamentais, preferências, dados de desempenho e contexto de dispositivo; get_variant_performance() que recupera dados de desempenho em tempo real com métricas atuais, dados históricos e metadados de período de tempo.

    Armazenando insights para decisões futuras

    Após cada seleção de variante, o sistema registra o resultado para melhorar decisões futuras. Conforme mais resultados são registrados, perfis de usuário tornam-se representações mais precisas de preferências individuais, permitindo que o Amazon Bedrock faça seleções de variante mais bem-informadas.

    Interpretando scores de confiança

    Cada decisão de IA inclui um score de confiança (0.0-1.0) que reflete a avaliação do sistema sobre quão certa está a seleção de variante baseada nos dados disponíveis. O Amazon Bedrock avalia múltiplos fatores: disponibilidade de dados, consistência de sinais, evidência de usuários similares, significância estatística de dados de desempenho e maturidade de perfil.

    Interpretação prática: scores 0.9–1.0 indicam extrema confiabilidade com evidência forte em todos os fatores; 0.7–0.89 indica alta confiança com qualidade de dados boa; 0.5–0.69 indica confiança moderada com dados razoáveis; 0.3–0.49 indica baixa confiança com dados limitados; scores menores que 0.3 indicam dados insuficientes para predição confiante.

    Exemplo prático: testando botões de chamada para ação

    Usuário 1: membro premium em dispositivo mobile

    Contexto inicial: dispositivo iPhone, membro de programa de lealdade premium, padrão de navegação rápido e orientado a objetivos, navegação direta, compras frequentes.

    O sistema executa: verificação de atribuição existente (nenhuma encontrada), recuperação de perfil do usuário (score de engajamento 0.89, score de probabilidade de conversão 0.24, estilo de interação “focused”), busca por usuários similares (52 membros de lealdade mobile encontrados preferindo Variante A), e recuperação de desempenho da Variante A (3.900 impressões, 125 conversões, taxa de conversão 3.2%, confiança 0.89).

    A decisão resultante: Variante A com confiança 0.86. Raciocínio: alinhamento forte entre múltiplos sinais — o perfil do usuário mostra estilo de interação “focused” com atenção curta, preferindo experiências simplificadas; a confiança no perfil é alta (0.87) baseado em dados históricos; 52 usuários similares de lealdade mobile preferem fortemente a Variante A; a Variante A mostra desempenho sólido com taxa de conversão de 3.2%; o status de lealdade significa a mensagem de frete grátis é redundante.

    Usuário 2: visitante primeira vez de site de cupons

    Contexto inicial: dispositivo Android, sem status de lealdade, padrão de navegação lento e comparativo, referência de site agregador de descontos.

    O sistema executa: verificação de atribuição existente (nenhuma encontrada), recuperação de perfil do usuário (score de engajamento 0.15, score de probabilidade de conversão 0.05, confiança muito baixa 0.12 — novo usuário), busca por usuários similares (39 novos usuários de sites de cupom encontrados preferindo Variante B com 2.3x conversão mais alta), recuperação de desempenho da Variante B (3.850 impressões, 158 conversões, taxa de conversão 4.1%, confiança 0.95).

    A decisão resultante: Variante B com confiança 0.91. Raciocínio: apesar da confiança baixa no perfil do usuário (novo usuário, confiança 0.12), sinais contextuais fortes criam alta confiança na decisão — a fonte de referência (site de cupons) indica comportamento orientado a descontos; 39 visitantes primeira vez similares de sites de cupom mostram preferência forte pela Variante B com incentivo de mensagem; a Variante B mostra desempenho forte com taxa de conversão 4.1%; o status de novo usuário significa nenhuma preferência de variante anterior para contradizer. A decisão orientada por contexto que aproveita padrões de usuários similares compensa a falta de histórico comportamental individual.

    Próximos passos e evoluções

    O sistema fornece fundação para personalizações avançadas: geração dinâmica de variantes em vez de seleção de variantes predefinidas, adaptando mensagens, cores e urgência baseado em comportamento individual; algoritmos de bandits multi-armados combinando personalização de IA com alocação automática de tráfego; aprendizado entre experimentos compartilhando insights através de testes; otimização em tempo real usando dados de streaming; segmentação avançada deixando a IA descobrir automaticamente segmentos de usuário através de clustering.

    Conclusão

    A AWS demonstra uma abordagem moderna para experimentação que transiciona de atribuição estática e aleatória para um mecanismo de personalização inteligente e continuamente aprendente. Os benefícios principais incluem decisões de variante personalizadas, aprendizado quase contínuo a partir do comportamento de usuário, arquitetura serverless com overhead operacional mínimo, custos previsíveis através de atribuição híbrida e integração profunda com serviços AWS.

    Para começar, a recomendação é: implantar a infraestrutura básica usando templates do AWS CloudFormation, começar com atribuição baseada em hash para todos os usuários estabelecendo uma linha de base; habilitar seleção assistida por IA para usuários retornando após dados comportamentais estarem disponíveis, começando com pequena percentagem de tráfego; expandir ferramentas MCP customizadas baseado em necessidades específicas de negócio; e monitorar latência de atribuição, custos da API Amazon Bedrock e métricas de conversão usando dashboards do Amazon CloudWatch.

    O código completo para implementação é disponibilizado incluindo backend FastAPI, frontend React, templates CloudFormation e implementação de servidor MCP no repositório A/B Testing Engine no GitHub. Para evitar encargos contínuos, os recursos criados durante a implementação devem ser deletados, com instruções detalhadas fornecidas no Infrastructure Cleanup Guide.

    Fonte

    Build an AI-Powered A/B testing engine using Amazon Bedrock (https://aws.amazon.com/blogs/machine-learning/build-an-ai-powered-a-b-testing-engine-using-amazon-bedrock/)

  • Avaliando agentes de IA em produção: guia prático para Strands Evals

    O desafio de validar agentes de IA em ambiente de produção

    Quando se trabalha com agentes de inteligência artificial, surge um problema que os testes tradicionais de software não conseguem resolver de forma adequada. Diferentemente de aplicações convencionais, onde uma entrada específica sempre produz a mesma saída, agentes de IA possuem características fundamentalmente diferentes: são flexíveis, adaptáveis e conscientes do contexto em que operam.

    Considere uma pergunta simples: “Qual é a previsão do tempo em Tóquio?” Um agente bem projetado poderia responder informando a temperatura em Celsius ou Fahrenheit, incluindo umidade e vento, ou focando apenas na temperatura. Todas essas respostas podem ser corretas e úteis — mas como você avalia sistematicamente algo que não segue um padrão determinístico?

    O problema se torna ainda mais complexo quando consideramos que agentes não apenas geram texto, mas também tomam ações. Um agente bem-projetado utiliza ferramentas, recupera informações e toma decisões durante toda uma conversa. Avaliar apenas a resposta final ignora se o agente seguiu passos apropriados para chegar àquele resultado.

    Além disso, conversas multi-turnos adicionam outra camada de complexidade. Quando usuários interagem com um agente ao longo de múltiplas trocas, respostas anteriores influenciam as posteriores. Um agente pode responder bem a perguntas isoladas, mas falhar em manter contexto coerente ao longo de uma conversa inteira.

    Por que a avaliação de agentes é diferente

    Essas características criam uma necessidade que os testes baseados em asserções simples não conseguem atender. A avaliação baseada em modelos de linguagem de grande escala (LLM — Large Language Model) surge como resposta, permitindo que se avaliem qualidades como utilidade, coerência e fidelidade que resistem a verificações mecânicas.

    A AWS apresenta o Strands Evals, um framework projetado especificamente para este desafio. Ele fornece um conjunto integrado de avaliadores baseados em LLM, ferramentas de simulação de usuários e capacidades de relatório, permitindo que equipes de desenvolvimento validem agentes de forma rigorosa e repetível.

    Conceitos fundamentais do Strands Evals

    O framework funciona seguindo um padrão familiar para quem já escreveu testes unitários, mas adaptado para a avaliação baseada em julgamento que agentes de IA exigem. Três conceitos formam a base:

    Cases

    Um Case representa um cenário único de teste. Contém a entrada que você deseja testar — por exemplo, uma pergunta do usuário — além de saídas esperadas opcionais, sequências de ferramentas esperadas (trajetórias) e metadados. Cases são a unidade atômica de avaliação.

    from strands_evals import Case
    case = Case(
        name="Weather Query",
        input="What is the weather like in Tokyo?",
        expected_output="Should include temperature and conditions",
        expected_trajectory=["weather_api"]
    )

    Experiments

    Um Experiment agrupa múltiplos Cases com um ou mais avaliadores. É o equivalente a um conjunto de testes (test suite) nos testes tradicionais. O Experiment orquestra o processo de avaliação: pega cada Case, executa o agente nele e aplica os avaliadores configurados para gerar pontuações.

    Evaluators

    Avaliadores funcionam como juízes. Examinam o que seu agente produziu e comparam contra o que era esperado. Diferentemente de verificações de asserção simples, os avaliadores no Strands Evals são principalmente baseados em LLM, usando modelos de linguagem para fazer julgamentos sofisticados sobre qualidade, relevância e utilidade.

    Task Function

    Uma Task Function é um elemento executável que você fornece ao Experiment. Recebe um Case e retorna os resultados da execução desse caso no seu sistema. Essa interface permite dois padrões fundamentalmente diferentes de avaliação.

    Avaliação online: invoca o agente ao vivo durante a avaliação. Sua Task Function cria um agente, envia a entrada do Case, captura a resposta e o rastreamento de execução, retornando-os para avaliação. Este padrão é recomendado durante desenvolvimento para feedback rápido ou em pipelines de CI/CD (Integração e Entrega Contínua).

    from strands import Agent
    def online_task(case):
        agent = Agent(tools=[search_tool, calculator_tool])
        result = agent(case.input)
        return {
            "output": str(result),
            "trajectory": agent.session
        }

    Avaliação offline: trabalha com dados históricos. Em vez de invocar um agente, sua Task Function recupera rastreamentos gravados anteriormente de logs, bancos de dados ou sistemas de observabilidade. Este padrão funciona bem quando você precisa avaliar tráfego de produção, realizar análise histórica ou comparar versões de agentes contra o mesmo conjunto de interações reais.

    def offline_task(case):
        trace = load_trace_from_database(case.session_id)
        session = session_mapper.map_to_session(trace)
        return {
            "output": extract_final_response(trace),
            "trajectory": session
        }

    Avaliadores integrados para avaliação abrangente

    O Strands Evals fornece dez avaliadores integrados, cada um projetado para avaliar uma dimensão diferente da qualidade do agente.

    Avaliadores baseados em rubrica

    Os avaliadores mais flexíveis permitem que você defina critérios personalizados através de rubricas em linguagem natural. O OutputEvaluator julga a resposta final que seu agente produz. Você fornece uma rubrica descrevendo o que é “bom”, e o avaliador usa um LLM para pontuar a saída contra esses critérios.

    O TrajectoryEvaluator estende isso para examinar a sequência de ações que o agente tomou. Além de apenas olhar para a resposta final, você pode verificar se o agente usou ferramentas apropriadas em uma ordem lógica. O avaliador inclui três funções de pontuação integradas: correspondência exata, correspondência em ordem e correspondência em qualquer ordem.

    O InteractionsEvaluator lida com sistemas de múltiplos agentes onde vários componentes se comunicam, avaliando sequências de interações entre agentes ou componentes do sistema.

    Avaliadores semânticos

    Algumas dimensões de qualidade são comuns o suficiente para que o Strands Evals forneça avaliadores pré-construídos com prompts cuidadosamente projetados.

    O HelpfulnessEvaluator avalia respostas da perspectiva do usuário usando uma escala de sete pontos, desde “não útil” até “acima e além”. O FaithfulnessEvaluator verifica se a resposta está fundamentada no histórico da conversa — particularmente importante para sistemas RAG (Recuperação Aumentada de Geração), onde você precisa garantir que o agente não fabrique informações.

    O HarmfulnessEvaluator realiza verificações de segurança, ajudando a determinar se as respostas contêm conteúdo prejudicial ou inadequado.

    Avaliadores em nível de ferramenta

    Quando seu agente usa ferramentas, frequentemente você precisa avaliar não apenas o resultado final, mas a qualidade de invocações individuais de ferramentas. O ToolSelectionAccuracyEvaluator examina cada chamada de ferramenta em contexto e julga se selecionar aquela ferramenta em particular era justificado. O ToolParameterAccuracyEvaluator vai além, verificando se os parâmetros passados a cada ferramenta estavam corretos e apropriados.

    Avaliadores em nível de sessão

    O GoalSuccessRateEvaluator adota a visão mais ampla, avaliando sessões de conversa inteiras para determinar se o usuário finalmente alcançou seu objetivo. Para agentes orientados por tarefas, sucesso é definido por resultados em vez de uma única resposta.

    Simulando usuários para testes multi-turnos

    Os avaliadores mencionados funcionam bem para interações de turno único. Conversas multi-turnos apresentam um desafio maior: usuários reais não seguem scripts. Fazem perguntas de acompanhamento, mudam de direção e expressam confusão.

    O Strands Evals inclui um ActorSimulator que cria usuários simulados alimentados por IA para conduzir conversas multi-turnos com seu agente. O simulador começa com um Case que define o que o usuário quer alcançar. A partir disso, ele gera um perfil de usuário realista usando um LLM, incluindo traços de personalidade, nível de expertise, estilo de comunicação e uma meta específica.

    from strands_evals import Case, ActorSimulator
    from strands import Agent
    
    case = Case(
        input="I need help setting up a new bank account",
        metadata={"task_description": "Successfully open a checking account"}
    )
    
    user_sim = ActorSimulator.from_case_for_user_simulator(
        case=case,
        max_turns=10
    )
    
    agent = Agent(system_prompt="You are a helpful banking assistant.")
    user_message = case.input
    
    while user_sim.has_next():
        agent_response = agent(user_message)
        user_result = user_sim.act(str(agent_response))
        user_message = str(user_result.structured_output.message)

    Durante a interação, o usuário simulado envia mensagens ao agente, recebe respostas e decide o que dizer em seguida. Este ciclo continua até que o objetivo seja alcançado ou o número máximo de turnos seja atingido. Você pode então passar a transcrição da conversa resultante para avaliadores em nível de sessão para avaliar se seu agente ajudou com sucesso o usuário simulado a alcançar sua meta.

    Estrutura hierárquica de avaliação

    Diferentes avaliadores operam em diferentes granularidades. O Strands Evals usa um TraceExtractor para analisar dados de sessão no formato que cada avaliador precisa.

    Avaliação em nível de sessão: analisa a conversa completa do início ao fim. O avaliador recebe o histórico completo, as execuções de ferramentas e entende todo o contexto. O GoalSuccessRateEvaluator funciona neste nível porque determinar alcance de objetivos requer entender a interação inteira.

    Avaliação em nível de rastreamento: foca em turnos individuais — cada par de pergunta do usuário e resposta do agente. Avaliadores neste nível recebem o histórico da conversa até aquele ponto e julgam a resposta específica. Helpfulness, Faithfulness e Harmfulness funcionam aqui.

    Avaliação em nível de ferramenta: desce para invocações individuais de ferramentas. Cada chamada é avaliada em contexto, com acesso às ferramentas disponíveis, a conversa até aquele ponto, e os argumentos específicos passados.

    Integração na prática

    Um fluxo de avaliação típico começa com a definição de casos de teste representando cenários que você quer que seu agente manipule bem. Eles podem vir de consultas de usuários reais, geração sintética ou casos extremos que você identificou:

    from strands_evals import Experiment, Case
    from strands_evals.evaluators import OutputEvaluator, TrajectoryEvaluator
    
    cases = [
        Case(
            name="Weather Query",
            input="What is the weather like in Tokyo?",
            expected_output="Should include temperature and conditions",
            expected_trajectory=["weather_api"]
        ),
        Case(
            name="Calculator Usage",
            input="What is 15% of 847?",
            expected_output="127.05",
            expected_trajectory=["calculator"]
        )
    ]

    Em seguida, você configura avaliadores com rubricas ou configurações apropriadas e cria um Experiment agrupando Cases e avaliadores. Finalmente, executa a avaliação com sua Task Function e examina os resultados através de relatórios detalhados.

    Para conjuntos de testes maiores, o Strands Evals suporta avaliação assíncrona com paralelismo configurável, permitindo escalar o processo de teste conforme suas necessidades crescem.

    Gerando casos de teste em escala

    O fluxo anterior assume que você já tem casos de teste prontos. Criar suites de teste abrangentes manualmente fica tedioso conforme as capacidades do seu agente crescem. O Strands Evals inclui um ExperimentGenerator que usa LLMs para criar casos de teste e rubricas de avaliação a partir de descrições de alto nível.

    O gerador cria casos de teste diversos cobrindo diferentes aspectos do contexto especificado, com níveis de dificuldade apropriados. Casos gerados são particularmente valiosos durante desenvolvimento inicial quando você quer cobertura ampla mas ainda não identificou padrões de falha específicos. Conforme sua prática de avaliação amadurece, complemente Cases gerados com cenários feitos à mão visando casos extremos conhecidos.

    Boas práticas para avaliação de agentes

    Comece pequeno e itere: inicie com poucos casos de teste cobrindo seus cenários de usuário mais críticos. Conforme observa como seu agente falha na prática, adicione casos direcionados que abordem esses modos de falha específicos.

    Escolha avaliadores que correspondam aos seus objetivos: selecione avaliadores que meçam diretamente o que importa para seu caso de uso. Um agente voltado para clientes pode priorizar Helpfulness e Goal Success, enquanto um assistente de pesquisa pode valorizar mais Faithfulness.

    Escreva rubricas claras e específicas: avaliadores baseados em rubricas são tão bons quanto as rubricas que você fornece. Evite critérios vagos em favor de padrões específicos e mensuráveis. Inclua exemplos do que constitui pontuações altas, médias e baixas.

    Combine avaliação online e offline: use avaliação online durante desenvolvimento para feedback rápido em mudanças de código. Complemente com avaliação offline de rastreamentos de produção para capturar problemas que só aparecem com comportamento real de usuários.

    Defina limiares significativos: defina limiares de aprovação/falha baseados em seus requisitos reais de qualidade. Analise resultados de avaliação para entender quais pontuações se correlacionam com bons resultados de usuários, então defina limiares correspondentes.

    Rastreie tendências ao longo do tempo: execuções individuais de avaliação fornecem snapshots, mas tendências revelam a trajetória. Armazene resultados de avaliação e rastreie métricas-chave entre lançamentos. Degradação gradual pode ser mais difícil de notar que falhas repentinas, mas igualmente prejudicial.

    Invista em diversidade de casos de teste: cubra a faixa completa de entradas que seu agente encontrará: consultas comuns, casos extremos, entradas adversariais e conversas multi-turnos.

    Avalie em múltiplos níveis: sucesso em nível de sessão pode mascarar problemas em nível de ferramenta, e vice-versa. Um agente pode alcançar metas de usuários através de passos intermediários ineficientes ou incorretos. Componha suites de avaliação que verifiquem qualidade em níveis de sessão, rastreamento e ferramenta para obter uma visão completa.

    Conclusão

    Construir agentes de IA confiáveis exige mais que intuição e verificações pontuais. Requer avaliação sistemática que rastreie qualidade através de múltiplas dimensões ao longo do tempo. O Strands Evals fornece uma fundação através de um framework projetado especificamente para os desafios únicos da avaliação de agentes.

    A separação entre invocação de agente e lógica de avaliação permite tanto testes online durante desenvolvimento quanto análise offline de rastreamentos de produção. Avaliadores baseados em LLM fornecem o julgamento que avaliação de qualidade exige. Níveis de avaliação hierárquicos permitem validação em múltiplas granularidades, desde chamadas individuais de ferramentas até sessões de conversa completas.

    Para explorar o Strands Evals, a documentação com exemplos práticos contém amostras que você pode adaptar para seus próprios casos de uso. Comece com poucos casos de teste representando seus cenários de usuário mais importantes, adicione avaliadores que correspondam a seus critérios de qualidade e execute avaliações como parte de seu fluxo de desenvolvimento. Ao longo do tempo, expanda sua suite de testes para cobrir mais cenários. Avaliação sistemática é a fundação que o ajuda a entregar agentes de IA com confiança.

    Fonte

    Evaluating AI agents for production: A practical guide to Strands Evals (https://aws.amazon.com/blogs/machine-learning/evaluating-ai-agents-for-production-a-practical-guide-to-strands-evals/)

  • Nemotron 3 Super: O Novo Modelo de IA Híbrido da NVIDIA Agora Disponível na Amazon Bedrock

    Um Novo Modelo Híbrido para Aplicações Complexas

    A Amazon Bedrock expandiu seu catálogo de modelos de inteligência artificial com o anúncio do Nemotron 3 Super, desenvolvido pela NVIDIA. Trata-se de um modelo de arquitetura híbrida baseado em Mixture-of-Experts (MoE) — uma abordagem que combina múltiplos especialistas para processar diferentes tipos de informação de forma mais eficiente.

    Este modelo foi especificamente projetado para atender workloads de natureza agentica, ou seja, aplicações onde agentes de IA precisam executar tarefas complexas em múltiplas etapas mantendo contexto e precisão ao longo de toda a operação. O Nemotron 3 Super oferece inferência rápida e otimizada em termos de custo, reduzindo o consumo de recursos computacionais sem comprometer a qualidade das respostas.

    Abertura e Flexibilidade Técnica

    Um dos diferenciais do Nemotron 3 Super é sua natureza completamente aberta. A NVIDIA disponibilizou não apenas os pesos do modelo (os parâmetros treinados), mas também os datasets utilizados no treinamento e as receitas — ou seja, as configurações e metodologias empregadas na construção do modelo.

    Essa abordagem de código aberto facilita a customização por parte das organizações, permitindo que empresas, startups e desenvolvedores individuais adaptem o modelo para suas necessidades específicas. Ao mesmo tempo, a transparência técnica contribui para implantações seguras, fundamental para contextos empresariais que exigem conformidade e auditoria.

    Integração Simplificada via Amazon Bedrock

    A grande vantagem de acessar o Nemotron 3 Super através da Amazon Bedrock é a eliminação da complexidade operacional. Em vez de gerenciar infraestrutura própria, provisionar servidores ou fazer o host do modelo, os usuários acessam o modelo através de uma API única totalmente gerenciada.

    O Bedrock oferece inferência sem servidor, o que significa que não há necessidade de preocupação com capacidade, escalabilidade ou manutenção de infraestrutura. Além disso, o serviço inclui controles de segurança integrados, garantindo que os dados processados sejam protegidos conforme os padrões corporativos.

    Compatibilidade com OpenAI API

    Um detalhe técnico importante é que o Nemotron 3 Super, quando acessado via Bedrock, é compatível com as especificações da API OpenAI. Isso significa que desenvolvedores que já trabalham com essa interface padrão podem integrar o modelo em seus fluxos de trabalho existentes com mínimas alterações de código. Essa compatibilidade reduz significativamente a curva de aprendizado e o tempo de implementação.

    Disponibilidade e Próximos Passos

    O Nemotron 3 Super está disponível na Amazon Bedrock em regiões selecionadas da AWS. Para conhecer a lista completa de regiões onde o modelo está disponível, consulte a documentação sobre compatibilidade de modelos.

    Desenvolvedores interessados em começar a usar o modelo podem acessar o console da Amazon Bedrock ou consultar a documentação técnica do serviço. Para quem busca começar especificamente com os endpoints compatíveis com a API OpenAI, a AWS fornece documentação detalhada sobre como iniciarse com essa abordagem.

    Fonte

    NVIDIA Nemotron 3 Super now available on Amazon Bedrock (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-bedrock-nemotron-3-super/)

  • Campanha de Ransomware Interlock Explorava Vulnerabilidade em Firewalls Cisco — Análise da Pesquisa de Segurança da AWS

    Descoberta de uma Campanha de Ransomware com Zero-Day

    As equipes de inteligência de ameaças da AWS identificaram uma campanha ativa do ransomware Interlock que explorra a CVE-2026-20131, uma vulnerabilidade crítica no software do Centro de Gerenciamento de Firewall Seguro Cisco (FMC). Esta vulnerabilidade permite que um atacante não autenticado execute código Java arbitrário com privilégios de root em um dispositivo afetado. A vulnerabilidade foi divulgada publicamente pela Cisco em 4 de março de 2026.

    O que torna este caso particularmente preocupante é o cronograma: a pesquisa revelou que o grupo Interlock estava explorando esta vulnerabilidade desde 26 de janeiro de 2026 — 36 dias antes do conhecimento público. Em outras palavras, o grupo possuía um zero-day em mãos, tendo uma semana de vantagem para comprometer organizações antes que os defensores soubessem que deveriam investigar.

    Após descobrir essa atividade, a AWS compartilhou seus achados com a Cisco para apoiar a investigação e proteger os clientes. Um erro operacional crítico — um servidor de infraestrutura mal configurado — expôs o arsenal completo do grupo Interlock. Este acidente raro forneceu aos times de segurança da AWS visibilidade sobre a cadeia de ataque multi-estágio do grupo ransomware, incluindo trojans de acesso remoto customizados, scripts de reconhecimento automatizados e técnicas sofisticadas de evasão.

    É importante notar que a infraestrutura da AWS e as cargas de trabalho de clientes não foram observadas como envolvidas nesta campanha.

    Cronologia da Descoberta e Investigação

    A equipes de inteligência de ameaças da AWS começou a identificar atividade potencialmente relacionada à CVE-2026-20131 em 26 de janeiro de 2026, antecedendo a divulgação pública. A atividade observada envolvia requisições HTTP para um caminho específico no software afetado, com corpos contendo tentativas de execução de código Java e duas URLs incorporadas: uma para entregar dados de configuração e outra para confirmar a exploração bem-sucedida.

    Para avançar na investigação e obter inteligência de ameaças adicional, os analistas simularam a resposta esperada — fingindo ser um sistema compromitido com sucesso. Esta ação acionou corretamente o grupo Interlock a prosseguir para a próxima fase, emitindo comandos para buscar e executar um binário ELF malicioso (arquivo executável Linux) de um servidor remoto. Quando os analistas recuperaram o binário, descobriram que o mesmo host era usado para distribuir todo o arsenal operacional do Interlock.

    A infraestrutura exposta estava organizada com artefatos em caminhos separados correspondendo a alvos individuais — os mesmos caminhos utilizados tanto para baixar ferramentas para hosts compromitidos quanto para fazer upload de artefatos operacionais de volta ao servidor de staging.

    Atribuição ao Ransomware Interlock

    O binário ELF e artefatos associados foram atribuídos à família de ransomware Interlock através de indicadores técnicos e operacionais convergentes. A nota de resgate incorporada e o portal de negociação TOR são consistentes com a marca estabelecida do Interlock e sua infraestrutura. A nota invoca múltiplas regulações de proteção de dados — uma prática documentada do Interlock de citar exposição regulatória para pressionar vítimas, essencialmente ameaçando organizações não apenas com criptografia de dados, mas com multas regulatórias e violações de conformidade.

    O identificador de organização específico da campanha incorporado na nota se alinha com o modelo de rastreamento por vítima do Interlock. Historicamente, o grupo tem direcionado setores específicos onde a interrupção operacional cria pressão máxima para pagamento: educação representa a maior parte de sua atividade, seguida por firmas de engenharia, arquitetura e construção, organizações de manufatura e industriais, provedores de saúde, e entidades de governo e setor público.

    A análise temporal de timestamps revelou que os atores provavelmente operam na zona UTC+3 com confiança de 75–80%. A análise sistemática mostrou que UTC+3 produziu o melhor ajuste: primeira atividade por volta de 08:30, pico de atividade entre 12:00 e 18:00, e uma provável janela de descanso de 00:30–08:30.

    Análise Técnica: O Arsenal Operacional do Interlock

    Script de Reconhecimento Pós-Comprometimento

    Uma vez que o Interlock obtém acesso inicial, utiliza diversas ferramentas prioritárias para completar seu ataque. Os times de inteligência de ameaças da AWS recuperaram um script PowerShell projetado para enumeração sistemática do ambiente Windows. O script coleta detalhes do sistema operacional e hardware, serviços em execução, software instalado, configuração de armazenamento, inventário de máquinas virtuais Hyper-V, listagens de arquivos de usuários através de Desktop, Documents e Downloads, artefatos de navegadores (Chrome, Edge, Firefox, Internet Explorer e 360 browser, incluindo histórico, bookmarks, credenciais armazenadas e extensões), conexões de rede ativas correlacionadas com processos responsáveis, tabelas ARP, dados de sessões iSCSI e eventos de autenticação RDP a partir dos logs de eventos do Windows.

    O script encena resultados em um compartilhamento de rede centralizado usando o nome de host totalmente qualificado de cada sistema para criar diretórios dedicados — essencialmente criando uma pasta para cada computador compromitido. Após coleta, comprime dados em arquivos ZIP nomeados após cada hostname e remove os dados brutos originais. Este formato de saída estruturado por host indica que o script opera entre múltiplas máquinas dentro de uma rede — uma característica de cadeias de intrusão ransomware que se preparam para criptografia em toda a organização.

    Trojans de Acesso Remoto Customizados

    Trojans de acesso remoto (RATs) são programas maliciosos que fornecem aos atacantes controle persistente sobre sistemas compromitidos, funcionando como software de desktop remoto não autorizado.

    Implant JavaScript: Os times de inteligência da AWS recuperaram um trojan de acesso remoto JavaScript ofuscado que suprime saída de debug sobrescrevendo métodos de console do navegador. Na execução, perfila o host infectado usando PowerShell e Windows Management Instrumentation (WMI), coletando identidade do sistema, associação de domínio, nome de usuário, versão do SO e contexto de privilégio antes de transmitir estes dados durante um handshake de inicialização criptografado. A comunicação com comando e controle ocorre sobre conexões WebSocket persistentes com mensagens criptografadas em RC4 usando chaves aleatórias de 16 bytes por mensagem incorporadas em cabeçalhos de pacotes — essencialmente, cada mensagem usa uma chave de criptografia diferente, tornando a interceptação mais difícil. O implant cicla através de múltiplos hostnames e endereços IP controlados pelo operador em ordem aleatória com backoff exponencial entre tentativas de reconexão. O implant fornece acesso interativo a shell, execução arbitrária de comando, transferência de arquivo bidirecional e capacidade de proxy SOCKS5 para tunelamento de tráfego TCP.

    Implant Java: Um cliente funcionalmente equivalente implementado em Java fornece capacidades idênticas de comando e controle. Construído sobre bibliotecas do ecossistema GlassFish, utiliza Grizzly para transporte de I/O não-bloqueante e Tyrus para comunicação de protocolo WebSocket. Em termos mais simples, o Interlock construiu a mesma porta de fundos em duas linguagens de programação diferentes, garantindo que mantenha acesso mesmo se defensores detectem uma versão.

    Script de Lavagem de Infraestrutura

    Atores sofisticados não atacam a partir de sua própria infraestrutura — eles constroem redes relay descartáveis para esconder seus rastros. Os times de inteligência da AWS identificaram um script Bash que configura servidores Linux como proxies reversos HTTP (servidores intermediários que encaminham tráfego para esconder a localização real do atacante). O script executa atualizações de sistema, instala fail2ban com proteção contra força bruta SSH, e compila HAProxy 3.1.2 a partir do código-fonte. A instância HAProxy escuta na porta 80 e encaminha todo tráfego HTTP inbound para um IP alvo codificado, com systemd garantindo persistência através de reinicializações. Um componente notável é uma rotina de apagamento de logs executada como cron job a cada cinco minutos. A rotina trunca todos os arquivos *.log sob /var/log e suprime o histórico de shell alterando a variável HISTFILE. Esta destruição agressiva de evidências, limpando logs a cada cinco minutos, combinada com o propósito específico de proxy de encaminhamento HTTP, indica que o script estabelece nós relay descartáveis de lavagem de tráfego. Estes nós obscurecem a origem do tráfego de exploração, retransmitem comunicações de comando e controle, ou fazem proxy de exfiltração de dados, tornando praticamente impossível rastrear ataques de volta à sua fonte.

    Webshell Residente em Memória

    Os times de inteligência da AWS observaram um arquivo classe Java entregue como alternativa ao drop de binário ELF. Quando carregado pela Máquina Virtual Java (JVM), seu inicializador estático registra um ServletRequestListener com o StandardContext do servidor, essencialmente instalando uma porta de fundos persistente residente em memória que intercepta requisições HTTP sem escrever arquivos em disco. Esta abordagem “sem arquivos” elude a varredura tradicional de antivírus que busca por arquivos maliciosos. O listener inspeciona requisições recebidas procurando por parâmetros especialmente crafted contendo payloads de comando criptografados. Os payloads são descriptografados usando AES-128 com chave derivada do hash MD5 de um seed codificado. Os payloads descriptografados são tratados como bytecode Java compilado, dinamicamente carregados na JVM, e executados — uma técnica projetada para eludir detecção baseada em arquivo executando código malicioso inteiramente em memória.

    Ferramenta de Verificação de Conectividade

    Os times de inteligência da AWS recuperaram arquivos classe Java implementando um servidor TCP básico escutando em uma porta codificada para obscurecer o número da porta da análise estática. O servidor aceita conexões, registra endereços IP de conexão, envia uma mensagem de saudação, e imediatamente fecha conexões. Este perfil operacional é consistente com um beacon de rede leve — essencialmente uma ferramenta “phone home” utilizada para verificar execução bem-sucedida de código ou confirmar alcançabilidade de porta de rede após exploração inicial.

    Abuso de Ferramentas Legítimas

    O Interlock implantou ConnectWise ScreenConnect, uma ferramenta comercial legítima de desktop remoto, ao lado de implants customizados. Quando operadores de ransomware implantam ferramentas de acesso remoto legítimas ao lado de seu malware customizado, estão comprando seguro — se defensores encontram e removem uma porta de fundos, ainda possuem outro caminho de entrada. Isto indica múltiplos mecanismos de acesso remoto redundantes — um padrão consistente com operadores de ransomware buscando manter acesso mesmo se pontos de apoio individuais forem removidos. A pegada de rede legítima da ferramenta ajuda a se misturar com tráfego de administração remota autorizada, tornando a detecção mais desafiadora.

    Os times de inteligência da AWS também recuperaram Volatility, um framework open-source de análise forense de memória tipicamente utilizado por respondentes de incidentes — a mesma ferramenta que defensores usam para investigar ataques. Enquanto nenhum artefato indicava uso automatizado, sua presença ao lado de implants customizados e scripts de reconhecimento é consistente com operações avançadas de ameaças. Tanto grupos de ransomware quanto atores de nível estatal foram observados implantando Volatility durante intrusões. O foco da ferramenta em parsear dumps de memória fornece acesso a dados sensíveis como credenciais armazenadas em RAM, que podem capacitar movimento lateral e comprometimento mais profundo do ambiente em apoio a operações de resgate ou objetivos de espionagem.

    O Interlock também utilizou Certify, uma ferramenta ofensiva de segurança open-source projetada para explorar misconfigurations em Active Directory Certificate Services (AD CS). Para operadores de ransomware, Certify fornece um caminho para identificar templates de certificado vulneráveis e permissões de inscrição que permitem requisição de certificados com capacidade de autenticação. Estes certificados podem ser utilizados para impersonar usuários, escalar privilégios, ou manter acesso persistente. Estas capacidades apoiam diretamente ambos objetivos de comprometimento inicial e objetivos de persistência de longo prazo em operações de ransomware.

    Indicadores de Comprometimento (IoCs)

    Os seguintes indicadores apóiam medidas defensivas por organizações que possam ser afetadas. Devido ao uso de técnicas de variação de conteúdo pelo Interlock, a maioria dos hashes de arquivo não está incluída como indicadores confiáveis. O ator de ameaça modificou a maioria dos artefatos como scripts e binários baixados para diferentes alvos, resultando em diferentes hashes de arquivo para ferramentas funcionalmente idênticas. A customização permitiu que cada ataque eludisse detecção baseada em assinatura que busca por correspondências exatas de arquivo.

    Endereços IP:

    • 206.251.239[.]164 — IP fonte de exploração (ativo jan 2026)
    • 199.217.98[.]153 — IP fonte de exploração (ativo mar 2026)
    • 89.46.237[.]33 — IP fonte de exploração (ativo mar 2026)
    • 144.172.94[.]59 — IP fallback C2 (ativo mar 2026)
    • 199.217.99[.]121 — IP fallback C2 (ativo mar 2026)
    • 188.245.41[.]78 — IP fallback C2 (ativo mar 2026)
    • 144.172.110[.]106 — IP backend C2 (ativo mar 2026)
    • 95.217.22[.]175 — IP backend C2 (ativo mar 2026)
    • 37.27.244[.]222 — IP host de staging (ativo mar 2026)

    Identificadores de Rede:

    • Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:136.0) Gecko/20100101 Firefox/136.0 — User-Agent HTTP de exploração (observado jan e mar 2026)
    • b885946e72ad51dca6c70abc2f773506 — TLS JA3 de exploração (observado jan e mar 2026)
    • f80d3d09f61892c5846c854dd84ac403 — TLS JA3 de exploração (observado mar 2026)
    • t13i1811h1_85036bcba153_b26ce05bbdd6 — TLS JA4 de exploração (observado jan e mar 2026)
    • t13i4311h1_c7886603b240_b26ce05bbdd6 — TLS JA4 de exploração (observado mar 2026)

    Domínios e URLs:

    • hxxp://ebhmkoohccl45qesdbvrjqtyro2hmhkmh6vkyfyjjzfllm3ix72aqaid[.]onion/chat.php — Portal de negociação de resgate (ativo mar 2026)
    • cherryberry[.]click — Domínio de suporte de exploração (ativo jan 2026)
    • ms-server-default[.]com — Domínio de suporte de exploração (ativo mar 2026)
    • initialize-configs[.]com — Domínio de suporte de exploração (ativo mar 2026)
    • ms-global.first-update-server[.]com — Domínio de suporte de exploração (ativo mar 2026)
    • ms-sql-auth[.]com — Domínio de suporte de exploração (ativo mar 2026)
    • kolonialeru[.]com — Domínio de suporte de exploração (ativo mar 2026)
    • sclair.it[.]com — Domínio de suporte de exploração (ativo mar 2026)
    • browser-updater[.]com — Domínio C2 (ativo mar 2026)
    • browser-updater[.]live — Domínio C2 (ativo mar 2026)
    • os-update-server[.]com — Domínio C2 (ativo mar 2026)
    • os-update-server[.]org — Domínio C2 (ativo mar 2026)
    • os-update-server[.]live — Domínio C2 (ativo mar 2026)
    • os-update-server[.]top — Domínio C2 (ativo mar 2026)

    Hashes de Artefatos:

    • d1caa376cb45b6a1eb3a45c5633c5ef75f7466b8601ed72c8022a8b3f6c1f3be — Ferramenta de segurança ofensiva (Certify) observada mar 2026
    • 6c8efbcef3af80a574cb2aa2224c145bb2e37c2f3d3f091571708288ceb22d5f — Screen locker observado mar 2026

    Recomendações Defensivas

    As organizações devem executar as seguintes ações para se proteger contra operações de ransomware Interlock.

    Ações Imediatas

    • Aplicar patches de segurança da Cisco para o Centro de Gerenciamento de Firewall Seguro Cisco
    • Revisar logs em busca dos indicadores de comprometimento listados acima
    • Conduzir avaliações de segurança para identificar comprometimento potencial
    • Revisar implantações de ScreenConnect em busca de instalações não autorizadas

    Oportunidades de Detecção

    • Monitorar scripts PowerShell encenando dados em compartilhamentos de rede com estruturas de diretório baseadas em hostname
    • Detectar registros de ServletRequestListener em contextos de aplicações web Java (modificações incomuns em aplicações web Java)
    • Identificar instalações de HAProxy com agressivos cron jobs de exclusão de logs (servidores proxy que apagam seus próprios logs a cada cinco minutos)
    • Monitorar conexões TCP para portas numeradas incomuns

    Medidas de Longo Prazo

    • Implementar estratégias de defesa em profundidade com múltiplas camadas de controles de segurança
    • Manter capacidades contínuas de monitoramento e busca de ameaças
    • Garantir logging abrangente com armazenamento de logs centralizado e seguro (armazenado separadamente de sistemas que podem ser comprometidos)
    • Testar regularmente procedimentos de resposta a incidentes para cenários de ransomware
    • Educar times de segurança sobre táticas, técnicas e procedimentos do Interlock

    Entendendo o Contexto Maior

    A história real aqui não é apenas sobre uma vulnerabilidade ou um grupo de ransomware — é sobre o desafio fundamental que exploits zero-day colocam em todos os modelos de segurança. Quando atacantes exploram vulnerabilidades antes que patches existam, mesmo programas de patching diligentes não podem proteger naquele período crítico. É precisamente por isso que a defesa em profundidade é essencial — controles de segurança em camadas fornecem proteção quando qualquer controle individual falha ou ainda não foi implantado. Patching rápido permanece fundamental em gerenciamento de vulnerabilidades, mas defesa em profundidade ajuda organizações a não ficarem indefesas durante a janela entre exploit e patch.

    Os times de Inteligência de Ameaças da AWS continuam monitorando operações do ransomware Interlock e fornecerão atualizações conforme informações adicionais se tornem disponíveis. A inteligência coletada desta campanha está sendo integrada aos serviços de segurança da AWS para proteger proativamente os clientes.

    Fonte

    Amazon threat intelligence teams identify Interlock ransomware campaign targeting enterprise firewalls (https://aws.amazon.com/blogs/security/amazon-threat-intelligence-teams-identify-interlock-ransomware-campaign-targeting-enterprise-firewalls/)

  • Amazon S3 Access Grants chega à região AWS da Ásia-Pacífico (Nova Zelândia)

    Expansão regional do Access Grants para Amazon S3

    A AWS anunciou, em março de 2026, a disponibilidade do Amazon S3 Access Grants na região AWS Ásia-Pacífico (Nova Zelândia). Essa expansão amplia as opções de localização geográfica para organizações que precisam gerenciar o acesso a dados armazenados no Amazon S3 (Simple Storage Service) de forma segura e escalável.

    Como funciona o S3 Access Grants

    O Amazon S3 Access Grants atua como um mecanismo de mapeamento entre identidades corporativas e conjuntos de dados armazenados no S3. Ele estabelece uma ponte entre sistemas de identidade, como o Microsoft Entra ID (antigo Azure AD) ou os principals do AWS IAM (Identity and Access Management), e os recursos específicos no S3.

    Essa funcionalidade resolve um desafio importante para empresas: em vez de gerenciar permissões de acesso manualmente para cada usuário ou aplicação, o S3 Access Grants automatiza esse processo. O sistema reconhece a identidade corporativa de um usuário e concede acesso apropriado aos dados no S3 com base nas políticas pré-configuradas da organização.

    Benefícios para a gestão de dados em escala

    Uma das principais vantagens do S3 Access Grants é sua capacidade de simplificar a administração de permissões. Para organizações com centenas ou milhares de usuários, configurar e manter regras de acesso granulares pode se tornar complexo e propenso a erros. O Access Grants reduz essa complexidade ao centralizar a política de acesso e aplicá-la de forma consistente.

    Ao integrar-se com sistemas de diretório corporativo existentes, como o Microsoft Entra ID, o S3 Access Grants aproveita a infraestrutura de identidade que muitas empresas já possuem. Isso significa que decisões sobre quem tem acesso a qual dado podem ser sincronizadas com a estrutura organizacional real, tornando a governança de dados mais alinhada com a realidade operacional.

    Próximos passos

    Organizações que operam ou planejam expandir suas operações na região Ásia-Pacífico (Nova Zelândia) agora podem utilizar o S3 Access Grants como parte de sua estratégia de segurança e governança de dados. Para verificar a disponibilidade completa em outras regiões e explorar todas as capacidades do serviço, consulte a tabela de regiões da AWS.

    Para aprofundar o conhecimento sobre como implementar o Amazon S3 Access Grants em sua infraestrutura, visite a página de detalhes do serviço.

    Fonte

    Amazon S3 Access Grants are now available in the AWS Asia Pacific (New Zealand) Region (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-s3-access-grants-new-zealand/)

  • Amazon ECR agora suporta cache de puxada para Chainguard

    Integração do ECR com o registro do Chainguard

    A Amazon anunciou que o Registro Elástico de Contêineres (ECR) agora suporta o cache de puxada com o registro do Chainguard como fonte a montante. Essa integração permite que clientes da AWS usufruam da segurança e disponibilidade do ECR para imagens privadas do Chainguard.

    Sincronização simplificada de imagens

    A medida que os clientes expandem o uso de imagens do Chainguard em seus ambientes, manter essas imagens sincronizadas com o registro do Chainguard torna-se cada vez mais crítico. O recurso de cache de puxada do ECR oferece uma solução integrada: os clientes podem manter imagens do Chainguard atualizadas sem precisar de fluxos de trabalho adicionais ou ferramentas de gerenciamento externas.

    O cache de puxada do ECR suporta sincronizações frequentes de registro, garantindo que as imagens de contêineres obtidas do Chainguard permaneçam sempre atualizadas. Essa abordagem elimina a complexidade operacional de gerenciar sincronizações manuais ou processos separados.

    Recursos avançados para imagens cacheadas

    Após o cache das imagens do Chainguard no ECR, os clientes podem aplicar funcionalidades importantes do ECR, como varredura de imagens e políticas de ciclo de vida. Essas capacidades oferecem maior controle sobre segurança e conformidade das imagens armazenadas.

    Disponibilidade e próximos passos

    O cache de puxada para Chainguard está disponível em todas as regiões da AWS onde o cache de puxada do ECR já é suportado. Para começar, os clientes devem consultar a documentação oficial que contém instruções detalhadas sobre como configurar e usar esse novo recurso.

    Fonte

    Amazon ECR now supports pull through cache for Chainguard (https://aws.amazon.com/about-aws/whats-new/2026/03/amazon-ecr-pull-through-cache-chainguard/)