Esta semana em cloud (06–12/abr): o agente saiu do palco e entrou no plantão

TL;DR: Foi a semana em que o agente autônomo virou produto de prateleira: a AWS levou DevOps Agent e Security Agent a GA, e a Microsoft fechou o Agent Framework 1.0 e o Azure MCP Server 2.0. Mas o trabalho ficou na base: o Kubernetes 1.35 no OKE matou o cgroup v1 e o IPVS, o Karpenter chegou ao OCI, o S3 virou file system e o Valkey 8.1 ganhou vector search. A conta do agente é least-privilege, custo e deprecation.

Teve uma assimetria curiosa nesta semana. No nível do anúncio, tudo foi sobre o agente que age sozinho: a AWS declarou disponibilidade geral dos seus frontier agents, a Microsoft fechou três peças do quebra-cabeça agentic no mesmo ciclo, e até o storage e o cache passaram a se vender como "prontos para IA". No nível da operação, porém, a semana foi sobre o de sempre — só que com a régua mais alta. Quem vai colocar esses agentes em produção passou os mesmos dias mexendo em cgroup, em modo de kube-proxy, em policy de IAM e em camada de cache.

A leitura para quem opera infra no Brasil é direta: o agente saiu do palco e foi para o plantão, mas o plantão não mudou de natureza. Ele continua exigindo base segura, custo sob controle e dívida técnica em dia. O que mudou é que agora um sistema autônomo vai herdar — e amplificar — qualquer atalho que você deixou para trás.

A AWS colocou o agente em GA. E agora, quem assina embaixo?

O recado da semana saiu do roundup da AWS: o AWS DevOps Agent e o AWS Security Agent chegaram à disponibilidade geral. O que no último re:Invent era apresentado como frontier agent — promessa de palco — virou serviço com SLA. O DevOps Agent automatiza investigação e remediação de incidentes, com a AWS falando em redução de até 75% no MTTR; o Security Agent puxa pentesting contínuo para dentro do ciclo de desenvolvimento, no espírito shift-left, prometendo menos falso-positivo e ciclos de teste mais rápidos. No mesmo roundup vieram reforços de plataforma que sustentam esse mundo: ECS Managed Daemons para controlar a execução de agentes no cluster, CloudWatch OTel Container Insights fortalecendo a observabilidade nativa do EKS, e uma nova Sustainability Console.

A Microsoft jogou na mesma direção, só que distribuída em três lançamentos. O Microsoft Agent Framework 1.0 chegou a GA unificando AutoGen e Semantic Kernel sob o pacote Microsoft.Agents.AI — com breaking changes que valem nota para quem tem código em preview, como a renomeação do parâmetro thread para session em RunAsync. O Azure MCP Server 2.0 estabilizou o Model Context Protocol como peça de automação empresarial, com transporte HTTP endurecido, suporte a Managed Identity e fluxo On-Behalf-Of, padronizando 276 ferramentas sobre 57 serviços do Azure. E o Foundry Local entrou em GA levando inferência on-device para Windows, Linux e macOS — rodando modelos das famílias Qwen, DeepSeek e Phi localmente, com compatibilidade de API OpenAI, para fugir do custo per-token e da latência de rede.

O vocabulário é novo; o problema de engenharia, não. Um agente que investiga incidente precisa de permissão para agir — e é aqui que o entusiasmo de GA encontra a realidade. Automatizar remediação sobre um ambiente mal instrumentado e com IAM permissivo é automatizar o erro em velocidade de máquina. O ganho de 75% no MTTR pressupõe que o agente tenha sinal limpo para ler e escopo certo para agir. Quem não fez a lição de casa de observabilidade e menor privilégio não vai colher autonomia: vai colher blast radius.

Quer plugar agentes de DevOps e segurança em produção sem abrir mão de least-privilege e observabilidade? Fale com os especialistas da Nuvem Online.

Enquanto o agente subia ao palco, o Kubernetes consertava o chão

Longe do keynote, a semana foi pesada para quem roda cluster. O Kubernetes 1.35 chegou ao OKE (a comunidade apelidou o release de "Timbernetes"), e o pacote traz tanto conforto quanto armadilha. Do lado bom: resize de Pods sem restart — agora dá para ajustar CPU e memory requests/limits in-place, o que é ouro para workload stateful e FinOps em tempo real —, além do campo managedBy em Jobs e do .metadata.generation para rastrear se o kubelet processou o último spec.

Do lado da armadilha, três itens podem transformar manutenção em incidente. O 1.35 exige cgroup v2: node pool baseado em OL7 simplesmente não sobe, porque o kubelet não inicia — migrar para OL8 ou superior é o item zero de qualquer checklist. O modo IPVS no kube-proxy foi depreciado, com nftables virando a recomendação e o iptables ficando para legado. E o Ingress NGINX, mantido pela comunidade, foi aposentado — manter um controlador em fim de vida na borda do cluster deixou de ser dívida técnica e virou exposição. Soma-se o ciclo acelerado: o suporte ao 1.32 termina 30 dias após o lançamento do 1.35+, então quem deixa para depois acumula upgrades sequenciais sob pressão de SLA.

A boa notícia do mesmo ecossistema é o Karpenter chegando ao OCI em GA. Diferente do Cluster Autoscaler, preso a node pools estáticos e à "fragmentação de capacidade" (instâncias ociosas espalhadas em vários pools só para o scaling não travar), o Karpenter olha os pods pendentes e provisiona just-in-time exatamente o shape necessário. Se um shape falta na OCI, ele salta para a próxima melhor opção sem intervenção humana. A separação entre NodePool (o "o quê" da nuvem) e OciNodeClass (o "como" da infra) é um shift-left real: o time de plataforma governa a classe, o desenvolvedor faz deploy com spec padrão. A recomendação madura é começar por workload não crítico, mantendo o Cluster Autoscaler como cinto de segurança no core.

E há um prazo de IAM no horizonte que ninguém deveria ignorar: a partir de 7 de agosto de 2026, o OKE deixa de usar o service principal como fallback na autorização de Node Pools, exigindo o node pool resource principal de forma explícita. O runtime de workloads ativos não é afetado, mas quem usa custom images em outra tenancy ou chaves KMS próprias precisa ajustar as policies de endorse/admit agora — ou o scale-up vai falhar depois da data. É a mesma melodia secure-by-default tocando em todo provedor: o implícito permissivo está sendo trocado pelo explícito de menor privilégio, e o custo de não acompanhar é indisponibilidade.

Storage virou file system e o cache virou banco vetorial

A semana também redesenhou duas fronteiras antigas de arquitetura. A AWS lançou o Amazon S3 Files, que monta um bucket S3 como sistema de arquivos via NFS v4.1+, usando EFS por baixo do capô para entregar latência na ordem de ~1ms em dados ativos. Na prática, dissolve-se o velho trade-off entre a resiliência barata do object storage e a interatividade POSIX de um file system — instâncias EC2, containers (ECS/EKS) e funções Lambda passam a conversar direto com o bucket, sem pipeline de cópia entre camadas. Para ML training pipeline e cenários de agentic AI, eliminar essa replicação manual reduz overhead e risco de inconsistência.

Mas o S3 Files não é bala de prata, e o ângulo brasileiro é de FinOps. A precificação é ditada pela camada de alta performance e pelo tráfego de dados, não pelo preço de objeto frio do S3 — arquivos grandes e acessos recorrentes podem disparar sincronização e inflar a fatura. E ele não aposenta o FSx: HPC, processamento GPU intensivo via FSx for Lustre e integração com NetApp ONTAP seguem no terreno do FSx. A regra continua simples: colaboração via file system sobre dados no S3 vai de S3 Files; carga especializada continua no serviço especializado.

Na camada de cache, o destaque ressoa com quem foge de lock-in: o Valkey 8.1 chegou ao OCI Cache. Vale lembrar o que o Valkey é — o fork open source mantido pela comunidade após a mudança de licença do Redis, e não um derivado de vendor. A versão 8.1 entrega ganhos que batem direto no custo: Enhanced I/O Threading para mais throughput, otimização do hash table que reduz o footprint de memória (mais dados no mesmo cluster, sem upsize horizontal imediato) e iterator prefetching que deixa KEYS e fluxos de replicação até 3,5x mais rápidos. O salto estratégico, porém, são os módulos: JSON nativo e o Valkey-search, que traz busca de similaridade vetorial com latência sub-millisecond. Isso significa montar recomendação e RAG sem manter um cluster separado de outra engine — convergência que simplifica a topologia e corta custo.

A conta do agente: custo de log, segurança por padrão e a gravidade do dado

Se o tema da semana foi colocar IA para operar, o subtexto foi quem paga por isso. A Microsoft lançou o Sentinel Cost Estimator (em public preview), e ele endereça uma dor concreta de quem centraliza segurança no Sentinel: a imprevisibilidade do modelo por ingestão. Em vez da estimativa genérica do Pricing Calculator, a ferramenta detalha como cada meter contribui para a conta e permite simular decisões de arquitetura — por exemplo, manter 90 dias no Analytics tier e mandar o restante para o Sentinel data lake, equilibrando compliance (logs por anos) com custo. É a tradução de uma verdade que todo time de SecOps já sabe: em cloud, política de retenção é decisão de FinOps.

No mesmo período, o Google Cloud empurrou segurança para o padrão: o Security Command Center Standard passou a habilitar, por padrão, detecção de instâncias de Gemini inference desprotegidas, relatórios de violação de guardrails em LLMs e agentes, e quatro controles de AI posture — tudo no tier gratuito. A base subiu para mais de 44 verificações de configuração baseadas no Google Cloud Security Essentials, com varredura de vulnerabilidade agentless e DSPM para mapear o data estate em Vertex AI, BigQuery e Cloud Storage. É o mesmo movimento secure-by-default que vimos no OKE e no Kubernetes 1.35, agora na camada de postura: a proteção deixa de ser add-on e vira default — o que reduz superfície de ataque, mas exige que o time saiba o que está ligado.

E por baixo de tudo, a velha física do dado. A Equinix lembrou, ao analisar a migração de mainframes IBM Z para colocation no core banking, que modernizar não é só reescrever em microserviço: é resolver latency, interconexão e data gravity. O digital front end já é cloud-native, mas o core continua exigindo topologia de rede privilegiada e proximidade física. Para quem opera no Brasil, distante dos grandes data centers dos hiperescalares, isso é literal: cada milissegundo de rede a mais por iteração de agente vira processamento desperdiçado e fatura maior. A pergunta deixou de ser "tenho compute?" e passou a ser "onde está esse compute em relação ao meu dado — e quanto custa cada chamada que ele faz?".

O que levar desta semana

O agente em GA é real, e a oferta amadureceu de verdade nesta semana — AWS, Microsoft e até a camada de storage e cache se reposicionaram em torno dele. Mas o trabalho que ele cria é o de sempre, com a régua mais alta. Antes de plugar o primeiro agente em produção, três frentes apareceram nesta semana e precisam estar maduras: base segura e atualizada (cgroup v2 e nftables no 1.35, Ingress NGINX fora da borda, resource principal no OKE antes de agosto), custo sob medida (S3 Files e Sentinel cobram pela camada certa, Valkey da comunidade densifica memória, retenção é FinOps) e higiene de deprecation (o implícito permissivo está sendo trocado pelo explícito de menor privilégio em todo provedor). Quem operar essas frentes com disciplina vai colher autonomia. Quem só comprar a narrativa de GA vai descobrir, no primeiro incidente ou na primeira fatura, que agente em produção é, antes de tudo, infraestrutura bem operada.

Perguntas Frequentes

O AWS DevOps Agent e o Security Agent em GA já valem para produção?
Valem como ferramenta, não como piloto automático. A AWS coloca os dois em disponibilidade geral e fala em até 75% de redução no MTTR para o DevOps Agent e pentesting contínuo no shift-left para o Security Agent. O ganho é real, mas o pré-requisito também: o agente só remedia bem o que está bem instrumentado e com permissões de menor privilégio. Sem observabilidade e IAM em ordem, automatizar investigação é automatizar o caos.

Vou subir para o Kubernetes 1.35 no OKE. O que pode me derrubar?
Três itens. O 1.35 exige cgroup v2, então node pool em OL7 não sobe — o kubelet não inicia, e a migração para OL8 ou superior é o primeiro item do checklist. O modo IPVS no kube-proxy foi depreciado (a recomendação passa a ser nftables) e o Ingress NGINX foi aposentado pela comunidade. Some a isso o ciclo acelerado: o suporte ao 1.32 termina 30 dias após o lançamento do 1.35+.

O Amazon S3 Files substitui EFS e FSx?
Não substitui, complementa. O S3 Files monta um bucket como file system via NFS v4.1+ usando EFS por baixo, com latência na ordem de ~1ms para dados ativos, e é ideal para colaboração POSIX sobre dados que já vivem no S3. Mas HPC, GPU intensivo (FSx for Lustre) e integração com NetApp ONTAP continuam no terreno do FSx. E atenção ao FinOps: você paga pela camada de alta performance e pelo tráfego, não pelo preço de objeto frio do S3.

Por que o Valkey 8.1 no OCI Cache importa para quem evita lock-in?
Porque é o fork open source mantido pela comunidade, não um derivado de vendor. O 8.1 no OCI Cache traz Enhanced I/O Threading, otimização de hash table (menos memória, mais densidade no mesmo cluster) e iterator prefetching que acelera KEYS e replicação em até 3,5x. Mais relevante: os módulos JSON e Valkey-search adicionam busca vetorial sub-millisecond, viabilizando RAG sem manter um cluster separado de outra engine.

A mudança de autorização de Node Pool no OKE pode quebrar meu cluster?
Pode quebrar operações de ciclo de vida — provisionamento, scaling e upgrade — a partir de 7 de agosto de 2026, quando o OKE deixa de usar o service principal como fallback e passa a exigir o node pool resource principal. O runtime de workloads já ativos não é afetado. O risco está em quem usa custom images em outra tenancy ou KMS keys próprias: sem ajustar as policies de endorse/admit, o scale-up falha após a data limite.

Fontes: