14 de junho de 202611 min de leitura

Esta semana em cloud (08–14/jun): a conta do agente chega à infraestrutura

Redação Nuvem Online

Nuvem Online

Banner - Esta semana em cloud (08–14/jun): a conta do agente chega à infraestrutura

TL;DR: A semana de 8 a 14 de junho deixou claro que agentic AI virou problema de infraestrutura, não de demo. AWS lançou o Graviton5 (M9g) mirando agentes CPU-bound; Azure e Google correram para dar a agentes acesso seguro a dados de produção via MCP, identidade e confidential computing. No contracheque: aposentadorias no Azure, FinOps mais granular e o ataque Mini Shai-Hulud na supply chain. Conclusão: invista na base antes do hype.

Se você só leu os títulos esta semana, a impressão é a de sempre: mais um lote de modelos, mais um punhado de recursos em preview. Mas, lidos juntos, os anúncios contam uma história só — e ela não é sobre IA. É sobre a conta de infraestrutura que o agente traz junto. Os provedores pararam de vender a promessa do agente e começaram a vender o encanamento: a CPU que ele consome, o banco de dados que ele lê, a identidade que ele assume e o isolamento que ele exige. Para quem opera infra no Brasil, essa é a semana em que a IA agentic deixou de ser pauta do time de inovação e virou pauta do time de plataforma, FinOps e segurança.

Por que o lançamento do Graviton5 é, na verdade, um anúncio de IA?

A AWS tornou geralmente disponíveis as instâncias EC2 M9g e M9gd, as primeiras com o processador Graviton5. O número que vai circular é "até 25% mais performance computacional" sobre o Graviton4, com picos relatados de até 35% em web e inferência de ML. Mas o enquadramento da própria AWS é o que importa: o Graviton5 foi posicionado explicitamente para a fase em que "a IA passa de responder perguntas para executar ações". Raciocínio em tempo real, execução de código e orquestração multi-etapa são cargas CPU-bound — e a AWS está dizendo que a Meta já está implantando dezenas de milhões de cores Graviton justamente para sustentar agentes.

A leitura prática: parte do trabalho de agentes não precisa de GPU. Para um time brasileiro que está montando seu primeiro pipeline agentic, isso abre uma porta de custo — Arm é mais barato por core, e os benchmarks de early adopters (ClickHouse e Honeycomb falam em ~36% sem mudar código, HubSpot em queries MySQL até 60% mais rápidas) reforçam o caso — números desses clientes, não garantias oficiais da AWS. Vale também o aceno de segurança: o Nitro Isolation Engine é descrito como o primeiro hypervisor de nuvem formalmente verificado, um argumento concreto para quem opera multi-tenant sob regulação.

O porém é geográfico e merece destaque honesto: no lançamento, M9g e M9gd só existem em N. Virginia, Ohio, Oregon e Frankfurt. Nenhuma região brasileira. Para boa parte das cargas sensíveis a latência ou a soberania de dados, isso é um bloqueio, não um detalhe. A recomendação da Nuvem Online é a de sempre: trate o benchmark de terceiro como hipótese, valide no seu workload e só então leve para a mesa de Savings Plan.

Como os provedores estão tentando dar a agentes acesso seguro a dados de produção?

O gargalo seguinte do agente, depois da CPU, é o dado. E aqui a semana foi densa. A Microsoft tornou o SQL MCP Server geralmente disponível, oferecendo aos agentes uma camada de acesso a PostgreSQL e Cosmos DB via Model Context Protocol, com controle granular por tabela e coluna. No mesmo movimento, o Azure colocou em preview o MCP integrado no App Service, transformando REST APIs em servidores MCP sem código, e detalhou como produtizar e versionar servidores MCP no API Management. O recado dos fornecedores é claro: MCP virou a interface padrão entre agente e backend corporativo.

Isso é poderoso e perigoso na mesma medida. Um MCP server é, na prática, um caminho autorizado dos seus dados de produção para um modelo de linguagem. A própria documentação recomenda IAM com privilégio mínimo, auditoria via Azure Monitor e teste de penetração antes de produção — não porque seja burocracia, mas porque a alternativa é entregar uma query arbitrária à sua base sob LGPD. Para sustentar isso, a semana também trouxe as peças de identidade: logins de servidor com Microsoft Entra no Azure SQL Database (GA) e RBAC via Entra ID no Azure Managed Redis, ambos eliminando chaves compartilhadas estáticas em favor de tokens auditáveis. A direção é boa — menos segredos rotacionados na mão, mais trilha de auditoria —, mas exige planejar a migração, não só ligar o recurso.

Na ponta mais sofisticada, Google e Apple mostraram aonde isso chega: o Private Cloud Compute da Apple agora roda sobre Google Cloud usando confidential computing — Intel TDX, GPUs NVIDIA H100 com isolamento e chips Titan, tudo com atestação auditável. A mensagem para o mercado corporativo brasileiro é que confidential computing amadureceu o suficiente para inferência de missão crítica: dá para processar dado pessoal na nuvem com isolamento verificável em hardware. Ainda é nicho, mas é o teto de qualidade que define o padrão.

Quem está pagando essa conta — e como o FinOps fica mais granular?

Toda essa capacidade nova precisa caber no orçamento, e a semana trouxe duas frentes de "faxina" que sustentam a inovação. A primeira é FinOps mais fino. Um material excelente do blog de FinOps do Azure mostrou como sair da recomendação de "caixa-preta" de Savings Plans: o portal mostra um número único, mas a API Benefit Recommendations expõe a série horária de uso PAYG e níveis alternativos de commitment. A diferença é concreta — no exemplo real, comprometer US$ 16.359/hora dava 97,9% de cobertura e 44,1% de economia com wastage quase zero, enquanto comprometer um pouco mais (US$ 16.806/hora) fazia o desperdício saltar para US$ 315 na janela. Esse é o tipo de decisão que precisa ser defensável em reunião, não um chute arredondado para cima. Para times brasileiros, é o lembrete de que FinOps começa na fase "Inform": extraia o dado horário antes de assinar três anos de compromisso.

A segunda frente é a onda de aposentadorias do Azure, e ela foi grande nesta semana. Saíram avisos de descontinuação de contas GPv1 e Legacy Blob no Storage, fim de séries de VMs no Azure Batch (D-series, Dv2, Ls-series e correlatas), retirada das regras Inbound NAT v1 em Load Balancer para VMSS, deprecação do Azure Synapse Link para Cosmos DB NoSQL e fim do Azure VPN Client para Linux. Individualmente, nenhum quebra produção amanhã. Somados, são um recado: o provedor está consolidando portfólio, e a dívida técnica de quem adiou migração vira risco operacional com prazo. A ação correta não é entrar em pânico — é montar agora um inventário do que sua organização ainda roda nesses serviços e cronograma de migração, recalculando custos (GPv2, por exemplo, tem modelo de preço diferente).

A supply chain ainda é o elo mais fraco?

Enquanto a indústria discute agentes, uma análise publicada esta semana pela Microsoft relembrou que o problema mais antigo segue aberto. O ataque Mini Shai-Hulud — identificado no fim de abril — comprometeu quatro pacotes npm oficiais do ecossistema SAP CAP — incluindo @cap-js/postgres e a ferramenta de build mbt —, trocando-os por versões maliciosas que roubavam tokens do GitHub, secrets de AWS/Azure/GCP, kubeconfigs e chaves SSH, e então criavam um repositório público no GitHub da própria vítima para exfiltrar. O Defender for Endpoint detectou e neutralizou no mesmo dia, e o ângulo Microsoft destaca a correlação via Sentinel; mas o aprendizado independe de fornecedor: qualquer pipeline de CI/CD que puxa dependências sem trava está exposto ao mesmo padrão.

A resposta concreta veio, oportunamente, da CNCF, num guia do projeto Cilium sobre blindar CI/CD. As práticas são diretas e portáveis para qualquer time: pinar ações e imagens do GitHub Actions pelo SHA completo (não pela tag, que pode ser sobrescrita), versionar (vendoring) dependências Go para mover a decisão de confiança do build para o code review, e configurar o Renovate com minimumReleaseAge de alguns dias — porque é justamente nas primeiras horas que um pacote comprometido costuma ser descoberto e removido. No mesmo tom, GitHub e Azure DevOps avançaram em automação de correção com Copilot Autofix. Bom — desde que ninguém confunda "a IA corrige" com "não preciso mais pinar dependência".

O fechamento: base antes de hype

Se há uma frase para levar da semana, ela não veio de um keynote, mas de um painel da Equinix com líderes de infraestrutura da Fortune 500: eles estão empolgados com IA e, ao mesmo tempo, sobrecarregados e com medo de ficar para trás. A conclusão deles ecoa exatamente o que a Nuvem Online defende para o mercado brasileiro: a preparação para IA não é correr atrás de cada modelo novo, é construir uma base resiliente — rede com latência e throughput revistos, FinOps com visibilidade real de custo, identidade sem chaves compartilhadas e supply chain travada.

Os anúncios desta semana são, no fim, peças desse encanamento: CPU mais eficiente, acesso a dados governado, isolamento verificável, custo defensável. O agente é a aplicação; a infraestrutura é o que decide se ele entra em produção sem virar incidente. Quem investir na base agora vai colocar agentes para rodar com confiança. Quem só perseguir o hype vai descobrir a conta — de custo, de risco e de migração — no pior momento possível.

Perguntas Frequentes

O que conecta tantos anúncios de IA desta semana sob a ótica de quem opera infraestrutura?
O fio condutor é que agentic AI deixou de ser experimento e passou a consumir recursos de produção: CPU (Graviton5), acesso a bancos de dados (SQL MCP Server), identidade (Entra logins, RBAC no Redis) e isolamento de hardware (confidential computing). Cada anúncio resolve um gargalo para colocar agentes em produção — e cada um gera custo, risco e trabalho de governança que precisam ser planejados antes.

Vale a pena migrar workloads para Graviton5 (M9g) agora?
Para cargas CPU-bound e sensíveis a cache — bancos de dados, microserviços, inferência de ML em CPU, aplicações Java de alto throughput — sim, vale avaliar. A própria AWS cita até 25% mais performance computacional sobre o Graviton4; já os ganhos de 36% sem mudança de código são benchmarks de early adopters (ClickHouse e Honeycomb), não números oficiais da AWS. Mas há um porém para o Brasil: no lançamento, M9g e M9gd só estão em N. Virginia, Ohio, Oregon e Frankfurt. Sem região brasileira, a latência e a soberania de dados podem inviabilizar parte dos casos de uso. Teste em workload real antes de comprometer Savings Plan.

Dar acesso de banco de dados de produção a um agente de IA é seguro?
Só com camadas explícitas de controle. O SQL MCP Server (GA no Azure) oferece acesso granular a PostgreSQL e Cosmos DB, mas a segurança não vem de graça: depende de IAM com privilégio mínimo, auditoria via Azure Monitor, filtros por tabela/coluna e — idealmente — teste de penetração antes de produção. Tratar o MCP server como middleware confiável sem essas barreiras é abrir um caminho direto aos seus dados sensíveis sob LGPD.

Quais aposentadorias do Azure desta semana exigem ação imediata?
A descontinuação de contas GPv1 e Legacy Blob no Azure Storage é a mais urgente para quem ainda roda esses modelos — a migração para GPv2 envolve revisar scripts, IAM e custos. Também saíram avisos sobre fim de séries de VMs no Azure Batch, retirada das Inbound NAT Rules v1 em Load Balancer e do Azure VPN Client para Linux. Nenhuma quebra amanhã, mas todas pedem um inventário e um plano de migração agora.

O ataque Mini Shai-Hulud muda algo para quem não usa SAP?
Muda. O alvo foi o ecossistema SAP CAP, mas o vetor foi npm — pacotes oficiais trocados por gêmeos maliciosos que roubavam tokens de GitHub, secrets de cloud e kubeconfigs. Qualquer pipeline de CI/CD que puxa dependências sem pinning está exposto ao mesmo padrão. A lição da semana, reforçada pelo guia do Cilium na CNCF, é prática: pinar ações e imagens por SHA, versionar dependências e segurar atualizações recém-publicadas por alguns dias.


Fontes:

Gostou? Compartilhe:
Precisa de ajuda?Fale com nossos especialistas 👋
Avatar Walcew - Headset