Author: Make.com Service User

  • Amazon Bedrock anuncia redução de preços para o OpenAI GPT-5.6 Sol

    Redução de preços chega ao GPT-5.6 Sol no Amazon Bedrock

    A OpenAI anunciou a redução dos preços de API para o modelo GPT-5.6 Sol, disponível no Amazon Bedrock. A novidade segue uma tendência recente de cortes de preço que já havia contemplado outros modelos da linha, como o Terra e o Luna. Agora é a vez do Sol receber um ajuste significativo, tornando o acesso mais viável para equipes que trabalham com cargas de trabalho intensas e de alto volume.

    Novos valores de precificação

    Com a atualização, o GPT-5.6 Sol passa a custar:

    • $4 por milhão de tokens de entrada — redução de 20% em relação ao preço anterior
    • $20 por milhão de tokens de saída — redução de 33,3% em relação ao preço anterior

    Vale destacar que essa é uma precificação promocional, garantida pelo menos até 21 de novembro de 2026. Ou seja, há uma janela relevante para times que queiram experimentar o modelo ou escalar projetos que já estão em andamento.

    Para quais casos de uso faz sentido?

    O GPT-5.6 Sol é um modelo posicionado para tarefas que exigem alto desempenho em cenários agênticos — aqueles em que o modelo age de forma autônoma para executar sequências de tarefas. Entre os casos de uso mais relevantes estão:

    • Agentes de codificação autônomos, que escrevem, revisam e depuram código de forma independente
    • Análises complexas com múltiplos passos, em que o modelo precisa encadear raciocínios e tomar decisões intermediárias
    • Fluxos de trabalho avançados de pesquisa, que demandam processamento extenso de informações

    O modelo já entrega resultados de ponta em benchmarks de codificação agêntica, e a queda no preço amplia o espaço para experimentação e para sustentar operações de maior escala sem comprometer o orçamento.

    Disponibilidade e documentação

    A disponibilidade do GPT-5.6 Sol varia por região da AWS. Para verificar em quais regiões AWS o modelo já está disponível, consulte a página oficial de compatibilidade regional. Para detalhes completos sobre preços e como começar a usar o modelo, a documentação do Amazon Bedrock traz todas as informações necessárias.

    Fonte

    Amazon Bedrock announces reduced pricing for OpenAI GPT-5.6 Sol (https://aws.amazon.com/about-aws/whats-new/2026/08/bedrock-openai-gpt-56-sol-reduced-pricing/)

  • Amazon Connect Customer permite que gestores conversem com seus dados em linguagem natural

    O que mudou no Amazon Connect Customer

    A AWS anunciou uma atualização relevante para quem gerencia contact centers com o Amazon Connect Customer: agora os gestores podem simplesmente conversar com seus dados operacionais em linguagem natural e receber, em segundos, a resposta que procuram — junto com as evidências que a sustentam e a recomendação de ação mais adequada.

    Na prática, isso significa o fim da dependência de dashboards complexos, analistas de dados e semanas de investigação para entender o que está afetando a performance do time.

    O problema que essa funcionalidade resolve

    Gestores de contact center sempre tiveram acesso a dados. O que faltava era tempo — e clareza. Identificar o que está impactando o desempenho, entender a causa raiz e decidir o próximo passo exigia cruzar múltiplos relatórios, envolver analistas e aguardar dias ou semanas por uma resposta confiável.

    Com essa novidade, o Amazon Connect Customer assume esse trabalho. A ferramenta vasculha mais de 150 métricas distribuídas em três grandes dimensões operacionais:

    • Autoatendimento — desempenho dos fluxos automatizados
    • Performance dos agentes — indicadores individuais e de equipe
    • Performance das filas — comportamento e gargalos no atendimento

    A partir dessas métricas, o sistema identifica o que importa, explica o porquê e recomenda o melhor próximo passo.

    Como funciona na prática

    A interação acontece em formato conversacional: o gestor começa com uma pergunta ampla e pode ir aprofundando o tema dentro da mesma conversa, sem precisar trocar de ferramenta ou reformular a busca do zero.

    Um exemplo ilustrativo citado pela própria AWS: um gestor pergunta quais filas são as melhores candidatas para automação. O Amazon Connect Customer então analisa onde o tempo médio de atendimento e o trabalho pós-contato estão mais elevados, e devolve uma lista priorizada com pontuações de confiança e o impacto projetado de cada ação.

    O que antes demandava analistas, dashboards e semanas de investigação passa a ser um plano de ação priorizado gerado em segundos.

    Disponibilidade

    O recurso está disponível em todas as regiões AWS onde os Amazon Connect Customer AI Agents são suportados. Para saber mais sobre como configurar e utilizar essa funcionalidade, a AWS disponibiliza a documentação oficial do produto.

    Fonte

    Amazon Connect Customer now lets managers chat with their data (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-connect-customer-ai-data-analytics)

  • Reduza os custos de RAG no Amazon Bedrock com compressão orientada por consulta

    O problema: tokens de contexto custam caro em escala

    Quem já operou uma aplicação de Geração Aumentada por Recuperação (RAG) em produção sabe que os tokens de entrada enviados ao modelo de fundação (FM) representam uma fatia relevante do custo total. O Amazon Bedrock oferece os modelos e as ferramentas para construir essas aplicações, mas a lógica padrão de recuperação tende a priorizar alto recall — ou seja, retornar muitos chunks potencialmente relevantes para garantir que o modelo tenha material suficiente na hora da inferência.

    Esse comportamento é sensato do ponto de vista de qualidade, mas tem um custo: com 5 a 20 chunks recuperados em tamanhos típicos, muitas aplicações de RAG acabam enviando milhares de tokens de contexto ao modelo principal em cada consulta. À medida que a escala cresce, esse volume se torna um alvo natural de otimização.

    A AWS publicou um padrão técnico que endereça exatamente esse ponto: a compressão de contexto orientada por consulta. A ideia central é inserir um modelo menor e mais barato entre a etapa de recuperação e o modelo principal, filtrando o contexto antes da chamada mais cara. Além da economia, há um benefício adicional: menos contexto irrelevante significa menos superfície para alucinações.

    Como o padrão funciona

    O fluxo de um RAG tradicional segue estas etapas: a aplicação embute a consulta do usuário, o índice vetorial retorna os top-k chunks, opcionalmente um reranker reordena esses chunks por relevância, todos eles são concatenados no prompt e o modelo principal gera a resposta.

    O padrão de compressão adiciona uma única etapa entre a recuperação e a resposta final: um modelo menor lê os chunks recuperados junto com a consulta do usuário e extrai apenas os trechos verbatim relevantes para aquela pergunta. O modelo principal então recebe esse contexto filtrado — muito menor — e gera a resposta.

    A implementação proposta pela AWS roda dentro de uma única função AWS Lambda, que orquestra duas chamadas ao Amazon Bedrock via Converse API: primeiro ao modelo de compressão, depois ao modelo principal. O padrão é compatível com qualquer recuperador do Amazon Bedrock, incluindo o Amazon Bedrock Knowledge Bases.

    Por que isso funciona economicamente

    A lógica financeira depende de dois fatores: a razão de preço entre o modelo menor e o modelo principal, e a taxa de compressão que o modelo menor consegue atingir. Quando o contexto recuperado é grande, o modelo principal é a parte cara da chamada, e a maior parte do conteúdo recuperado não é necessária para responder à pergunta específica do usuário — as economias podem ser expressivas.

    Para ilustrar: com R tokens recuperados, uma taxa de compressão c e preços por token distintos para cada modelo, o custo com compressão inclui a chamada ao modelo menor (leitura de R tokens e escrita de R/c tokens) mais a chamada ao modelo principal sobre o contexto reduzido (R/c tokens de entrada). O custo sem compressão inclui apenas a chamada ao modelo principal sobre o contexto completo (R tokens de entrada). A diferença favorece a compressão quando o contexto é grande, a razão de preço entre os modelos é alta e uma parcela significativa do conteúdo recuperado pode ser descartada sem afetar a qualidade da resposta.

    A AWS usa Claude Haiku como modelo de compressão e Claude Sonnet como modelo principal no exemplo, mas o padrão funciona com outros pares dentro de uma mesma família de modelos no Amazon Bedrock. O par Amazon Nova Micro com Amazon Nova Pro é outra combinação citada. As taxas atuais estão disponíveis na página de preços do Amazon Bedrock.

    Implementação: o prompt de compressão é a peça central

    A função Lambda recebe a consulta do usuário e os chunks recuperados, lê os IDs dos dois modelos de variáveis de ambiente e inicializa um cliente do Amazon Bedrock Runtime com retentativas adaptativas. O elemento mais importante da implementação é o prompt de compressão, que instrui o modelo menor a extrair trechos — não resumir, não parafrasear, não reescrever. O modelo deve copiar verbatim apenas as sentenças ou parágrafos curtos que contêm evidências diretamente relevantes para a pergunta, preservando os identificadores de chunk para que o sistema downstream possa citar as fontes.

    COMPRESSION_SYSTEM_PROMPT = """You extract evidence from retrieved documents. You will receive a user QUESTION and a list of CHUNKS. Your job: 1. For each chunk, identify the spans (verbatim sentences or short paragraphs) that contain evidence directly relevant to answering the QUESTION. 2. Output ONLY those spans, copied verbatim from the source. Do not paraphrase, summarize, or rewrite. 3. Preserve chunk identifiers so the downstream system can cite sources. 4. If a chunk contains no relevant evidence, output the chunk identifier followed by NO_RELEVANT_EVIDENCE. Output format (strict): [CHUNK_ID: <id>] <verbatim span 1> <verbatim span 2> [CHUNK_ID: <id>] NO_RELEVANT_EVIDENCE Do not add commentary, headings, conclusions, or your own words. Only verbatim spans from the source chunks, grouped by chunk identifier."""

    A chamada de compressão roda com temperatura 0.0, o que mantém a extração determinística — o modelo copia os trechos exatamente como aparecem na fonte. Em seguida, o modelo principal recebe a consulta e o contexto comprimido para gerar a resposta final.

    # Step 1: Compress. The smaller model filters the retrieved chunks.
    compressed = bedrock.converse(
        modelId=COMPRESSION_MODEL_ID,
        system=[{"text": COMPRESSION_SYSTEM_PROMPT}],
        messages=[{"role": "user", "content": [{"text": f"QUESTION:\n{query}\n\nCHUNKS:\n{chunks}"}]}],
        inferenceConfig={"temperature": 0.0},
    )
    
    # Step 2: Answer. The primary model reasons over the filtered evidence.
    answer = bedrock.converse(
        modelId=ANSWER_MODEL_ID,
        system=[{"text": "Answer using only the evidence provided. Cite sources."}],
        messages=[{"role": "user", "content": [{"text": f"QUESTION:\n{query}\n\nEVIDENCE:\n{compressed}"}]}],
    )

    Os prompts acima são exemplos e devem ser adaptados ao tipo de documento e às perguntas do seu caso de uso específico.

    Pré-requisitos para implementar

    Resultados do benchmark

    Antes de recomendar o padrão, a AWS o avaliou empiricamente. O benchmark cobriu um corpus de mais de 500 mil documentos distribuídos em 9 tipos de fontes corporativas — mensagens de chat, e-mail, tickets de rastreamento de problemas, documentos em drives compartilhados, registros de CRM, transcrições de reuniões, repositórios de código e páginas de wiki. Foram executadas 500 perguntas em 10 categorias, variando de consultas factuais pontuais a perguntas mais amplas com múltiplas partes. As respostas foram avaliadas por um juiz baseado em modelo de linguagem de grande porte (LLM) em quatro dimensões: correção, completude, precisão de citação e concisão. A taxa de alucinação foi rastreada separadamente.

    Os resultados consolidados foram os seguintes:

    • Custo: baseline 100% → compressão 67% → rerank + compressão 64%
    • Tokens enviados ao modelo: baseline 100% → compressão 12% → rerank + compressão 10%
    • Latência: compressão +19% mais lenta; rerank + compressão +12% mais lenta
    • Qualidade composta (4 dimensões): baseline 100% → compressão 97,5% → rerank + compressão 97,6%
    • Taxa de alucinação: baseline 51% → compressão 44% → rerank + compressão 38%
    Imagem original — fonte: Aws

    A compressão sozinha atingiu 33% de redução de custo e 8,6 vezes menos tokens enviados ao modelo principal. Com rerank + compressão, os números chegaram a 36% de redução de custo e 10,1 vezes menos tokens.

    Imagem original — fonte: Aws

    Na dimensão de qualidade, a correção das respostas ficou dentro de 0,07 ponto da linha de base em todas as condições. A completude e a precisão de citação ficaram ligeiramente abaixo, enquanto a concisão melhorou. Já a taxa de alucinação caiu de 51% no baseline para 44% com compressão e 38% com rerank + compressão.

    Imagem original — fonte: Aws

    Um ponto importante: a economia diminui em consultas mais complexas. Para perguntas típicas, a compressão economizou 37% e o rerank + compressão 40%. Para perguntas difíceis, esses números caíram para 26% e 30%, respectivamente.

    Imagem original — fonte: Aws

    Considerações para uso em produção

    Latência

    Adicionar a chamada de compressão inclui uma etapa extra no caminho da requisição. Como o Claude Haiku é otimizado para velocidade e o modelo principal processa um contexto menor, parte da latência adicionada é recuperada na chamada de resposta. O impacto líquido depende do tamanho original do contexto e de quão compute-bound o modelo principal é. Para superfícies com requisitos de latência abaixo de um segundo, a recomendação é medir com os próprios tamanhos de contexto antes de colocar em produção.

    Qualidade e fidelidade

    O prompt de compressão é projetado para preservar a consistência factual (extração verbatim de toda evidência relevante), os identificadores de chunk para citação, a integridade de raciocínio em múltiplas etapas e os valores numéricos exatos. A instrução “verbatim only” combinada com temperatura 0.0 garante que o modelo de compressão copie os trechos como aparecem na fonte.

    Escolha do modelo menor

    Três fatores guiam a escolha: a razão de preço relativa entre o modelo menor e o principal (quanto menor o preço do modelo de compressão, maior a margem de economia líquida), a velocidade de inferência (modelos otimizados para velocidade limitam a latência adicional) e o alinhamento de família de modelos (usar modelos da mesma família mantém consistência no tratamento de formatação e marcadores de chunk). A disponibilidade de modelos por região no Amazon Bedrock deve ser verificada antes da implementação.

    Abordagem de avaliação antes do deploy

    A recomendação é montar um conjunto de avaliação com consultas representativas dos logs da aplicação (anonimizadas), cobrindo tanto buscas pontuais quanto perguntas com múltiplos fatos na proporção em que ocorrem em produção. Rodar os pipelines baseline e comprimido sobre os mesmos resultados de recuperação permite isolar o efeito da compressão. As respostas devem ser avaliadas nas dimensões relevantes para o caso de uso — correção, completude, precisão de citação e fidelidade à evidência recebida pelo modelo principal. Para deployments em produção, o Amazon Bedrock Guardrails pode fornecer filtragem de conteúdo e validação de ancoragem como controles complementares.

    Onde esse padrão se encaixa bem

    O padrão entrega valor quando três condições se alinham: o contexto recuperado é grande, o modelo principal é a parte cara da chamada e a pergunta é estreita em relação à amplitude do que foi recuperado. Alguns cenários que se encaixam bem:

    • Assistentes de conformidade e políticas em setores regulados — utilidades, serviços financeiros, seguros e saúde mantêm boletins, tarifas e documentos de política longos onde uma única seção responde à maioria das perguntas. A extração verbatim preserva a redação regulatória exata e o ID da fonte, o que importa quando a resposta precisa ser defensável em uma auditoria.
    • Copilots de suporte ao cliente sobre grandes bases de conhecimento de produto — o top-k é configurado alto para reduzir a chance de perder casos extremos, mas a maioria dos tickets resolve com um ou dois parágrafos de um artigo longo. Em volumes de suporte da ordem de centenas de milhares de tickets por mês, pequenas economias por consulta se acumulam rapidamente.
    • Assistentes internos de engenharia e operações sobre runbooks e wikis — documentos internos são verbosos e pouco estruturados, mas as perguntas são específicas. A resposta costuma ser algumas linhas; o contexto de política e background ao redor não é necessário.
    • Análise financeira e de calls de resultados — chunks densos (seções de 10-K, parágrafos de transcrição) com perguntas pontuais. A compressão preserva a capacidade de citar a fonte verbatim enquanto reduz o custo por consulta no modelo maior.

    Se o workload envolve chat conversacional com contexto recuperado pequeno e requisitos de latência abaixo de um segundo, o padrão pode não ser o mais adequado. Nesses casos, recursos como prompt caching e Intelligent Prompt Routing do Amazon Bedrock oferecem mais valor com menos latência adicional.

    Combinando com outras capacidades do Amazon Bedrock

    O padrão pode ser combinado com recursos existentes do Amazon Bedrock para otimizações compostas ao longo de todo o pipeline de RAG: prompt caching, Intelligent Prompt Routing e a Rerank API. Cada camada adicional contribui para reduzir custos ou melhorar a relevância do contexto, e o padrão de compressão se encaixa naturalmente nessa stack sem exigir mudanças na lógica de recuperação já existente.

    Conclusão

    A compressão de contexto orientada por consulta é um padrão de pós-recuperação que se insere entre o recuperador e o modelo principal sem alterar a estratégia de recuperação. Uma única função Lambda orquestra as duas chamadas ao Amazon Bedrock, comprime o contexto e ajusta o equilíbrio entre custo e qualidade para o workload específico. O prompt de compressão lida tanto com consultas simples quanto com perguntas complexas de múltiplas fontes sem exigir lógica de roteamento separada.

    Para começar, consulte a documentação do Amazon Bedrock e a página de preços do Amazon Bedrock para os custos atuais dos modelos.

    Fonte

    Reduce RAG costs on Amazon Bedrock with query-aware compression (https://aws.amazon.com/blogs/machine-learning/reduce-rag-costs-on-amazon-bedrock-with-query-aware-compression/)

  • Criando políticas Dogwood a partir de linguagem natural no Amazon Bedrock AgentCore

    O problema de controlar agentes de IA em produção

    Agentes de IA são capazes de automatizar fluxos de trabalho complexos, mas sem os controles certos, eles podem tomar ações que conflitam com as políticas internas da organização ou com obrigações regulatórias. Para endereçar esse desafio, a AWS desenvolveu o recurso de Política no Amazon Bedrock AgentCore, que permite às equipes aplicar controles de forma centralizada sobre os agentes que rodam no Amazon Bedrock AgentCore.

    Recentemente, a AWS expandiu esse recurso com novas capacidades que permitem impor restrições ao longo do tempo — como limites de taxa, pré-requisitos de chamadas, ordenação sequencial de ferramentas e controle de efeitos cumulativos. Essas políticas são expressas em Dogwood, uma linguagem de governança de código aberto, e aplicadas em tempo real pelo monitor Dogwood embutido no AgentCore Gateway.

    O que é o Policy Authoring

    Como parte desse lançamento, a AWS também expandiu as capacidades do Policy Authoring, uma ferramenta baseada em IA que converte documentos de especificação de políticas escritos em linguagem natural em especificações formais Dogwood — sintaticamente e semanticamente corretas.

    Com essa funcionalidade, é possível gerar políticas que:

    • Impõem restrições temporais e de trajetória de ações;
    • Invocam o Amazon Bedrock Guardrails para detectar conteúdo inadequado em campos de texto livre;
    • Restringem os parâmetros de entrada das ferramentas disponíveis para o agente.

    O ponto central é que qualquer pessoa, independentemente do nível técnico, pode importar um documento de políticas escrito em prosa diretamente no Amazon Bedrock AgentCore para proteger os sistemas agênticos em produção.

    Como o Policy Authoring funciona na prática

    O Policy Authoring funciona melhor quando as regras já existem em prosa — quando o trabalho é de transcrição, não de design. Você pode fornecer um documento com um conjunto de regras: uma lista de políticas, a seção de regras de um procedimento operacional ou um parágrafo descrevendo ações permitidas ou restritas.

    A ferramenta atua como um tradutor, não como um resumidor. Documentos que misturam regras com justificativas e comentários funcionam melhor quando pré-processados para isolar apenas as regras em si.

    O cenário de exemplo: banco de varejo

    Para ilustrar as traduções, o artigo da AWS usa o exemplo de um agente de atendimento ao cliente em um banco de varejo. Esse agente verifica identidades, abre disputas, emite reembolsos, move fundos entre contas e solicita aprovação de supervisores. Suas ferramentas são acessadas via AgentCore Gateway e incluem:

    • verify_identity — verificação de identidade do chamador;
    • initiate_transfer — transferência de fundos entre contas do cliente;
    • issue_refund — reversão de uma cobrança disputada;
    • file_dispute — abertura de caso de disputa;
    • request_approval — solicitação de aprovação de um supervisor.

    O Policy Authoring recebe junto ao documento um esquema com os nomes das ferramentas, seus argumentos e retornos — gerado a partir do manifesto de ferramentas MCP (Model Context Protocol) do agente. Isso garante que as políticas geradas referenciem exatamente os mesmos nomes que o agente usa.

    Exemplos de tradução de políticas

    Restrição em argumentos de uma ferramenta

    Regra em linguagem natural: Reembolsos só podem ser emitidos durante o horário comercial (9h–17h UTC) e apenas para valores de até US$ 2.500.

    permit (
      principal,
      action == AgentCore::Action::"issue_refund",
      resource
    )
    when {
      context.system.now.toTime() >= duration("9h") &&
      context.system.now.toTime() <= duration("17h")
    }
    when {
      context.input.amount <= 2500
    };

    Uma única frase com dois requisitos independentes se torna uma política com duas condições. Para mais detalhes sobre funções baseadas em tempo como duration, consulte o suporte a políticas baseadas em tempo.

    Pré-requisito obrigatório

    Regra: Não inicie uma transferência a menos que a identidade do chamador tenha sido verificada para a mesma conta nos últimos 15 minutos.

    permit (
      principal,
      action == AgentCore::Action::"initiate_transfer",
      resource
    )
    when temporal {
      formerly within 15m
        AgentCore::Action::"verify_identity"::response{
          input.account: context.input.account,
          output.verified: true
        }
    };

    Aqui a condição não pode ser resolvida apenas com a requisição de transferência — ela consulta o histórico da sessão. O operador formerly within 15m verifica se o evento descrito ocorreu nos últimos 15 minutos. A correlação por account garante que uma verificação de outra conta não satisfaça a regra.

    Limite cumulativo

    Regra: Bloqueie uma transferência se o total transferido nas últimas 12 horas ultrapassar US$ 50.000.

    forbid (
      principal,
      action == AgentCore::Action::"initiate_transfer",
      resource
    )
    when temporal {
      exists (total: Long). (
        (sum a for (a: Long), (t: Timepoint).
          where (
            formerly within 12h (
              AgentCore::Action::"initiate_transfer"::request{
                input.amount: a
              } && tp(t)
            )
          )
        ) == total &&
        total > 50000
      )
    };

    Aqui o histórico não é apenas consultado — ele é somado. A política soma o argumento amount de todas as transferências nas últimas 12 horas e bloqueia a chamada atual se o total ultrapassar US$ 50.000. Cada transferência individual pode ser pequena, mas a condição restringe o agregado.

    Limite de taxa

    Regra: O agente não pode tentar mais de três reembolsos para a mesma conta em uma hora.

    forbid (
      principal,
      action == AgentCore::Action::"issue_refund",
      resource
    )
    when temporal {
      exists (n: Long). (
        (count for (t: Timepoint).
          where (
            formerly within 1h (
              AgentCore::Action::"issue_refund"::request{
                input.account: context.input.account
              } && tp(t)
            )
          )
        ) == n &&
        n > 3
      )
    };

    Estrutura semelhante ao exemplo anterior, mas contando eventos em vez de somar valores. A contagem inclui a tentativa atual, portanto a quarta tentativa na mesma hora é bloqueada. Como a regra diz "tentativa", reembolsos negados ou com falha também contam.

    Verificação de texto livre

    Regra: Rejeite qualquer abertura de disputa cuja descrição contenha um número de Seguro Social americano.

    forbid (
      principal,
      action == AgentCore::Action::"file_dispute",
      resource
    )
    when {
      BedrockGuardrails::SensitiveInformation(
        ["US_SOCIAL_SECURITY_NUMBER"],
        [context.input.description]
      ).maxConfidenceScore().greaterThanOrEqual(decimal("0.2"))
    };

    Algumas regras dizem respeito ao significado de texto livre, não a valores estruturados. Para esses casos, a política gerada invoca uma verificação do Amazon Bedrock Guardrails diretamente no campo indicado. Como a regra original não especifica um limiar de confiança, a tradução usa o valor padrão para essa verificação.

    Regra que combina múltiplos tipos de condição

    Regra: Um reembolso acima de US$ 500 exige aprovação de supervisor para aquela cobrança, registrada nos últimos 30 minutos.

    forbid (
      principal,
      action == AgentCore::Action::"issue_refund",
      resource
    )
    when {
      context.input.amount > 500
    }
    unless temporal {
      formerly within 30m
        AgentCore::Action::"request_approval"::response{
          input.charge_id: context.input.charge_id,
          output.approved: true
        }
    };

    A sentença tem duas partes verificadas de formas distintas: um limite no argumento da chamada atual e uma condição sobre o histórico da sessão. A cláusula unless levanta a negação quando uma aprovação correspondente está registrada. A correlação por charge_id impede que uma aprovação para uma cobrança autorize o reembolso de outra.

    Boas práticas para escrever políticas em linguagem natural

    Políticas claras e sem ambiguidade geram comportamentos mais previsíveis — tanto para humanos quanto para o autoformalizador. A AWS destaca as seguintes orientações:

    • Diga se você quer a tentativa ou o resultado. "Após uma transferência" é ambíguo. "Após uma transferência ser concluída com sucesso" não é. Limites de taxa e caps cumulativos geralmente se aplicam a tentativas; pré-requisitos e regras de ordenação, a resultados.
    • Declare a janela de tempo. "Recentemente" não tem tradução. "Nos últimos 30 minutos" sim. Se a regra deve resetar em um limite de calendário (e não deslizar com o relógio), declare isso explicitamente.
    • Nomeie o sujeito da regra. "Não mais que três transferências por hora" não diz de quem: três pelo mesmo chamador ou três contra a mesma conta? Ambas são expressáveis, mas são políticas diferentes.
    • Forneça o limiar e seu limite. "Mais de três" e "pelo menos três" diferem por uma ação — geralmente a que a regra existe para impedir. O mesmo vale para níveis de confiança em verificações de conteúdo.
    • Revise as políticas Dogwood geradas. Cada política é retornada junto com a frase que a originou para leitura lado a lado. A validação verifica se a política é bem formada, mas não confirma se ela expressa exatamente o que o autor pretendia. Esse julgamento fica com quem é dono do documento.

    O que não pode ser aplicado por políticas

    O serviço de authoring consegue identificar e sinalizar políticas incompatíveis com o mecanismo de execução. Há quatro categorias comuns de regras que não podem ser traduzidas para Dogwood:

    • Não é uma regra sobre uma ação. Exemplo: "Agentes devem sempre agir no melhor interesse financeiro do cliente." Não há condição sobre nenhuma ação, campo ou principal. Essa é uma exigência legítima, mas pertence às instruções do agente, às avaliações e ao treinamento — não a um mecanismo de autorização.
    • Pede uma ação, não um veredicto. Exemplo: "Quando uma descrição de disputa contiver um número de Seguro Social, remova-o antes de salvar." Um mecanismo de políticas permite ou nega uma chamada — ele não a modifica. Redação é um controle diferente, aplicado em outro ponto do pipeline.
    • Usa construtos não suportados pela linguagem. Exemplo: "Negue transferências em fins de semana e feriados federais americanos." O suporte a data e hora no Dogwood cobre pontos no tempo, offsets e diferenças, mas não há acesso ao dia da semana nem a calendários de feriados. O guia da linguagem Dogwood detalha quais construtos estão disponíveis.
    • Está fora do escopo de execução. Exemplo: "Um cliente pode iniciar no máximo dez transferências por dia, contadas em todas as sessões simultâneas." A execução avalia trajetórias dentro de uma sessão; um cap que agrega entre sessões não pode ser recuperado com uma formulação diferente.

    Em cada um desses casos, o resultado útil não é uma política, mas um rótulo indicando que a regra não pode ser traduzida para Dogwood — o que sinaliza a necessidade de considerar alternativas: reescrever, mover para outro controle ou aceitar que permanece como processo humano.

    Como funciona o pipeline de autoformação

    O processo de autoformação roda em quatro etapas:

    1. Decomposição: O documento é quebrado em regras atômicas. Uma cláusula numerada frequentemente carrega várias obrigações independentes, e cada uma se torna uma instrução sobre uma ferramenta específica que pode ser aplicada de forma isolada.
    2. Roteamento: Cada regra é classificada como expressável ou não em Dogwood. As inexpressáveis são separadas antes da tradução, evitando que se tornem políticas que validam corretamente mas aplicam a coisa errada.
    3. Autoformação: As regras restantes são convertidas em Dogwood, ancoradas no esquema de ferramentas fornecido junto ao documento.
    4. Validação: Cada política candidata é validada usando as mesmas ferramentas de linha de comando Dogwood que acompanham a linguagem open source. O compilador é uma autoridade precisa e determinística sobre se uma política pode ser analisada e se todos os nomes existem no esquema. Quando uma candidata é rejeitada, seus diagnósticos são retornados e a regra é traduzida novamente com esses erros em vista, por um número limitado de rodadas.

    O resultado final são duas coleções: as políticas que validaram para sintaxe e compatibilidade com o esquema do ambiente (junto com as regras atômicas que as geraram) e as regras atômicas que foram separadas por não serem expressáveis.

    Conclusão

    O Policy Authoring no Amazon Bedrock AgentCore representa um avanço importante para equipes que precisam aplicar governança sobre agentes de IA sem precisar dominar uma linguagem formal de especificação. A abordagem reconhece que as regras geralmente já existem em prosa — em procedimentos operacionais, documentos de conformidade ou políticas internas — e encurta o caminho entre esse documento e um conjunto de políticas revisável e implantável.

    O Dogwood pode ser escrito diretamente por quem preferir trabalhar na linguagem. O Policy Authoring existe para o caso mais comum: quando as regras já estão em prosa e o trabalho é de transcrição.

    Para começar, consulte a documentação de Política no AgentCore para criar um motor de políticas e gerar políticas a partir de um documento, e o guia da linguagem Dogwood para quem quiser ler ou estender as políticas geradas. Para entender como essas políticas são interpretadas e aplicadas em tempo de execução, veja também Securing AI agents with temporal policies in Amazon Bedrock AgentCore e Introducing Dogwood: runtime verification for AI agents.

    Fonte

    Authoring Dogwood policies from natural language in Amazon Bedrock AgentCore (https://aws.amazon.com/blogs/machine-learning/authoring-dogwood-policies-from-natural-language-in-amazon-bedrock-agentcore/)

  • Fluxo de ML sem código com Snowflake e SageMaker Canvas – Parte 2: Preparação de dados e construção de modelos

    Contexto da série

    Esta é a segunda parte de uma série de três artigos publicada pela AWS sobre como montar um fluxo completo de Aprendizado de Máquina (ML) sem escrever código. A primeira parte tratou da configuração do ambiente Snowflake e da infraestrutura necessária. Agora, a AWS demonstra como usar o Amazon SageMaker Canvas para preparar os dados e treinar um modelo de detecção de fraudes — do começo ao fim, sem programação.

    O que é o Amazon SageMaker Canvas?

    O Amazon SageMaker Canvas é um serviço visual de ML que permite que analistas de negócios e especialistas de domínio construam modelos preditivos e gerem previsões sem precisar escrever código. A proposta é democratizar o acesso ao ML dentro das organizações, mantendo controles de segurança e governança corporativa. A interface intuitiva cobre todo o ciclo: preparação de dados, treinamento de modelos e geração de previsões.

    Pré-requisitos

    Antes de começar, é necessário ter concluído a primeira parte da série, que configura o ambiente Snowflake. As credenciais e detalhes de conexão da conta Snowflake obtidos nessa etapa são indispensáveis para seguir adiante.

    Configurando o Amazon SageMaker Canvas

    O primeiro passo é acessar o Console de Gerenciamento da AWS (AWS Management Console) e localizar o Amazon SageMaker Canvas. Em seguida, é preciso criar um domínio — que funciona como a unidade organizacional base do ambiente SageMaker, agrupando perfis de usuário, configurações de armazenamento e controles de acesso.

    Para uma configuração rápida, a AWS recomenda a opção Configuração para usuário único (Quick setup), que cria automaticamente o domínio e o perfil de usuário. Após a criação, basta selecionar o Canvas no painel lateral, escolher o domínio e o perfil criados, e aguardar de 3 a 5 minutos para o ambiente ficar disponível.

    Preparação de dados com o Data Wrangler

    O Amazon SageMaker Data Wrangler é a ferramenta integrada ao Canvas responsável por simplificar a preparação de dados para fluxos de ML. Com transformações visuais e uma interface intuitiva, ele reduz significativamente o tempo gasto nessa etapa — que costuma ser uma das mais trabalhosas em qualquer projeto de ML.

    A integração direta com o Snowflake é um ponto de destaque: elimina a necessidade de exportar dados manualmente, garantindo que o trabalho seja feito sempre com os dados mais atualizados do data warehouse.

    A. Conexão com a fonte de dados

    Para conectar o Canvas ao Snowflake, o caminho é: acessar o Data Wrangler pelo painel de navegação, escolher a opção de importar dados tabulares e selecionar o Snowflake como tipo de conexão. No formulário de conexão, são fornecidos o nome da conexão, o ID da conta Snowflake (no formato organização + hífen + ID da conta), o nome de usuário e a senha.

    Com a conexão estabelecida, a AWS orienta a executar uma consulta SQL para criar limiares de outliers por cartão e categoria — uma técnica para identificar padrões de gastos incomuns. A lógica calcula a média mais três desvios padrão dos valores de transação, agrupados por número de cartão e categoria:

    select CC_NUM, CATEGORY,
      avg(AMT) + (3* stddev_pop(AMT)) as amt_outlier,
      case when sum(is_fraud)>1 then 1 else 0 end as fraud_history
    from FRAUD.PUBLIC.FRAUD_TABLE
    where trans_date_trans_time<'2020-12-01'
    group by CC_NUM, CATEGORY

    Após executar a consulta e visualizar os resultados, os dados são importados para o workspace do Canvas.

    B. Enriquecimento dos dados

    Na sequência, uma segunda fonte de dados é adicionada ao fluxo. Essa etapa incorpora características temporais (hora do dia, dia da semana), informações demográficas (faixa etária) e limiares de outlier por comerciante — todos sinais relevantes para detecção de fraudes. A consulta SQL utilizada é:

    select t.MERCHANT, t.CC_NUM,
      'H'||extract(hour from t.TRANS_DATE_TRANS_TIME) as TRANS_HOUR,
      'D'||extract(dow from t.TRANS_DATE_TRANS_TIME) as TRANS_DOW,
      t.state, t.gender,
      'A'||FLOOR(DATEDIFF(YEAR, DATEADD(DAY, 1, CAST(t.dob AS DATE)), CAST(t.TRANS_DATE_TRANS_TIME AS DATE)) / 5) * 5 AS age_category,
      t.CATEGORY, t.IS_FRAUD, t.AMT,
      m.merchant_amt_outlier, m.merchant_fraud_history
    from FRAUD.PUBLIC.FRAUD_TABLE t
    left join (
      select MERCHANT,
        avg(AMT) + (3* stddev_pop(AMT)) as merchant_amt_outlier,
        case when sum(is_fraud)>1 then 1 else 0 end as merchant_fraud_history
      from FRAUD.PUBLIC.FRAUD_TABLE
      where trans_date_trans_time<'2020-12-01'
      group by MERCHANT
    ) m on t.MERCHANT = m.MERCHANT
    where t.trans_date_trans_time<'2020-12-01'

    C. Transformação dos dados

    Com as duas fontes importadas, o próximo passo é combiná-las. No Data Wrangler, o fluxo de dados (Data flow) exibe as duas origens Snowflake. A junção é feita com um Left outer join usando a coluna CATEGORY como chave de relacionamento.

    Após a junção, duas novas colunas são criadas usando fórmulas personalizadas com expressões Spark SQL:

    • CC_FLAG: indica se o valor da transação supera o limiar de outlier do cartão:
      CASE WHEN AMT > AMT_OUTLIER THEN 1 ELSE 0 END
    • MERCHANT_AMT_FLAG: indica se o valor supera o limiar de outlier do comerciante:
      CASE WHEN AMT > MERCHANT_AMT_OUTLIER THEN 1 ELSE 0 END

    Por fim, colunas sensíveis ou desnecessárias são removidas do dataset para garantir que o modelo não seja treinado com informações que possam causar vazamento de dados ou comprometer a privacidade. As colunas eliminadas são: CC_NUM, AMT_OUTLIER, MERCHANT e MERCHANT_AMT_OUTLIER.

    D. Análise de qualidade e exportação para o modelo

    Com a preparação concluída, o Canvas permite executar um relatório de qualidade e insights dos dados. Para isso, basta acessar a aba de Análises, selecionar o tipo "Data Quality and Insights Report", definir IS_FRAUD como coluna-alvo e escolher o tipo de problema como Classificação.

    O relatório gerado em poucos minutos inclui um resumo dos dados, análise de features, linhas duplicadas, amostras anômalas e, na seção "Quick model", métricas de acurácia e uma matriz de confusão. A seção de resumo de features mostra a importância preditiva de cada variável — útil para decidir quais colunas manter ou descartar.

    Quando a preparação estiver satisfatória, o dataset é exportado para o ambiente de construção de modelos diretamente pelo Data flow, escolhendo a opção "Create model" no nó da última transformação.

    Construção do modelo de detecção de fraudes

    Na tela de construção (Build), o processo é direto: seleciona-se IS_FRAUD como coluna-alvo, configura-se o tipo de modelo como "2-category" (classificação binária) e escolhe-se o método de treinamento Ensemble com o algoritmo XGBoost — uma combinação que equilibra acurácia e eficiência computacional.

    As colunas FRAUD_HISTORY e MERCHANT_FRAUD_HISTORY são desmarcadas antes de iniciar o treinamento padrão (Standard build). O processo leva aproximadamente 15 a 30 minutos para ser concluído.

    Após o treinamento, a aba Analyze exibe quais features tiveram maior impacto nas previsões, além de gráficos de dispersão e classificações de fraude. A opção Advanced Metrics oferece uma visão mais aprofundada da performance do modelo.

    Gerando previsões

    Com o modelo treinado, o próximo passo é aplicá-lo a um conjunto de dados inédito. A AWS disponibiliza um arquivo CSV de exemplo para previsões. Na aba Predict do Canvas, o usuário carrega esse arquivo, cria um dataset e aciona a geração de previsões. O processo leva alguns minutos; quando o status muda para "Ready", os resultados estão disponíveis.

    Enviando resultados para o Amazon QuickSight

    Para visualizar os resultados de forma interativa no Amazon QuickSight, alguns pré-requisitos precisam ser atendidos. A AWS detalha esses requisitos na documentação oficial, mas em resumo são:

    • Alinhamento de região: a conta do QuickSight deve estar na mesma região AWS do domínio SageMaker Canvas.
    • Permissões de Gerenciamento de Identidade e Acesso (IAM): a função de execução associada ao domínio SageMaker (criada durante a configuração do domínio) precisa de permissões adicionais para enviar previsões ao QuickSight. A política inline necessária está descrita na documentação da AWS.
    • Acesso ao bucket S3: o QuickSight precisa de acesso ao bucket S3 onde o Canvas armazena as previsões, nomeado no formato sagemaker-{região}-{id_da_conta}.
    • Usuários do QuickSight: os usuários que receberão o dashboard precisam ter perfil de Author ou Admin no QuickSight. Mais detalhes em Gerenciamento de acesso de usuários.

    Com os pré-requisitos atendidos, basta selecionar o job de previsão no Canvas e usar a opção "Send to Amazon QuickSight", adicionando os usuários que terão acesso ao dashboard.

    Conclusão

    Esta segunda parte da série demonstra que é possível construir um pipeline completo de ML — desde a conexão com um data warehouse até o treinamento de um modelo de detecção de fraudes — sem escrever uma linha de código de ML. O Amazon SageMaker Canvas, integrado ao Data Wrangler e ao Snowflake, oferece um ambiente visual que coloca analistas de negócios e especialistas de domínio no controle do processo.

    Com o modelo treinado e as previsões geradas, o terreno está preparado para a terceira parte da série, que mostra como transformar esses insights em dashboards interativos no Amazon QuickSight.

    Referências da série

    Fonte

    Build a no-code ML workflow with Snowflake, Amazon SageMaker Canvas and Amazon Quick – Part 2: Data preparation and model building with Amazon SageMaker Canvas (https://aws.amazon.com/blogs/machine-learning/build-a-no-code-ml-workflow-with-snowflake-amazon-sagemaker-canvas-and-amazon-quick-part-2-data-preparation-and-model-building-with-amazon-sagemaker-canvas/)

  • Amazon EKS agora suporta rotação de Autoridade Certificadora (CA) com gerenciamento automatizado de ciclo de vida

    O que foi anunciado

    O Amazon Elastic Kubernetes Service (Amazon EKS) anunciou suporte à rotação de Autoridade Certificadora (CA), permitindo que os clientes rotem a CA do cluster por meio de um ciclo de vida gerenciado com salvaguardas automatizadas.

    Cada cluster do Amazon EKS possui sua própria CA, responsável por habilitar conexões criptografadas com a Interface de Programação de Aplicações (API) do Kubernetes. Com esse novo recurso, é possível realizar a rotação da CA antes de sua expiração, garantindo que o cluster continue operacional e seguro.

    Por que isso é relevante agora

    Os clusters do Amazon EKS criados desde o lançamento do serviço em 2018 possuem CAs com validade de 10 anos — ou seja, muitos desses clusters estão se aproximando do momento em que a rotação deve ser iniciada. É exatamente para esse cenário que a AWS desenvolveu esse mecanismo gerenciado.

    Responsabilidade compartilhada na rotação

    A rotação de CA no Amazon EKS segue um modelo de responsabilidade compartilhada:

    • A AWS gerencia o ciclo de vida da rotação e atualiza automaticamente os componentes gerenciados pela própria AWS para que passem a confiar na CA sucessora. Instâncias no EKS Auto Mode e nós do AWS Fargate são atualizados automaticamente.
    • Os clientes são responsáveis por substituir os worker nodes e atualizar clientes externos para que confiem na CA sucessora antes de sua ativação — inclusive quando utilizam EKS Auto Mode ou Fargate, no que diz respeito aos clientes externos que se conectam ao servidor de API do cluster.

    Salvaguardas automatizadas

    Para apoiar os clientes durante o processo, o Amazon EKS oferece um conjunto de proteções automáticas:

    • Notificações antecipadas antes da expiração da CA;
    • Adição automática de uma CA sucessora, caso o cliente não crie uma por conta própria;
    • Ativação automática da CA sucessora, caso o cliente não realize a ativação dentro do prazo;
    • Capacidade de rollback, permitindo reverter para a CA anterior caso algum problema surja durante a transição.

    Disponibilidade e como começar

    A rotação de CA no Amazon EKS está disponível sem custo adicional em todas as regiões comerciais da AWS. Para iniciar o processo, é possível utilizar o AWS CLI, as APIs do EKS, o CloudFormation ou o console da AWS.

    Para mais detalhes, consulte a documentação oficial do Amazon EKS e o artigo técnico Deep dive sobre rotação de Autoridade Certificadora no Amazon EKS.

    Fonte

    Amazon EKS now supports certificate authority (CA) rotation with automated lifecycle management (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-eks-certificate-authority-ca-rotation-automated-lifecycle-management)

  • Amazon CloudFront agora suporta Controle de Acesso de Origem (OAC) para Pontos de Acesso Multi-Região do S3

    O que foi anunciado

    A AWS anunciou que o Amazon CloudFront agora oferece suporte nativo ao Controle de Acesso de Origem (OAC — Origin Access Control) para os Pontos de Acesso Multi-Região (MRAP — Multi-Region Access Points) do Amazon S3. A novidade simplifica bastante a forma como equipes protegem seus conteúdos distribuídos globalmente.

    Como funciona essa combinação

    Quando times de engenharia utilizam o Amazon S3 MRAP junto ao CloudFront, o objetivo é servir conteúdo a partir de um único endpoint global. Esse endpoint roteia automaticamente as requisições para o bucket replicado mais próximo do usuário, sempre que ocorre um cache miss — ou seja, quando o conteúdo solicitado ainda não está em cache na borda. Esse modelo melhora tanto a performance quanto a resiliência para usuários distribuídos ao redor do mundo.

    Qual era o problema antes

    Até então, para proteger adequadamente os origens MRAP, as equipes precisavam calcular e encaminhar manualmente o cabeçalho de autorização SigV4a (Versão de Assinatura Assimétrica 4) usando uma função personalizada de Lambda@Edge. Esse processo adicionava complexidade operacional: era necessário manter código customizado apenas para lidar com a assinatura das requisições.

    O que muda com o novo suporte

    Com o suporte nativo ao OAC, o CloudFront passa a assinar automaticamente as requisições direcionadas às origens S3 MRAP — sem nenhuma função Lambda@Edge adicional. Na prática, isso traz dois ganhos diretos:

    • Preenchimento de cache mais rápido: as requisições de cache miss são resolvidas a partir da região mais próxima disponível.
    • Acesso restrito e seguro via OAC: o MRAP fica protegido sem a necessidade de computação personalizada do cabeçalho de autorização.

    Disponibilidade e como começar

    O suporte ao OAC do CloudFront para origens S3 MRAP está disponível mundialmente, com exceção da região CloudFront China. Para habilitar o recurso, basta acessar o Console do CloudFront, o SDK, a CLI ou o CloudFormation e ativar o OAC ao configurar o endpoint S3 MRAP desejado.

    Não há cobrança adicional associada a essa funcionalidade. Para mais detalhes técnicos, a AWS disponibiliza o Guia do Desenvolvedor do CloudFront com todas as instruções necessárias.

    Fonte

    Amazon CloudFront now supports Origin Access Control (OAC) for Amazon S3 Multi-Region Access Points (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-cloudfront-oac-s3-mrap)

  • AWS Network Firewall agora suporta contagem de hits por regra

    O problema que motivou a novidade

    Quem gerencia firewalls em ambientes corporativos sabe bem como conjuntos de regras crescem com o tempo. Novas regras são adicionadas para atender a requisitos de segurança, auditorias ou incidentes pontuais — e poucas são removidas. O resultado é um conjunto de regras cada vez mais extenso, com muitas entradas que podem nunca ser acionadas na prática.

    Até então, a única forma de descobrir quais regras do AWS Network Firewall estavam realmente correspondendo ao tráfego era analisar logs manualmente. Isso cria dois problemas sérios: operacional e de conformidade. Do ponto de vista operacional, equipes não conseguem identificar regras dormentes que consomem capacidade sem servir a nenhum propósito. Do ponto de vista de conformidade, frameworks como o Padrão de Segurança de Dados da Indústria de Cartões de Pagamento (PCI) 4.0 e a Lei de Resiliência Operacional Digital (DORA) exigem evidências de que controles específicos estão ativamente funcionando — e sem dados de ativação de regras, essa evidência simplesmente não existe.

    Para resolver esse cenário, a AWS anunciou o suporte a rule hit count (contagem de hits por regra) no Network Firewall, uma funcionalidade que entrega exatamente essa visibilidade de forma nativa e automática.

    Como funciona o rule hit count

    O rule hit count registra quantas vezes cada regra stateful corresponde ao tráfego de rede. O contador é incrementado sempre que uma regra gera um log de alerta — ou seja, regras com ações de alert, drop ou reject são contabilizadas automaticamente, pois essas ações produzem logs de alerta por padrão.

    Regras configuradas com a ação pass, por outro lado, não geram logs de alerta por padrão e, portanto, não aparecem na métrica de hit count. Para incluir esse tipo de regra na contagem, basta adicionar a palavra-chave alert dentro da própria regra de pass. Isso faz com que o tráfego continue sendo permitido normalmente, mas um log de alerta também seja gerado, tornando a regra visível na métrica. O exemplo abaixo, em sintaxe Suricata, ilustra esse padrão:

    pass tls $HOME_NET any -> $EXTERNAL_NET 443 (msg:"Pass and Log HTTPS traffic"; alert; sid:1000001; rev:1;)

    Essa regra permite o tráfego HTTPS ao destino pretendido e, ao mesmo tempo, gera um log de alerta para que a regra apareça no hit count.

    Metadados adicionados nos logs de alerta

    A funcionalidade também enriquece cada log de alerta com um bloco de metadados que identifica o grupo de regras responsável pelo match. Esse enriquecimento é automático e não requer configuração adicional:

    "aws_metadata": {
      "resource_arn": "arn:aws:network-firewall:us-east-1:123456789012:stateful-rulegroup/StatefulRuleGroup"
    }

    Para ilustrar como esse metadado aparece em um log completo, veja o exemplo abaixo:

    {
      "firewall_name": "egress-and-east-west-firewall",
      "availability_zone": "us-east-1a",
      "event_timestamp": "1786112515",
      "event": {
        "tx_guessed": true,
        "aws_category": "",
        "tx_id": 0,
        "app_proto": "http",
        "ip_v": 4,
        "src_ip": "10.2.1.205",
        "src_port": 46240,
        "event_type": "alert",
        "alert": {
          "severity": 3,
          "signature_id": 10000003,
          "rev": 0,
          "signature": "Egress HTTP but not port TCP/80",
          "action": "blocked",
          "category": ""
        },
        "ts_progress": "request_complete",
        "flow_id": 927132830538451,
        "dest_ip": "3.226.253.175",
        "proto": "TCP",
        "verdict": {
          "action": "drop"
        },
        "http": {
          "hostname": "3.226.253.175",
          "http_port": 4444,
          "url": "/",
          "http_user_agent": "curl/8.17.0",
          "http_method": "GET",
          "protocol": "HTTP/1.1",
          "length": 0
        },
        "tc_progress": "response_started",
        "dest_port": 4444,
        "pkt_src": "geneve encapsulation",
        "aws_metadata": {
          "resource_arn": "arn:aws:network-firewall:us-east-1:123456789012:stateful-rulegroup/StatefulRuleGroup"
        },
        "timestamp": "2026-08-07T14:21:55.611810+0000",
        "direction": "to_server"
      }
    }

    O Network Firewall envia esses logs de alerta para o Amazon CloudWatch Logs ou para o Amazon Simple Storage Service (Amazon S3). Para identificar qual regra específica gerou um alerta, basta combinar os campos sid (identificador de assinatura) e resource_arn na consulta. O dashboard de monitoramento do firewall usa exatamente esses campos para calcular e exibir os hit counts por regra, dispensando a necessidade de consultar os logs diretamente. Mas caso prefira análise customizada, é possível usar o CloudWatch Logs Insights para logs armazenados no CloudWatch, ou o Amazon Athena para logs no S3.

    Como começar a usar

    O rule hit count já vem habilitado por padrão no Network Firewall — não é necessária nenhuma configuração adicional. Assim que as regras do firewall estão em operação, o rastreamento de hits começa automaticamente.

    Pré-requisitos

    Para aproveitar o recurso, alguns pontos precisam estar configurados:

    • Firewall existente: É necessário ter um Network Firewall configurado para inspecionar tráfego de uma Amazon Virtual Private Cloud (Amazon VPC). Se ainda não tiver um, o guia de introdução ao AWS Network Firewall é o ponto de partida recomendado.
    • Entrega de logs de alerta configurada: O firewall precisa ter o log de alertas habilitado. Os metadados de hit count são capturados independentemente do destino dos logs, mas o dashboard nativo exige que os logs sejam enviados ao CloudWatch Logs ou ao Amazon S3.
    • Monitoramento detalhado habilitado: Para visualizar o painel de Top Rule Hits no console, é necessário habilitar o monitoramento detalhado nas configurações de log do firewall ou pela aba de Monitoramento no Console de Gerenciamento da AWS. Se você tiver uma solução de dashboard própria, os metadados necessários já estão presentes nos logs automaticamente — independentemente de o monitoramento detalhado estar ativo ou não.
    • Regras pass com a palavra-chave alert: Regras com ação pass não geram logs de alerta por padrão. Para que apareçam na métrica de hit count, inclua a palavra-chave alert nessas regras, conforme demonstrado anteriormente.

    Visualizando os dados no console

    Para acessar as métricas de hit count, abra o console do Network Firewall, selecione o firewall desejado e navegue até a seção Monitoring and observability. Em Top analysis, o painel Top Rule Hits exibe as regras stateful mais acionadas. É possível selecionar um período de lookback para filtrar a atividade dentro de um intervalo de tempo específico.

    O painel apresenta colunas para contagem de hits (com gráfico de barras e fração), percentual do total de hits, Resource ARN (Nome de Recurso da Amazon), Signature ID (identificador de assinatura), descrição da regra (campo msg da regra Suricata) e última ocorrência em UTC.

    Vale notar que os IDs de assinatura 2, 4, 6 e 8 são assinaturas geradas automaticamente pelo sistema, correspondentes às ações padrão da política de firewall em modo de ordem estrita. Como essas assinaturas têm origem na política — e não em um grupo de regras —, o campo resource_arn exibe o ARN da política de firewall em vez do ARN de um grupo de regras. Elas aparecem no Top Rule Hits quando a política tem ações padrão como Drop established, Alert established ou suas variantes de camada de aplicação configuradas. Essas assinaturas disparam em pacotes de conexão estabelecida que não correspondem a nenhuma regra explícita, aplicando a postura de negação padrão da política.

    Casos de uso práticos

    Identificando regras inativas

    Qualquer regra cujo Signature ID não apareça no painel de Top Rule Hits durante o período selecionado não correspondeu a nenhum tráfego naquele intervalo. Isso indica que a regra pode estar obsoleta ou posicionada incorretamente dentro do grupo de regras.

    Acelerando a resposta a incidentes

    Filtrando o painel pelo período de um incidente suspeito, a equipe consegue identificar rapidamente quais regras foram acionadas naquele intervalo — sem precisar percorrer manualmente milhares de entradas de log. Por exemplo: uma regra com a descrição traffic_to_oast [oast[.]fun] com seis hits pode indicar que um atacante está tentando exfiltrar dados ou validar uma vulnerabilidade no ambiente.

    Validando regras recém-adicionadas

    Após adicionar uma nova regra para monitorar ou restringir tráfego — como uma regra de geofencing para bloquear conexões a países fora dos Estados Unidos, ou uma regra para categorizar tráfego a domínios de Inteligência Artificial e Aprendizado de Máquina (IA/ML) —, o hit count confirma se a regra está sendo acionada conforme esperado. Isso fornece evidência concreta de que os controles implantados estão funcionando.

    Preços

    O rule hit count está incluído no Network Firewall sem custo adicional. No entanto, as tarifas padrão se aplicam ao armazenamento e à consulta dos dados de log. Se os logs forem enviados ao CloudWatch Logs, aplicam-se os preços do CloudWatch. Se forem armazenados no Amazon S3 e consultados via Athena, aplicam-se as tarifas padrão de armazenamento do S3 e de consulta do Athena. Para detalhes completos, consulte a página de preços do AWS Network Firewall.

    Considerações importantes

    • Para gerenciar custos, revise a utilização dos logs e configure políticas de filtragem ou retenção.
    • O rule hit count se aplica apenas a regras stateful. Regras stateless não suportam rastreamento de hit count no momento.
    • O recurso está disponível em todas as regiões AWS onde o Network Firewall é suportado, exceto Oriente Médio (Emirados Árabes Unidos) e Oriente Médio (Bahrein).

    Conclusão

    O rule hit count é uma adição relevante para equipes que precisam de mais visibilidade sobre a efetividade das suas políticas de firewall. A funcionalidade resolve um problema concreto e recorrente: saber quais regras realmente fazem alguma coisa. Com ela, é possível limpar conjuntos de regras obsoletos, demonstrar conformidade com evidências reais e reagir mais rápido durante investigações de segurança.

    Para mais informações sobre o serviço, consulte a documentação do AWS Network Firewall.

    Fonte

    AWS Network Firewall now supports rule hit count (https://aws.amazon.com/blogs/security/aws-network-firewall-now-supports-rule-hit-count/)

  • Instâncias Amazon EC2 P6-B300 chegam à região Ásia-Pacífico (Seul)

    Mais uma região recebe as instâncias EC2 P6-B300

    A AWS anunciou a disponibilidade das instâncias Amazon EC2 P6-B300 na região Ásia-Pacífico (Seul). A expansão geográfica é relevante para equipes de inteligência artificial que operam nessa parte do mundo e precisam de infraestrutura de alto desempenho para cargas de trabalho intensivas de IA.

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

    As instâncias P6-B300 são voltadas para workloads de IA de grande escala. Cada instância conta com:

    • 8x GPUs NVIDIA Blackwell Ultra
    • 2,1 TB de memória de GPU de alta largura de banda
    • 6,4 Tbps de rede EFA (Elastic Fabric Adapter)
    • 300 Gbps de throughput dedicado via ENA (Elastic Network Adapter)
    • 4 TB de memória do sistema

    Esse conjunto de especificações posiciona as P6-B300 como uma das opções mais robustas da AWS para treinamento e implantação de modelos de fundação (FMs) e grandes modelos de linguagem (LLMs) com técnicas sofisticadas e parâmetros na casa dos trilhões.

    Comparação com as instâncias P6-B200

    Em relação à geração anterior, as instâncias P6-B200, as P6-B300 entregam melhorias significativas:

    • 2x mais largura de banda de rede
    • 1,5x mais memória de GPU
    • 1,5x mais TFLOPS de GPU (medidos em FP4, sem esparsidade)

    Na prática, isso se traduz em tempos de treinamento mais rápidos e maior throughput de tokens para workloads de IA — dois fatores críticos para quem trabalha com modelos de linguagem em escala de produção.

    Disponibilidade regional

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

    • US West (Oregon)
    • AWS GovCloud (US-East)
    • US East (N. Virginia)
    • Asia Pacific (Seoul)

    Para saber mais

    Para quem quer se aprofundar nas especificações técnicas e casos de uso das instâncias P6-B300, a AWS disponibiliza a documentação completa na página oficial das instâncias Amazon EC2 P6.

    Fonte

    Amazon EC2 P6-B300 instances are now available in the Asia Pacific (Seoul) Region (https://aws.amazon.com/about-aws/whats-new/2026/08/amazon-ec2-p6-b300/)

  • Workflow de ML sem código com Snowflake e Amazon SageMaker Canvas – Parte 1: Configurando o ambiente Snowflake

    O problema que esse workflow resolve

    Organizações das áreas de saúde, varejo e ciências da vida acumulam volumes massivos de dados operacionais em data warehouses na nuvem, como o Snowflake. Esses sistemas armazenam e escalam informações com eficiência, mas transformar esses dados em previsões úteis ainda é um desafio real para a maioria das equipes.

    O modelo tradicional de Aprendizado de Máquina (ML) exige equipes especializadas, longos ciclos de desenvolvimento e suporte pesado de engenharia. O resultado prático? Atrasos, gargalos e pouca margem para experimentação — justamente para as equipes de negócio que mais conhecem os dados e as perguntas que precisam ser respondidas.

    Um workflow de ML sem código muda essa dinâmica. Com o Amazon SageMaker Canvas, é possível explorar conjuntos de dados, preparar features, construir modelos preditivos e gerar insights de forma visual — sem escrever uma linha de código e sem depender de recursos de ciência de dados. Analistas de negócio, donos de produto e times operacionais passam a acelerar a tomada de decisão mantendo a segurança e a governança corporativa.

    Sobre esta série

    Este é o primeiro artigo de uma série de três partes publicada pela AWS. A divisão é a seguinte:

    • Parte 1 (este artigo): configuração da conta AWS e do ambiente Snowflake.
    • Parte 2: conexão do Amazon SageMaker Canvas ao Snowflake para preparar os dados e construir um modelo de detecção de fraudes.
    • Parte 3: envio das previsões ao Amazon QuickSight para criação de dashboards interativos e compartilhamento de insights com stakeholders.

    O desafio de negócio que inspirou a solução

    A solução descrita foi inspirada em uma organização real da área de saúde que havia acumulado anos de dados operacionais no Snowflake — transações de vendas, movimentação de produtos, interações com pacientes e métricas de desempenho regional. A base de dados era sólida, mas transformar esses dados em insights preditivos continuava sendo um obstáculo.

    As equipes de negócio queriam prever demanda por múltiplas categorias de produtos, entender padrões sazonais e regionais de consumo, e visualizar insights orientados por ML diretamente nas ferramentas de Inteligência de Negócios (BI) para apoiar decisões mais rápidas. O problema: a organização não tinha capacidade suficiente de ciência de dados para atender a essas demandas. Cada nova solicitação de previsão ou análise exigia especialistas em engenharia ou ML, resultando em longos ciclos de desenvolvimento e pouca margem para experimentação.

    O gap era claro: as equipes de negócio entendiam as perguntas e os dados, mas não tinham uma forma prática de construir e iterar sobre modelos preditivos por conta própria. Além disso, depois que as previsões eram geradas, era necessário visualizá-las e compartilhá-las com stakeholders por meio de dashboards interativos.

    A solução precisava funcionar nativamente com os dados existentes no Snowflake, visualizar previsões em ferramentas de BI já conhecidas e reduzir a dependência de recursos especializados — sem abrir mão de governança e segurança.

    Visão geral da solução

    Para preencher essa lacuna entre ambientes ricos em dados e equipes de negócio carentes de insights, a AWS descreve um workflow de ML sem código construído sobre o Amazon SageMaker Canvas. A abordagem não substitui a infraestrutura de dados existente — ela estende o valor dos investimentos em Snowflake, tornando o ML acessível a usuários não técnicos e conectando previsões diretamente a ferramentas de visualização.

    O Amazon SageMaker Canvas oferece uma interface visual e intuitiva que se conecta diretamente ao Snowflake, permitindo preparar dados, construir modelos de ML e gerar previsões. Após o treinamento do modelo, é possível fazer o deploy para um Amazon SageMaker Endpoint diretamente da página de detalhes do modelo no Canvas, sem nenhuma configuração de infraestrutura. Quando o status do endpoint aparece como In service, as previsões sobre os dados de transações do Snowflake já podem ser geradas.

    Para visualizar os resultados no Amazon QuickSight, utiliza-se a funcionalidade de previsões em lote (batch predictions) no Canvas para exportar o conjunto de dados com os scores para o Amazon Simple Storage Service (Amazon S3). O QuickSight então visualiza esses insights por meio de dashboards interativos, tornando as previsões de ML acessíveis aos stakeholders de toda a organização — sem pipelines customizados ou intervenção de cientistas de dados.

    Os principais benefícios dessa arquitetura são:

    Implementação técnica: configurando o ambiente Snowflake

    Esta seção apresenta os passos práticos para configurar o ambiente Snowflake com dados de exemplo para detecção de fraudes.

    Pré-requisitos

    Criando o banco de dados no Snowflake

    Para criar o banco de dados no Snowflake, acesse o painel do console Snowflake, clique no sinal de mais (+) no painel lateral esquerdo e selecione SQL worksheet. Um arquivo SQL em branco será aberto. Copie e cole os comandos SQL abaixo na planilha e execute-os:

    -- Create database and warehouse
    USE ROLE accountadmin;
    CREATE OR REPLACE WAREHOUSE HOL_WH WITH WAREHOUSE_SIZE='X-SMALL';
    CREATE OR REPLACE DATABASE FRAUD;
    
    -- Use the database
    USE DATABASE FRAUD;
    
    -- Create the final fraud table with proper data types
    CREATE OR REPLACE TABLE FRAUD.PUBLIC.FRAUD_TABLE (
        id NUMBER,
        trans_date_trans_time TIMESTAMP_NTZ(9),
        cc_num NUMBER,
        merchant VARCHAR,
        category VARCHAR,
        amt NUMBER(38,2),
        first VARCHAR,
        last VARCHAR,
        gender VARCHAR,
        street VARCHAR,
        city VARCHAR,
        state VARCHAR,
        zip NUMBER,
        lat NUMBER(38,15),
        long NUMBER(38,14),
        city_pop NUMBER(38,0),
        job VARCHAR,
        dob DATE,
        trans_num VARCHAR,
        unix_time NUMBER,
        merch_lat NUMBER(38,15),
        merch_long NUMBER(38,14),
        is_fraud NUMBER
    );

    Em seguida, insira os dados de exemplo para detecção de fraudes com o comando abaixo:

    -- Generate sample fraud detection data for 2020
    INSERT INTO FRAUD.PUBLIC.FRAUD_TABLE
    WITH raw_data AS (
        SELECT
            ROW_NUMBER() OVER (ORDER BY SEQ4()) as id,
            DATEADD(minute, UNIFORM(0, 525600, RANDOM()), '2020-01-01 00:00:00'::TIMESTAMP_NTZ) as trans_date_trans_time,
            UNIFORM(1, 1000, RANDOM()) as cc_num,
            CONCAT('merchant_', UNIFORM(1, 500, RANDOM())) as merchant,
            CASE UNIFORM(1, 14, RANDOM())
                WHEN 1 THEN 'grocery_pos'
                WHEN 2 THEN 'gas_transport'
                WHEN 3 THEN 'shopping_net'
                WHEN 4 THEN 'shopping_pos'
                WHEN 5 THEN 'food_dining'
                WHEN 6 THEN 'entertainment'
                WHEN 7 THEN 'personal_care'
                WHEN 8 THEN 'health_fitness'
                WHEN 9 THEN 'travel'
                WHEN 10 THEN 'kids_pets'
                WHEN 11 THEN 'home'
                WHEN 12 THEN 'misc_net'
                WHEN 13 THEN 'misc_pos'
                ELSE 'other'
            END as category,
            ROUND(UNIFORM(1, 1000, RANDOM()) + UNIFORM(0, 99, RANDOM())/100, 2) as amt,
            CONCAT('FirstName', UNIFORM(1, 1000, RANDOM())) as first,
            CONCAT('LastName', UNIFORM(1, 1000, RANDOM())) as last,
            CASE UNIFORM(0, 1, RANDOM())
                WHEN 0 THEN 'M'
                ELSE 'F'
            END as gender,
            CONCAT(UNIFORM(1, 9999, RANDOM()), ' Main St') as street,
            CASE UNIFORM(1, 10, RANDOM())
                WHEN 1 THEN 'New York'
                WHEN 2 THEN 'Los Angeles'
                WHEN 3 THEN 'Chicago'
                WHEN 4 THEN 'Houston'
                WHEN 5 THEN 'Phoenix'
                WHEN 6 THEN 'Philadelphia'
                WHEN 7 THEN 'San Antonio'
                WHEN 8 THEN 'San Diego'
                WHEN 9 THEN 'Dallas'
                ELSE 'San Jose'
            END as city,
            CASE UNIFORM(1, 10, RANDOM())
                WHEN 1 THEN 'NY'
                WHEN 2 THEN 'CA'
                WHEN 3 THEN 'IL'
                WHEN 4 THEN 'TX'
                WHEN 5 THEN 'AZ'
                WHEN 6 THEN 'PA'
                WHEN 7 THEN 'TX'
                WHEN 8 THEN 'CA'
                WHEN 9 THEN 'TX'
                ELSE 'CA'
            END as state,
            UNIFORM(10000, 99999, RANDOM()) as zip,
            ROUND(UNIFORM(25.0, 49.0, RANDOM()) + UNIFORM(0, 999999, RANDOM())/1000000, 15) as lat,
            ROUND(UNIFORM(-125.0, -65.0, RANDOM()) + UNIFORM(0, 99999999999999, RANDOM())/100000000000000, 14) as "LONG",
            UNIFORM(10000, 5000000, RANDOM()) as city_pop,
            CONCAT('Job_Title_', UNIFORM(1, 100, RANDOM())) as job,
            DATEADD(year, -UNIFORM(18, 80, RANDOM()), '2020-12-01'::DATE) as dob,
            CONCAT('trans_', LPAD(ROW_NUMBER() OVER (ORDER BY SEQ4()), 10, '0')) as trans_num,
            DATEDIFF(second, '1970-01-01', DATEADD(minute, UNIFORM(0, 44640, RANDOM()), '2020-12-01 00:00:00'::TIMESTAMP_NTZ)) as unix_time,
            ROUND(UNIFORM(25.0, 49.0, RANDOM()) + UNIFORM(0, 999999, RANDOM())/1000000, 15) as merch_lat,
            ROUND(UNIFORM(-125.0, -65.0, RANDOM()) + UNIFORM(0, 99999999999999, RANDOM())/100000000000000, 14) as merch_long
        FROM TABLE(GENERATOR(ROWCOUNT => 139538))
    )
    SELECT
        id,
        trans_date_trans_time,
        cc_num,
        merchant,
        category,
        amt,
        first,
        last,
        gender,
        street,
        city,
        state,
        zip,
        lat,
        "LONG",
        city_pop,
        job,
        dob,
        trans_num,
        unix_time,
        merch_lat,
        merch_long,
        CASE
            WHEN category IN ('shopping_net', 'misc_net') AND amt > 700 AND UNIFORM(0, 100, RANDOM()) < 85 THEN 1
            WHEN category = 'travel' AND amt > 800 AND UNIFORM(0, 100, RANDOM()) < 80 THEN 1
            WHEN amt > 900 AND EXTRACT(HOUR FROM trans_date_trans_time) BETWEEN 0 AND 4 AND UNIFORM(0, 100, RANDOM()) < 75 THEN 1
            WHEN category IN ('shopping_net', 'misc_net', 'travel') AND amt > 400 AND amt <= 700 AND UNIFORM(0, 100, RANDOM()) < 12 THEN 1
            WHEN EXTRACT(HOUR FROM trans_date_trans_time) BETWEEN 0 AND 3 AND UNIFORM(0, 100, RANDOM()) < 3 THEN 1
            ELSE 0
        END as is_fraud
    FROM raw_data;

    Execute cada subseção separadamente, selecionando o bloco desejado e clicando em Run. Após a execução bem-sucedida das queries, confirme a configuração com as seguintes queries de verificação:

    SELECT COUNT(*) as total_records FROM FRAUD_TABLE;
    SELECT TOP 10 * FROM FRAUD_TABLE;
    SELECT is_fraud, COUNT(*) as count FROM FRAUD_TABLE GROUP BY is_fraud;

    Obtendo as informações de conexão do Snowflake

    Para conectar o Snowflake ao Amazon SageMaker Canvas, será necessário o nome da conta da organização no Snowflake, que combina o nome da organização e o nome da conta separados por um hífen. Execute a query abaixo na planilha SQL para obter esse valor:

    SELECT CURRENT_ORGANIZATION_NAME()||'-'||CURRENT_ACCOUNT_NAME() AS organizaton_account_name;

    Guarde esse valor — ele será necessário na próxima etapa da série.

    Conclusão

    Nesta primeira parte da série de três artigos, a AWS apresenta o desafio de negócio enfrentado por organizações com ambientes ricos em dados no Snowflake e introduz um workflow de ML sem código como solução. Os passos cobertos aqui incluem a criação do banco de dados Snowflake, o carregamento de dados de exemplo para detecção de fraudes e a obtenção das informações de conexão necessárias para os próximos passos.

    Na Parte 2, o Amazon SageMaker Canvas é conectado aos dados do Snowflake, o conjunto de dados é preparado e transformado com ferramentas visuais, e um modelo de detecção de fraudes é construído.

    Referências

    Fonte

    Build a no-code ML workflow with Snowflake, Amazon SageMaker Canvas and Amazon Quick – Part 1: Setting up your Snowflake environment (https://aws.amazon.com/blogs/machine-learning/build-a-no-code-ml-workflow-with-snowflake-amazon-sagemaker-canvas-and-amazon-quick-part-1-setting-up-your-snowflake-environment/)