Blog

  • Jornada da IA Generativa: O Framework Caminho-para-Valor da AWS

    Entendendo o desafio real da IA generativa

    A IA generativa está transformando a forma como as organizações abordam produtividade, experiências do cliente e capacidades operacionais. Equipes em diferentes setores experimentam essa tecnologia para descobrir novas formas de trabalhar. Muitos desses esforços geram provas de conceito (POC) convincentes que demonstram viabilidade técnica.

    O problema real começa após esses primeiros sucessos. Embora as POCs frequentemente comprovem a viabilidade técnica, as organizações enfrentam dificuldades para transformar esses protótipos em sistemas prontos para produção que gerem valor mensurável para o negócio. A transição do conceito para produção, e depois para criação de valor sustentado, apresenta desafios que vão além da tecnologia—envolvem questões organizacionais e de governança.

    A AWS desenvolveu o framework Caminho-para-Valor (P2V) para preencher essa lacuna. Ele fornece um modelo mental e um guia prático que ajuda as organizações a movimentar iniciativas de IA generativa de forma sistemática, desde a ideação e experimentação até a produção em escala. O objetivo é criar valor duradouro para o negócio.

    As quatro categorias principais de barreiras

    Quando as organizações transitam a IA generativa da fase experimental para produção e criação de valor, os desafios se concentram em quatro categorias principais.

    Imagem original — fonte: Aws

    Valor

    Muitas iniciativas de IA generativa carecem de um ROI claramente definido ou de resultados mensuráveis. Sem critérios de sucesso concretos, fica difícil justificar investimentos continuados ou priorizar esforços. O foco deve estar em tornar o sucesso mensurável e garantir que os investimentos gerem resultados reais.

    Risco

    Preocupações com exposição legal, privacidade de dados, vulnerabilidades de segurança e impacto reputacional criam resistência. O panorama regulatório em evolução para a IA aumenta ainda mais a incerteza em torno de conformidade. As organizações precisam estabelecer guardrails desde o início, não depois.

    Tecnologia

    Colocar IA generativa em produção apresenta desafios técnicos além da seleção do modelo. A integração com sistemas existentes, requisitos de infraestrutura, problemas de qualidade de dados e complexidade operacional (observabilidade, escalabilidade, resiliência) são frequentemente subestimados. Avaliação e validação continuam sendo desafios críticos antes da produção. As equipes devem estabelecer métricas, construir conjuntos de dados de teste, medir desempenho em diferentes cenários e implementar monitoramento contínuo.

    Pessoas

    A adoção é desacelerada por resistência à mudança, lacunas de habilidades nas equipes, incerteza sobre como a IA generativa afeta papéis e responsabilidades, e dificuldades em encontrar ou desenvolver a expertise correta. Essas barreiras raramente aparecem isoladamente. Resolver uma sem abordar as outras frequentemente apenas desloca o problema em vez de solucioná-lo.

    O framework Caminho-para-Valor

    O framework P2V serve como um modelo mental compartilhado e um roteiro para stakeholders técnicos e não-técnicos. Fornece orientação sobre o ciclo de vida de workloads de IA generativa, desde a ideação inicial, passando pela implementação pronta para produção, até a realização de valor sustentado.

    Ao invés de tratar a produção como o objetivo final, o framework a posiciona como um marco no caminho para o impacto comercial. Seu propósito é ajudar as organizações a remover os bloqueadores mais comuns que impedem iniciativas de IA generativa de escalar com sucesso.

    Estrutura do framework

    O framework traduz experiências de implementação do mundo real em orientação prática por meio de três componentes principais: pilares (que representam as áreas-chave a serem abordadas), pontos de verificação (que esclarecem o que significa estar pronto em diferentes estágios) e orientação com artefatos (que fornecem ferramentas concretas para apoiar a execução).

    Um sistema interconectado, não um processo linear

    O framework P2V não é concebido para ser aplicado como um processo linear e sequencial. A adoção de IA generativa raramente avança em linha reta. As organizações devem aplicar o framework com flexibilidade e de forma assíncrona, abordando múltiplos pilares em paralelo. Por exemplo, as equipes podem simultaneamente construir capacidades técnicas enquanto estabelecem guardrails de governança e desenvolvem casos de negócio para diferentes casos de uso. Essa abordagem paralela pode acelerar significativamente o caminho geral para produção e valor.

    Imagem original — fonte: Aws

    Os pilares principais do framework

    O framework P2V se organiza em torno de um conjunto de pilares fundamentais. Cada pilar define uma dimensão crítica que deve ser abordada para mover iniciativas de IA generativa da experimentação para produção e valor comercial sustentado.

    Caso de negócio e criação de valor

    Em um mercado competitivo, investimentos em IA generativa devem demonstrar retornos claros. Este pilar foca em definir e medir resultados comerciais para que as iniciativas avancem além de provas de conceito em direção a soluções em produção que entregam valor quantificável.

    As áreas de foco incluem criar um template estruturado para documentar a proposta de valor e resultados esperados, estabelecer uma matriz de decisão sobre custos para avaliar custos de implementação contra retornos potenciais (incluindo técnicas de otimização como cache de prompts, destilação de conhecimento e roteamento inteligente de modelos), e definir métricas de negócio claras para medir impacto e desempenho.

    Estratégia de dados

    Dados de qualidade são a fundação de IA bem-sucedida. Este pilar enfatiza a integração de dados de alta qualidade de sistemas de conhecimento corporativo, em vez de depender de modelos cada vez mais complexos. Ao focar em qualidade, governança e integração de dados, as organizações frequentemente conseguem melhores resultados com menor complexidade técnica.

    O foco inclui estabelecer diretrizes para coleta e pré-processamento de dados relevantes, definir padrões para precisão e confiabilidade, criar frameworks para gerenciar e governar ativos de dados, definir critérios para datasets de referência usados em treinamento, e construir pipelines eficientes de processamento de dados que mantenham qualidade ao longo do ciclo de vida da IA.

    Segurança, conformidade e governança

    À medida que a IA generativa se torna crítica para operações comerciais, a implementação responsável é essencial. Este pilar estabelece os guardrails necessários para escalar a IA generativa com confiança, permitindo que as organizações construam segurança, conformidade e governança desde o início, em vez de adicioná-las depois.

    As áreas críticas incluem definir protocolos de acesso a sistemas e dados, implementar mecanismos de segurança para evitar uso indevido, aplicar padrões consistentes para proteger modelos e endpoints, escalar controles de nível POC para protocolos de segurança em nível de produção, e estabelecer frameworks de autossupervisão para desenvolvimento responsável de IA.

    Avaliação de escolhas tecnológicas

    Selecionar a abordagem correta em IA generativa exige mais do que comparar especificações técnicas. Este pilar alinha decisões tecnológicas com objetivos comerciais, fornecendo orientação clara sobre estratégias de implementação e otimização de recursos. As áreas de foco incluem avaliar diferentes arquiteturas de modelos usando critérios consistentes, aplicar abordagens estruturadas para decisões de seleção de tecnologia, planejar transições entre abordagens de IA generativa conforme os requisitos evoluem, e avaliar considerações para sistemas que lidam com múltiplos tipos de dados.

    IA responsável

    IA responsável agora é um requisito central para adoção empresarial. Este pilar estabelece guardrails que abordam conformidade regulatória enquanto constroem confiança com stakeholders. As organizações que operacionalizam IA responsável no início podem acelerar aprovações e fortalecer sua posição competitiva.

    O foco inclui avaliar implicações de sourcing e propriedade do modelo, implementar técnicas que preservam privacidade em dados e workflows de inferência, identificar e abordar implicações de IA responsável em casos de uso, detectar e reduzir viés algorítmico, e apoiar a capacidade de entender e explicar decisões orientadas por IA.

    Ciclo de vida de desenvolvimento

    Entregar IA generativa com sucesso em produção exige selecionar a abordagem técnica correta sem se perder em complexidade. Este pilar fornece orientação clara para avaliação, arquitetura e implementação, de modo que decisões técnicas permaneçam alinhadas com resultados comerciais e eficiência de custos conforme os sistemas escalam.

    As áreas de foco incluem definir padrões para medir desempenho de modelos e validar comportamento, estabelecer abordagens estruturadas de teste e validação, aplicar diferentes métodos de avaliação para testes pré-produção versus uso ao vivo, e integrar julgamento humano ao longo do ciclo de vida de IA para melhorar precisão, segurança e alinhamento.

    Excelência operacional

    A diferença entre implementações bem-sucedidas de IA generativa e experimentos estagnados vem down à execução operacional. Este pilar foca em executar sistemas de IA generativa de forma confiável em produção por meio de otimização contínua, monitoramento de KPI e gestão disciplinada de custos. Mecanismos de feedback robustos ajudam os sistemas a melhorar ao longo do tempo enquanto mantêm desempenho previsível.

    O foco está em tratar a IA generativa como um workload em produção de longa duração, não como uma implementação única. As áreas críticas incluem estabelecer diretrizes para gerenciamento de produção do dia a dia, lidar com demanda variável como picos de tráfego de inferência, manter visibilidade sobre comportamento e falhas do sistema, simplificar atualizações de modelos e configurações, administrar e otimizar recursos de tempo de execução, manter latência e throughput consistentes em escala, e continuamente refinar modelos com base em sinais de produção.

    Desenvolvimento de habilidades e treinamento

    O sucesso sustentado em IA generativa depende tanto de pessoas quanto de tecnologia. Este pilar foca em construir as habilidades e prontidão organizacional necessárias para adotar, operar e escalar IA generativa de forma eficaz. O objetivo é garantir que capacidades técnicas se traduzam diretamente em valor comercial. Ao alinhar treinamento com casos de uso reais e medir impacto, as organizações podem impulsionar adoção enquanto mantêm um link claro entre esforços de habilitação e resultados.

    Imagem original — fonte: Aws

    A jornada de adoção de IA generativa

    O framework P2V, como um modelo mental, simplifica a jornada de adoção de IA generativa. Fornece um sistema flexível e interconectado que guia as organizações através de fases críticas, desde desenvolvimento inicial de conceito, passando por implementação pronta para produção, até criação de valor sustentável.

    Como um framework agnóstico em relação à indústria, caso de uso e tecnologia, ele pode ser aplicado em diversos contextos e cenários organizacionais. Ao invés de otimizar para um único estágio, o framework aborda sistematicamente as dimensões que determinam sucesso a longo prazo: criação de valor, gerenciamento de risco, rigor técnico e transformação de pessoas.

    As organizações podem entrar na jornada quando desejarem e progredir em seu próprio ritmo mantendo alinhamento com objetivos comerciais e práticas de IA responsável. O framework P2V não é intencionalmente uma abordagem rígida e em cascata. Serve como guia proativo e ferramenta diagnóstica, ajudando organizações que lutam com implementação em produção ou realização de valor a identificar rapidamente lacunas e desenvolver caminhos customizados para frente.

    Amazon Bedrock como motor de execução

    O serviço Amazon Bedrock (a plataforma para construir aplicações e agentes de IA generativa em escala de produção) ajuda as organizações a executar a jornada Caminho-para-Valor ao simplificar a transição de conceito para produção. Fornece um ambiente unificado para implementação de IA generativa que aborda elementos-chave do framework P2V como acesso a modelos, segurança e escalabilidade. Ao oferecer infraestrutura gerenciada, controles de governança incorporados e capacidades de integração empresarial, o Amazon Bedrock reduz fricção operacional e acelera prontidão para produção. Isso permite que as equipes se concentrem menos em preocupações infraestruturais não diferenciadas e mais em aplicar o framework P2V para entregar resultados comerciais mensuráveis.

    Imagem original — fonte: Aws

    Desenvolvendo IA generativa com velocidade e controle

    O framework P2V aborda o que as organizações precisam acertar ao longo da jornada de IA generativa, mas a velocidade dessa jornada depende muito de como as equipes desenvolvem. Práticas tradicionais de desenvolvimento de software, projetadas para processos sequenciais orientados por humanos, frequentemente se tornam o gargalo oculto que estagna iniciativas entre prova de conceito e produção.

    O Ciclo de Vida de Desenvolvimento Orientado por IA (IA-DLC) aborda isso posicionando IA como um colaborador central, não apenas um assistente de codificação. Reimagina o ciclo de vida inteiro em torno de um padrão poderoso: IA ajuda a criar planos, busca clarificação e apoia implementação, enquanto humanos tomam decisões críticas. As três fases do IA-DLC (Inception, Construção e Operações) espelham a jornada P2V de conceito através de produção para valor sustentado, com potencial para comprimir ciclos de desenvolvimento de semanas para horas enquanto mantém trabalho técnico alinhado com resultados comerciais e requisitos de governança.

    Conclusão

    O framework Caminho-para-Valor da IA Generativa oferece um modelo mental abrangente para navegar as complexidades da adoção de IA generativa. Ao fornecer orientação ao longo da jornada completa, desde conceito até pronto para produção e criação de valor, o framework ajuda as organizações a abordar desafios comuns em cada estágio.

    Para organizações com iniciativas de IA generativa estagnadas, o framework oferece orientação direcionada para diagnosticar bloqueadores e adaptar um caminho para frente. Ajuda a garantir que muitos aspectos de implementação bem-sucedida sejam considerados.

    À medida que a IA generativa continua evoluindo, este modelo mental pode servir como um recurso valioso para organizações buscando usar essa tecnologia em escala.

    Fonte

    Navigating the generative AI journey: The Path-to-Value framework from AWS (https://aws.amazon.com/blogs/machine-learning/navigating-the-generative-ai-journey-the-path-to-value-framework-from-aws/)

  • AWS Secrets Manager agora protege segredos contra ameaças quânticas com TLS pós-quântico híbrido

    Proteção Contra Ameaças Quânticas no Gerenciamento de Segredos

    A AWS anunciou que o Secrets Manager agora oferece suporte a troca de chaves pós-quântica híbrida utilizando ML-KEM (Mecanismo de Encapsulamento de Chave Baseado em Módulos Lattice). Esse novo recurso fortalece as conexões TLS usadas para recuperar e gerenciar segredos, combinando a segurança criptográfica clássica com proteção contra ameaças futuras relacionadas à computação quântica.

    Ativação Automática e Compatibilidade

    O suporte a troca de chaves pós-quântica está automaticamente habilitado nas versões mais recentes dos principais componentes de integração:

    • Secrets Manager Agent (versão 2.0.0+)
    • AWS Lambda Extension (versão 19+)
    • Secrets Manager CSI Driver (versão 2.0.0+)

    Para clientes que utilizam bibliotecas de cliente baseadas em SDKs, a troca de chaves pós-quântica está disponível nos seguintes ambientes: Rust, Go, Node.js, Kotlin, Python (com OpenSSL 3.5+) e Java v2 (v2.35.11+).

    Proteção Contra Ataques “Harvest Now, Decrypt Later”

    As aplicações agora recuperam segredos por meio de conexões TLS que combinam troca de chaves clássica com criptografia pós-quântica. Isso oferece proteção simultânea contra dois cenários de segurança: ataques criptográficos tradicionais e ameaças futuras conhecidas como “harvest now, decrypt later” (HNDL), em que adversários capturam dados criptografados hoje para descriptografá-los após o desenvolvimento de computadores quânticos.

    Implementação Sem Mudanças de Código

    Um dos diferenciais dessa implementação é a simplicidade de adoção. Para clientes utilizando as versões mais recentes dos componentes de integração, nenhuma alteração de código, atualização de configuração ou esforço de migração são necessários — com exceção de clientes Java v2.

    Um exemplo prático: um microsserviço que requer múltiplos segredos durante inicialização agora pode recuperá-los por conexões TLS resistentes a ataques quânticos simplesmente atualizando para a versão mais recente do Secrets Manager Agent.

    Verificação e Monitoramento

    É possível confirmar que a troca de chaves pós-quântica híbrida está ativa consultando os registros do CloudTrail. Basta verificar a presença do algoritmo de troca de chaves “X25519MLKEM768” no campo tlsDetails das chamadas da API GetSecretValue.

    Disponibilidade Regional

    A troca de chaves pós-quântica híbrida usando ML-KEM para o Secrets Manager está disponível em todas as regiões da AWS onde o serviço é oferecido.

    Próximos Passos

    Para aprofundar o conhecimento técnico, é recomendado consultar a documentação do AWS Secrets Manager e a página de migração para criptografia pós-quântica da AWS, que oferecem guias detalhados sobre a implementação e as melhores práticas.

    Fonte

    AWS Secrets Manager now supports hybrid post-quantum TLS to protect secrets from quantum threats (https://aws.amazon.com/about-aws/whats-new/2026/04/aws-secrets-manager-post-quantum-tls/)

  • Instâncias EC2 P6-B300 agora disponíveis na AWS GovCloud (US-East)

    Novas Instâncias P6-B300 na AWS GovCloud

    A AWS anunciou, a partir de abril de 2026, a disponibilidade das instâncias Amazon EC2 P6-B300 na região AWS GovCloud (US-East). Esta nova opção representa um avanço significativo para organizações que trabalham com cargas de trabalho de inteligência artificial exigentes e precisam de conformidade com regulamentações governamentais.

    Capacidades Técnicas da P6-B300

    As instâncias P6-B300 trazem especificações que as destacam como ferramentas poderosas para processamento intensivo de IA. Cada instância é equipada com 8 GPUs NVIDIA Blackwell Ultra, oferecendo 2,1 TB de memória GPU de alta largura de banda. A infraestrutura de rede é igualmente robusta, com 6,4 Tbps de networking EFA (Elastic Fabric Adapter) e 300 Gbps de throughput dedicado de ENA (Elastic Network Adapter), além de 4 TB de memória do sistema.

    Melhorias Comparativas

    Quando comparadas com as instâncias P6-B200, as novas P6-B300 oferecem vantagens substanciais: o dobro de largura de banda de rede, 50% mais memória GPU e 50% mais capacidade computacional de GPUs (em FP4, sem esparsidade). Essas melhorias se traduzem em benefícios práticos durante o ciclo de desenvolvimento — tempos de treinamento mais rápidos e maior throughput de tokens para cargas de trabalho de IA.

    Aplicações em Modelos de Linguagem

    A combinação de memória expandida e conectividade aprimorada torna as instâncias P6-B300 particularmente adequadas para treinar e implantar modelos fundacionais (FMs) de grande escala com trilhões de parâmetros e modelos de linguagem de grande porte (LLMs) utilizando técnicas sofisticadas. Isso permite que organizações trabalhem com arquiteturas mais complexas e lidem com volumes maiores de dados simultaneamente.

    Disponibilidade Regional

    No momento, as instâncias P6-B300 estão disponíveis no tamanho p6-b300.48xlarge em duas regiões da AWS: US West (Oregon) e AWS GovCloud (US-East). Para conhecer mais detalhes técnicos e explorar as características completas dessas instâncias, você pode consultar a documentação oficial sobre instâncias EC2 P6.

    Fonte

    Amazon EC2 P6-B300 instances are now available in the AWS GovCloud (US-East) Region (https://aws.amazon.com/about-aws/whats-new/2026/04/ec2-p6-b300-govcloud-us-east/)

  • Padrões Seguros de Acesso para Agentes de IA a Recursos AWS Usando Model Context Protocol

    Segurança de Agentes de IA Acessando Recursos AWS

    A inteligência artificial generativa trouxe uma nova categoria de aplicações: os agentes de IA e assistentes de codificação. Diferente das aplicações tradicionais com fluxos de código previsíveis, esses agentes raciocinam dinamicamente, escolhendo diferentes ferramentas e acessando diferentes dados conforme o contexto. Essa característica fundamental muda completamente a abordagem de segurança necessária.

    O acesso desses agentes aos recursos da AWS acontece frequentemente através do Model Context Protocol (MCP). A AWS publicou orientações técnicas focadas especificamente em como garantir que esse acesso seja seguro, apresentando três princípios de segurança para construir controles determinísticos em sistemas não-determinísticos de IA.

    Entendendo o Problema de Segurança

    O desafio fundamental é que você deve assumir que um agente pode fazer qualquer coisa dentro de suas permissões concedidas, independentemente da intenção original. Diferente de uma aplicação tradicional onde você revisa o código e entende exatamente quais APIs serão chamadas, um agente pode invocar diferentes ferramentas em diferentes contextos.

    Agentes operam em velocidade de máquina, o que significa que o impacto de permissões mal configuradas escala rapidamente. Um agente pode fazer milhares de chamadas de API em segundos. Se receber permissões excessivas, pode causar danos significativos antes de qualquer detecção humana.

    A AWS Identity and Access Management (IAM) é a camada de autorização para acesso aos recursos AWS. O foco da orientação é em como usar IAM de forma adequada, considerando a natureza não-determinística dos agentes de IA.

    Padrões de Implantação do MCP

    Onde os Agentes Executam

    Os agentes acessam recursos AWS de três locais distintos. O primeiro padrão é em máquinas de desenvolvimento, como assistentes de IA (ex: Kiro e Claude Code) executando localmente. Neste caso, as credenciais vêm do ambiente local do desenvolvedor, e o desenvolvedor controla qual principal IAM o agente usa.

    O segundo padrão é em ambientes de hospedagem gerenciados pela organização, como Amazon Bedrock AgentCore, Amazon EC2 ou Amazon EKS. Aqui, o agente usa um papel IAM de execução configurado pela organização.

    O terceiro padrão é em plataformas de agentes de terceiros, onde a organização não controla a infraestrutura. Este artigo se concentra nos dois primeiros padrões.

    Tipos de Servidores MCP

    Existem dois tipos de servidores MCP. Os servidores gerenciados pela AWS, como o AWS MCP Server, Amazon EKS MCP Server e Amazon ECS MCP Server, rodam na infraestrutura AWS sem necessidade de instalação.

    Os servidores auto-gerenciados são aqueles que você instala e mantém você mesmo, incluindo servidores fornecidos pela AWS no AWS MCP GitHub repository ou servidores customizados que você constrói do zero.

    A diferença de segurança é importante: os servidores gerenciados pela AWS adicionam automaticamente chaves de contexto IAM a cada chamada de serviço AWS downstream. Os servidores auto-gerenciados não fazem isso automaticamente; você precisa configurá-los para adicionar tags de sessão ao assumir papéis IAM.

    Princípio 1: Assuma que Todas as Permissões Concedidas Podem Ser Usadas

    Este é o princípio fundamental. Qualquer permissão que você conceda a um agente pode ser exercida, regardless da sua intenção original. Se você concede s3:DeleteObject, deve assumir que o agente pode deletar qualquer objeto S3 ao qual tem acesso.

    As aplicações tradicionais seguem caminhos de código determinísticos. Você revisa o código-fonte e identifica exatamente quais APIs serão chamadas. Agentes de IA operam diferente. Eles tomam decisões em tempo de execução baseadas em raciocínio e contexto.

    Cenários de Risco

    Alucinação: O agente interpreta mal uma solicitação e realiza a ação errada. Um agente designado para limpar arquivos temporários pode alucinar que dados de produção são temporários e deletá-los.

    Injeção de prompt: Um terceiro malicioso elabora entrada inesperada que influencia o raciocínio do agente. Um agente designado para consultar tabelas Amazon DynamoDB poderia ser direcionado a chamar operações de escrita em recursos fora de seu escopo.

    Erros de lógica: O raciocínio do agente leva a uma conclusão incorreta. Um agente analisando custos de armazenamento S3 pode concluir que dados frequentemente acessados são não utilizados e deletá-los para economizar.

    Envenenamento de ferramentas: Um servidor MCP comprometido ou dependência realiza operações não intencionais usando as credenciais do agente.

    Implementação Prática

    Aplique o princípio de menor privilégio rigorosamente. Se um agente precisa apenas ler objetos S3, conceda apenas s3:GetObject, não s3:*. Use condições de política IAM para limitar permissões a recursos específicos.

    Considere implementar perímetros de dados como camada adicional de defesa. Use alarmes do CloudWatch para monitorar ações inesperadas do agente. Conduza auditorias regulares de permissões para identificar e remover acessos que não são mais necessários.

    Princípio 2: Orientação Organizacional sobre Uso de Papéis

    Este princípio aborda governança organizacional. Quando desenvolvedores usam assistentes de IA e configuram servidores MCP, frequentemente escolhem papéis existentes que foram designados para uso humano com permissões muito mais amplas que os agentes realmente precisam.

    Para Agentes que Você Controla

    Quando você controla o código do agente, pode implementar gerenciamento de credenciais dinâmico. Este é o modelo de execução mais forte. O papel IAM define o teto máximo de permissões, mas você usa políticas de sessão para restringir permissões por operação específica.

    Quando o agente invoca uma ferramenta específica, chama AssumeRole com uma política de sessão que restringe permissões apenas ao que essa ferramenta requer. As permissões efetivas são a interseção das políticas do papel e da política de sessão.

    import boto3
    
    sts = boto3.client('sts')
    
    response = sts.assume_role(
        RoleArn='arn:aws:iam::111122223333:role/AgentDataRole',
        RoleSessionName='agent-data-reader',
        PolicyArns=[
            {'arn': 'arn:aws:iam::aws:policy/ReadOnlyAccess'}
        ],
        DurationSeconds=3600
    )
    
    credentials = response['Credentials']
    s3 = boto3.client(
        's3',
        aws_access_key_id=credentials['AccessKeyId'],
        aws_secret_access_key=credentials['SecretAccessKey'],
        aws_session_token=credentials['SessionToken']
    )

    Para Assistentes de IA Configurados

    Quando você usa assistentes de IA com configuração fixa (como Kiro ou Claude Code), seus controles de segurança devem estar em lugar antes do agente executar. Crie papéis específicos para agentes com permissões mais restritas que papéis equivalentes de humanos.

    Use limites de permissão IAM para estabelecer governança organizacional. Um limite de permissão é uma política gerenciada que sua equipe de segurança anexa a um papel IAM para definir as permissões máximas que esse papel pode conceder. As permissões efetivas são a interseção das políticas de identidade do papel e do limite de permissão.

    Para ambientes multi-conta, use AWS Organizations e políticas de controle de serviço (SCPs) para estabelecer limites máximos de permissões em toda a organização.

    Princípio 3: Diferenciar Ações Orientadas por IA de Ações Iniciadas por Humanos

    Este terceiro princípio adiciona um nível complementar de controle. Enquanto o princípio 2 governa quais permissões um agente tem, este princípio governa o que o agente pode fazer com essas permissões baseado em se a ação é orientada por IA ou iniciada por humano.

    Sem mecanismo de diferenciação, políticas IAM não podem distinguir entre ações de IA e iniciadas por humano. Se um desenvolvedor tem permissão s3:DeleteObject e usa um agente com suas credenciais, o agente também tem essa permissão sem forma de restringir.

    Servidores MCP Gerenciados pela AWS

    Os servidores gerenciados pela AWS oferecem diferenciação por padrão. Eles adicionam automaticamente as chaves de contexto IAM aws:ViaAWSMCPService (booleano true quando a solicitação vem através de um servidor MCP gerenciado) e aws:CalledViaAWSMCP (string contendo o nome do servidor MCP) a cada chamada de serviço AWS downstream.

    Você precisa apenas escrever políticas IAM que verifiquem essas chaves. A seguinte política nega operações de delete quando acessadas através de qualquer servidor MCP gerenciado:

    {
      "Version": "2012-10-17",
      "Statement": [{
        "Sid": "AllowS3ReadOperations",
        "Effect": "Allow",
        "Action": [
          "s3:GetObject",
          "s3:ListBucket"
        ],
        "Resource": "*"
      }, {
        "Sid": "DenyDeleteWhenAccessedViaMCP",
        "Effect": "Deny",
        "Action": [
          "s3:DeleteObject",
          "s3:DeleteBucket"
        ],
        "Resource": "*",
        "Condition": {
          "Bool": {
            "aws:ViaAWSMCPService": "true"
          }
        }
      }]
    }

    Servidores MCP Auto-Gerenciados

    Servidores auto-gerenciados não adicionam chaves de contexto automaticamente. Para implementar diferenciação, você deve configurar o servidor MCP para adicionar tags de sessão ao assumir papéis IAM. Isso requer modificar seu servidor MCP para chamar AssumeRole com tags anexadas:

    import boto3
    
    sts = boto3.client('sts')
    
    response = sts.assume_role(
        RoleArn='arn:aws:iam::111122223333:role/MCPServerRole',
        RoleSessionName='mcp-server-session',
        Tags=[
            {'Key': 'AccessType', 'Value': 'AI'},
            {'Key': 'Source', 'Value': 'AgentRuntime'},
            {'Key': 'MCPServer', 'Value': 'org-data-server'}
        ]
    )
    
    credentials = response['Credentials']

    Você então escreve políticas IAM que verificam essas tags usando a chave de condição aws:PrincipalTag para diferenciar ações de agentes:

    {
      "Version": "2012-10-17",
      "Statement": [{
        "Sid": "AllowS3ReadOperations",
        "Effect": "Allow",
        "Action": [
          "s3:GetObject",
          "s3:ListBucket"
        ],
        "Resource": "*"
      }, {
        "Sid": "DenyDeleteWhenAccessedViaAI",
        "Effect": "Deny",
        "Action": [
          "s3:DeleteObject",
          "s3:DeleteBucket"
        ],
        "Resource": "*",
        "Condition": {
          "StringEquals": {
            "aws:PrincipalTag/AccessType": "AI"
          }
        }
      }]
    }

    Monitoramento através de CloudTrail

    Ambos os mecanismos de diferenciação geram logs no AWS CloudTrail. Para servidores gerenciados, chamadas originadas de MCP aparecem com identificadores de serviço MCP nos campos da solicitação. Para servidores auto-gerenciados, as tags de sessão aparecem no campo requestParameters.principalTags do evento AssumeRole.

    Com esses logs, você pode consultar CloudTrail para encontrar todas as ações orientadas por IA e analisar padrões de comportamento do agente. Configure alarmes para detectar ações de agentes em recursos sensíveis ou padrões incomuns.

    Considerações Importantes

    Quando agentes usam ferramentas de propósito geral como bash ou shell para executar comandos AWS CLI ou scripts Python, a solicitação vai direto para AWS, contornando completamente os servidores MCP. Nestes casos, as chaves de contexto de diferenciação não são aplicadas.

    Os controles de diferenciação garantem o caminho de acesso MCP. Para caminhos de acesso direto, os princípios 1 e 2 são seus controles primários. Se o papel não tem permissão s3:DeleteObject, o agente não pode deletar objetos, independentemente do caminho.

    Você pode usar frameworks de agentes e ambientes de hospedagem para limitar quais ferramentas um agente pode acessar, removendo capacidades de execução de propósito geral para agentes que interagem com AWS exclusivamente através de servidores MCP.

    Síntese Prática

    Comece com o Princípio 1: audite as permissões atuais do agente e padrão para acesso somente leitura quando possível. Em seguida, implemente o Princípio 2 estabelecendo limites de permissão e selecionando papéis específicos para agentes. Finalmente, adicione diferenciação do Princípio 3 baseada no tipo de seu servidor MCP.

    Para servidores gerenciados pela AWS, use as chaves de contexto automáticas em suas políticas IAM. Para servidores auto-gerenciados, configure tags de sessão e refira-se a elas em suas políticas.

    Fonte

    Secure AI agent access patterns to AWS resources using Model Context Protocol (https://aws.amazon.com/blogs/security/secure-ai-agent-access-patterns-to-aws-resources-using-model-context-protocol/)

  • AWS Transform agora está disponível no Kiro e VS Code

    AWS Transform chega a novos ambientes de desenvolvimento

    A AWS anunciou a disponibilidade do AWS Transform através de duas ferramentas adicionais para desenvolvedores: Kiro e VS Code. Esse movimento representa uma estratégia de trazer capacidades de migração e modernização diretamente para os ambientes onde os times já trabalham, eliminando a necessidade de mudar de contexto ou trocar de plataforma.

    O serviço foi concebido como uma “fábrica agentic” de migração e modernização, desenhada para comprimir cronogramas de transformação empresarial — reduzindo períodos que historicamente duravam anos para apenas meses. A proposta é eliminar problemas comuns em programas de grande escala, como transferências manuais de contexto e interrupções que costumam paralisar esses projetos.

    Transformações customizadas ao alcance dos desenvolvedores

    Com este lançamento, profissionais podem começar a trabalhar com transformações customizadas do AWS Transform diretamente de onde já atuam. Basta instalar o AWS Transform Power no Kiro ou a extensão do AWS Transform no VS Code.

    As transformações customizadas permitem atacar débito técnico em escala. A AWS oferece transformações gerenciadas para padrões comuns, como atualizações de versão em Java, Python e Node.js, além de migrações de SDK da AWS (de boto2 para boto3, Java SDK v1 para v2, e JS SDK v2 para v3). Equipes também podem definir suas próprias transformações personalizadas conforme necessário.

    Flexibilidade e integração entre ferramentas

    Essas novas interfaces tornam mais fácil descobrir capacidades adicionais à medida que ficam disponíveis, construir e iterar sobre transformações customizadas, e executar qualquer agente repetidamente ou across thousands of repositories de uma vez. As transformações customizadas são o primeiro elemento de uma biblioteca em crescimento de playbooks que chegarão às ferramentas de desenvolvimento.

    O desenho complementa o console web e a interface de linha de comando (CLI) já existentes do AWS Transform. Isso permite que desenvolvedores iniciem um job na IDE (Integrated Development Environment), acompanhem o progresso no console web, e finalizem transformações onde fizer mais sentido — com estado do job e contexto compartilhados entre todas as superfícies.

    Disponibilidade regional

    O AWS Transform oferece suporte para implantação em todas as regiões comerciais da AWS. As transformações customizadas estão disponíveis em US East (N. Virginia) e Europe (Frankfurt).

    Para obter mais detalhes técnicos e começar a usar o serviço, acesse a página do produto e o guia do usuário do AWS Transform.

    Fonte

    AWS Transform is now available in Kiro and VS Code (https://aws.amazon.com/about-aws/whats-new/2026/04/aws-transform-kiro-vscode/)

  • Implantações Otimizadas por Caso de Uso no SageMaker JumpStart

    Acesso Rápido a Modelos Pré-treinados para IA

    O Amazon SageMaker JumpStart oferece uma biblioteca de modelos pré-treinados que abrangem diversos tipos de problemas, facilitando o início de projetos de inteligência artificial. A plataforma disponibiliza soluções para os principais casos de uso, que podem ser implantadas em endpoints de Inferência Gerenciada do SageMaker AI ou em clusters SageMaker HyperPod. Com opções de implantação pré-configuradas, os usuários conseguem transitar rapidamente da seleção do modelo até sua colocação em produção.

    O Desafio das Implantações Genéricas

    As implantações através do SageMaker JumpStart sempre foram rápidas e diretas. Os clientes podiam selecionar opções baseadas no número esperado de usuários simultâneos, mantendo visibilidade sobre métricas como latência P50, tempo até o primeiro token (TTFT) e vazão (tokens por segundo por usuário).

    Porém, as opções de configuração de usuários simultâneos, embora úteis para cenários genéricos, não levariam em conta as características específicas das tarefas. A AWS reconheceu que clientes utilizam o SageMaker JumpStart para aplicações bastante distintas e especializadas — geração de conteúdo, resumização de textos, sistemas de perguntas e respostas, entre outras. Cada uma dessas aplicações demanda configurações particulares para otimizar desempenho.

    Além disso, a definição de “desempenho” vai além da latência. Alguns clientes priorizam vazão, enquanto outros buscam minimizar o custo por token. Essas variações exigiam abordagens de implantação mais granulares e direcionadas.

    Implantações Otimizadas por Caso de Uso

    Respondendo a essas necessidades, a AWS anunciou o lançamento das implantações otimizadas do SageMaker JumpStart. Essa capacidade oferece configurações de implantação pré-definidas, cada uma elaborada especificamente para um caso de uso determinado, resolvendo a demanda por customização clara e direta.

    Os clientes mantêm o mesmo nível de transparência sobre os detalhes de suas implantações propostas, mas agora as configurações são otimizadas para o caso de uso específico e para a restrição de desempenho desejada. Essa abordagem combina facilidade de uso com precisão técnica.

    Preparação para Começar

    Para utilizar as implantações otimizadas do SageMaker JumpStart, são necessários os seguintes pré-requisitos:

    Com esses componentes em lugar, os usuários podem começar a usar as implantações otimizadas imediatamente.

    Iniciando uma Implantação Otimizada

    O processo de configuração é direto. Primeiro, abre-se o SageMaker Studio e acessa-se a seção de Modelos. Em seguida, seleciona-se um dos modelos que suportam implantações otimizadas (listados na próxima seção) e clica-se em “Deploy” no canto superior direito.

    A tela que se abre apresenta uma nova seção expansível denominada “Performance”, que contém as opções para implantações otimizadas. Antes de mais nada, pede-se ao usuário que escolha um caso de uso. Para modelos baseados em texto, esses casos de uso podem variar desde escrita generativa até interações em estilo de chat. Suporte para imagem e vídeo virá com futuras atualizações.

    Fonte: Aws

    Após selecionar o caso de uso, o usuário precisa escolher uma das três otimizações de restrição: Otimizado para Custo, Otimizado para Vazão e Otimizado para Latência. Existe também uma opção Balanceada para quem busca o melhor desempenho médio entre todas as métricas registradas.

    Uma vez selecionada, uma configuração de implantação pré-definida é gerada para o endpoint. Os usuários podem revisar e ajustar valores adicionais como timeouts, nomenclatura do endpoint e configurações de segurança. Após completar a configuração, basta clicar em “Deploy” no canto inferior direito para finalizar.

    Modelos Disponíveis para Implantação Otimizada

    As implantações otimizadas do SageMaker JumpStart estão disponíveis para o seguinte conjunto de modelos:

    Modelos Meta Llama

    • Llama-3.1-8B-Instruct
    • Llama-2-7b-hf
    • Llama-3.2-3B
    • Meta-Llama-3-8B
    • Llama-3.2-1B-Instruct
    • Llama-3.2-1B
    • Llama-3.1-70B-Instruct
    • Llama-3.2-3B-Instruct
    • Meta-Llama-3-8B

    Modelos Microsoft Phi

    • Phi-3-mini-4k-instruct

    Modelos Mistral AI

    • Mistral-7B-Instruct-v0.2
    • Mistral-Small-24B-Instruct-2501
    • Mistral-7B-v0.1
    • Mistral-7B-Instruct-v0.3
    • Mixtral-8x7B-Instruct-v0.1

    Modelos Qwen

    • Qwen3-8B
    • Qwen3-32B
    • Qwen3-0.6B
    • Qwen2.5-7B-Instruct
    • Qwen2.5-72B-Instruct
    • Qwen2-VL-7B-Instruct
    • Qwen2-1.5B-Instruct

    Modelos Google Gemma

    • gemma-7b
    • gemma-7b-it
    • gemma-2b

    Outros Modelos

    • Tiiuae Falcon3-1B-Instruct

    Esses modelos formam o lançamento inicial das implantações otimizadas, e a AWS está expandindo ativamente o suporte para incluir modelos adicionais.

    Próximos Passos

    Usuários interessados podem começar a trabalhar com as implantações otimizadas do SageMaker JumpStart imediatamente. Basta selecionar um dos modelos de implantação otimizada disponíveis no hub de modelos do SageMaker Studio, explorar as diferentes opções de configuração e determinar qual delas melhor se adequa à aplicação em questão. A capacidade de ajustar a implantação ao caso de uso específico promete facilitar significativamente a colocação de modelos de linguagem em produção.

    Fonte

    Use-case based deployments on SageMaker JumpStart (https://aws.amazon.com/blogs/machine-learning/use-case-based-deployments-on-sagemaker-jumpstart/)

  • Boas práticas para executar inferência no Amazon SageMaker HyperPod

    Introdução

    Implantar e escalar modelos de fundação para inferência de IA generativa apresenta desafios significativos para as organizações. Equipes frequentemente enfrentam dificuldades com configuração complexa de infraestrutura, padrões de tráfego imprevisíveis que levam ao excesso de provisionamento ou gargalos de desempenho, e overhead operacional ao gerenciar recursos de GPU de forma eficiente. Esses pontos críticos resultam em atraso no time-to-market, desempenho subótimo dos modelos e custos inflados que podem comprometer a viabilidade de iniciativas de IA em escala.

    O Amazon SageMaker HyperPod oferece uma solução abrangente para esses desafios, fornecendo uma plataforma dedicada para cargas de trabalho de inferência. O serviço integra escalabilidade dinâmica, implantação simplificada e gerenciamento inteligente de recursos. As organizações que adotam essas práticas recomendadas podem reduzir o custo total de propriedade em até 40% enquanto aceleram a implantação de IA generativa da concepção à produção.

    Criação de cluster com um clique

    O HyperPod simplifica significativamente o processo de criação de infraestrutura. Para criar um cluster HyperPod com orquestração via Amazon Elastic Kubernetes Service (Amazon EKS), acesse o console da Amazon SageMaker AI e navegue até a página de gerenciamento de clusters.

    O processo ocorre em etapas bem definidas:

    • Passo 1: Selecione a opção “Criar cluster HyperPod” e escolha o modelo “Orquestrado pelo Amazon EKS”.
    • Passo 2: Escolha entre configuração rápida ou personalizada. A configuração rápida cria recursos padrão, enquanto a personalizada permite integração com recursos existentes ou customização conforme necessidades específicas.
    • Passo 3: Configure controladores Kubernetes e complementos (add-ons) conforme seu caso de uso, habilitando ou desabilitando cada um de acordo com os requisitos.
    • Passo 4: Revise a arquitetura de alto nível que mostra como o SageMaker HyperPod funciona com o plano de controle do orquestrador Amazon EKS.
    Arquitetura de alto nível do SageMaker HyperPod — fonte: Aws

    Opções de implantação

    O Amazon SageMaker HyperPod agora oferece uma plataforma de inferência abrangente que combina a flexibilidade do Kubernetes com serviços gerenciados da AWS. A solução permite implantar, escalar e otimizar modelos de aprendizado de máquina com confiabilidade de produção em todo seu ciclo de vida.

    A plataforma fornece interfaces de implantação flexíveis, dimensionamento automático avançado e recursos abrangentes de monitoramento. Utilizando o operador de implantação de inferência, é possível implantar modelos a partir de buckets do S3, FSx para Lustre e JumpStart sem escrever código.

    • Implantação a partir do SageMaker JumpStart: Acesse exemplos de código e notebooks de amostra para começar rapidamente.
    • Implantação de modelos personalizados ou ajustados do S3: Use notebooks de amostra para guiar o processo de implantação.
    • Implantação a partir do FSx Lustre: Consulte os notebooks de amostra para otimizar o desempenho com armazenamento em alta velocidade.

    Escalabilidade automática com KEDA e Karpenter

    O Amazon SageMaker HyperPod oferece uma arquitetura de escalabilidade automática que combina KEDA (Kubernetes Event-Driven Autoscaling — Escalabilidade Automática Acionada por Eventos no Kubernetes) para escalabilidade em nível de pod e Karpenter para escalabilidade em nível de nó. Essa abordagem em duas camadas ativa uma infraestrutura dinâmica e eficiente em custos que se expande de zero para cargas de trabalho em produção conforme a demanda em tempo real.

    Arquitetura de escalabilidade automática com KEDA e Karpenter — fonte: Aws

    Escalabilidade em nível de pod com KEDA

    KEDA é um projeto de código aberto da Cloud Native Computing Foundation (CNCF) que estende o Kubernetes com recursos de escalabilidade automática acionados por eventos. O KEDA é instalado automaticamente como parte do operador de inferência do HyperPod, fornecendo escalabilidade automática de pods pronta para uso sem necessidade de instalação ou configuração separada.

    Ele escala o número de pods de inferência baseado em métricas como comprimento da fila de requisições, métricas do Amazon CloudWatch (como invocações de endpoint do SageMaker), latência ou métricas customizadas do Prometheus. O KEDA pode escalar implantações para zero pods quando não há tráfego, eliminando custos durante períodos de inatividade.

    Escalabilidade em nível de nó com Karpenter

    Karpenter é um escalonador automático de cluster Kubernetes que provisiona ou remove nós de computação baseado em requisitos de pods pendentes. Ele funciona no plano de controle do Amazon EKS, o que significa que não há custos computacionais adicionais para executar o escalonador. Essa implantação no plano de controle gerenciado permite verdadeiras capacidades de escalabilidade para zero.

    Quando o KEDA reduz pods para zero devido à falta de tráfego, o Karpenter pode remover todos os nós de trabalho, garantindo que você não incorra em custos de infraestrutura durante períodos de inatividade.

    Integração entre KEDA e Karpenter

    A integração entre KEDA e Karpenter cria uma experiência de escalabilidade automática eficiente. O Coletor ADOT (AWS Distro for OpenTelemetry — Distribuição AWS para OpenTelemetry) coleta métricas de pods de inferência e as envia para Amazon Managed Service para Prometheus ou CloudWatch, que o operador KEDA (instalado com o operador de inferência) consulta periodicamente e avalia em relação aos limites de gatilho configurados em seu YAML de JumpStartModel ou InferenceEndpointConfig.

    Quando as métricas excedem os limites, o KEDA dispara o Horizontal Pod Autoscaler (HPA) para criar novos pods de inferência. Se esses pods permanecerem pendentes devido à capacidade insuficiente de nós, o Karpenter (executando no plano de controle) detecta essa situação e provisiona novos nós com os tipos de instância e configurações de GPU apropriadas. O agendador do Kubernetes então implanta os pods pendentes nos nós recém-provisionados, distribuindo o tráfego de inferência pela infraestrutura escalada.

    Quando a demanda diminui, o KEDA reduz os pods com base nas mesmas métricas. O Karpenter consolida cargas de trabalho e remove nós subutilizados para reduzir custos de infraestrutura. Durante períodos sem tráfego, o KEDA pode reduzir para zero pods e o Karpenter remove todos os nós de trabalho, resultando em zero custos computacionais enquanto mantém a capacidade de escalar rapidamente quando o tráfego retoma. Essa arquitetura garante que você pague apenas pelos recursos computacionais enquanto servem ativamente requisições de inferência, sem custos adicionais para a infraestrutura de escalabilidade automática, já que o Karpenter funciona no plano de controle gerenciado.

    Habilitando o Karpenter

    Para habilitar a escalabilidade automática, verifique se a função de execução do cluster HyperPod possui as seguintes políticas: sagemaker:BatchAddClusterNodes, sagemaker:BatchDeleteClusterNodes e sagemaker:BatchPutMetrics nos recursos apropriados.

    Execute o seguinte comando:

    aws sagemaker update-cluster --cluster-name 'ml-cluster' --auto-scaling '{ "Mode": "Enable", "AutoScalerType": "Karpenter" }' --cluster-role 'arn:aws:iam::XXXXXXXXXXXX:role/sagemaker-ml-cluster-e3cb1e31ExecRole' --region us-east-1

    Após executar este comando, você receberá uma resposta de sucesso com o ARN do cluster. Para verificar se o Karpenter foi habilitado, execute a API DescribeCluster:

    aws sagemaker describe-cluster --cluster-name ml-cluster --query AutoScaling --region us-east-1

    A resposta confirmará que o modo está habilitado e o tipo de escalonador automático é Karpenter.

    Cache KV em camadas e roteamento inteligente

    O Amazon SageMaker HyperPod agora oferece suporte a cache KV (pares chave-valor) gerenciado em camadas e roteamento inteligente para otimizar o desempenho da inferência de modelos de linguagem grande (LLM), particularmente para prompts de contexto longo e conversas multi-volta.

    Roteamento inteligente e cache KV em camadas — fonte: Aws

    Cache KV gerenciado em camadas

    O recurso de cache KV gerenciado em camadas aborda restrições de memória durante a inferência implementando uma estratégia de cache multi-camada. O cache de pares chave-valor é essencial para a eficiência da inferência em LLM. Ele armazena computações de atenção intermediárias de tokens anteriores, evitando recálculos redundantes e reduzindo significativamente a latência. Ao gerenciar cache em múltiplas camadas de armazenamento, o HyperPod viabiliza:

    • Redução da pressão de memória nos recursos de GPU
    • Suporte a janelas de contexto mais longas sem degradação de desempenho
    • Gerenciamento automático de cache sem intervenção manual

    Roteamento inteligente

    O roteamento inteligente otimiza a inferência direcionando requisições com prefixos de prompt compartilhados para a mesma instância de inferência, maximizando a reutilização do cache KV. Essa abordagem:

    • Roteia requisições estrategicamente para instâncias que já processaram prefixos similares
    • Acelera o processamento reutilizando dados de KV em cache
    • Reduz latência para conversas multi-volta e requisições em lote com contextos comuns

    Benefícios de desempenho

    Juntos, esses recursos oferecem melhorias substanciais:

    • Até 40% de redução em latência para requisições de inferência
    • 25% de melhoria em throughput no processamento de requisições
    • 25% de economia de custos em comparação com configurações baseline sem essas otimizações

    Esses recursos estão disponíveis através do operador de inferência do HyperPod, fornecendo capacidades gerenciadas prontas para uso para implantações de LLM em produção. Para mais detalhes sobre esse recurso, consulte Cache KV em camadas gerenciado e roteamento inteligente para Amazon SageMaker HyperPod.

    Suporte a GPU com Multi-Instance GPU (MIG)

    O SageMaker HyperPod Inference agora oferece suporte a implantações de modelos em aceleradores que foram particionados usando a tecnologia NVIDIA Multi Instance GPU (MIG). Implantar modelos pequenos em GPUs grandes pode desperdiçar recursos. Para resolver isso, o SageMaker HyperPod permite usar uma fração de GPUs que funcionam isoladamente uma da outra.

    Se a GPU já foi particionada, é possível implantar diretamente o JumpStartModel ou InferenceEndpointConfig usando a solução SageMaker HyperPod Inference.

    Para JumpStartModels, use spec.server.acceleratorPartitionType para definir o perfil MIG de sua escolha:

    apiVersion: inference.sagemaker.aws.amazon.com/v1
    kind: JumpStartModel
    metadata:
      name: deepseek
    spec:
      sageMakerEndpoint:
        name: deepseek
      model:
        modelHubName: SageMakerPublicHub
        modelId: deepseek-llm-r1-distill-qwen-1-5b
      server:
        acceleratorPartitionType: mig-7g.40gb
        instanceType: ml.p4d.24xlarge

    O JumpStartModel também conduz validação interna antes da implantação do modelo. É possível desativar essa validação usando o campo spec.server.validations.acceleratorPartitionValidation no YAML e configurando-o como false.

    Para InferenceEndpointConfig, implante o modelo no perfil MIG de sua escolha usando os campos spec.worker.resources.requests e spec.worker.resources.limits:

    apiVersion: inference.sagemaker.aws.amazon.com/v1
    kind: InferenceEndpointConfig
    ....
    spec:
      worker:
        resources:
          requests:
            cpu: 5600m
            memory: 10Gi
            nvidia.com/mig-4g.71gb: 1
          limits:
            nvidia.com/mig-4g.71gb: 1

    Com essas configurações, é possível usar outras tecnologias suportadas pelo SageMaker HyperPod Inference juntamente com a implantação do modelo em MIG. Para informações adicionais, consulte HyperPod agora oferece suporte a GPU Multi-Instance para maximizar utilização de GPU para tarefas de IA generativa.

    Observabilidade

    É possível monitorar métricas do HyperPod Inference através dos recursos de observabilidade do SageMaker HyperPod. Para habilitar esses recursos, siga as instruções em Acelere desenvolvimento de modelos de fundação com observabilidade com um clique no Amazon SageMaker HyperPod.

    A observabilidade do HyperPod fornece dashboards integrados no Grafana. Por exemplo, o dashboard de Inferência oferece visibilidade em métricas relacionadas à inferência como Taxa de Requisições Recebidas, Latência e Tempo até Primeiro Byte (TTFB).

    Dashboard Grafana de monitoramento — fonte: Aws

    Executar notebooks em clusters HyperPod

    Clusters HyperPod com orquestração Amazon EKS agora oferecem suporte à criação e gerenciamento de ambientes de desenvolvimento interativos como JupyterLab e Visual Studio Code de código aberto, simplificando o ciclo de vida de desenvolvimento de ML ao fornecer ambientes gerenciados para ferramentas familiares aos cientistas de dados.

    Esse recurso introduz um novo complemento chamado Amazon SageMaker Spaces que permite aos desenvolvedores de IA criar e gerenciar ambientes autocontidos para executar notebooks. Agora é possível maximizar investimentos em GPU executando tanto cargas de trabalho interativas quanto seus trabalhos de treinamento na mesma infraestrutura, com suporte a alocações fracionais de GPU para melhorar eficiência de custos.

    Arquitetura de notebook Jupyter em cluster HyperPod — fonte: Aws

    A AWS está introduzindo uma nova capacidade para clusters do SageMaker HyperPod EKS que permite aos desenvolvedores de IA executar cargas de trabalho interativas de aprendizado de máquina diretamente no cluster HyperPod EKS. Esse recurso apresenta um novo complemento chamado Amazon SageMaker Spaces que possibilita aos desenvolvedores de IA criar e gerenciar ambientes autocontidos para execução de notebooks.

    Conclusão

    O Amazon SageMaker HyperPod oferece uma infraestrutura escalável e eficiente em custos para executar cargas de trabalho de inferência. Seguindo as práticas recomendadas apresentadas neste artigo, é possível utilizar as capacidades do HyperPod para implantar modelos de fundação usando integração com JumpStart em um clique, S3 e FSx para Lustre, escalabilidade automática gerenciada com Karpenter e infraestrutura unificada que se expande dinamicamente de zero para produção.

    Com recursos como cache KV, roteamento inteligente e suporte a GPU Multi-Instance, é possível otimizar cargas de trabalho de inferência, reduzindo latência, aumentando throughput e diminuindo custos usando Spot Instances. Ao adotar essas práticas recomendadas, as organizações podem acelerar fluxos de trabalho de aprendizado de máquina, melhorar desempenho de modelos e atingir reduções significativas no custo total de propriedade, permitindo escalar IA generativa de forma responsável e eficiente em ambientes de produção.

    Fonte

    Best practices to run inference on Amazon SageMaker HyperPod (https://aws.amazon.com/blogs/machine-learning/best-practices-to-run-inference-on-amazon-sagemaker-hyperpod/)

  • Aurora DSQL apresenta conector que simplifica o desenvolvimento de aplicações PHP

    Um novo conector simplifica aplicações PHP na Aurora DSQL

    A AWS anunciou o lançamento do Conector Aurora DSQL para PHP (PDO_PGSQL), uma solução pensada para facilitar a construção de aplicações PHP que rodem sobre o Aurora DSQL. Este novo conectar representa um avanço significativo na forma como desenvolvedores brasileiros podem integrar suas aplicações ao banco de dados relacional distribuído da Amazon.

    Autenticação simplificada e segura

    Um dos destaques do novo conectar é a forma como ele revoluciona o modelo de autenticação. Ao invés de trabalhar com senhas tradicionais geradas manualmente (uma prática que traz riscos de segurança), o conector gera tokens automaticamente a cada conexão. Isso garante que tokens válidos estejam sempre em uso, eliminando vulnerabilidades associadas ao gerenciamento manual de credenciais.

    A implementação mantém compatibilidade total com os recursos existentes do PDO_PGSQL, permitindo que desenvolvedores façam transição suave sem precisar reescrever seus códigos.

    Capacidades principais do conector

    O conectar Aurora DSQL para PHP gerencia automaticamente aspectos técnicos complexos da conexão, como geração de tokens Identify and Access Management (IAM), configuração de Secure Sockets Layer (SSL) e pooling de conexões. Com essas funcionalidades consolidadas, desenvolvedores podem escalar suas aplicações de forma linear — começando com scripts simples e evoluindo para cargas de trabalho em produção, tudo sem alterar a abordagem de autenticação.

    Além disso, o conector oferece:

    • Controle de concorrência otimista (Optimistic Concurrency Control – OCC) com retry automático e backoff exponencial
    • Suporte a provedores de credenciais Identify and Access Management (IAM) personalizados
    • Integração com perfis de credenciais da AWS

    Essas funcionalidades tornam mais simples desenvolver lógica de retry no cliente e gerenciar credenciais da AWS em diferentes cenários de aplicação.

    Como começar

    Desenvolvedores interessados em utilizar o novo conector podem acessar a documentação completa sobre conectores para Aurora DSQL para detalhes técnicos aprofundados. Para aqueles que preferem aprender através de exemplos práticos, está disponível um repositório no GitHub com exemplos do conector PHP.

    A AWS oferece a possibilidade de começar com Aurora DSQL gratuitamente através da Camada Gratuita da AWS, permitindo que desenvolvedores experimentem a solução sem custos iniciais. Para conhecer mais detalhes sobre o Aurora DSQL em geral, consulte a página oficial do serviço.

    Fonte

    Aurora DSQL launches connector that simplifies building PHP applications (https://aws.amazon.com/about-aws/whats-new/2026/04/aurora-dsql-connector-for-php/)

  • Funções de Recompensa Eficientes com AWS Lambda para Personalização do Amazon Nova

    Personalização inteligente de modelos com funções de recompensa

    Construir funções de recompensa eficazes possibilita a personalização de modelos Amazon Nova conforme necessidades específicas de cada organização. O AWS Lambda oferece a base escalável e econômica para essa tarefa, permitindo que arquitetos se concentrem na definição de critérios de qualidade enquanto a infraestrutura computacional é gerenciada automaticamente.

    A AWS disponibiliza múltiplas abordagens de personalização. O ajuste fino com reforço (RFT) destaca-se pela capacidade de ensinar ao modelo comportamentos desejados através de feedback iterativo. Diferentemente do ajuste fino supervisionado (SFT), que requer milhares de exemplos rotulados com caminhos de raciocínio anotados, o RFT aprende a partir de sinais de avaliação nas respostas finais.

    No coração do RFT encontra-se a função de recompensa — um mecanismo de pontuação que guia o modelo em direção a respostas melhores. Este conceito central permite que os modelos aprendam quais comportamentos devem ser reforçados e quais devem ser evitados, sem necessidade de exemplos exaustivos de raciocínios corretos.

    Comparando Abordagens de Aprendizado por Reforço

    Quando usar Aprendizado Supervisionado (SFT)

    O ajuste fino supervisionado funciona bem quando a organização possui exemplos claros de entrada e saída, e deseja ensinar padrões de resposta específicos. É particularmente eficaz para tarefas como classificação, reconhecimento de entidades nomeadas, ou adaptação de modelos a terminologia e convenções de formatação específicas do domínio.

    Este método produz bons resultados quando o comportamento desejado pode ser demonstrado através de exemplos, tornando-o ideal para ensinar estilo consistente, estrutura ou transferência de conhecimento factual.

    Quando usar Aprendizado por Reforço (RFT)

    Alguns desafios de personalização requerem uma abordagem diferente. Quando aplicações precisam que modelos equilibrem múltiplas dimensões de qualidade simultaneamente — como respostas de atendimento ao cliente que devem ser precisas, empáticas, concisas e alinhadas à marca ao mesmo tempo — ou quando criar milhares de caminhos de raciocínio anotados se torna impraticável, métodos baseados em reforço oferecem uma alternativa melhor.

    O RFT aborda esses cenários aprendendo a partir de sinais de avaliação em vez de requerer demonstrações rotuladas exaustivas de processos de raciocínio corretos. Funções de recompensa baseadas em Lambda simplificam essa implementação. Ao invés de mostrar ao modelo milhares de exemplos eficazes, a organização fornece prompts e define lógica de avaliação que pontua respostas — então o modelo aprende a melhorar através de feedback iterativo.

    Esta abordagem requer menos exemplos rotulados enquanto oferece controle preciso sobre comportamentos desejados. Pontuação multidimensional captura critérios de qualidade nuançados que impedem modelos de explorar atalhos, enquanto a arquitetura serverless do Lambda gerencia cargas de trabalho de treinamento variáveis sem gerenciamento de infraestrutura.

    Arquitetura de Funções de Recompensa com Lambda

    O RFT utiliza AWS Lambda como um avaliador de recompensa serverless que se integra ao pipeline de treinamento do Amazon Nova, criando um loop de feedback que guia o aprendizado do modelo. O processo começa quando o trabalho de treinamento gera respostas candidatas do modelo Nova para cada prompt de treinamento.

    Essas respostas fluem para a função Lambda, que avalia sua qualidade através de dimensões como correção, segurança, formatação e concisão. A função retorna então pontuações numéricas escalares — típicamente na faixa de -1 a 1 como melhor prática.

    Pontuações mais altas guiam o modelo a reforçar os comportamentos que as produziram, enquanto pontuações mais baixas o guiam para longe de padrões que levaram a respostas pobres. Este ciclo se repete milhares de vezes durante o treinamento, moldando progressivamente o modelo para respostas que consistentemente ganham recompensas mais altas.

    Componentes da Arquitetura

    A arquitetura reúne vários serviços AWS em uma solução coesa. Lambda executa a lógica de avaliação de recompensa com escalabilidade automática que gerencia demandas variáveis de treinamento sem exigir provisionamento ou gerenciamento de infraestrutura. Amazon SageMaker AI oferece opções através de Trabalhos de Treinamento do SageMaker AI e HyperPod do SageMaker AI, ambos suportando as mesmas funções de recompensa baseadas em Lambda.

    Amazon CloudWatch monitora o desempenho de Lambda em tempo real, registra informações detalhadas de depuração sobre distribuições de recompensa e progresso de treinamento, e dispara alertas quando problemas surgem. No fundamento encontra-se o Amazon Nova — modelos com receitas de personalização otimizadas que respondem efetivamente aos sinais de feedback que as funções de recompensa fornecem.

    Escolhendo o Mecanismo de Recompensa Adequado

    O fundamento do RFT bem-sucedido é escolher o mecanismo de feedback adequado. Aprendizado por Reforço via Recompensas Verificáveis (RLVR) e Aprendizado por Reforço via Feedback de IA (RLAIF) são duas técnicas utilizadas para ajuste fino de modelos de linguagem grande após seu treinamento inicial. Sua maior diferença está em como fornecem feedback ao modelo.

    RLVR — Recompensas Verificáveis

    RLVR usa código determinístico para verificar correção objetiva. É projetado para domínios onde uma resposta “correta” pode ser verificada matematicamente ou logicamente — por exemplo, resolver um problema de matemática. Esta abordagem usa funções determinísticas para atribuir pontuações em vez de um modelo de recompensa aprendido.

    RLVR falha para tarefas como escrita criativa ou voz de marca onde nenhuma verdade absoluta existe. É ideal para: geração de código, raciocínio matemático, tarefas de saída estruturada. Exemplos incluem executar código gerado contra casos de teste, validar respostas da API, verificar precisão de cálculos.

    A vantagem está na pontuação confiável, auditável e determinística. Funções RLVR verificam programaticamente a correção contra a verdade absoluta. Um exemplo prático implementa análise de sentimento verificável através de extração determinística de respostas e comparação com valores de referência.

    RLAIF — Avaliação com IA

    RLAIF usa modelos de IA como juízes para avaliação subjetiva. Alcança desempenho comparável ao aprendizado por reforço com feedback humano enquanto é significativamente mais rápido e menos custoso. É ideal para: escrita criativa, sumarização, alinhamento de voz de marca, utilidade. Exemplos incluem avaliar tom de resposta, avaliar qualidade de conteúdo, julgar alinhamento de intenção do usuário.

    A vantagem é julgamento escalável semelhante ao humano sem custos de rotulação manual. Funções RLAIF delegam julgamento a modelos de IA capazes como um “juiz de linguagem”. Nesta implementação, um modelo disponibilizado via Bedrock atua como juiz comparando respostas e retornando pontuações numéricas.

    Implementando Funções de Recompensa Robustas

    Princípios de Design Essenciais

    Ao escrever funções de recompensa para RFT, comece simples. Crie uma paisagem de recompensa suave — não binária com apenas acerto ou erro. Ao invés de simples passar/falhar (0 ou 1), use sinais de recompensa suave e densos que forneçam crédito parcial por estar “no caminho certo”.

    Este feedback granular ajuda o modelo a aprender a partir de melhorias incrementais em vez de esperar por uma resposta perfeita. Para tarefas complexas e multi-etapa, forneça recompensas para progresso intermediário (moldagem) em vez de apenas o resultado final (escasso).

    Saiba exatamente qual é o aspecto do sucesso. Implemente múltiplas estratégias de análise que lidam graciosamente com vários formatos de resposta. Valide entradas a cada passo usando práticas de código defensivo que previnem travamentos de entradas malformadas.

    Evitando Exploração de Recompensas

    Uma única pontuação escalar é facilmente explorada. A recompensa deve avaliar o desempenho do modelo em múltiplas dimensões: correção, fidelidade à entrada, alinhamento com políticas de segurança, formatação e concisão. Garanta que o modelo não possa obter altas recompensas através de atalhos — por exemplo, palpites de sorte ou ações repetitivas.

    Para tarefas objetivas como geração de código ou matemática, use avaliadores automatizados que executem o código ou analisem tags de resposta específicas para verificar correção sem humano no loop. Quando código programático não consegue julgar a resposta — como em sumarização — use um modelo separado e capaz como um “juiz de linguagem”.

    Otimização em Escala de Treinamento

    Configuração de Lambda para Performance

    Uma vez que a função de recompensa funciona corretamente, otimização ajuda a treinar mais rápido enquanto controla custos. Técnicas de otimização combinam seu impacto — uma função Lambda bem-configurada com dimensionamento apropriado de lotes, configurações de concorrência, mitigação de inicialização fria e tratamento de erros pode avaliar respostas dez vezes mais rápido que uma implementação ingênua enquanto custa significativamente menos e fornece melhor confiabilidade de treinamento.

    Defina timeout para 60 segundos (padrão é apenas 3 segundos) fornecendo espaço livre para chamadas de juiz RLAIF ou lógica RLVR complexa. Configure memória para 512 MB (padrão é 128 MB) — CPU acelerada melhora desempenho de tempo de resposta.

    Mitigação de Inicialização Fria

    A inicialização fria evita picos de latência que podem desacelerar treinamento e aumentar custos. Mantenha pacotes de implantação abaixo de 50MB para minimizar tempo de inicialização — frequentemente significa excluir dependências desnecessárias e usar camadas Lambda para bibliotecas compartilhadas grandes.

    Reutilize conexões entre invocações inicializando clientes como o cliente runtime de Bedrock em escopo global ao invés de dentro da função manipuladora, permitindo que o ambiente de execução de Lambda mantenha essas conexões entre invocações. Perfil da função usando Lambda Insights para identificar gargalos de performance.

    Armazene em cache dados frequentemente acessados como rubrica de avaliação, regras de validação ou parâmetros de configuração em escopo global para que Lambda os carregue uma vez por container ao invés de em cada invocação. Este padrão de inicialização global com execução em nível de manipulador prova ser particularmente eficaz para funções Lambda lidando com milhares de avaliações durante treinamento.

    Gerenciamento de Dependências

    As dependências podem ser incluídas diretamente com código em um pacote de implantação (arquivo .zip) ou utilizar camadas Lambda para gerenciar dependências separadamente da lógica principal. Use camadas para dependências compartilhadas entre múltiplas funções e pacotes de implantação para lógica específica da função.

    Para implementações RLAIF, o papel de execução da função Lambda deve ter acesso a Bedrock para chamadas de API de LLM. Seguindo o princípio de menor privilégio, escope a ARN de Resource para o modelo de fundação específico que está sendo usado como juiz em vez de usar um curinga.

    Monitoramento e Depuração com CloudWatch

    Visibilidade no processo de treinamento é essencial tanto para monitorar progresso quanto para troubleshooting de problemas. Informações abrangentes são automaticamente registradas em CloudWatch para cada estágio do pipeline de treinamento: métricas de cada etapa de treinamento — incluindo pontuações de recompensa por etapa e traces de execução detalhadas para cada componente do pipeline.

    Este registro granular torna direto rastrear progresso de treinamento em tempo real, verificar que a função de recompensa está pontuando respostas conforme esperado, e rapidamente diagnosticar problemas quando surgem. Se o treinamento não estiver melhorando, pode-se examinar as distribuições de recompensa em CloudWatch para ver se a função está retornando principalmente zeros ou se há sinal insuficiente.

    Consultas Amazon CloudWatch Insights úteis incluem: encontrar amostras com recompensas zero, calcular distribuição de recompensas em faixas, identificar avaliações lentas acima de limiares de tempo, e rastrear métricas multidimensionais como correção, formatação, segurança e concisão ao longo do tempo.

    Começando com a Implementação

    A abordagem de funções de recompensa baseadas em Lambda desbloqueiam personalização de Amazon Nova para organizações que precisam de controle comportamental preciso sem datasets massivos rotulados. Isto entrega vantagens significativas através de flexibilidade, escalabilidade e custo-efetividade que simplificam o processo de personalização do modelo.

    A arquitetura permite RLVR para lidar com tarefas de verificação objetiva enquanto RLAIF auxilia com julgamento subjetivo para avaliações de qualidade nuançadas. Organizações podem usá-las individualmente ou combiná-las para avaliação abrangente que capture tanto precisão factual quanto preferências estilísticas.

    Escalabilidade emerge naturalmente da fundação serverless, gerenciando automaticamente cargas de trabalho de treinamento variáveis desde experimentação inicial através de personalização em escala de produção. Custo-efetividade flui diretamente deste design — organizações pagam apenas por computação de avaliação real, com trabalhos de treinamento completando mais rápido devido a concorrência otimizada de Lambda e cálculo eficiente de recompensas.

    A combinação de modelos de fundação Amazon Nova, escalabilidade serverless de Lambda, e infraestrutura de personalização gerenciada do Bedrock torna ajuste fino com reforço mais acessível independentemente da escala organizacional. O caminho para começar é experimentar com exemplos de código e iniciar a personalização de modelos Amazon Nova que entregam exatamente os comportamentos que as aplicações necessitam.

    Fonte

    How to build effective reward functions with AWS Lambda for Amazon Nova model customization (https://aws.amazon.com/blogs/machine-learning/how-to-build-effective-reward-functions-with-aws-lambda-for-amazon-nova-model-customization/)

  • CloudTroop Weekly #007 — 2026-w15





    CloudTroop Weekly #007 — 2026-w15

    12 de abril de 2026

    Resumo da Semana

    A semana foi dominada por IA em produção com foco em três frentes: controle de custos, governança e operação de agentes. O Amazon Bedrock ganhou rastreamento de gastos por usuário e função IAM, além de proteções de segurança entre contas em GA — dois recursos que resolvem gaps reais em ambientes multi-time. No lado de observabilidade, CloudWatch Pipelines e OpenSearch avançaram em conformidade e rastreamento de agentes. Para fechar, Lambda com streaming global e Cost Explorer com linguagem natural reduzem fricção operacional. Semana densa para quem opera IA na AWS com seriedade.

    O que muda na prática

    • Custos de IA agora podem ser alocados por usuário e função IAM no Bedrock — times de FinOps finalmente têm visibilidade granular sem gambiarras de tagging manual.
    • Guardrails do Bedrock entre contas entram em GA — controles de segurança de IA podem ser centralizados na conta de gerenciamento e aplicados automaticamente nas contas filhas.
    • Lambda response streaming está disponível globalmente — aplicações de IA generativa e APIs sensíveis à latência podem adotar o recurso em qualquer região sem restrição.

    Ações da semana

    • Ative a alocação de custos por IAM no Bedrock e crie tags de custo por equipe ou projeto — leva menos de uma hora e entrega visibilidade imediata para o próximo ciclo de FinOps.
    • Revise o ciclo de vida dos modelos em uso no Bedrock e mapeie as janelas de deprecação — evite surpresas em produção configurando alertas ou já planejando a migração para versões suportadas.

    Top 10 da Semana

    1

    Amazon Bedrock: alocação de custos por usuário e função IAM

    Permite rastrear e atribuir gastos de IA por equipe, projeto ou aplicação, resolvendo um dos maiores gaps de FinOps em ambientes com múltiplos times usando Bedrock.

    Para quem: Arquitetos de plataforma, FinOps e gestores que precisam controlar custos de IA em organizações multi-time.

    FinOps IA

    2

    Bedrock Guardrails: proteções de segurança entre contas em GA

    Centralizar controles de segurança de IA em toda a organização elimina configurações manuais repetitivas e reduz risco de exposição em contas filhas.

    Para quem: Engenheiros de segurança e arquitetos responsáveis por governança de IA em ambientes multi-conta.

    Segurança IA

    3

    AWS KMS e Encryption SDK: superando limites da criptografia simétrica

    Entender como o KMS deriva chaves automaticamente evita falhas críticas de segurança em aplicações de alta escala que usam AES-GCM.

    Para quem: Engenheiros de segurança e desenvolvedores que implementam criptografia em aplicações com alto volume de operações.

    Criptografia

    4

    CloudWatch Pipelines ganha recursos de conformidade e governança

    Preservar dados originais e rastrear transformações em pipelines de logs é requisito crescente em auditorias e compliance, agora disponível sem custo adicional.

    Para quem: Engenheiros de operações e times de compliance que gerenciam pipelines de observabilidade em ambientes regulados.

    Observabilidade Compliance

    5

    Framework para coleta forense segura em buckets S3

    Automatizar a coleta de artefatos forenses com menor privilégio e credenciais temporárias reduz o tempo de resposta a incidentes e elimina riscos de credenciais expostas.

    Para quem: Times de resposta a incidentes (IR) e engenheiros de segurança que precisam de playbooks forenses na AWS.

    Forense Segurança

    6

    OpenSearch integra Prometheus gerenciado e rastreamento de agentes IA

    Consolidar métricas, logs, traces e rastreamento de agentes de IA em uma única interface reduz complexidade operacional e custos de duplicação de dados.

    Para quem: Engenheiros de plataforma e SREs que gerenciam observabilidade de aplicações e workloads de IA.

    Observabilidade

    7

    Ciclo de vida dos modelos no Amazon Bedrock: guia prático

    Compreender deprecações e janelas de migração de modelos é essencial para evitar interrupções em aplicações de IA em produção.

    Para quem: Desenvolvedores e arquitetos que mantêm aplicações baseadas em modelos de fundação no Bedrock.

    Gestão Modelos IA

    8

    Cost Explorer agora responde perguntas em linguagem natural via Amazon Q

    Democratizar a análise de custos para membros não técnicos da equipe acelera decisões de FinOps sem depender de especialistas em queries.

    Para quem: Gestores de produto, FinOps e qualquer profissional que precise analisar custos AWS sem expertise em ferramentas de billing.

    FinOps

    9

    AWS Lambda: streaming de respostas disponível em todas as regiões

    A disponibilidade global do response streaming reduz latência percebida em aplicações de IA generativa e sistemas web sensíveis ao tempo.

    Para quem: Desenvolvedores serverless que constroem APIs e aplicações de IA com Lambda em qualquer região AWS.

    Serverless

    10

    Verified Permissions: aliases para policy stores e políticas nomeadas

    Aliases eliminam a necessidade de tabelas de mapeamento manual em implementações multi-tenant, simplificando significativamente a gestão de autorização em escala.

    Para quem: Arquitetos de segurança e desenvolvedores que implementam autorização fine-grained em aplicações SaaS multi-tenant.

    Autorização IAM