Blog

  • Amazon Kinesis Video Streams: Nova Camada de Armazenamento Econômico para Retenção de Vídeos

    Nova Camada de Armazenamento Aquecido para Kinesis Video Streams

    A AWS ampliou as capacidades de armazenamento do Amazon Kinesis Video Streams com a introdução de uma nova camada de armazenamento econômica, designada como “warm tier”. Essa novidade oferece aos desenvolvedores uma opção mais eficiente em custos para manter vídeos e mídia por períodos prolongados, sem sacrificar a performance.

    Entendendo as Duas Camadas de Armazenamento

    Anteriormente, o Amazon Kinesis Video Streams operava com uma única camada de armazenamento, agora renomeada como “hot tier”. Essa camada permanece otimizada para acesso em tempo real e armazenamento de curta duração, mantendo todas as suas características de baixa latência.

    A nova camada “warm” foi projetada especificamente para cenários que exigem retenção de longa duração de mídia. O diferencial está na manutenção de acesso em sub-segundo — mesmo com custos de armazenamento significativamente reduzidos — tornando-a ideal para aplicações que precisam preservar dados históricos sem manter infraestrutura de acesso instantâneo.

    Casos de Uso Práticos

    A solução beneficia especialmente dois segmentos:

    • Segurança residencial: Desenvolvedoras de soluções de monitoramento residencial podem agora oferecer retenção estendida de vídeo, armazenando semanas ou meses de gravações com custos operacionais reduzidos.
    • Monitoramento empresarial: Organizações com múltiplas câmeras de vigilância conseguem manter históricos longos para auditoria, conformidade regulatória e análise de incidentes, equilibrando retenção com custos.

    Maior Flexibilidade na Configuração

    Além das duas camadas de armazenamento, a AWS adicionou controle granular sobre o tamanho dos fragmentos de dados. Desenvolvedores podem agora escolher entre:

    • Fragmentos menores: Para casos de uso que exigem latência ultra-baixa e responsividade imediata.
    • Fragmentos maiores: Para reduzir custos de ingestão, ideal quando a prioridade é economia de processamento em vez de latência extrema.

    Integração com Serviços de IA e Análise

    Ambas as camadas (hot e warm) funcionam nativamente com os serviços de visão computacional da AWS. A integração com Amazon Rekognition Video e Amazon SageMaker permite que desenvolvedores construam pipelines contínuos de processamento de vídeo e análise, independente de qual camada de armazenamento estejam utilizando.

    Disponibilidade Global

    A nova camada warm do Amazon Kinesis Video Streams está disponível em todas as regiões onde o serviço já opera, com a exceção das AWS GovCloud (US) Regions.

    Para aprofundar a implementação, consulte o guia de primeiros passos da documentação oficial.

    Fonte

    Amazon Kinesis Video Streams now supports a new cost effective warm storage tier (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-kinesis-video-streams-warm-storage-tier/)

  • SageMaker HyperPod agora oferece cache KV gerenciado em camadas e roteamento inteligente

    Otimização de Inferência de Modelos de Linguagem

    A AWS anunciou novas funcionalidades para o SageMaker HyperPod voltadas à otimização da inferência de modelos de linguagem em larga escala (LLM — Large Language Models). O serviço agora suporta Cache KV (Key-Value) Gerenciado em Camadas e Roteamento Inteligente, permitindo que clientes processem contextos extensos e conversas multi-turno com significativa melhoria de desempenho.

    O Desafio da Inferência de Longa Duração

    Quando aplicações de LLM precisam processar documentos extensos ou manter históricos de conversação, as arquiteturas tradicionais de inferência enfrentam um problema fundamental: a cada novo token gerado, o sistema precisa recalcular os mecanismos de atenção considerando todos os tokens anteriores. Esse reprocessamento contínuo gera sobrecarga computacional e eleva significativamente os custos operacionais.

    Como Funciona o Cache KV Gerenciado em Camadas

    A solução implementada pela AWS resolve esse problema através de uma arquitetura em dois níveis. O Cache KV Gerenciado em Camadas combina memória CPU local (Nível 1) com armazenamento distribuído em cluster (Nível 2), possibilitando que valores previamente calculados sejam reutilizados entre requisições.

    Para o Nível 2, a AWS oferece duas opções:

    • Armazenamento Tiered Disaggregado nativo da AWS: oferece capacidade escalável em escala de terabytes, com tiering automático de memória CPU para SSD local, otimizando a utilização de recursos
    • Redis: disponível como alternativa para o backend de cache de Nível 2

    Roteamento Inteligente de Requisições

    Complementando o sistema de cache, o Roteamento Inteligente maximiza a utilização do cache através de três estratégias configuráveis:

    • Roteamento com Reconhecimento de Prefixo: identifica padrões comuns em prompts e direcionam requisições para instâncias relevantes
    • Roteamento com Reconhecimento de KV: maximiza a eficiência do cache através de rastreamento em tempo real do estado do cache
    • Round-robin: para cargas de trabalho sem estado (stateless)

    Essas estratégias trabalham em conjunto para reduzir o tempo até o primeiro token em análise de documentos e manter o fluxo natural da conversação em diálogos multi-turno.

    Impacto Quantificável de Desempenho

    Segundo a AWS, essas funcionalidades juntas entregam resultados notáveis em comparação com configurações baseline:

    • Redução de até 40% em latência
    • Melhoria de até 25% em throughput
    • Economia de até 25% em custos

    Observabilidade e Implementação

    O novo conjunto de capacidades inclui integração nativa com Amazon Managed Grafana para observabilidade integrada, permitindo monitoramento detalhado das métricas de desempenho.

    Para ativar essas funcionalidades, os clientes podem fazer uso de InferenceEndpointConfig ou SageMaker JumpStart ao implantar modelos através do HyperPod Inference Operator em clusters orquestrados por EKS (Elastic Kubernetes Service).

    Disponibilidade e Próximos Passos

    Os recursos estão disponíveis em todas as regiões onde o SageMaker HyperPod opera atualmente. Para implementação completa, a AWS disponibiliza documentação técnica e guias de configuração através de sua documentação oficial.

    Fonte

    SageMaker HyperPod now supports Managed tiered KV cache and intelligent routing (https://aws.amazon.com/about-aws/whats-new/2025/11/sagemaker-hyperpod-managed-tiered-kv-cache/)

  • Aurora PostgreSQL agora oferece suporte a versões 17.6, 16.10, 15.14, 14.19 e 13.22

    Novas versões do PostgreSQL no Amazon Aurora

    A AWS anunciou o suporte a cinco novas versões secundárias do PostgreSQL no Amazon Aurora PostgreSQL-Compatible Edition: versões 17.6, 16.10, 15.14, 14.19 e 13.22. Essas atualizações incorporam as correções de bugs e melhorias de produtos da comunidade PostgreSQL, além de incluir aprimoramentos específicos do Aurora.

    Segurança elevada com Mascaramento Dinâmico de Dados

    Um dos destaques desta liberação é o Mascaramento Dinâmico de Dados (DDM — Dynamic Data Masking), disponível nas versões 16.10 e 17.6. Esse recurso de segurança em nível de banco de dados oferece proteção para dados sensíveis, como informações de identificação pessoal, ao mascarar valores de coluna dinamicamente durante a execução de consultas. O aspecto mais importante: o mascaramento ocorre em tempo de consulta, com base em políticas de função de acesso, sem alterar os dados armazenados de fato.

    Outras melhorias implementadas

    Além da segurança, esta versão traz aprimoramentos significativos em desempenho e confiabilidade. A introdução de um compartilhamento de plano de cache melhora a eficiência das operações. Também houve melhoria no objetivo de tempo de recuperação (RTO — Recovery Time Objective), reduzindo o tempo necessário para retomar as operações após uma falha. Para ambientes multi-região, a troca de banco de dados global (Global Database switchovers) agora funciona de forma otimizada.

    Como começar com as novas versões

    Para utilizar as versões mais recentes, você pode criar um novo banco de dados Aurora PostgreSQL-compatible diretamente pelo Console de Gerenciamento do Amazon RDS em poucos cliques. Caso já possua um banco de dados existente, também é possível fazer uma atualização. A AWS recomenda consultar a documentação do Aurora para compreender melhor o processo de upgrade.

    Planejamento de atualizações

    Para decidir com qual frequência atualizar e como planejar seu processo de upgrade, consulte a política de versão do Aurora. Esse documento fornece orientações sobre ciclos de suporte e estratégias de migração.

    Disponibilidade global

    Essas novas versões estão disponíveis em todas as regiões comerciais da AWS, assim como nas regiões do AWS GovCloud (US).

    Sobre o Amazon Aurora

    O Amazon Aurora é projetado para oferecer desempenho e disponibilidade sem precedentes em escala global, com compatibilidade completa com MySQL e PostgreSQL. A plataforma oferece segurança integrada, backups contínuos, computação serverless, até 15 réplicas de leitura, replicação automatizada entre regiões e integração com outros serviços da AWS. Para dar seus primeiros passos, consulte a página de primeiros passos.

    Fonte

    Amazon Aurora now supports PostgreSQL 17.6, 16.10, 15.14, 14.19, and 13.22 (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-aurora-minor-versions-17-6-16-10-15-14-14-19-13-22)

  • AWS Private Certificate Authority agora suporta CRLs particionadas

    O desafio da infraestrutura de chaves públicas em escala

    A Infraestrutura de Chaves Públicas (PKI) é fundamental para garantir a segurança e estabelecer confiança nas comunicações digitais. À medida que as organizações expandem suas operações digitais, precisam emitir e revogar certificados continuamente. A revogação de certificados é especialmente importante quando funcionários se desligam, durante migrações para novas hierarquias de autoridades certificadoras, para atender requisitos de conformidade ou em resposta a incidentes de segurança.

    Para rastrear certificados revogados, as organizações podem usar a Lista de Revogação de Certificados (CRL) ou o Protocolo de Status de Certificado Online (OCSP). A Autoridade Certificadora Privada da AWS (AWS Private CA) permite criar uma autoridade certificadora que publica informações de revogação através desses métodos, possibilitando que sistemas verifiquem a validade dos certificados.

    Porém, empresas que enfrentam crescimento significativo encontram limitações ao usar CRLs completas para emitir e revogar mais de 1 milhão de certificados. Simplesmente aumentar o tamanho do arquivo CRL não é uma solução viável, pois muitas aplicações não conseguem processar arquivos CRL grandes — algumas exigem um máximo de 1 MB. Além disso, soluções alternativas como OCSP podem ser rejeitadas por grandes repositórios de confiança e fornecedores de navegadores devido a preocupações com privacidade e requisitos de conformidade. Essas restrições impactam significativamente a capacidade das organizações de escalar sua infraestrutura de PKI de forma eficiente, mantendo segurança e conformidade.

    A solução: CRLs particionadas

    A AWS Private CA agora oferece CRLs particionadas como resposta a esses desafios. Essa funcionalidade permite a emissão e revogação de até 100 milhões de certificados por CA, distribuindo as informações de revogação em múltiplas partições de CRL menores e gerenciáveis, cada uma mantendo um tamanho máximo de 1 MB para melhor compatibilidade com aplicações.

    No momento da emissão, os certificados são automaticamente vinculados a partições CRL específicas através de uma extensão crítica de Ponto de Distribuição do Emissor (IDP), que contém uma URI única identificando a partição. A validação funciona comparando a URI de CRL na extensão de Ponto de Distribuição de CRL (CDP) do certificado contra a extensão IDP da CRL, proporcionando validação precisa.

    Capacidades principais da nova funcionalidade

    As CRLs particionadas oferecem diversos benefícios operacionais:

    • Escalabilidade automática do limite de emissão de certificados: de 1 milhão para 100 milhões de certificados por CA
    • Suporte tanto para novas quanto para autoridades certificadoras existentes
    • Opções de configuração flexível para nomes e caminhos de CRL
    • Compatibilidade reversa, preservando a funcionalidade completa de CRL existente enquanto oferece CRL particionada como recurso opcional
    • Conformidade com padrões da indústria, como o RFC5280, mantendo eficiência operacional e segurança

    Configurando CRLs particionadas na AWS Private CA

    A configuração de CRLs particionadas em autoridades certificadoras existentes segue um processo estruturado através do console da AWS:

    Passos de configuração

    Para ativar CRLs particionadas, acesse sua autoridade certificadora privada no console da AWS Private CA. Primeiro, selecione a CA desejada e navegue até a aba de configuração de revogação. Se a distribuição de CRL estiver desabilitada, você precisará ativá-la nos próximos passos.

    Ao editar as configurações, marque a opção para ativar distribuição de CRL e selecione um bucket do Amazon S3 existente para armazenar os arquivos de CRL. É importante verificar que o recurso de Bloqueio de Acesso Público está desabilitado para sua conta e para o bucket. Se necessário, você pode consultar a documentação sobre criar uma CA privada na AWS Private CA para obter instruções detalhadas sobre políticas de acesso. Para configurações de segurança mais específicas, consulte o guia sobre políticas de acesso para CRLs no Amazon S3 e aprenda como adicionar uma política de bucket usando o console do Amazon S3.

    Na seção de configurações de CRL, marque a caixa para ativar o particionamento. Isso habilitará o uso de CRL particionada. Se você não ativar o particionamento, uma CRL completa será criada e sua CA ficará sujeita ao limite de 1 milhão de certificados emitidos ou revogados. Para informações sobre limites de capacidade, consulte as cotas da AWS Private CA.

    Após salvar as alterações, a distribuição de CRL aparecerá como habilitada com CRLs particionadas, e o limite de 1 milhão será automaticamente atualizado para 100 milhões por CA.

    Benefícios para segurança, operações e conformidade

    As CRLs particionadas da AWS Private CA oferecem benefícios substanciais em múltiplas dimensões organizacionais.

    Perspectiva de segurança

    A funcionalidade mantém a validação de certificados enquanto suporta capacidades abrangentes de revogação para até 100 milhões de certificados por CA. Isso permite que as organizações respondam efetivamente a incidentes de segurança ou comprometimento de chaves.

    Perspectiva operacional

    Operacionalmente, o recurso reduz a necessidade de rotação de autoridades certificadoras, diminuindo a sobrecarga administrativa e simplificando o gerenciamento de PKI. Manter os tamanhos de partição de CRL em 1 MB oferece compatibilidade ampla com aplicações, enquanto suporta gerenciamento automático de partições.

    Perspectiva de conformidade

    Para conformidade regulatória, a solução permite que as organizações atendam a múltiplos requisitos da indústria:

    Custo e disponibilidade

    Um ponto importante é que você pode maximizar o valor de suas autoridades certificadoras de propósito geral ou vida curta ativando CRL particionada sem custos adicionais, além da AWS Private CA e do Amazon Simple Storage Service (Amazon S3). Todos os certificados continuam sendo revogáveis, proporcionando uma solução completa e econômica para gestão de PKI em escala.

    Próximos passos

    Organizações interessadas em começar podem criar sua autoridade certificadora através do console de gerenciamento da AWS Private CA. A nova funcionalidade está disponível para configuração imediata em autoridades certificadoras existentes ou novas.

    Fonte

    AWS Private Certificate Authority now supports partitioned CRLs (https://aws.amazon.com/blogs/security/aws-private-certificate-authority-now-supports-partitioned-crls/)

  • Protegendo Secrets no Kubernetes: O Novo Add-on da AWS para o EKS

    Uma nova forma de gerenciar secrets no Kubernetes

    A AWS anunciou um novo provedor para o Secrets Store CSI Driver destinado ao Amazon EKS (Elastic Kubernetes Service), que funciona como um add-on gerenciado para a plataforma. Esse novo componente permite que as equipes de desenvolvimento recuperem secrets do AWS Secrets Manager e parâmetros do AWS Systems Manager Parameter Store, montando-os como arquivos nos pods do Kubernetes. A solução é clara em sua proposta: oferecer uma forma segura, confiável e gerenciada de acessar credenciais dentro de ambientes containerizados.

    O novo add-on simplifica significativamente o processo de instalação e configuração, funciona tanto em instâncias de Amazon Elastic Compute Cloud (EC2) quanto em nós híbridos, e é mantido com as correções de segurança e atualizações mais recentes. Para equipes brasileiras que trabalham com Kubernetes em ambientes AWS, isso representa uma redução considerável no tempo necessário para implementar práticas seguras de gestão de credenciais.

    Por que isso importa para a segurança

    Historicamente, um dos maiores desafios em ambientes Kubernetes é evitar o uso de credenciais hardcoded no código-fonte das aplicações. O Secrets Manager já resolve essa questão no contexto geral da AWS, mas integrá-lo nativamente com Kubernetes exigia passos complexos de instalação e manutenção.

    O novo provedor funciona como um DaemonSet do Kubernetes de código aberto, trabalhando em conjunto com o Secrets Store CSI Driver mantido pela comunidade Kubernetes. Essa arquitetura permite que o driver de armazenamento de secrets funcione de forma nativa no cluster, sem necessidade de integração customizada.

    Benefícios do add-on gerenciado

    Os add-ons do EKS da AWS proporcionam instalação e gerenciamento de um conjunto curado de componentes para clusters EKS. Em vez de depender de métodos legados como Helm ou kubectl, o novo add-on reduz significativamente o tempo de setup e aumenta a estabilidade geral dos clusters. Além disso, o gerenciamento centralizado pela AWS garante que patches de segurança e correções de bugs sejam aplicados de forma automática e consistente.

    Considerações de segurança

    Como em qualquer solução que envolve gestão de credenciais, a segurança é uma preocupação central. A AWS recomenda armazenar secrets em cache na memória quando possível, reduzindo a frequência de acesso ao Secrets Manager. Para equipes que preferem uma experiência totalmente nativa do Kubernetes, o AWS Secrets Manager Agent oferece uma alternativa complementar.

    Do ponto de vista de controle de acesso, qualquer entidade IAM (Identity and Access Management) que precise acessar os secrets deve ter permissões explícitas no Secrets Manager. Se usar Parameter Store, também precisa de permissões específicas para ler parâmetros. As políticas de recurso funcionam como mecanismo adicional de controle de acesso, e é especialmente importante quando se acessa secrets de contas AWS diferentes.

    O add-on inclui suporte a endpoints FIPS, alinhando-se com exigências de conformidade em ambientes altamente regulados. A AWS fornece uma política IAM gerenciada chamada AWSSecretsManagerClientReadOnlyAccess, que é a recomendação padrão para uso com esse add-on. Para implementar o princípio do menor privilégio, é possível criar políticas customizadas direcionadas apenas aos secrets específicos que cada aplicação precisa acessar.

    Guia prático de implementação

    Para equipes que desejam começar, a AWS disponibiliza um fluxo de trabalho completo desde a criação do cluster até a recuperação efetiva de um secret. Abaixo, apresentamos um resumo dos passos principais.

    Pré-requisitos

    Antes de iniciar, certifique-se de ter:

    • Credenciais AWS configuradas no seu ambiente para permitir chamadas à API
    • AWS CLI v2 ou superior
    • A região preferida configurada no seu ambiente via comando: aws configure set default.region <regiao-preferida>
    • As ferramentas de linha de comando kubectl e eksctl instaladas
    • Um arquivo de deployment Kubernetes disponível no repositório do provedor

    Criando o cluster EKS

    Comece criando uma variável de shell com o nome do seu cluster:

    CLUSTER_NAME="my-test-cluster"

    Depois, crie o cluster:

    eksctl create cluster $CLUSTER_NAME

    O eksctl usará automaticamente uma versão recente do Kubernetes e criará todos os recursos necessários para o funcionamento do cluster. Esse comando geralmente leva cerca de 15 minutos.

    Criando um secret de teste

    Crie um secret chamado addon_secret no Secrets Manager:

    aws secretsmanager create-secret \
    --name addon_secret \
    --secret-string "super secret!"

    Instalando o add-on do Secrets Store CSI Driver

    Use o eksctl para instalar o add-on:

    eksctl create addon \
    --cluster $CLUSTER_NAME \
    --name aws-secrets-store-csi-driver-provider

    Configurando autenticação com IAM e Pod Identity

    Crie uma role IAM que o serviço de Pod Identity do EKS possa assumir (substitua <regiao> pela sua região AWS):

    ROLE_ARN=$(aws --region <regiao> --query Role.Arn --output text iam create-role --role-name nginx-deployment-role --assume-role-policy-document '{
      "Version": "2012-10-17",
      "Statement": [
        {
          "Effect": "Allow",
          "Principal": {
            "Service": "pods.eks.amazonaws.com"
          },
          "Action": [
            "sts:AssumeRole",
            "sts:TagSession"
          ]
        }
      ]
    }')

    Anexe a política gerenciada à role que você acabou de criar:

    aws iam attach-role-policy \
    --role-name nginx-deployment-role \
    --policy-arn arn:aws:iam::aws:policy/AWSSecretsManagerClientReadOnlyAccess

    Instalando o EKS Pod Identity Agent

    O add-on oferece dois métodos de autenticação: IAM roles para service accounts (IRSA) e EKS Pod Identity. Neste exemplo, usaremos Pod Identity. Instale o agent:

    eksctl create addon \
    --cluster $CLUSTER_NAME \
    --name eks-pod-identity-agent

    Depois, crie a associação de Pod Identity para o cluster (substituindo <regiao> pela sua região):

    eksctl create podidentityassociation \
    --cluster $CLUSTER_NAME \
    --namespace default \
    --region <regiao> \
    --service-account-name nginx-pod-identity-deployment-sa \
    --role-arn $ROLE_ARN \
    --create-service-account true

    Configurando a SecretProviderClass

    A SecretProviderClass é um arquivo YAML que define quais secrets e parâmetros devem ser montados como arquivos no seu cluster. Crie um arquivo chamado spc.yaml com o seguinte conteúdo:

    apiVersion: secrets-store.csi.x-k8s.io/v1
    kind: SecretProviderClass
    metadata:
      name: nginx-pod-identity-deployment-aws-secrets
    spec:
      provider: aws
      parameters:
        objects: |
          - objectName: "addon_secret"
            objectType: "secretsmanager"
            usePodIdentity: "true"

    Aplique a configuração:

    kubectl apply -f spc.yaml

    Para detalhes adicionais sobre a SecretProviderClass, consulte a documentação no GitHub do provedor.

    Implantando o pod no cluster

    Use o arquivo de deployment disponível no repositório para implantar o pod:

    kubectl apply -f https://raw.githubusercontent.com/aws/secrets-store-csi-driver-provider-aws/main/examples/ExampleDeployment-PodIdentity.yaml

    Isso montará o addon_secret no caminho /mnt/secrets-store dentro do seu cluster.

    Recuperando e verificando o secret

    Para confirmar que o secret foi montado com sucesso, execute:

    kubectl exec -it $(kubectl get pods | awk '/nginx-pod-identity-deployment/{print $1}' | head -1) -- cat /mnt/secrets-store/addon_secret

    Você deverá ver a saída:

    super secret!

    Parabéns! Você recuperou com sucesso um secret do Secrets Manager e o montou como arquivo no seu cluster Kubernetes usando o novo add-on da AWS.

    Limpeza de recursos

    Quando terminar a implementação de testes, limpe os recursos criados:

    aws secretsmanager delete-secret \
    --secret-id addon_secret \
    --force-delete-without-recovery
    
    aws iam delete-role --role-name nginx-deployment-role
    
    eksctl delete cluster $CLUSTER_NAME

    Alternativas de instalação

    Embora o add-on gerenciado seja a forma recomendada, a AWS também oferece opções alternativas de instalação usando AWS CloudFormation, AWS Command Line Interface (AWS CLI), console de gerenciamento ou a própria API do EKS.

    Conclusão

    O novo add-on do Secrets Store CSI Driver para EKS representa um avanço significativo na forma como as equipes podem gerenciar credenciais em ambientes Kubernetes hospedados na AWS. Ao oferecer instalação simplificada, gerenciamento centralizado, atualizações de segurança automáticas e integração estreita com o EKS, a solução reduz tanto a complexidade operacional quanto o risco de segurança associado ao armazenamento inadequado de secrets.

    Para organizações brasileiras que trabalham com Kubernetes em escala, esse add-on se posiciona como uma alternativa muito mais prática do que métodos legados de instalação, mantendo a flexibilidade e a conformidade com padrões de segurança internacionais. A documentação técnica completa está disponível para equipes que desejam explorar cenários mais avançados e configurações específicas.

    Saiba mais

    Fonte

    How to use the Secrets Store CSI Driver provider Amazon EKS add-on with Secrets Manager (https://aws.amazon.com/blogs/security/how-to-use-the-secrets-store-csi-driver-provider-amazon-eks-add-on-with-secrets-manager/)

  • Cache KV Escalonado Gerenciado e Roteamento Inteligente para o Amazon SageMaker HyperPod

    Otimizando Inferência de Modelos de Linguagem em Escala

    Aplicações modernas de IA enfrentam um desafio crescente: fornecer respostas rápidas e econômicas através de modelos de linguagem grandes, particularmente ao processar documentos extensos ou conversas com múltiplas mensagens. O problema surge quando a inferência de modelos de linguagem se torna cada vez mais lenta e cara à medida que o comprimento do contexto aumenta, com latência crescendo exponencialmente e custos elevados a cada interação.

    Essa ineficiência ocorre porque esses modelos precisam recalcular os mecanismos de atenção para todos os tokens anteriores toda vez que geram um novo token. Essa redundância cria sobrecarga computacional significativa e alta latência em sequências longas.

    Entendendo o Cache KV e o Roteamento Inteligente

    O cache KV (par chave-valor) resolve esse gargalo armazenando e reutilizando os vetores de chave-valor de cálculos anteriores, reduzindo drasticamente a latência de inferência e o tempo até o primeiro token (TTFT, ou Tempo até o Primeiro Token).

    O roteamento inteligente complementa essa abordagem ao direcionar requisições com prompts compartilhados para a mesma instância de inferência, maximizando a eficiência do cache KV. Quando uma nova requisição chega, o sistema a envia para uma instância que já processou o mesmo prefixo, permitindo reutilizar os dados em cache e acelerar o processamento.

    No entanto, configurar e gerenciar o framework correto para cache KV e roteamento inteligente em escala produção é complexo e requer ciclos experimentais longos. A AWS anunciou que o Amazon SageMaker HyperPod agora oferece essas capacidades através do Operador de Inferência HyperPod, simplificando significativamente essa implementação.

    Capacidades Principais do Cache KV Escalonado Gerenciado

    Arquitetura em Dois Níveis

    O cache KV escalonado gerenciado funciona através de uma arquitetura em dois níveis, otimizada para diferentes padrões de acesso:

    Cache L1 (Local): Reside na memória da CPU de cada nó de inferência e oferece acesso extremamente rápido. O cache gerencia automaticamente alocação de memória e políticas de despejo para otimizar o conteúdo armazenado em cache de maior valor.

    Cache L2 (Distribuído): Opera como uma camada de cache distribuída abrangendo todo o cluster, permitindo compartilhamento de cache entre múltiplas instâncias de modelo. A AWS oferece dois backends para o cache L2:

    • Cache KV Escalonado Gerenciado (recomendado): Uma solução de memória disagregada do HyperPod que oferece escalabilidade excelente para pools de terabytes, baixa latência, otimização de rede AWS, design consciente de GPU com suporte zero-copy e eficiência de custos em escala.
    • Redis: Simples de configurar, funciona bem para cargas de trabalho pequenas e médias, com rico ecossistema de ferramentas e integrações.

    Quando uma requisição chega, o sistema primeiro verifica o cache L1 para pares KV necessários. Se encontrados, são utilizados imediatamente com latência mínima. Se não encontrados em L1, o sistema consulta o cache L2. Se localizados lá, os dados são recuperados e opcionalmente promovidos para L1 para acesso mais rápido no futuro. Apenas se os dados não existirem em nenhum cache, o sistema executa o cálculo completo, armazenando os resultados em ambas as camadas para reutilização futura.

    Fluxo de requisições de inferência com cache KV e roteamento inteligente. Imagem original — fonte: Aws

    Estratégias de Roteamento Inteligente

    O roteamento inteligente oferece quatro estratégias configuráveis para otimizar a distribuição de requisições conforme as características da carga de trabalho:

    • Roteamento Ciente de Prefixo (padrão): Mantém uma estrutura de árvore rastreando quais prefixos estão em cache em quais endpoints, oferecendo desempenho geral robusto. Ideal para conversas multi-turno, bots de atendimento ao cliente com saudações padrão e geração de código com importações comuns.
    • Roteamento Ciente de KV: Oferece gerenciamento de cache mais sofisticado através de um controlador centralizado que rastreia localizações de cache e trata eventos de despejo em tempo real. Excele em threads de conversas longas, fluxos de trabalho de processamento de documentos e sessões estendidas de programação onde eficiência máxima de cache é crítica.
    • Roteamento Round-robin: Abordagem mais simples, distribuindo requisições uniformemente entre workers. Melhor para cenários onde requisições são independentes, como trabalhos de inferência em lote, chamadas de API stateless e testes de carga.

    Impacto em Cenários do Mundo Real

    As otimizações delivram benefícios tangíveis para aplicações práticas. Equipes jurídicas analisando contratos de 200 páginas agora recebem respostas instantâneas para perguntas de acompanhamento em vez de aguardar mais de 5 segundos por consulta. Chatbots de saúde mantêm fluxo de conversa natural através de diálogos com pacientes de 20+ turnos. Sistemas de atendimento ao cliente processam milhões de requisições diárias com desempenho superior e custos de infraestrutura reduzidos.

    Essas otimizações tornam análise de documentos, conversas multi-turno e aplicações de inferência de alta taxa de transferência viáveis economicamente em escala empresarial.

    Implementando Cache KV Escalonado Gerenciado

    Pré-requisitos

    Antes de começar, você precisará:

    • Um cluster HyperPod criado com Amazon EKS (Elastic Kubernetes Service) como orquestrador
    • Status do cluster verificado como InService
    • Operador de inferência verificado e em execução

    Para criar um cluster, acesse o console SageMaker AI, navegue para HyperPod Clusters e selecione Gerenciamento de Cluster. Escolha criar um novo cluster orquestrado por Amazon EKS. Para detalhes de configuração do cluster, consulte a documentação sobre criação de um cluster SageMaker HyperPod com orquestração Amazon EKS.

    Se estiver usando um cluster EKS existente, você precisará configurar seus clusters HyperPod para implantação de modelo e instalar manualmente o operador de inferência.

    Configurando o Manifesto de Implantação

    Você pode habilitar essas funcionalidades adicionando configurações ao seu arquivo CRD (Definição de Recurso Customizado) InferenceEndpointConfig. Para um exemplo completo, visite o repositório de exemplos da AWS no GitHub.

    O arquivo de configuração define variáveis de ambiente e especificações de cache. Para o cache L1, você habilita a cache na memória local. Para o cache L2, você especifica o backend (armazenamento em camadas ou Redis). A configuração de roteamento inteligente permite que você escolha a estratégia que melhor se ajusta a seu padrão de carga de trabalho.

    O seguinte exemplo mostra a estrutura básica de configuração:

    apiVersion: inference.sagemaker.aws.amazon.com/v1
    kind: InferenceEndpointConfig
    metadata:
      name: ${NAME}
      namespace: ${NAMESPACE}
    spec:
      modelName: ${MODEL_NAME}
      instanceType: ${INSTANCE_TYPE}
      replicas: 1
      kvCacheSpec:
        enableL1Cache: true
        enableL2Cache: true
        l2CacheSpec:
          l2CacheBackend: "tieredstorage"
      intelligentRoutingSpec:
        enabled: true
        routingStrategy: prefixaware

    Após preparar o manifesto, aplique a configuração e verifique o status dos pods. O sistema criará automaticamente pods de worker para modelo e um roteador inteligente para gerenciar distribuição de requisições.

    Monitoramento e Observabilidade

    Métricas de Cache KV disponíveis no painel de inferência. Imagem original — fonte: Aws

    Você pode monitorar as métricas do cache KV gerenciado e roteamento inteligente através dos recursos de observabilidade do SageMaker HyperPod. Para informações detalhadas, consulte o artigo sobre aceleração do desenvolvimento de modelos de fundação com observabilidade de um clique no Amazon SageMaker HyperPod.

    As métricas de cache KV estão disponíveis no painel de inferência e incluem uso de cache L1, taxas de acerto, eficiência de roteamento e latência de requisição, fornecendo visibilidade completa sobre o desempenho da sua implantação.

    Resultados de Desempenho

    A AWS conduziu testes abrangentes para validar melhorias de desempenho em implantações reais de LLM. Os testes utilizaram o modelo Llama-3.1-70B-Instruct implantado em 7 réplicas em instâncias p5.48xlarge (cada uma equipada com oito GPUs NVIDIA), sob padrão de tráfego de carga constante.

    Redução de tempo até o primeiro token no percentil P90. Imagem original — fonte: Aws
    Redução de tempo até o primeiro token no percentil P50. Imagem original — fonte: Aws
    Aumento de taxa de transferência em transações por segundo. Imagem original — fonte: Aws
    Redução de custo por 1.000 tokens. Imagem original — fonte: Aws

    Para contextos médios (8k tokens): O sistema alcançou redução de 40% no tempo até o primeiro token no P90, redução de 72% no P50, aumento de 24% na taxa de transferência e redução de 21% em custos comparado às configurações baseline sem otimização.

    Para cargas de trabalho com contextos longos (64k tokens): Os benefícios são ainda mais pronunciados, com redução de 35% no TTFT no P90, redução de 94% no P50, aumento de 38% na taxa de transferência e economia de 28% em custos.

    Os ganhos em otimização aumentam dramaticamente com o comprimento do contexto. Enquanto cenários de 8k tokens demonstram melhorias sólidas em todas as métricas, cargas de trabalho de 64k tokens experimentam ganhos transformadores que fundamentalmente mudam a experiência do usuário.

    Os testes também confirmaram que o armazenamento em camadas gerenciado pela AWS superou consistentemente o cache L2 baseado em Redis em todos os cenários. O backend de armazenamento em camadas ofereceu melhor latência e taxa de transferência sem o overhead operacional de gerenciar infraestrutura Redis separada, tornando-o a escolha recomendada para a maioria das implantações.

    Diferentemente de otimizações tradicionais que exigem compromissos entre custo e velocidade, essa solução oferece ambos simultaneamente.

    Começando

    Você pode começar hoje adicionando essas configurações às suas implantações de modelo HyperPod nas regiões AWS onde o SageMaker HyperPod está disponível. Para saber mais, visite a documentação do SageMaker HyperPod nas regiões AWS onde está disponível ou consulte o guia de primeiros passos de implantação de modelo.

    Fonte

    Managed Tiered KV Cache and Intelligent Routing for Amazon SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/managed-tiered-kv-cache-and-intelligent-routing-for-amazon-sagemaker-hyperpod/)

  • Controle de Acesso Refinado com Interceptadores do Gateway AgentCore do Bedrock

    O Desafio de Escalar Agentes de IA com Segurança

    As empresas estão adotando agentes de IA em ritmo acelerado para automatizar fluxos de trabalho e aumentar produtividade. No entanto, esse crescimento traz um problema crítico de segurança: como garantir que centenas de agentes autônomos acessem apenas as ferramentas que lhes são permitidas quando milhares de ferramentas estão distribuídas entre diferentes times e unidades de negócio?

    Diferentemente de arquiteturas tradicionais com alguns agentes chamando poucas APIs, as plataformas de IA modernas envolvem cenários muito mais complexos. Uma organização pode ter centenas de agentes, aplicações de IA para consumidores e fluxos de trabalho automatizados precisando acessar milhares de ferramentas através do Protocolo de Contexto de Modelo (MCP). Cada acesso precisa ser validado não apenas pela identidade do agente, mas também pela identidade do usuário, contexto de execução, canal de acesso e permissões que podem mudar dinamicamente.

    Imagem original — fonte: Aws

    Apresentando os Interceptadores do Gateway AgentCore

    Para resolver esses desafios de segurança e governança em escala, a AWS lançou um novo recurso: interceptadores de gateway para o Amazon Bedrock AgentCore Gateway. Trata-se de uma capacidade poderosa que fornece segurança refinada, controle de acesso dinâmico e gerenciamento flexível de esquemas.

    Os interceptadores funcionam como pontos programáveis onde você pode injetar lógica de segurança personalizada, permitindo transformar requisições e respostas sem modificar as ferramentas subjacentes ou os servidores MCP.

    Dois Pontos de Interceptação

    O gateway oferece interceptação em dois momentos críticos do ciclo de requisição-resposta:

    • Interceptador de requisição do gateway: Processa requisições recebidas antes de atingirem as ferramentas alvo, permitindo controle de acesso refinado, validação de credenciais, criação de trilhas de auditoria e tradução de esquemas.
    • Interceptador de resposta do gateway: Processa respostas de saída antes de retornarem ao agente chamador, possibilitando filtragem de ferramentas, criação de trilhas de auditoria e tradução de esquemas com base em permissões do usuário.
    Imagem original — fonte: Aws

    Principais Capacidades dos Interceptadores

    Controle de Acesso Refinado para Ferramentas

    Organizações já implantam milhares de ferramentas MCP através de um gateway unificado. O desafio é garantir que cada principal chamador — seja um agente, usuário ou aplicação — acesse apenas as ferramentas autorizadas, baseando-se em múltiplos fatores dinâmicos como identidade do agente, identidade do usuário e contexto de execução.

    Os interceptadores de requisição garantem que a chamada de uma ferramenta seja bloqueada se o usuário não tiver permissão específica. Isso é feito através da extração e validação do token JWT (Token Web JSON), verificação do escopo do usuário e bloqueio de invocações não autorizadas com um erro MCP estruturado — tudo antes que a ferramenta seja executada.

    Filtragem Dinâmica de Ferramentas

    Agentes descobrem ferramentas disponíveis através de buscas semânticas e operações padrão de listagem. Sem controles apropriados, os servidores MCP retornariam a lista completa de ferramentas independentemente do nível de autorização do agente ou usuário, criando vulnerabilidades de segurança.

    Os interceptadores de resposta resolvem isso filtrando a lista de ferramentas antes que retorne ao agente. Para cada ferramenta na lista, o interceptador avalia se o usuário tem autorização com base nos escopos do JWT, removendo as ferramentas não autorizadas antes de enviar a resposta.

    Imagem original — fonte: Aws

    Tradução de Esquemas e Proteção de Dados

    Empresas enfrentam desafios complexos ao gerenciar contratos entre agentes de IA e APIs downstream. É necessário mapear dinamicamente esquemas de requisição MCP para esquemas de API correspondentes, possibilitando proteção crítica de dados como redação ou remoção de informações pessoalmente identificáveis (PII) que usuários possam enviar em prompts.

    O desacoplamento entre o esquema MCP e as implementações downstream permite que times de backend modifiquem suas APIs, alterem nomes de campos, reestruturem payloads ou atualizem requisitos de autenticação sem quebrar contratos de agentes ou forçando retreinamento de modelos.

    Propagação de Headers Customizados e Gerenciamento de Contexto de Identidade

    Quando agentes interagem com múltiplos serviços downstream, manter a identidade do usuário através de limites de serviços torna-se crítico para segurança, conformidade e trilhas de auditoria. Os interceptadores de requisição extraem informações de identidade dos headers de requisição recebida, transformam-nas no formato esperado pelos serviços downstream e enriquecem requisições antes que alcancem os serviços alvo.

    Imagem original — fonte: Aws

    Abordagens de Autorização: Representação versus Agindo em Nome de

    Uma decisão fundamental em como a identidade flui através de fluxos de trabalho multi-hop é escolher entre representação (impersonation) ou agindo em nome de (act-on-behalf).

    Abordagem de Representação (Não Recomendada)

    Na representação, o token JWT original do usuário é passado inalterado por cada etapa da cadeia de chamadas. Embora mais simples de implementar, cria riscos de segurança significativos:

    • Serviços downstream recebem tokens com privilégios mais amplos do que necessário
    • Risco aumentado de escalação de privilégio se qualquer componente for comprometido
    • Escopo do token não pode ser limitado a alvos downstream específicos
    • Vulnerável a ataques de deputy confuso, onde serviços comprometidos abusam tokens excessivamente privilegiados

    Abordagem Agindo em Nome de (Recomendada)

    Na abordagem agindo em nome de, cada etapa do fluxo de trabalho recebe um token separado e limitado especificamente emitido para aquele alvo downstream, enquanto JWT é usado para propagar contexto de execução. Isso implementa o princípio do menor privilégio e oferece benefícios significativos:

    • Cada serviço recebe apenas as permissões necessárias para acessar APIs específicas downstream
    • Raio de explosão reduzido — tokens comprometidos têm escopo limitado e não podem ser reutilizados
    • Auditoria melhorada — cadeia clara de custódia mostrando qual serviço agiu em nome do usuário
    • Prevenção de deputy confuso — tokens de escopo limitado impedem serviços de serem enganados
    Imagem original — fonte: Aws

    Implementação de Controle de Acesso Refinado

    Usando Escopos JWT

    O controle de acesso refinado usa valores de escopo JWT emitidos pelo Amazon Cognito ou outro provedor OAuth 2. A convenção segue um padrão simples: usuários recebem acesso completo a um alvo MCP (por exemplo, mcp-target-123) ou acesso em nível de ferramenta (por exemplo, mcp-target-123:getOrder).

    O interceptador de requisição valida permissões em tempo de execução através de etapas simples:

    • Extrai e decodifica o JWT para recuperar a solicitação de escopo
    • Identifica qual ferramenta está sendo invocada
    • Bloqueia a requisição se o usuário não tiver acesso completo ao alvo ou permissão específica da ferramenta
    • Retorna um erro MCP estruturado para invocações não autorizadas

    Este modelo é facilmente extensível com claims adicionais (como tenantId e workspaceId) para arquiteturas multi-tenant.

    Imagem original — fonte: Aws

    Modelos de Autorização Flexível: Sem Autenticação e OAuth

    Muitas empresas necessitam de modelos de autorização flexíveis que equilibrem descoberta com segurança. Um cenário comum é permitir que agentes e aplicações descubram e busquem ferramentas MCP disponíveis sem autenticação, facilitando exploração perfeita do catálogo de ferramentas. Porém, ao invocar ferramentas, é necessária autorização OAuth rigorosa.

    O gateway agora suporta isso através de um tipo de autorização “Sem Autenticação” (No Auth) em nível de gateway para todas as chamadas recebidas. Quando configurado, torna todos os alvo e ferramentas acessíveis sem autenticação para fins de descoberta.

    Para aplicar autorização OAuth em nível de método (ListTools versus CallTools) ou implementar políticas de autorização por ferramenta, você usa interceptadores de gateway para examinar o JWT recebido, validá-lo contra requisitos de RFC 6749 usando a URL de descoberta do servidor de autorização, e programaticamente permitir ou negar acesso a métodos ou chamadas de ferramentas específicas.

    Imagem original — fonte: Aws

    Observabilidade e Monitoramento

    A observabilidade abrangente fornecida pelo AgentCore Observability é crítica para monitorar, depurar e auditar fluxos de trabalho de agentes de IA. Os interceptadores de gateway aplicam autorização, transformam requisições e filtram dados antes que serviços downstream executem, tornando a camada de observabilidade um limite crítico de segurança.

    Os interceptadores integram-se automaticamente com AgentCore Observability, fornecendo:

    • Monitoramento em tempo real de decisões de autorização
    • Identificação de gargalos de desempenho através de métricas de duração e invocação
    • Rastreabilidade ponta a ponta através de fluxos de trabalho de agentes multi-hop
    • Atributos de identidade e contexto para validar comportamento de autorização em ambientes multi-tenant
    Imagem original — fonte: Aws

    Integração do AgentCore Gateway

    O AgentCore Gateway transforma APIs e funções AWS Lambda existentes em ferramentas compatíveis com agentes, conecta-se a servidores MCP existentes e fornece integração perfeita com ferramentas e serviços de negócio essenciais de terceiros como Jira, Asana e Zendesk. Este ponto de acesso unificado habilita integração segura entre sistemas corporativos.

    Com o lançamento dos interceptadores de gateway, as organizações podem implementar controle de acesso refinado e gerenciamento de credenciais através de funções Lambda customizadas nos dois pontos críticos do ciclo de requisição-resposta.

    Conclusão

    Os interceptadores de gateway do AgentCore resolvem os desafios fundamentais de segurança que organizações enfrentam ao implantar sistemas de IA em escala. Fornecendo pontos de interceptação programáveis para requisições e respostas, as organizações implementam controle de acesso refinado sem modificar implementações de ferramentas subjacentes ou arquiteturas de servidores MCP.

    À medida que organizações escalam para centenas de agentes e milhares de ferramentas, os interceptadores de gateway oferecem a flexibilidade e controle necessários para manter segurança, conformidade e visibilidade operacional através de implantações complexas de IA, alinhando-se com padrões de integração empresarial e práticas recomendadas de segurança.

    Para explorar como aplicar interceptadores de gateway a desafios empresariais comuns, consulte os exemplos de controle de acesso refinado e propagação de headers customizados. Para documentação completa sobre configuração e implementação de interceptadores de gateway, consulte Controle de acesso refinado para Amazon Bedrock AgentCore Gateway.

    Fonte

    Apply fine-grained access control with Bedrock AgentCore Gateway interceptors (https://aws.amazon.com/blogs/machine-learning/apply-fine-grained-access-control-with-bedrock-agentcore-gateway-interceptors/)

  • Amazon S3 Block Public Access: agora com controle em nível organizacional

    Controle centralizado de segurança no S3

    A AWS anunciou uma importante expansão do Block Public Access (Bloqueio de Acesso Público) para o Amazon S3. O serviço agora permite gerenciamento centralizado através do AWS Organizations, possibilitando que organizações padronizem e enforcem configurações de acesso público em todos os accounts de sua estrutura por meio de uma única configuração de política.

    Como funciona o Block Public Access em nível organizacional

    Propagação automática de políticas

    O Block Public Access em nível organizacional opera através de uma configuração única que controla todas as definições de acesso público em todos os accounts dentro da organização. Quando você anexa a política no root ou em uma Unidade Organizacional (OU, do inglês Organizational Unit) da sua organização, ela se propaga automaticamente para todos os sub-accounts dentro desse escopo. Contas-membro novas herdam a política de forma automática, eliminando a necessidade de configuração manual individual.

    Flexibilidade de aplicação

    Além da abordagem centralizada, você também tem a opção de aplicar a política a accounts específicos quando precisa de um controle mais granular. Essa flexibilidade permite que organizações balanceiem a uniformidade de segurança com necessidades específicas de diferentes times ou departamentos.

    Como começar

    Configuração através do console

    Para iniciar, acesse o console do AWS Organizations e utilize o checkbox “Bloquear todo acesso público” ou use o editor JSON para configurações mais avançadas. A interface permite que você customize exatamente quais tipos de acesso público devem ser bloqueados em toda a sua organização.

    Monitoramento e auditoria

    A AWS CloudTrail pode ser utilizada para auditar e acompanhar a anexação de políticas, bem como monitorar o enforcement da política em todas as contas-membro. Isso oferece visibilidade completa sobre como as configurações de segurança estão sendo aplicadas e mantidas em toda a organização.

    Disponibilidade e acesso

    Esse recurso está disponível no console do AWS Organizations, bem como através da AWS CLI (Interface de Linha de Comando, do inglês Command Line Interface) e SDKs (Kits de Desenvolvimento de Software, do inglês Software Development Kits), em todas as regiões AWS onde AWS Organizations e Amazon S3 são suportados. Importante destacar que não há custos adicionais para usar esse recurso.

    Para aprofundar seus conhecimentos, você pode consultar o guia do usuário do AWS Organizations e a documentação do Block Public Access do Amazon S3 para detalhes técnicos e melhores práticas de implementação.

    Fonte

    Amazon S3 Block Public Access now supports organization-level enforcement (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-s3-block-public-access-organization-level-enforcement)

  • Amazon SageMaker HyperPod agora oferece suporte a labels e taints personalizados do Kubernetes

    Controle granular sobre o agendamento de cargas de trabalho

    A AWS anunciou um novo recurso no Amazon SageMaker HyperPod que oferece suporte a labels (etiquetas) e taints (repugnâncias) personalizados do Kubernetes. Essa funcionalidade permite aos clientes exercer controle preciso sobre o posicionamento de pods e garantir integração tranquila com infraestruturas Kubernetes já existentes.

    Para equipes que implantam cargas de trabalho de inteligência artificial em clusters HyperPod orquestrados com EKS (Elastic Kubernetes Service), esse é um recurso particularmente valioso. A capacidade de controlar exatamente onde cada pod é executado ajuda a evitar que recursos caros, como GPUs, sejam consumidos por pods de sistema ou cargas de trabalho não relacionadas a inteligência artificial, enquanto mantém compatibilidade com plugins de dispositivo personalizados, como o EFA (Elastic Fabric Adapter) e operadores NVIDIA GPU.

    Eliminando a sobrecarga operacional

    O desafio anterior

    Antes deste anúncio, clientes precisavam aplicar manualmente labels e taints usando kubectl, tendo que reaplicá-los após cada substituição de nó, operação de escalonamento ou patch do sistema. Esse processo manual gerava sobrecarga operacional significativa e aumentava o risco de inconsistências.

    A solução implementada

    O novo recurso permite configurar labels e taints no nível do grupo de instâncias através das APIs CreateCluster e UpdateCluster, oferecendo uma abordagem gerenciada para definir e manter políticas de agendamento ao longo de todo o ciclo de vida dos nós.

    Capacidades técnicas

    Utilizando o novo parâmetro KubernetesConfig, é possível especificar até 50 labels e 50 taints por grupo de instâncias. As labels habilitam organização de recursos e direcionamento de pods através de seletores de nó, enquanto taints repelem pods que não possuem tolerâncias correspondentes, protegendo nós especializados.

    Casos de uso práticos

    Um exemplo concreto é aplicar taints do tipo NoSchedule em grupos de instâncias com GPUs, garantindo que apenas trabalhos de treinamento de inteligência artificial com tolerâncias explícitas consumam esses recursos de alto custo. Outra aplicação é adicionar labels personalizados que permitam aos pods de plugins de dispositivo agendar corretamente no ambiente.

    Operação simplificada

    O HyperPod aplica automaticamente essas configurações durante a criação de nós e as mantém durante substituição, escalonamento e operações de patch. Isso elimina a necessidade de intervenção manual e reduz significativamente a sobrecarga operacional que as equipes enfrentavam anteriormente.

    O recurso está disponível em todas as regiões da AWS onde o Amazon SageMaker HyperPod é oferecido. Para aprofundar seus conhecimentos sobre labels e taints personalizados, consulte a documentação técnica completa.

    Fonte

    Amazon SageMaker HyperPod now supports custom Kubernetes labels and taints (https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-sagemaker-hyperpod-kubernetes/)

  • Diretrizes para Varreduras de Rede: O Novo Padrão de Segurança da AWS

    A Varredura de Rede e o Desafio da Segurança

    A AWS apresentou um conjunto de diretrizes destinadas às varreduras de rede realizadas em ambientes de clientes. O objetivo? Permitir que ferramentas conformes coletem dados mais precisos, reduzam relatos de abuso e contribuam para elevar o nível de segurança na internet como um todo.

    Varreduras de rede são práticas comuns em infraestruturas modernas de TI. No entanto, essa prática enfrenta um dilema fundamental: ela pode servir tanto a propósitos legítimos quanto a atividades maliciosas. Do lado legítimo, equipes de segurança, administradores de sistemas e pesquisadores autorizados utilizam varreduras para manter inventários precisos de ativos, validar configurações de segurança e identificar vulnerabilidades ou versões desatualizadas de software que demandam atenção imediata.

    Já do lado malicioso, atores de ameaça realizam varreduras para enumerar sistemas, descobrir fraquezas e coletar inteligência para futuros ataques. Distinguir entre essas duas situações é um desafio constante para operações de segurança.

    Por Que Essas Diretrizes Importam

    O Crescimento Exponencial de Vulnerabilidades

    O cenário atual apresenta pressões significativas. De acordo com o banco de dados de vulnerabilidades da NIST (Banco Nacional de Dados de Vulnerabilidades), o número de vulnerabilidades conhecidas cresce a uma taxa de 21% ao ano nos últimos dez anos. Quando uma vulnerabilidade é descoberta por meio de varredura, a intenção do scanner torna-se crítica. Se um ator de ameaça explorar essa vulnerabilidade antes que seja corrigida, ele poderá obter acesso não autorizado aos sistemas organizacionais.

    As organizações precisam gerenciar efetivamente suas vulnerabilidades de software para se protegerem contra ransomware, roubo de dados, problemas operacionais e penalidades regulatórias. Porém, isso só é possível quando os dados de segurança coletados por varreduras permanecem protegidos.

    Os Múltiplos Interessados nos Dados de Segurança

    Diferentes grupos possuem interesses legítimos mas distintos em relação aos dados de segurança coletados:

    • Organizações querem entender seus ativos e corrigir vulnerabilidades rapidamente para proteger sua infraestrutura
    • Auditores de compliance buscam evidências de controles robustos na gestão de infraestrutura
    • Provedores de seguros cibernéticos precisam avaliar o risco da postura de segurança organizacional
    • Investidores em avaliação de diligência querem compreender o perfil de risco cibernético de uma organização
    • Pesquisadores de segurança desejam identificar riscos e notificar organizações para que ajam
    • Atores de ameaça buscam explorar vulnerabilidades não corrigidas e fraquezas para obter acesso não autorizado

    Esse ecossistema complexo de interesses concorrentes exige que dados sensíveis de segurança sejam mantidos com níveis diferentes de acesso. Se esses dados caírem nas mãos erradas, as consequências podem ser severas: comprometimento de sistemas, ransomware, negação de serviço e custos significativos para os proprietários dos sistemas.

    Considerando o crescimento exponencial de data centers e cargas de trabalho de software conectadas que fornecem serviços críticos em setores como energia, manufatura, saúde, governo, educação, finanças e transportes, o impacto de dados de segurança em mãos erradas pode ter consequências significativas no mundo real.

    A Falta de um Padrão Unificado

    Atualmente, não existe um padrão único para identificação de scanners de rede na internet. Proprietários de sistemas geralmente não sabem quem está realizando varreduras em suas infraestruturas. Cada proprietário é independentemente responsável por gerenciar a identificação dessas diferentes partes. Scanners podem usar métodos variados para se identificar — como busca reversa de DNS, agentes de usuário personalizados ou faixas de rede dedicadas. Já atores maliciosos podem tentar evitar identificação completamente.

    Esse grau de variação na identidade torna extremamente difícil para os proprietários de sistemas compreender a motivação por trás das varreduras que recebem. É nesse contexto que a AWS apresenta suas diretrizes comportamentais para varreduras de rede, buscando proteger redes e clientes.

    Os Benefícios das Diretrizes

    Quando scanners em conformidade com essas diretrizes realizam varreduras, eles coletam dados mais confiáveis da infraestrutura AWS. Organizações que executam workloads na AWS recebem um maior grau de confiança em sua gestão de riscos. Quando a varredura segue essas diretrizes, proprietários de sistemas conseguem fortalecer suas defesas e melhorar visibilidade em todo seu ecossistema digital.

    Ferramentas como o Amazon Inspector podem detectar vulnerabilidades de software e priorizar esforços de correção enquanto aderem a essas diretrizes. Parceiros do AWS Marketplace utilizam essas orientações para coletar sinais de segurança em toda a internet e ajudar organizações a compreender e gerenciar riscos cibernéticos. Como afirmou um especialista do Bitsight: “Quando organizações têm visibilidade clara orientada por dados sobre sua própria postura de segurança e a de terceiros, conseguem tomar decisões mais rápidas e inteligentes para reduzir riscos cibernéticos em todo o ecossistema.”

    Reportando Atividades Abusivas

    A segurança funciona melhor quando há colaboração. Clientes da AWS podem reportar varreduras abusivas através do Centro de Confiança e Segurança, selecionando o tipo de relatório como “Atividade de Rede > Varredura de Portas e Tentativas de Intrusão”. Cada relatório contribui para melhorar a proteção coletiva contra o uso malicioso de dados de segurança.

    As Diretrizes de Conformidade

    Para permitir que scanners legítimos se diferenciem claramente de atores de ameaça, a AWS oferece as seguintes orientações para varredura de workloads. Essas diretrizes complementam as políticas existentes sobre testes de penetração e relatório de vulnerabilidades. A AWS se reserva o direito de limitar ou bloquear tráfego que pareça não estar em conformidade com essas diretrizes.

    1. Observacional

    Um scanner em conformidade não realiza ações que tentem criar, modificar ou deletar recursos ou dados nos endpoints descobertos. Respeita a integridade dos sistemas-alvo. As varreduras não causam degradação na funcionalidade do sistema e não introduzem mudanças nas configurações.

    Exemplos de varredura não-modificadora incluem:

    • Iniciar e completar um handshake TCP
    • Recuperar o banner de um serviço SSH

    2. Identificável

    Um scanner em conformidade oferece transparência ao publicar as fontes de sua atividade de varredura. Implementa um processo verificável para confirmar a autenticidade de atividades de varredura.

    Exemplos de varredura identificável incluem:

    • Suportar buscas reversa de DNS para uma das zonas de DNS públicas de sua organização nos IPs de varredura
    • Publicar intervalos de IP de varredura, organizados por tipos de requisições (como verificação de existência de serviços, verificações de vulnerabilidades)
    • Se realizar varreduras HTTP, incluir conteúdo significativo em strings de agente de usuário (como nomes de suas zonas de DNS públicas, URL para opt-out)

    3. Cooperativo

    Um scanner em conformidade limita taxas de varredura para minimizar impacto nos sistemas-alvo. Oferece um mecanismo de opt-out para proprietários de recursos verificados que desejam solicitar cessação da atividade de varredura. Honra solicitações de opt-out dentro de um período de resposta razoável.

    Exemplos de varredura cooperativa incluem:

    • Limitar varredura a uma transação de serviço por segundo por serviço de destino
    • Respeitar configurações de site conforme expressos em robots.txt, security.txt e outros padrões da indústria para expressar intenção do proprietário do site

    4. Confidencial

    Um scanner em conformidade mantém práticas seguras de infraestrutura e manipulação de dados, refletidas em certificações de padrão industrial como SOC2. Garante nenhum acesso não autenticado ou não autorizado aos dados coletados. Implementa processos de identificação e verificação de usuários.

    O Caminho Adiante

    À medida que mais scanners de rede adotam essas diretrizes, proprietários de sistemas se beneficiarão de riscos reduzidos em relação a confidencialidade, integridade e disponibilidade. Scanners legítimos enviarão um sinal claro de sua intenção e melhorarão a qualidade de visibilidade que conseguem obter. Com o estado em constante mudança do networking, espera-se que essas diretrizes evoluam acompanhando controles técnicos ao longo do tempo.

    A AWS convida feedback de clientes, proprietários de sistemas, scanners de rede e outros interessados para continuar melhorando a postura de segurança em toda a AWS e na internet. Consulte as diretrizes completas na AWS ou entre em contato com o Suporte AWS para dúvidas específicas.

    Fonte

    Introducing guidelines for network scanning (https://aws.amazon.com/blogs/security/introducing-guidelines-for-network-scanning/)