Blog

  • Detecção de Objetos com Amazon Nova 2 Lite: Visão Computacional Sem Treinar Modelos

    Visão computacional sem o custo de sempre

    Montar uma solução tradicional de visão computacional é caro e demorado. Pipelines de dados, infraestrutura de treinamento, recursos de computação e uma equipe dedicada de ciência de dados são barreiras reais — especialmente para times menores ou empresas que estão começando a explorar esse território.

    A AWS apresenta o Amazon Nova 2 Lite, disponível pelo Amazon Bedrock, como uma alternativa direta a esse cenário. Trata-se de um modelo de fundação multimodal capaz de detectar objetos em imagens por meio de prompts em linguagem natural — sem nenhum treinamento prévio. Você especifica o que quer encontrar (“veículo”, “pessoa”, “amassado”) e o modelo retorna coordenadas precisas de bounding box em formato JSON estruturado.

    O que você vai aprender

    O artigo original da AWS demonstra como implementar detecção de objetos com o Nova 2 Lite usando AWS Lambda e Amazon API Gateway. O conteúdo cobre como construir prompts eficazes, processar a saída JSON, visualizar os resultados e explorar aplicações práticas em manufatura, agricultura e logística.

    Pré-requisitos e custos estimados

    Para seguir a implementação, você vai precisar de:

    • Conta AWS ativa com acesso ao Amazon Bedrock habilitado
    • Permissões do Gerenciamento de Identidade e Acesso (IAM) para bedrock:InvokeModel
    • Acesso ao modelo Amazon Nova 2 Lite na sua região
    • Interface de Linha de Comando da AWS (AWS CLI) configurada
    • Python 3.8 ou superior, com Boto3 (versão 1.28.0+) e Pillow instalados

    A instalação das dependências é feita com:

    pip install boto3 pillow

    Em relação a custos, o Amazon Bedrock cobra $0,0003 por mil tokens de entrada e $0,0025 por mil tokens de saída. Uma imagem típica gera cerca de 230 tokens de entrada (~$0,000069) e ~200 tokens de saída (~$0,0005). Para 10.000 imagens, o custo estimado fica em torno de $5,69. Lambda e API Gateway seguem o modelo de pagamento por uso, com custo mínimo em cenários de teste. O tempo estimado para implementação é de 30 a 45 minutos.

    Como a solução funciona

    A detecção de objetos com o Nova 2 Lite segue quatro etapas principais:

    • Engenharia de prompt — Estruturar o prompt especificando os objetos a detectar e o formato JSON esperado na saída
    • Amazon Bedrock — Invocar o Nova 2 Lite via API, sem gerenciar infraestrutura, e extrair as coordenadas de bounding box da resposta
    • Processamento de coordenadas — Converter as coordenadas normalizadas do Nova (escala 0-1000) para posições em pixels com base nas dimensões reais da imagem
    • Visualização — Desenhar os bounding boxes sobre a imagem original para validação

    O fluxo é direto: você envia uma imagem e uma lista de objetos para a API Converse do Amazon Bedrock. O Nova 2 Lite analisa a imagem e retorna um JSON com as coordenadas de cada objeto detectado. Em seguida, você converte essas coordenadas normalizadas para pixels e visualiza os resultados.

    Engenharia de prompt: a chave para detecções precisas

    A qualidade das detecções depende diretamente de como o prompt é estruturado. O template utilizado no exemplo contém um conjunto de instruções que define claramente os requisitos. Duas variáveis dinâmicas — elements (elementos a detectar) e schema (estrutura esperada do JSON) — permitem que o mesmo template funcione para qualquer categoria de objeto sem modificações.

    Veja o template completo:

    # Object Detection and Localization
    
    ## Objective
    Your task is to detect and localize objects in the target image with high precision and recall.
    
    ## Instruction
    - The objects to be detected are: {elements}
    - Analyze the provided target image and return only the reasoning and a JSON object with bounding box data for detected objects
    - Think step-by-step and then provide precise bounding box coordinates for each detection
    - Detect all instances of the specified objects
    - Fit bounding boxes tightly around each object
    - Do not output duplicate bounding boxes
    - Coordinates should use the format [x_min, y_min, x_max, y_max] where:
      * (x_min, y_min) is the top-left corner of the bounding box
      * (x_max, y_max) is the bottom-right corner of the bounding box
    
    ## Output Requirements and Examples
    The JSON output should strictly follow this structure including the word json:
    ```json
    {schema}
    ```
    
    ### Example JSON Structure:
    ```json
    {{
      "car": [{{
        "bbox": [321, 432, 543, 876],
      }}],
      "pedestrian": [{{
        "bbox": [432, 543, 654, 987],
      }}, {{
        "bbox": [123, 234, 345, 678],
      }}],
      // Continue for all detected elements...
    }}
    ```
    
    Briefly explain the detection results and provide the specified JSON format wrapped within triple backticks.

    Para os detalhes completos de implementação, o código está disponível no repositório GitHub.

    Exemplo prático: detecção em cena urbana

    A AWS testou o Nova 2 Lite em uma imagem de rua. Sem nenhum treinamento ou ajuste fino, o modelo foi capaz de detectar dois tipos de objeto — “vehicle” (veículo) e “stop sign” (placa de pare) — com alta precisão. O resultado mostrou que o modelo identifica não apenas objetos óbvios, mas também aqueles que são pequenos, distantes ou parcialmente encobertos. Os bounding boxes se ajustam com precisão aos limites dos objetos usando apenas nomes básicos, sem descrições detalhadas.

    Implantando na nuvem: escolha sua plataforma de computação

    O Amazon Bedrock fornece acesso via API ao Nova 2 Lite, o que significa que ele pode ser invocado a partir de qualquer serviço de computação da AWS. A escolha depende do tipo de carga de trabalho:

    Independentemente do serviço de computação escolhido, todos utilizam a mesma API Converse do Amazon Bedrock para interagir com os modelos Nova. Essa consistência facilita a integração da detecção de objetos na infraestrutura existente e a migração entre plataformas conforme as necessidades evoluem.

    Aplicação serverless de exemplo

    A AWS construiu uma aplicação web serverless de exemplo que demonstra a detecção de objetos com o Nova 2 Lite. A arquitetura segue o modelo serverless-first, combinando múltiplos serviços AWS:

    • O Amazon CloudFront serve a aplicação de página única a partir de um bucket privado do Amazon Simple Storage Service (Amazon S3), com distribuição global e aplicação de HTTPS via Origin Access Control.
    • Quando o usuário faz upload de uma imagem e especifica os objetos a detectar, o front-end envia a requisição ao Amazon API Gateway, que a roteia para uma função AWS Lambda.
    • A função Lambda atua como camada de orquestração, chamando a API Converse do Amazon Bedrock para enviar a imagem e o prompt de detecção ao Nova 2 Lite.
    • O Nova retorna as coordenadas normalizadas de bounding box para cada objeto detectado. A Lambda converte essas coordenadas para posições em pixels e renderiza os boxes anotados sobre a imagem.
    • O resultado anotado percorre o caminho inverso — Lambda → API Gateway → front-end — e o usuário vê a imagem com os objetos destacados.

    Essa arquitetura escala automaticamente e mantém cada componente focado em uma única responsabilidade.

    Como implantar a aplicação

    O código-fonte completo, incluindo todas as definições de infraestrutura do Kit de Desenvolvimento de Nuvem da AWS (AWS CDK) e a função Lambda, está disponível no repositório GitHub. Após instalar o AWS CLI e o AWS CDK e habilitar o acesso ao Amazon Nova 2 Lite no console do Amazon Bedrock, a implantação é direta.

    Para evitar cobranças contínuas após os testes, basta remover os recursos criados:

    # Delete the AWS CloudFormation stack
    cdk destroy
    
    # Verify resources are removed
    aws cloudformation list-stacks --stack-status-filter DELETE_COMPLETE

    Se preferir limpeza manual, os recursos a remover são: bucket do Amazon S3 e seu conteúdo, funções AWS Lambda, endpoints do Amazon API Gateway e a distribuição do Amazon CloudFront.

    Vale destacar: as chamadas à API do Amazon Bedrock são cobradas por uso, sem custos de infraestrutura contínuos. Após excluir os recursos de implantação, você só paga quando faz chamadas à API.

    Aplicações práticas por setor

    Controle de qualidade na manufatura

    Uma instalação de fabricação de metal que processa 10.000 peças por mês pode usar o Nova 2 Lite para automatizar a inspeção de qualidade. Especificando defeitos como “scratch” (arranhão), “dent” (amassado) ou “rust spot” (ponto de ferrugem), o sistema identifica problemas automaticamente. O custo de analisar 5 imagens por peça fica em aproximadamente $8 por mês — bem abaixo do custo de retornos e retrabalho causados por peças defeituosas que chegam ao cliente.

    Agricultura de precisão

    Uma fazenda de 5.000 acres que captura imagens semanais de drone durante uma temporada de 20 semanas pode usar o modelo para detectar problemas nas plantações cedo. Especificando “diseased leaf” (folha doente), “pest damage” (dano por pragas) ou “fungus” (fungo), o sistema permite intervenção antes que o problema se agrave. O processamento de 1,2 milhão de imagens de alta resolução por temporada custa aproximadamente $200. A mesma abordagem pode guiar equipamentos por GPS para detectar obstruções no campo — como veículos, equipamentos ou detritos — abrindo caminho para operações autônomas.

    Logística e centros de distribuição

    Centros de distribuição podem identificar pacotes danificados especificando: “torn box” (caixa rasgada), “crushed package” (pacote amassado) ou “water damage” (dano por água). O sistema sinaliza automaticamente os itens para inspeção e os direciona para áreas de controle de qualidade. A mesma lógica se aplica ao monitoramento de inventário — como “empty shelf” (prateleira vazia) ou “misplaced item” (item fora do lugar) — e à conformidade de segurança, verificando o uso de “hard hat” (capacete), “safety vest” (colete de segurança) e “safety glasses” (óculos de proteção).

    Conclusão

    O Amazon Nova 2 Lite representa uma mudança significativa na acessibilidade da visão computacional. Ao especificar nomes de objetos via prompts em linguagem natural, equipes podem implantar aplicações de detecção em horas — não em meses — sem gerenciar infraestrutura ou exigir expertise em aprendizado de máquina. O modelo entrega performance de detecção por meio de uma única API, com estrutura de custo por uso.

    Para quem quiser experimentar, o código de exemplo está no repositório GitHub, e os modelos Nova podem ser explorados diretamente no console do Amazon Bedrock.

    Fonte

    Object detection with Amazon Nova 2 Lite (https://aws.amazon.com/blogs/machine-learning/object-detection-with-amazon-nova-2-lite/)

  • Amazon ElastiCache para Valkey agora oferece suporte a durabilidade

    ElastiCache ganha durabilidade: cache de alta velocidade sem abrir mão da segurança dos dados

    A AWS anunciou, em junho de 2026, suporte a durabilidade no Amazon ElastiCache para Valkey. A novidade é relevante porque resolve uma limitação histórica dos serviços de cache em memória: a velocidade impressionante de leitura e escrita vinha acompanhada do risco de perda de dados em caso de falha. Agora, esses dois requisitos podem coexistir no mesmo serviço.

    O que muda com a durabilidade no ElastiCache

    Com esse novo recurso, o ElastiCache passa a armazenar dados de forma durável em múltiplas Zonas de Disponibilidade (AZs — Availability Zones), utilizando um log transacional Multi-AZ. Essa arquitetura garante failover rápido, recuperação do banco de dados e reinicialização de nós sem perda de informações — mesmo em cenários de falha inesperada.

    Na prática, isso significa que o ElastiCache deixa de ser exclusivamente uma camada de cache temporário e passa a ser uma opção viável para workloads onde a perda de dados simplesmente não é tolerável.

    Duas opções de durabilidade: síncrona e assíncrona

    A AWS disponibiliza duas modalidades de escrita com durabilidade, cada uma com características distintas:

    • Escrita síncrona: os dados são persistidos em pelo menos duas AZs antes de o serviço responder ao cliente. Essa opção é projetada para zero perda de dados, com latência de escrita em milissegundos de um único dígito.
    • Escrita assíncrona: os dados são persistidos após a resposta ao cliente, mantendo a latência de escrita em microssegundos — sem custo adicional. O trade-off é que, em um evento de falha raro, até 10 segundos de dados ainda não confirmados podem ser perdidos.

    Vale destacar que ambas as opções mantêm a latência de leitura em microssegundos, preservando a principal vantagem competitiva do ElastiCache.

    Novos casos de uso viabilizados

    Com a durabilidade disponível, o ElastiCache passa a atender uma gama mais ampla de cenários que antes exigiam soluções alternativas. Entre os casos de uso mencionados pela AWS estão:

    • Memória de longo prazo para agentes de IA
    • Estado de workflows de agentes de IA
    • Bases de conhecimento para aplicações de RAG (Retrieval-Augmented Generation — Geração Aumentada por Recuperação)
    • Tokenização de pagamentos
    • Gerenciamento de inventário em tempo real

    Esses exemplos mostram que o serviço agora compete diretamente em cenários onde a consistência e a persistência dos dados são requisitos críticos de negócio.

    Disponibilidade e como começar

    A durabilidade no ElastiCache está disponível a partir do Valkey 9.0, em todas as regiões comerciais da AWS, regiões da China e regiões do AWS GovCloud (EUA).

    Para habilitar o recurso, basta criar um novo cluster ElastiCache e selecionar a opção de durabilidade desejada. Isso pode ser feito pelo Console de Gerenciamento da AWS, pelo Kit de Desenvolvimento de Software (SDK — Software Development Kit) da AWS ou pela Interface de Linha de Comando (CLI — Command Line Interface) da AWS.

    Para detalhes sobre preços, consulte a página de preços do Amazon ElastiCache. Para aprofundar o conhecimento técnico, a documentação oficial do ElastiCache e o post no blog da AWS são os recursos recomendados.

    Fonte

    Amazon ElastiCache for Valkey now supports durability (https://aws.amazon.com/about-aws/whats-new/2026/06/durability-amazon-elasticache)

  • AWS Config passa a suportar regras vinculadas a serviços internos

    O que mudou no AWS Config

    A AWS anunciou uma expansão importante no AWS Config: o serviço agora oferece suporte a regras vinculadas a serviços internos (internal service linked rules). Com essa novidade, outros serviços da AWS passam a conseguir avaliar configurações de recursos diretamente por meio das regras gerenciadas do AWS Config.

    Como essa funcionalidade se encaixa no ecossistema

    Essa capacidade é uma extensão natural do gravador vinculado a serviços (service linked recorder), que já existia anteriormente. A diferença agora é que serviços como o AWS Security Hub CSPM podem ir além do registro: eles conseguem implantar e gerenciar avaliações de regras voltadas para funcionalidades específicas de cada serviço.

    Na prática, isso significa que serviços da AWS podem usar as regras gerenciadas do Config para oferecer capacidades integradas de segurança e conformidade — sem que o cliente precise configurar ou gerenciar essas regras manualmente.

    Entrega de resultados e modelo de custos

    Os resultados das avaliações são entregues diretamente ao serviço da AWS que implantou a regra. Um ponto importante para quem gerencia custos na nuvem: não há cobrança do AWS Config ao cliente por essas avaliações realizadas via regras vinculadas a serviços internos.

    Independência em relação às configurações existentes

    As regras vinculadas a serviços internos operam de forma independente dos gravadores e regras gerenciados pelo próprio cliente no AWS Config. Isso garante que quem já usa o Config para inventário, governança, conformidade e auditoria pode continuar fazendo isso normalmente — enquanto os serviços da AWS gerenciam, de forma autônoma, as avaliações específicas de cada um deles.

    Ou seja, não há interferência entre o que o cliente configura e o que os serviços internos da AWS gerenciam. As duas camadas coexistem sem conflito.

    Disponibilidade

    As regras vinculadas a serviços internos do AWS Security Hub CSPM já estão disponíveis em todas as regiões comerciais, regiões GovCloud e regiões da China.

    Para se aprofundar no funcionamento técnico do recurso, a AWS disponibiliza a documentação oficial do AWS Config.

    Fonte

    AWS Config now supports internal service linked rules (https://aws.amazon.com/about-aws/whats-new/2026/06/aws-config-supports-internal-service-linked-rules)

  • Amazon EKS e EKS Distro passam a suportar Kubernetes versão 1.36

    Suporte ao Kubernetes 1.36 chega ao Amazon EKS

    A AWS anunciou que o Amazon Serviço Elástico de Kubernetes (EKS) e o Amazon EKS Distro agora oferecem suporte oficial ao Kubernetes versão 1.36. A partir de agora, é possível criar novos clusters EKS com essa versão ou atualizar clusters existentes — tudo isso via console do EKS, pela interface de linha de comando eksctl ou por ferramentas de infraestrutura como código.

    O que há de novo no Kubernetes 1.36

    Esta versão traz quatro melhorias de destaque que valem atenção de quem opera ambientes Kubernetes em produção:

    • User Namespaces em disponibilidade geral: o recurso que mapeia o usuário root de um contêiner para um usuário sem privilégios no host passou da fase beta para GA (disponibilidade geral). Na prática, isso significa que mesmo que um processo consiga escapar do contêiner, ele não terá privilégios no nó subjacente — um ganho relevante de segurança.
    • Mutating Admission Policies: agora é possível realizar mutações de recursos diretamente no servidor de API usando CEL (Common Expression Language), sem precisar configurar infraestrutura de webhook. Isso simplifica pipelines de admissão e reduz dependências operacionais.
    • Escalonamento vertical de recursos de Pod sem reinicialização: os Pods podem agora redimensionar seu orçamento compartilhado de CPU e memória em tempo real, sem precisar ser reiniciados. Esse recurso, chamado de In-Place Pod-Level Resources Vertical Scaling, traz mais flexibilidade para workloads que precisam de ajustes dinâmicos de capacidade.
    • Resource Health Status: a saúde de dispositivos de hardware agora é reportada diretamente no status do Pod. Isso facilita a identificação de crash loops causados por falhas de hardware, tornando o diagnóstico de problemas muito mais direto.

    Para conhecer todos os detalhes das mudanças introduzidas no Kubernetes 1.36, a AWS disponibiliza a documentação oficial e as notas de release do projeto Kubernetes.

    Disponibilidade e como atualizar

    O suporte ao Kubernetes 1.36 no EKS já está ativo em todas as regiões AWS onde o serviço está disponível, incluindo as regiões AWS GovCloud (US). Para consultar as versões disponíveis e obter instruções detalhadas de atualização, a AWS indica a documentação do EKS.

    Antes de realizar o upgrade, vale usar o recurso EKS cluster insights para verificar se há problemas que possam impactar o processo de atualização do cluster.

    As builds do EKS Distro para o Kubernetes 1.36 já estão disponíveis no ECR Public Gallery e no GitHub. Para entender melhor as políticas de ciclo de vida das versões suportadas pelo EKS, a AWS mantém documentação específica sobre o tema.

    Fonte

    Amazon EKS and Amazon EKS Distro now supports Kubernetes version 1.36 (https://aws.amazon.com/about-aws/whats-new/2026/06/amazon-eks-distro-kubernetes-version-1-36)

  • Identifique chaves AWS KMS não utilizadas e evite exclusões acidentais

    Gerenciar chaves KMS em escala é um desafio real

    Conforme o uso da Amazon Web Services (AWS) cresce dentro de uma organização, o gerenciamento de chaves criptográficas se torna cada vez mais complexo. Seja com um punhado de chaves ou com milhares distribuídas por múltiplas contas e regiões, existe sempre a necessidade de auditar o uso dessas chaves — seja para atender requisitos de conformidade, avaliar riscos ou reduzir custos operacionais.

    O problema é que descobrir quais chaves estão ativas e quais ficaram paradas sem uso costumava ser um processo trabalhoso. Para resolver isso, o Serviço de Gerenciamento de Chaves da AWS (AWS KMS) lançou a API GetKeyLastUsage, uma nova funcionalidade que permite identificar rapidamente quando cada chave foi usada pela última vez em uma operação criptográfica. Para saber mais, consulte a documentação Determine past usage of a KMS key.

    Como era feita a auditoria antes

    Antes desse lançamento, a principal forma de auditar o uso de chaves era por meio dos logs do AWS CloudTrail. O CloudTrail registra todas as operações criptográficas por padrão, então os dados estavam disponíveis — o problema era transformar esse volume de dados em informação acionável.

    Para os últimos 90 dias, o histórico de eventos do CloudTrail tornava o processo viável. Para períodos mais longos, era necessário criar uma trilha dedicada, entregar os logs para o Amazon Simple Storage Service (Amazon S3) para retenção de longo prazo e, em seguida, consultar esses logs com ferramentas como o Amazon Athena. Um fluxo complexo para uma pergunta relativamente simples: “quando essa chave foi usada pela última vez?”

    O que a API GetKeyLastUsage oferece

    O AWS KMS agora disponibiliza uma forma direta de consultar quando uma chave foi utilizada pela última vez em operações criptográficas. Essa informação também pode ser visualizada pelo console de gerenciamento da AWS e pela Interface de Linha de Comando da AWS (AWS CLI).

    A API GetKeyLastUsage retorna a data e hora da operação criptográfica mais recente realizada com uma chave KMS — sem precisar vasculhar logs do CloudTrail. Os dados retornados incluem:

    • Data e hora da última operação com a chave
    • Tipo de operação realizada
    • ID do evento no CloudTrail
    • ID da requisição no KMS

    Essa informação está disponível para todas as chaves gerenciadas pelo cliente e chaves gerenciadas pela AWS, independentemente do tipo de chave, origem, armazenamento ou tipo de uso.

    Além disso, é possível restringir a desativação ou o agendamento de exclusão de uma chave que foi usada recentemente, incorporando essas informações de uso como condição na política da chave KMS.

    Entendendo o período de rastreamento

    Antes de depender das informações de último uso de uma chave, é fundamental compreender o conceito de período de rastreamento. Esse é o ponto de partida a partir do qual o AWS KMS passou a registrar a atividade criptográfica de cada chave. Para a maioria das regiões da AWS, o rastreamento teve início em 23 de abril de 2026.

    Isso é crítico: a ausência de informações de uso pode significar que a chave nunca foi usada ou que ela simplesmente não foi usada desde o início do rastreamento. Por exemplo, uma chave criada em 1º de janeiro de 2026 pode ter sido amplamente utilizada entre janeiro e 22 de abril — mas essas operações não estarão refletidas nos dados da API. Portanto, não é possível concluir que uma chave está em desuso apenas porque não há registros de uso após o início do rastreamento.

    Como visualizar as informações de uso

    Não é necessário habilitar nada nem fazer configurações adicionais para acessar as informações de último uso das chaves KMS. Basta acessar o console do KMS, selecionar uma chave em Customer-managed keys e verificar o campo Last used nas configurações gerais. Ao clicar no link exibido nesse campo, é possível ver detalhes adicionais como o timestamp, o tipo de operação e o ID do evento no CloudTrail.

    A coluna Last used também é exibida ao tentar agendar a exclusão de uma chave, permitindo tomar decisões mais informadas antes de confirmar a ação.

    Casos de uso práticos

    Caso de uso 1: Otimização de custos com limpeza de chaves não utilizadas

    Organizações que gerenciam milhares de chaves KMS distribuídas por múltiplas contas frequentemente acumulam chaves que nunca foram usadas ou que caíram em desuso. A limpeza dessas chaves reduz custos operacionais e diminui a superfície de segurança exposta. A API GetKeyLastUsage facilita esse processo ao indicar quais chaves não realizaram operações criptográficas recentemente.

    No entanto, é importante ter cautela: o fato de uma chave não ter sido usada recentemente não significa que ela pode ser excluída com segurança. Uma chave pode ficar meses sem atividade e ainda ser necessária para descriptografar arquivos em cenários de conformidade ou recuperação de desastres.

    Um exemplo claro disso são os volumes do Amazon Elastic Block Store (Amazon EBS). Esses volumes interagem com chaves KMS apenas em eventos específicos do ciclo de vida, como criação, anexação e desanexação. Após um volume ser anexado a uma instância do Amazon Elastic Compute Cloud (Amazon EC2), a chave de criptografia de dados em texto simples fica armazenada em cache no hardware do Nitro Card — e todas as operações subsequentes de leitura e gravação usam essa chave em cache, sem nenhuma chamada adicional à API do KMS.

    Isso significa que um volume de produção rodando continuamente por meses ou anos pode não mostrar nenhuma atividade KMS durante todo esse período — mas ainda depende completamente da chave para qualquer operação futura, como reinicializações de instância, reanexação de volume ou recuperação de desastres. Se a chave for excluída, a chave de criptografia de dados armazenada com o volume nunca poderá ser descriptografada novamente, tornando os dados do volume permanentemente inacessíveis.

    A recomendação é: ao identificar uma chave potencialmente não utilizada, primeiro desative-a usando o comando DisableKey e monitore suas aplicações e serviços em busca de falhas de criptografia ou descriptografia. Antes de excluir qualquer chave KMS, verifique se não há volumes EBS ou snapshots associados a ela, independentemente de quando ocorreu a última chamada à API do KMS.

    A AWS também disponibiliza um mecanismo para criar um alarme no CloudWatch que notifica quando uma chave com exclusão pendente está sendo acessada, dando a oportunidade de cancelar a exclusão antes que os dados se tornem inacessíveis.

    Script para identificar chaves não utilizadas

    A seguir, um exemplo de script que percorre todas as chaves gerenciadas pelo cliente em uma conta e recupera a data de último uso de cada uma via API GetKeyLastUsage. O script aceita dois parâmetros opcionais: um limite em dias e uma região da AWS. Ele filtra e exibe apenas as chaves que não foram usadas dentro do período especificado, apresentando os resultados em uma tabela com o nome da chave, ID da conta, região e data de último uso.

    Exemplo para verificar todas as chaves não usadas nos últimos 180 dias na região us-east-1:

    ./script.sh 180 us-east-1
    #!/bin/bash
    DAYS=${1:-90}
    REGION=${2:-$(aws configure get region)}
    CUTOFF=$(date -v-${DAYS}d +%s 2>/dev/null || date -d "-${DAYS} days" +%s)
    ACCOUNT_ID=$(aws sts get-caller-identity --query Account --output text)
    
    printf "Showing keys not used in the last %s days (Region: %s)\n\n" "$DAYS" "$REGION"
    printf "%-50s %-15s %-20s %-15s\n" "Key Name" "Account ID" "Region" "Last Usage Date"
    printf "%.0s-" {1..100}
    printf "\n"
    
    for key_id in $(aws kms list-keys --region $REGION --query 'Keys[*].KeyId' --output text); do
        key_manager=$(aws kms describe-key --region $REGION --key-id $key_id --query 'KeyMetadata.KeyManager' --output text)
        if [ "$key_manager" = "CUSTOMER" ]; then
            last_usage=$(aws kms get-key-last-usage --region $REGION --key-id $key_id)
            timestamp=$(echo $last_usage | jq -r '.KeyLastUsage.TimeStamp // empty')
            if [ -z "$timestamp" ]; then
                last_epoch=0
            else
                last_epoch=$(date -jf "%Y-%m-%dT%H:%M:%S" "$(echo $timestamp | cut -d. -f1)" +%s 2>/dev/null || date -d "$timestamp" +%s)
            fi
            if [ "$last_epoch" -lt "$CUTOFF" ]; then
                key_alias=$(aws kms list-aliases --region $REGION --key-id $key_id --query 'Aliases[0].AliasName' --output text)
                key_name=${key_alias:-$key_id}
                [ "$key_name" = "None" ] && key_name=$key_id
                if [ -z "$timestamp" ]; then
                    tracking_date=$(echo $last_usage | jq -r '.TrackingStartDate' | cut -d'T' -f1)
                    last_used="${tracking_date}*"
                else
                    last_used=$(echo $timestamp | cut -d'T' -f1)
                fi
                printf "%-50s %-15s %-20s %-15s\n" "$key_name" "$ACCOUNT_ID" "$REGION" "$last_used"
            fi
        fi
    done
    
    printf "\n* = No operations performed since tracking started\n"

    Caso de uso 2: Prevenção de exclusões acidentais com controles de política

    Exclusões acidentais de chaves KMS são um risco real nas organizações. Uma chave pode ser excluída porque alguém acredita que ela não está mais em uso — e só depois se descobre que aplicações ou workloads críticos dependiam dela. O resultado são falhas de acesso a dados, indisponibilidade de aplicações e procedimentos de recuperação de emergência.

    Para evitar esse cenário, é possível usar a chave de condição kms:TrailingDaysWithoutKeyUsage nas políticas de chave KMS, bloqueando automaticamente a exclusão ou desativação de chaves usadas recentemente. Veja como configurar isso no console do AWS KMS:

    1. Acesse o console do AWS KMS e selecione Customer managed keys no painel de navegação.
    2. Selecione a chave que deseja proteger.
    3. Na aba Key policy, clique em Edit.
    4. No editor de política, adicione o seguinte bloco:
    {
      "Sid": "PreventDeletionOfRecentlyUsedKeys",
      "Effect": "Deny",
      "Principal": "*",
      "Action": [
        "kms:ScheduleKeyDeletion",
        "kms:DisableKey"
      ],
      "Resource": "*",
      "Condition": {
        "NumericLessThanEquals": {
          "kms:TrailingDaysWithoutKeyUsage": "365"
        }
      }
    }

    Essa política bloqueia a exclusão ou desativação de qualquer chave que tenha sido usada nos últimos 365 dias. O limite pode ser ajustado conforme as necessidades da organização. Para mais informações sobre essa chave de condição, consulte a documentação de kms:TrailingDaysWithoutKeyUsage.

    Considerações importantes antes de excluir uma chave

    Ao revisar chaves para possível exclusão, é essencial ter em mente os seguintes pontos:

    • A exclusão de uma chave é irreversível e torna os dados criptografados com ela irrecuperáveis.
    • A AWS impõe um período de espera de 7 a 30 dias antes da exclusão ser efetivada. Durante esse tempo, monitore tentativas de uso e cancele a exclusão se necessário.
    • Exclua uma chave somente se tiver certeza de que nenhum dado foi ou será criptografado com ela.
    • Considere desativar a chave primeiro para testar o impacto da sua indisponibilidade antes de partir para a exclusão definitiva.
    • O CloudTrail continua sendo a fonte autoritativa de auditoria, pois fornece o histórico completo de quem fez cada requisição e com quais parâmetros. A GetKeyLastUsage informa rapidamente quando e qual operação ocorreu, mas o CloudTrail mostra o contexto completo. Saiba mais sobre registro de chamadas à API do KMS com o CloudTrail.

    Conclusão

    A API GetKeyLastUsage representa um avanço significativo nas capacidades de gerenciamento do ciclo de vida de chaves KMS. Ela oferece acesso imediato a dados de uso que antes só estavam disponíveis mediante consultas complexas ao CloudTrail. Para equipes que gerenciam grandes volumes de chaves, isso simplifica auditorias, reduz riscos de exclusões acidentais e facilita a otimização de custos.

    O ponto de partida é simples: acesse o console do AWS KMS e verifique o campo Last used nas chaves gerenciadas pelo cliente e nas chaves gerenciadas pela AWS. Para auditorias mais amplas, integre a API aos scripts de automação existentes usando os exemplos de AWS CLI apresentados aqui.

    Fonte

    Identify unused AWS KMS keys and prevent accidental key deletions (https://aws.amazon.com/blogs/security/identify-unused-aws-kms-keys-and-prevent-accidental-key-deletions/)

  • Amazon SageMaker Studio agora configura em segundos com personalização de modelos pronta desde o início

    Configuração em segundos: o que mudou no SageMaker Studio

    A AWS anunciou uma melhoria significativa no processo de inicialização do Amazon SageMaker Studio: o tempo de configuração rápida caiu de mais de dois minutos para menos de vinte segundos. Na prática, isso significa que profissionais de Machine Learning (ML) podem ir do login a um ambiente completamente configurado de forma quase imediata.

    Essa mudança beneficia qualquer fluxo de trabalho dentro do SageMaker Studio — seja construindo pipelines de ML, explorando dados, desenvolvendo em notebooks ou realizando fine-tuning de modelos de fundação.

    Permissões de personalização de modelos pré-configuradas

    Além da velocidade, a AWS trouxe outra novidade relevante: novos ambientes do Studio já são criados com as permissões de personalização de modelos serverless configuradas automaticamente. Uma nova política gerenciada chamada AmazonSageMakerModelCustomizationCoreAccess é criada e anexada ao ambiente automaticamente.

    Essa política cobre permissões para:

    • Jobs de personalização de modelos serverless
    • Fine-tuning com funções de recompensa customizadas para aprendizado por reforço
    • Avaliação de modelos
    • Deploy para endpoints do SageMaker ou do Bedrock

    O resultado prático é que não é mais necessário criar e configurar manualmente funções e políticas de Gerenciamento de Identidade e Acesso (IAM) antes de começar a experimentar — o ambiente já chega pronto para uso.

    E quem já tem um ambiente existente?

    Para quem já utiliza o SageMaker Studio com ambientes criados anteriormente, a AWS não deixou de fora: mensagens com orientações práticas e links diretos para a documentação guiam o usuário na adição dessas permissões ao ambiente existente.

    Disponibilidade

    O recurso está disponível em todas as regiões comerciais da AWS onde o Amazon SageMaker Studio é suportado. Para começar, basta criar um novo ambiente pelo console do SageMaker AI usando a opção de configuração rápida.

    Para saber mais, a AWS disponibiliza documentação detalhada sobre configuração rápida e sobre a configuração de permissões para personalização de modelos na documentação oficial do Amazon SageMaker.

    Fonte

    Amazon SageMaker Studio now sets up in seconds with model customization ready from the start (https://aws.amazon.com/about-aws/whats-new/2026/01/quick-setup-model-customization-sagemaker-studio/)

  • Novas capacidades do Amazon Bedrock AgentCore Gateway para MCP em produção

    Um único ponto de entrada para servidores MCP corporativos

    Quando uma organização começa a escalar o uso de servidores Protocolo de Contexto de Modelo (MCP) em produção, surgem desafios sérios: controle de acesso granular, visibilidade sobre quais equipes usam quais ferramentas, proteção contra vazamento de dados e gerenciamento centralizado de credenciais. Sem uma solução centralizada, cada servidor MCP precisa resolver esses problemas por conta própria.

    O Amazon Bedrock AgentCore Gateway foi criado exatamente para resolver esse cenário. Ele atua como intermediário entre os servidores MCP e os clientes que os consomem, centralizando credenciais, observabilidade e conectividade segura em um único ponto confiável. A AWS anunciou recentemente uma expansão significativa desse serviço com novas capacidades voltadas para implantações MCP em ambientes corporativos.

    As novidades cobrem: suporte estendido ao esquema de ferramentas MCP, prompts MCP e recursos MCP como primitivos de primeira classe, listagem dinâmica para descoberta em tempo de execução, streaming e gerenciamento de sessões para interações em tempo real, elicitação para solicitações de entrada durante a execução, e troca de tokens OAuth 2.0 on-behalf-of para autenticação delegada. Exemplos práticos estão disponíveis no repositório de amostras no GitHub.

    Como o AgentCore Gateway centraliza a governança

    Sem um gateway centralizado, cada servidor MCP construído pela organização precisa lidar individualmente com credenciais, aplicação de políticas, conectividade privada e logs. O servidor MCP de revisão de contratos do time jurídico, o de recuperação de dados do time financeiro e o de resposta a incidentes do time de operações — todos carregam o mesmo peso de infraestrutura. O time de segurança precisa revisar cada servidor separadamente, os desenvolvedores aguardam aprovações e ninguém tem uma visão unificada do uso da infraestrutura MCP.

    O AgentCore Gateway elimina essa duplicação ao estabelecer um ponto de entrada único para todo o tráfego MCP. Cada equipe cuida apenas da lógica de negócio do seu servidor; o gateway trata do restante. Ele agrega capacidades de diferentes tipos de destino, incluindo servidores MCP, APIs REST, funções AWS Lambda e outros.

    Entre os recursos de governança já disponíveis no AgentCore Gateway, destacam-se:

    Primitivos MCP como cidadãos de primeira classe

    O AgentCore Gateway passa a funcionar como um único endpoint MCP que agrega capacidades de todos os servidores MCP da organização. Os clientes enxergam um catálogo unificado de ferramentas, uma biblioteca de prompts e um namespace de recursos — sem precisar gerenciar 20 conexões separadas.

    O gateway suporta os três primitivos MCP: ferramentas, prompts e recursos. As definições de ferramentas incluem um outputSchema opcional para definir a estrutura de saída esperada e anotações que descrevem propriedades comportamentais, como se a ferramenta é somente leitura ou destrutiva. O gateway também suporta os métodos MCP completos: tools/list, tools/call, prompts/list, prompts/get, resources/list, resources/read e resources/templates/list.

    No modo de listagem padrão, o AgentCore Gateway descobre e armazena em cache as ferramentas, prompts e recursos dos servidores MCP conectados. Esse cache é atualizado implicitamente sempre que se chama CreateGatewayTarget ou UpdateGatewayTarget, e pode ser atualizado explicitamente com a API SynchronizeGatewayTargets. Quando os clientes fazem chamadas de listagem, o gateway responde diretamente do cache. A interação real com o servidor MCP só ocorre durante operações de invocação: tools/call, prompts/get e resources/read.

    Ferramentas e prompts retornados pelo gateway recebem o prefixo do nome do destino no formato targetName___. URIs de recursos são retornados sem prefixo — o URI original do servidor MCP é repassado diretamente. Um ponto de atenção importante: como os URIs de recursos não são validados pelo gateway, é preciso ter cuidado com destinos não confiáveis, pois um servidor MCP comprometido poderia retornar URIs apontando para endpoints internos ou caminhos do sistema de arquivos local.

    Listagem dinâmica para controle de acesso por usuário

    Alguns servidores MCP personalizam suas capacidades por usuário. Um servidor com controle de permissões pode expor a ferramenta approve_expense apenas para gerentes, ou um servidor multi-tenant pode disponibilizar ferramentas compatíveis com HIPAA somente para clientes de saúde. A listagem dinâmica permite preservar esse controle de acesso no lado do servidor, mesmo roteando pelo AgentCore Gateway.

    Ao criar um destino, é possível escolher entre dois modos de listagem: padrão e dinâmico.

    • Modo padrão: o gateway invoca o servidor MCP durante CreateGatewayTarget ou UpdateGatewayTarget para descobrir e armazenar em cache ferramentas, prompts e recursos. Chamadas de listagem são respondidas diretamente do cache.
    • Modo dinâmico: o gateway não invoca o servidor durante a criação ou atualização do destino. As chamadas de listagem são encaminhadas em tempo real ao servidor MCP, usando a identidade do usuário que está fazendo a chamada.

    Em ambos os modos, operações de invocação como tools/call, prompts/get e resources/read são roteadas diretamente ao servidor MCP de destino.

    Imagem original — fonte: Aws

    Essa arquitetura dual também oferece flexibilidade para multi-tenancy e controle de acesso granular (FGAC). Para o modo dinâmico, o controle de acesso pode ser gerenciado diretamente no servidor MCP, já que as operações de listagem são executadas sob a identidade do usuário final. Vale observar que, no modo dinâmico, os primitivos não são indexados no gateway, o que significa que a capacidade de busca semântica de ferramentas não pode ser utilizada.

    Streaming, gerenciamento de sessões e elicitação

    Muitos fluxos de trabalho MCP corporativos vão além de simples chamadas de requisição-resposta. Um servidor MCP pode precisar transmitir atualizações de progresso enquanto gera um relatório, pausar no meio da execução para pedir aprovação do usuário antes de uma ação sensível, ou manter contexto ao longo de uma conversa com múltiplos passos. O AgentCore Gateway agora suporta transporte HTTP com streaming, gerenciamento de sessões MCP e elicitação.

    HTTP com Streaming

    Sem streaming, uma chamada de ferramenta que leva 45 segundos não retorna nada até o final. Com streaming, o usuário vê eventos de progresso em tempo real. Quando um cliente envia uma requisição tools/call com Accept: application/json, text/event-stream, o AgentCore Gateway abre um stream SSE (Eventos Enviados pelo Servidor) e encaminha eventos do servidor MCP em tempo real, incluindo notificações de progresso, mensagens de log e o resultado final da ferramenta. Clientes que enviam apenas Accept: application/json continuam recebendo uma única resposta JSON, preservando compatibilidade retroativa.

    Para habilitar o streaming, basta configurar o bloco enableResponseStreaming na chamada de API CreateGateway ou UpdateGateway:

    "protocolConfiguration": {
      "mcp": {
        "streamingConfiguration": {
          "enableResponseStreaming": true
        }
      }
    }

    Um ponto de atenção: o AgentCore Gateway determina o código de status HTTP a partir do primeiro evento do stream. Se ocorrer um erro no meio do stream, ele é entregue como um objeto de erro JSON-RPC dentro de um frame SSE, e não como um código de status HTTP.

    Gerenciamento de Sessões

    O gerenciamento de sessões introduz fluxos de trabalho com múltiplos turnos ao AgentCore Gateway. Quando as sessões são habilitadas, o gateway gera um Mcp-Session-Id na primeira requisição de inicialização e o retorna como cabeçalho de resposta. O cliente inclui esse cabeçalho nas requisições subsequentes, permitindo que o gateway rastreie interações, mantenha mapeamentos para sessões de servidores MCP downstream e correlacione requisições de elicitação entre chamadas de ferramentas.

    Para habilitar sessões, adiciona-se um bloco sessionConfiguration na chamada de API CreateGateway ou UpdateGateway. O tempo limite de sessão pode ser configurado de 15 minutos a 8 horas, com padrão de 1 hora:

    "protocolConfiguration": {
      "mcp": {
        "sessionConfiguration": {
          "sessionTimeoutInSeconds": 3600
        }
      }
    }

    As sessões são escopadas ao usuário autenticado. O gateway deriva a identidade do usuário a partir do contexto de autorização — token JWT bearer para ingresso OAuth ou credenciais IAM para ingresso AWS_IAM — e valida que cada requisição dentro de uma sessão se origina do mesmo usuário, ajudando a prevenir sequestro de sessão. O gateway retorna HTTP 400 se receber uma requisição sem o cabeçalho Mcp-Session-Id, e HTTP 404 para sessões expiradas ou inexistentes.

    Elicitação

    A elicitação permite que servidores MCP por trás do AgentCore Gateway pausem a execução e solicitem entrada do usuário final. Isso é especialmente valioso para operações de alto risco que exigem confirmação explícita do usuário, coleta de dados estruturados ou autenticação fora de banda antes de prosseguir.

    O AgentCore Gateway suporta três modos de elicitação:

    • Modo formulário: o servidor MCP envia um JSON Schema descrevendo os campos necessários, e o cliente renderiza um formulário para o usuário preencher.
    • Modo URL: o servidor envia uma URL que o cliente abre para o usuário — tipicamente uma tela de consentimento OAuth ou um fluxo de aprovação externo.
    • Modo exceção URL: o servidor retorna um URLElicitationRequiredError contendo uma URL, solicitando que o cliente redirecione o usuário e tente novamente após a conclusão do fluxo externo.

    A elicitação requer que tanto o streaming quanto as sessões estejam habilitados no gateway. O AgentCore Gateway respeita a negociação de capacidades — ele só declara suporte à elicitação para um servidor MCP downstream quando o cliente conectado também declarou suporte durante a inicialização. O gateway também suporta múltiplas elicitações ativas por sessão, permitindo que chamadas de ferramentas concorrentes tenham cada uma sua própria elicitação pendente.

    Troca de tokens OAuth 2.0 on-behalf-of

    Quando agentes precisam acessar recursos downstream em nome de usuários autenticados, o AgentCore Gateway suporta troca de tokens OAuth 2.0 on-behalf-of (OBO) por meio do AgentCore Identity. Isso habilita um modelo de autenticação zero-trust onde a identidade original do usuário é preservada e propagada em cada salto da cadeia de requisições, enquanto cada camada recebe um token escopado precisamente para sua audiência pretendida.

    O fluxo funciona assim: o cliente MCP se autentica no AgentCore Gateway com JWT A, escopado para a audiência do gateway (aud: gw). Quando o gateway precisa chamar um servidor MCP downstream, ele chama o AgentCore Identity para trocar JWT A por JWT B, agora escopado para a audiência do servidor MCP (aud: mcp). Se o servidor MCP precisar chamar uma API ainda mais downstream, pode usar GetResourceOAuth2Token para obter JWT C escopado para essa API (aud: api). Em cada salto, a identidade original do usuário (sub: X) é mantida, permitindo que serviços downstream apliquem autorização granular por usuário sem disparar fluxos de consentimento adicionais.

    O AgentCore Identity atua como o broker central de tokens para todo esse fluxo. Ele fornece um cofre seguro de tokens para armazenar credenciais OAuth e segredos de cliente, além de suportar identidade de carga de trabalho para autenticação serviço a serviço usando identidade de carga de trabalho AWS em vez de segredos de longa duração. Suporta troca de tokens padrão (RFC 8693) ou concessão de autorização JWT (RFC 7523), dependendo do provedor de identidade.

    Adoção incremental sem quebrar o que já funciona

    Com essas novidades, é possível construir fluxos de trabalho agênticos com múltiplos turnos com streaming de progresso em tempo real, gates de aprovação humana que pausam e retomam a execução, e propagação de identidade zero-trust — tudo por meio de um único endpoint gerenciado. Sem stores de sessão customizados, sem infraestrutura de streaming manual, sem credenciais de conta de serviço compartilhadas.

    Para começar, a AWS recomenda consultar a documentação do Amazon Bedrock AgentCore Gateway para detalhes de configuração de cada recurso. Para exemplos práticos, o repositório de amostras no GitHub é o ponto de partida. Quem já executa servidores MCP por trás do AgentCore Gateway pode adotar essas capacidades de forma incremental, sem alterações nas configurações existentes do gateway ou dos destinos.

    Fonte

    Extending MCP support for Amazon Bedrock AgentCore Gateway (https://aws.amazon.com/blogs/machine-learning/extending-mcp-support-for-amazon-bedrock-agentcore-gateway-2/)

  • Como o Amazon Quick Research está transformando a pesquisa sobre cânceres raros

    O desafio de integrar dados na pesquisa de cânceres raros

    Quem trabalha com pesquisa oncológica sabe bem o problema: os dados estão espalhados em dezenas de fontes diferentes. Sequenciamento genômico, registros de ensaios clínicos, repositórios de biomarcadores, literatura científica revisada por pares — cada uma dessas fontes fala uma língua diferente, usa esquemas distintos e vive em sistemas isolados. Antes de qualquer análise começar, equipes inteiras precisam construir pipelines de Extração, Transformação e Carga (ETL) customizados, reconciliar esquemas manualmente e fazer consultas iterativas em sistemas desconectados. Um processo que facilmente consome semanas.

    É exatamente esse gargalo que a AWS propõe resolver com o Amazon Quick Research. Em um post recente, a empresa demonstrou como a ferramenta pode ser aplicada à pesquisa de sarcomas pediátricos — um tipo raro de câncer — usando bases de dados biomédicas públicas como o PubMed.

    O que é o Amazon Quick Research

    O Amazon Quick Research é um fluxo de trabalho de pesquisa agêntico dentro do Amazon Quick. Na prática, ele orquestra a recuperação de dados de múltiplas fontes e aplica síntese baseada em Modelos de Linguagem de Grande Escala (LLM) para gerar relatórios estruturados, com citações rastreáveis e controle de versão.

    Os componentes centrais da ferramenta são:

    • Interpretação do objetivo de pesquisa: o agente lê uma pergunta em linguagem natural e a divide em subtópicos estruturados para investigação paralela.
    • Ingestão de múltiplas fontes: suporta busca na web (incluindo PubMed, ClinicalTrials.gov e periódicos de acesso aberto), upload de arquivos (PDF, Word, Excel, PowerPoint) e ativos do Amazon Quick como Spaces, dashboards, bases de conhecimento e datasets.
    • Plano de pesquisa gerado por IA: antes de executar, o agente produz um plano estruturado listando os tópicos que investigará, as fontes que consultará por tópico e a abordagem analítica. O usuário pode revisar e ajustar esse plano antes de confirmar a execução.
    • Geração de relatório com citações: o resultado é um relatório estruturado com citações inline rastreáveis até os documentos ou URLs de origem. O recurso “Entender a afirmação” expõe a cadeia de evidências por trás de conclusões individuais.
    • Fluxo de revisão versionado: é possível anotar afirmações específicas com comentários de revisão (até 400 caracteres). Ao submeter uma revisão, um novo ciclo de pesquisa é iniciado com escopo nas seções anotadas, o número de versão é incrementado e as versões anteriores ficam disponíveis para comparação.
    • Formatos de exportação: os relatórios podem ser exportados em PDF ou Word. Variantes de resumo (Executivo, Geral, Personalizado) permitem ajustar o tamanho do output e a densidade de citações para diferentes públicos.

    O papel dos Spaces na organização dos dados

    O Spaces é a camada de organização de dados que alimenta o Amazon Quick Research. Um Space funciona como um contêiner lógico que agrupa até 10.000 arquivos junto com dashboards, tópicos e bases de conhecimento do Amazon Quick. Os arquivos são indexados no momento do upload e ficam disponíveis como corpus de recuperação para os ciclos de pesquisa.

    Os formatos suportados incluem Word, Excel, PowerPoint, PDF, CSV, TXT, RTF, JSON, YAML, XML e HTML. No exemplo demonstrado pela AWS, um Space foi populado com datasets públicos de genômica oncológica e resumos do PubMed para servir como corpus de conhecimento interno, complementado por buscas na web em tempo real.

    Passo a passo: pesquisa sobre sarcomas pediátricos

    A demonstração publicada pela AWS percorre o fluxo completo de uso do Amazon Quick Research aplicado à investigação de sarcomas pediátricos. Veja como o processo funciona na prática:

    Parte 1 — Criação do Space

    O primeiro passo é abrir o Amazon Quick, acessar a seção Spaces e criar um novo Space. Nele, o usuário adiciona os arquivos relevantes para a pesquisa — seja por upload direto, conexão com dashboards ou bases de conhecimento existentes. Todos os arquivos precisam aparecer com o status “Indexado” antes de prosseguir.

    Parte 2 — Criação do projeto de pesquisa

    Na página inicial do Amazon Quick, o usuário acessa a opção Quick Research e inicia um novo projeto. O fluxo guiado conduz desde a definição do objetivo até a geração do relatório final.

    Parte 3 — Definição do objetivo

    O objetivo de pesquisa é inserido em linguagem natural. A AWS recomenda que a pergunta seja focada e específica para obter melhores resultados. O exemplo utilizado na demonstração foi:

    “Quais são as abordagens promissoras de terapia-alvo para sarcomas pediátricos com alterações genômicas específicas, e como podemos identificar pacientes que podem se beneficiar desses tratamentos?”

    O agente de IA ajuda a refinar a pergunta e sugere ângulos adicionais de investigação com base nas fontes de dados disponíveis.

    Parte 4 — Seleção e integração de fontes de dados

    O usuário escolhe quais fontes incluir na pesquisa. No exemplo, foram habilitadas as seguintes opções:

    Para a investigação de sarcomas pediátricos, o sistema reconheceu automaticamente conexões entre dados de mutação genômica e bancos de alvos terapêuticos, dados de desfecho clínico e literatura de protocolos de tratamento, perfis de biomarcadores e padrões de resposta de pacientes, além de dados históricos de ensaios clínicos e opções terapêuticas atuais.

    Parte 5 — Revisão do plano gerado por IA

    Antes de executar a pesquisa, o Quick Research gera um plano estruturado para revisão. No exemplo demonstrado, os tópicos foram:

    • Tópico 1: Terapias-alvo guiadas por genômica para sarcomas pediátricos — seleção de pacientes e abordagens de tratamento.
    • Tópico 2: Panorama genômico dos sarcomas pediátricos — mutações, fusões gênicas (como PAX3) e subtipos incluindo rabdomiossarcoma, sarcoma de Ewing e osteossarcoma.
    • Tópico 3: Terapias-alvo aprovadas pela Administração de Alimentos e Medicamentos (FDA) — mecanismos de ação, eficácia e perfis genômicos.
    • Tópico 4: Direções futuras — edição gênica, terapias celulares, novos sistemas de entrega de fármacos e pesquisa pré-clínica.

    O usuário pode ajustar o plano antes de confirmar a execução, adicionando focos específicos como análise de mutações particulares ou comparações entre abordagens terapêuticas.

    Parte 6 — Execução e acompanhamento

    Após confirmar o plano, o usuário inicia a pesquisa. O sistema exibe um indicador de progresso e o status muda de “Não iniciado” para “Em andamento”. O processo completo leva entre 20 e 30 minutos.

    Parte 7 — Revisão do relatório gerado

    O relatório final sintetiza as descobertas de todas as fontes selecionadas em um formato estruturado, incluindo:

    • Resumo executivo com as principais descobertas e implicações clínicas.
    • Seções de análise detalhada com visualizações de dados de suporte.
    • Recomendações baseadas em evidências para direções futuras de pesquisa.
    • Fontes citadas e transparência metodológica.
    • Próximos passos acionáveis para implementação clínica.

    A navegação entre seções é feita pela aba de Tópicos no painel lateral. As citações numeradas ao longo do texto permitem acessar diretamente os materiais de origem para verificação. O recurso “Entender a afirmação” mostra como cada conclusão foi determinada e apresenta um resumo das evidências utilizadas.

    Parte 8 — Revisão e versionamento

    Para refinar a pesquisa com focos adicionais, o usuário pode adicionar comentários de revisão diretamente no relatório — selecionando o trecho que deseja expandir ou revisar e adicionando uma anotação de até 400 caracteres. Ao acionar o botão de revisão, o Quick Research analisa o conteúdo existente, aplica os comentários e gera uma nova versão (por exemplo, Versão 2) em 20 a 40 minutos. As versões anteriores ficam preservadas para comparação, criando um histórico de auditoria claro do processo de pesquisa.

    A ferramenta também oferece três formatos de resumo para diferentes necessidades de apresentação:

    • Resumo Executivo: orientado para lideranças, máximo de 2 páginas, sem citações.
    • Compartilhamento Geral: amigável para negócios, máximo de 6 páginas, com citações essenciais.
    • Resumo Personalizado: formato sob medida, até 5.000 caracteres.

    Os relatórios podem ser exportados em PDF (para apresentações) ou Word (para edição colaborativa) e compartilhados com membros da equipe diretamente pela plataforma.

    Limpeza dos recursos

    Como o Amazon Quick é um serviço pago, a AWS orienta que os usuários excluam os relatórios e os arquivos carregados nos Spaces ao final do uso para evitar cobranças contínuas. O processo envolve excluir o relatório pelo menu de ações e remover o Space pelo console do Amazon Quick. É recomendável exportar qualquer resultado relevante antes de realizar a limpeza.

    Por que isso importa

    O caso de uso demonstrado pela AWS evidencia um potencial real para equipes de pesquisa biomédica: a possibilidade de fazer perguntas complexas em linguagem natural que atravessam múltiplas fontes de dados, identificar correlações sutis via análise por IA e sintetizar descobertas de datasets heterogêneos — tudo isso em um fluxo estruturado, rastreável e versionado.

    Para quem trabalha com submissões regulatórias, pedidos de financiamento ou tomada de decisão clínica, ter um relatório com citações verificáveis e histórico de versões é um diferencial significativo. O resultado prometido é pesquisa mais rápida e insights mais abrangentes, baseados em evidências, que podem informar decisões clínicas e melhorar os desfechos para pacientes com diagnósticos de cânceres raros.

    Para explorar o serviço, a AWS disponibiliza a página do produto Amazon Quick para iniciar um trial e criar o primeiro Space, além da documentação do Amazon Quick Research com guias detalhados e boas práticas. Dúvidas e experiências podem ser compartilhadas na comunidade AWS para Saúde e Ciências da Vida.

    Fonte

    Transforming rare cancer research with Amazon Quick: Integrating biomedical databases for breakthrough discoveries (https://aws.amazon.com/blogs/machine-learning/transforming-rare-cancer-research-with-amazon-quick-integrating-biomedical-databases-for-breakthrough-discoveries/)

  • Amazon SageMaker agora suporta limites de permissões para conformidade com SCP

    O que mudou no SageMaker Unified Studio

    A AWS anunciou uma novidade importante para equipes que operam em ambientes corporativos com políticas de segurança rígidas: o Amazon SageMaker Unified Studio passou a suportar limites de permissões (permissions boundaries) personalizados do Controle de Acesso e Identidade (IAM). Com isso, organizações que utilizam Políticas de Controle de Serviço (SCP) e exigem que todas as funções IAM sejam criadas com um limite de permissões definido podem adotar o SageMaker Unified Studio sem precisar flexibilizar sua postura de segurança.

    Antes dessa atualização, esse tipo de requisito era um obstáculo real: a criação de projetos no SageMaker Unified Studio provisionava funções IAM sem respeitar automaticamente as SCPs corporativas, o que forçava administradores a intervir manualmente ou a abrir exceções nas políticas — algo que muitas equipes de segurança simplesmente não aceitam.

    Como funciona na prática

    Quando um usuário cria um projeto no SageMaker Unified Studio, a plataforma provisiona automaticamente três funções IAM:

    • Uma função de usuário do projeto (project user role)
    • Uma função de serviço do Amazon Bedrock (Amazon Bedrock service role)
    • Uma função de execução do Bedrock Lambda (Bedrock Lambda execution role)

    Com a nova funcionalidade, os administradores podem definir um limite de permissões diretamente na configuração do Tooling blueprint. A partir daí, todas as três funções são criadas já com esse limite de permissões aplicado — satisfazendo os requisitos das SCPs no momento da criação, sem que nenhuma intervenção adicional do administrador seja necessária.

    Controle centralizado e automático

    Outro ponto relevante dessa atualização é que o limite de permissões também restringe o que as funções provisionadas podem fazer. Isso significa que os administradores mantêm controle sobre as permissões em nível de projeto mesmo à medida que novos projetos são criados — sem precisar revisar cada um individualmente.

    E como a configuração é feita no nível do blueprint, ela se aplica automaticamente a todos os novos projetos criados a partir dali. Ou seja, o controle é centralizado e consistente por padrão.

    Disponibilidade

    O recurso já está disponível em todas as regiões da AWS onde o Amazon SageMaker Unified Studio está disponível. Para entender como configurar os parâmetros do blueprint, a AWS disponibiliza a documentação Gerenciar parâmetros do Tooling blueprint.

    Fonte

    Amazon SageMaker adds permissions boundaries for SCP compliance (https://aws.amazon.com/about-aws/whats-new/2026/05/amazon-sagemaker-scp/)

  • Referencie seus próprios segredos do AWS Secrets Manager no Amazon Bedrock AgentCore Identity

    O desafio de credenciais em agentes de IA em produção

    Agentes de IA são tão poderosos quanto as ferramentas que conseguem acessar. Para buscar dados em um CRM, publicar atualizações no Slack ou consultar um repositório no GitHub, esses agentes precisam chamar APIs externas — e isso significa passar credenciais com segurança em tempo de execução. Fazer isso corretamente, sem hardcodar segredos no código ou expô-los nos prompts do agente, é um dos grandes desafios de quem constrói sistemas agênticos prontos para produção.

    O Amazon Bedrock AgentCore Identity já endereçava esse problema por meio de provedores de credenciais e um cofre de tokens que criavam e gerenciavam automaticamente um segredo no AWS Secrets Manager para cada recurso de provedor de credencial de saída (Outbound credential provider). Esse segredo armazenava a chave de API ou o client secret junto com outros metadados do provedor de identidade externo.

    No entanto, havia uma limitação importante: os clientes não podiam configurar tags personalizadas, políticas de rotação ou criptografia com chaves gerenciadas pelo cliente via Serviço de Gerenciamento de Chaves da AWS (AWS KMS) no momento da criação desses segredos.

    O que a AWS anunciou

    A AWS anunciou a possibilidade de referenciar um segredo já existente no AWS Secrets Manager dentro do AgentCore Identity. Com isso, as equipes podem apontar para um segredo pré-configurado e manter controle total sobre como ele é gerenciado — sem precisar criar um novo segredo do zero gerenciado pelo serviço.

    Na prática, isso significa que é possível fornecer um segredo existente no Secrets Manager para uso com seus recursos de provedor de credenciais. A equipe retém controle completo sobre a configuração de criptografia, rotação, replicação, tags e políticas de recurso — exatamente como gerencia qualquer outro segredo no Secrets Manager.

    Outro ponto relevante: é possível referenciar um segredo de outra conta AWS dentro da mesma Região AWS, embora o compartilhamento entre Regiões diferentes não seja suportado. A funcionalidade também é compatível com segredos trazidos por meio de conectores externos do AWS Secrets Manager, permitindo integração com gerenciadores de segredos de terceiros.

    Casos de uso práticos

    A AWS apresentou alguns cenários concretos onde essa capacidade faz diferença:

    • Reutilização de segredos existentes: Se o agente acessa uma API externa para a qual a equipe já tem um segredo configurado, basta fornecer o Nome de Recurso da Amazon (ARN) desse segredo ao recurso de provedor de credenciais, em vez de criar um novo. Segredos de outras contas AWS na mesma Região e segredos trazidos via conectores externos também são suportados.
    • Rotação sem interrupção: Quando o valor do segredo é rotacionado seguindo boas práticas de segurança, o AgentCore Identity recupera automaticamente o valor atualizado na próxima leitura. Não é necessário atualizar ou recriar os recursos de provedor de credenciais.
    • Controle granular de acesso: É possível configurar a política de recurso diretamente no AWS Secrets Manager, controlando quais entidades principais do Gerenciamento de Identidade e Acesso da AWS (IAM) podem acessar o segredo e definindo condições de acesso específicas.
    • Ambientes regulados com criptografia própria: Para agentes que operam em ambientes regulados onde toda credencial precisa ser criptografada com chave gerenciada pelo cliente, basta criar o segredo com essa chave antes de fornecê-lo ao AgentCore Identity. Isso é especialmente útil para organizações que aplicam Políticas de Controle de Serviço (SCPs) e Políticas de Controle de Recursos (RCPs) para garantir que todos os dados sejam criptografados com chaves gerenciadas pelo cliente. Ao referenciar um segredo existente, a configuração de criptografia é preservada integralmente.
    • Governança e rastreabilidade por tags: Organizações que exigem tags de recurso em segredos para alocação de custos, rastreamento de conformidade ou auditoria de governança podem criar e tagear o segredo conforme seus padrões antes de fornecê-lo ao AgentCore Identity.

    Para saber mais sobre as opções de configuração de segredos disponíveis, a AWS disponibiliza o Guia do Usuário do AWS Secrets Manager.

    Pré-requisitos

    Para utilizar essa funcionalidade, são necessários:

    • Um segredo existente no AWS Secrets Manager contendo a chave de API ou o client secret OAuth.
    • Permissões de IAM para conceder ao service principal do AgentCore Identity acesso de secretsmanager:GetSecretValue ao segredo.
    • Se estiver usando uma chave AWS KMS gerenciada pelo cliente, permissão de kms:Decrypt nessa chave para o service principal.
    • Acesso ao console do Amazon Bedrock AgentCore Identity ou à Interface de Linha de Comando da AWS (AWS CLI).

    Como configurar na prática

    Para referenciar um segredo no AWS Secrets Manager, basta fornecer o ARN do segredo e a chave JSON ao criar os recursos de provedor de credenciais pela API do AgentCore Identity. O serviço recupera o valor da credencial a partir da chave JSON especificada no segredo em tempo de execução.

    Pelo console

    É possível configurar um segredo referenciado ao criar novos recursos de provedor de credenciais diretamente pelo console do Amazon Bedrock AgentCore. A funcionalidade suporta tanto chaves de API quanto credenciais de cliente OAuth.

    Para adicionar uma chave de API com segredo referenciado:

    • Abra o console do Amazon Bedrock AgentCore.
    • No painel de navegação esquerdo, escolha Identity.
    • Na seção Outbound Auth, escolha Add Outbound Auth.
    • Escolha Add API key.
    • Insira um nome para o recurso Outbound Auth.
    • Em API key selection method, escolha Provide API key via Secrets Manager.
    • No campo Secrets Manager ARN, insira ou selecione o ARN do segredo existente. A lista exibe os segredos disponíveis na conta. Por exemplo: arn:aws:secretsmanager:us-east-1:123456789012:secret:myApiKeySecret-AbCdEf.
    • No campo JSON key, especifique a chave dentro do segredo que contém o valor da chave de API.
    • Escolha Add e verifique se o provedor de credenciais aparece na lista de Outbound Auth.

    Para adicionar um client secret OAuth com segredo referenciado:

    • Na página Identity, escolha Add Outbound Auth.
    • Escolha Add OAuth client.
    • Insira um nome para o cliente OAuth (por exemplo, google-oauth-client-v5fz5).
    • Em Provider, escolha o provedor desejado (incluído ou personalizado).
    • Insira o Client ID fornecido pelo provedor de identidade.
    • Em Client secret, escolha Provide Client secret via Secrets Manager.
    • No campo Secrets Manager ARN, insira o ARN do segredo que contém o client secret OAuth.
    • No campo JSON key, especifique a chave dentro do segredo que contém o valor do client secret.
    • Escolha Add OAuth Client e verifique se o provedor aparece na lista.

    Pela AWS CLI

    Também é possível configurar um segredo referenciado ao criar um novo recurso Outbound Auth para um client secret OAuth diretamente pela AWS CLI:

    aws bedrock-agentcore-control create-oauth2-credential-provider \
    --name "google-oauth-client-v5fz5" \
    --credential-provider-vendor "GoogleOauth2" \
    --oauth2-provider-config-input '{
      "googleOauth2ProviderConfig": {
        "clientId": "",
        "clientSecretSource": "EXTERNAL",
        "clientSecretConfig": {
          "secretId": "arn:aws:secretsmanager:us-east-1:123456789012:secret:myGoogleKeySecret-AbCdEf",
          "jsonKey": "key"
        }
      }
    }'

    Por meio de um agente de IA

    Se a equipe utiliza um agente de codificação por IA (como o Kiro ou similar), é possível instruí-lo a configurar um segredo referenciado diretamente com um prompt como:

    “I have an existing secret in AWS Secrets Manager at ARN arn:aws:secretsmanager:us-east-1:123456789012:secret:my-api-key. Create an OAuth2 credential provider in Amazon Bedrock AgentCore Identity named <client-name>, using GoogleOauth2 as the vendor. The client ID is <clientId>, the client secret source is EXTERNAL, and the secret JSON key is key.”

    Substitua <client-name> e <clientId> pelos valores correspondentes.

    Atenção: É necessário conceder ao AgentCore Identity permissão para ler o segredo, adicionando uma política de recurso ao segredo que permita ao service principal chamar secretsmanager:GetSecretValue. Se o segredo estiver criptografado com uma chave KMS gerenciada pelo cliente, também é necessário conceder ao service principal a permissão kms:Decrypt nessa chave.

    Conclusão

    Com a capacidade de referenciar segredos existentes no AWS Secrets Manager, o AgentCore Identity passa a oferecer maior flexibilidade para equipes que já possuem processos de gestão de segredos consolidados. É possível manter controle total sobre como as credenciais são criptografadas, rotacionadas e acessadas, enquanto o AgentCore Identity cuida de recuperá-las em tempo de execução.

    Para começar, a AWS disponibiliza a documentação do Amazon Bedrock AgentCore Identity. Para mais informações sobre gestão de segredos, consulte o Guia do Usuário do AWS Secrets Manager.

    Fonte

    Reference your own AWS Secrets Manager secrets in Amazon Bedrock AgentCore Identity (https://aws.amazon.com/blogs/machine-learning/reference-your-own-aws-secrets-manager-secrets-in-amazon-bedrock-agentcore-identity/)